<dxld>
povik: super excited to see such a small implementation get so close to what abc can do :D
derekn has joined #yosys
<dxld>
I'm not familiar with the details here, could you shed some light on whether toymap would completely replace abc or are there other areas in yosys where it's still used?
<dxld>
(I want to get rid of abc because it's such a huge unmaintainable pile of complexity; I've had the displeasure of trying to figure out how to get it working on all the "weird" architectures in Debian ;)
<povik>
i mean, i have no idea what 98 % of abc commands do
<povik>
though i guess most people ever invoke abc from yosys for techmapping, which is in scope for toymap (being a toy though!)
<povik>
you are free to run abc from yosys with custom abc scripts
<Adrien[m]>
corecode: at least Interesting points of potential behaviour of tools to take care of, good for not getting trapped in trivial issues because of inexperience with these tools
<povik>
so in a way nothing can ever replace it...
Wolfvak has quit [Remote host closed the connection]
whitequark[cis] has joined #yosys
<whitequark[cis]>
<dxld> "(I want to get rid of abc..." <- abc basically doesn't work on 64-bit platforms
<whitequark[cis]>
that's a load bearing "basically"; the actual issue is that it's making assumptions incompatible with ASLR on macOS
<whitequark[cis]>
and there's no apparent way to fix that
<whitequark[cis]>
to clarify, the assumptions it's making are incorrect everywhere (as far as i know) but on macOS it happens to randomly segfault and the only solution for that we have is "run the thing again"
<dxld>
povik: I'm not too worried about custom abc scripts, nobody understands abc so nobody is likely to use those :]
<whitequark[cis]>
anyway, replacing abc wouldn't mean literally making an API-compatible application; it would mean building something much simpler and smaller that just does LUT mapping for FPGAs
<dxld>
whitequark[cis]: sounds like a job for qemu-user to me honestly :P
<whitequark[cis]>
and maybe sequential synthesis eventually
<whitequark[cis]>
dxld: one potential solution we've seriously thought about is building it for wasm, then using wasm2c to turn it back to C, then using that in yosys
<whitequark[cis]>
this sounds borderline absurd but you get almost the full performance
<whitequark[cis]>
it's basically an automated way to transform C code to safe(ish) C code :D
xiretza[cis] has joined #yosys
<xiretza[cis]>
I'm surprised that doesn't just make it crash all the time rather than just sometimes
<dxld>
you do know what qemu-user lets you do right? it's literally a drop-in way to run i386 (or any qemu supported arch) executables on any other architecture
<whitequark[cis]>
i mean i don't think there would be obstacles to shipping that except someone has to add it to yosys
<dxld>
as long as it's an executable (and abc is) you're golden
<whitequark[cis]>
dxld: yeah i'm familiar
<whitequark[cis]>
and if it's not an executable you can write a tiny main() that calls the function you want
<dxld>
well yeah, but if yosys, say, called abc as a library you'd have to compile all of yosys as 32bit which obviously sucks much more than just having it confined to abc
<whitequark[cis]>
it doesn't call it as a library because of the random memory corruption that used to happen when it did
<dxld>
haha :)
<whitequark[cis]>
the support is there, you can enable it via an option
<whitequark[cis]>
yowasp-yosys does that
<whitequark[cis]>
because wasm is 32-bit (the compiler prefix i'm using anyway) it doesn't tickle those bugs at least
<whitequark[cis]>
though... i tried building abc for wasm not as a library within yosys (as a standalone executable) and it segfaults with a completely inscrutable backtrace
<whitequark[cis]>
i tried to make this work twice and decided to just implement what i want in some other way
<dxld>
anyway point is, povik, please keep doing what you're doing <3
<whitequark[cis]>
(i wanted output redirection. i ended up using some really cursed freopen tricks. but that got it done in a day)
<povik>
dxld: i am happy you like it! though i can't promise it will ever amount to anything more serious
<whitequark[cis]>
I second dxld
<povik>
ok, that message applies to you too then :P
<dxld>
famous last words "just a hobby, won't be big and professional like gnu" :D
Wolfvak has joined #yosys
<jix>
besides techmapping, abc is also used for formal verification from SBY, in particular the pdr command which implements pdr/ic3 (two names for the same algorithm)
bjorkintosh has joined #yosys
bjorkintosh has quit [Changing host]
bjorkintosh has joined #yosys
bjorkintosh has quit [Client Quit]
<somlo>
whitequark: not to mention that abc is broken on BE platforms (not sure if maybe that's what you meant when you said "64-bit platforms" earlier)
<whitequark[cis]>
no, that's a separate issue
<whitequark[cis]>
but might be related
V has quit [Ping timeout: 240 seconds]
<jix>
IIRC the endianness issue was it casting pointers to access the same data as differently sized int types, with the cast and the accesses not being close to each other, so really hard to even enumerate the places where that issue is present
<jix>
but that shouldn't be affected by ASLR
<dxld>
I wonder if there's a ASAN/UBSAN mode for detecting misaligned accesses?
<dxld>
and if not why not :)
<dxld>
uuh ubsan does actually seem to support that
<jix>
I don't think the accesses were misaligned, or at least even if they are not, the code would still be buggy