<cr1901>
I'll spin up a container at home and see if I can dup. At the very least, a Windoze build of yosys with the most recent commit as of 12 hours ago doesn't change the LC count from what I expect (1276)
<cr1901>
Okay, I can thankfully duplicate in a container. And thankfully outside of the container I get the expected 1276 LUT count
<cr1901>
now to figure out the differences between oss-cad-suite and "the yosys I compile once per week"
<cr1901>
(Obligatory I should probably just switch to yowasp, but I still need a bunch of external tools so it'll be a weird hybrid of tools needed)
<cr1901>
So same yosys, same ABC, same OS, gives different results
<cr1901>
lofty: I have some logs if you're curious. I guess abc9 is using a different random seed/algorithm when compiled for the OSS Cad Suite versus mine. 1/2
<cr1901>
The logs are virtually identical until abc9 runs
<cr1901>
at which point the abc9 I'm using in CI starts performing a bit worse than the one I have locally
<lofty>
Okay, I do see one big change between the two
<lofty>
good is compiled with clang; bad is compiled with gcc
<cr1901>
Reverse, but yes
<lofty>
and, well, Yosys is known to have some small variances between compilers
<cr1901>
I was afraid of that.
<lofty>
Or perhaps ABC does, but either way
<cr1901>
In other words, I'm running too close to the ragged edge of disaster
* lofty
smiles thinly
<lofty>
it could be worse
<lofty>
I could be pulling out the very last idea I have to optimise things >.>
<cr1901>
There might be some low-hanging fruit left I can do, but I'm pretty set on locking the core as-is for now. I'm tired and want a break from working on it.
<cr1901>
I'll probably allow "continue-on-failure" in CI for now
<lofty>
I completely understand
<cr1901>
Yea, I am _not_ out of ideas. I am out of fuel :P.
<cr1901>
I am _not_ out of ideas on my end*
<lofty>
I guess I have a few tricks left, maybe
<lofty>
(maybe)
<cr1901>
(Really, a big problem is RV's insistence that illegal opcodes have to be handled. There's SO GD many of them
<lofty>
isn't that why SERV *doesn't* handle them? :p
<cr1901>
Yea, I actually keep forgetting that SERV doesn't handle them. But by the time I first realized that, I'd already put all the illegal crap in the decoder and didn't feel like ripping it out lol
<lofty>
It's a little amusing to me that you're not the only microcoded RV core that I know of
<cr1901>
Someone on a retro discord I passively watch is doing one in TTL chips IIRC
<cr1901>
lofty: >Figure out why clang and gcc abc are diverging, if possible. <-- Just on a lark, is there anything I can do here, like run abc with debug options to see into it's internal state a bit?
<lofty>
cr1901: truthfully, I don't know, but there's `abc9.debug` as a scratchpad bool, which should preserve the intermediate files going to and from ABC
<lofty>
checking if those match up seems like a good start
<lofty>
beware that ABC is a *mess* of undefined behaviour though
<cr1901>
Is that equivalent to -nocleanup or should it be used in conjunction?
<cr1901>
And also: Basically, will I be wasting Alan's time if I open an issue after doing some debugging?
<lofty>
cr1901: abc9.debug implies -nocleanup
<lofty>
and no, I don't think you'll be wasting Alan's time
<Myrl-saki>
How do I use CSDECODE? Does it count as like tristate, or?
<Myrl-saki>
(For reading, specifically)
<Myrl-saki>
(I want to get rid of the output multiplexer, because that seems to be part of my critical path.)