<daveshah>
the others should be totally inconsequentia
<daveshah>
*inconsequential
<whitequark>
then build with -DUSE_C_EMBED=ON
<whitequark>
then $ wasmtime run nextpnr-ecp5.wasm --dir . --mapdir /share/nextpnr/ecp5::build-ecp5-wasi/ecp5/chipdbs --
<whitequark>
where `build-ecp5-wasi` is just whatever build directory you have where the chipdbs are located
<whitequark>
the bba-related cmake code makes me very sad and i will burn it later
<whitequark>
with its ashes fertilizing something better
<whitequark>
to answer your question directly -DEXTERNAL_CHIPDB_ROOT=/share/nextpnr
<daveshah>
yep, working now, thanks
<daveshah>
maybe 1s slower than native but effectively the same
<daveshah>
nice
<whitequark>
on multiple runs?
<daveshah>
yes
<daveshah>
oh, nvm, I think it was something in the background
<daveshah>
now it is identical
<whitequark>
cool, so the same as I observe
<daveshah>
yep
<daveshah>
whitequark: does wasm use a 32bit pointer type or am I reading something out of date
<daveshah>
nextpnr is probably memory bandwidth/latency constrained so perhaps 32 bit pointers would explain the good performance
<whitequark>
yep
<whitequark>
there's a wasm64 proposal but it's vaporware for now i think
<whitequark>
fun fact
<whitequark>
if i compile the wasm file through wasm2c it'll probably be "faster than native" :p
<whitequark>
daveshah: the weirdest part is the threads
<whitequark>
which aren't apparently doing anything in nextpnr
<awygle>
Damn nice
<daveshah>
whitequark: they only speed up a small part of HeAP in the default settings
<daveshah>
router2 benefits from threads but it has other issues for ECP5 so isn't enabled at the moment
<whitequark>
ah
Getorix has quit [Ping timeout: 260 seconds]
Getorix has joined #glasgow
Getorix has quit [Ping timeout: 240 seconds]
Stormwind_mobile has quit [Ping timeout: 256 seconds]
Getorix has joined #glasgow
Stormwind_mobile has joined #glasgow
Getorix has quit [Ping timeout: 246 seconds]
<whitequark>
daveshah: about 15% faster than native with wavm
Getorix has joined #glasgow
Stephie has quit [Ping timeout: 256 seconds]
<gruetzkopf>
ooh..kay
Stephie has joined #glasgow
<awygle>
is there a way to use 32 bit pointers on 64 bit x86-64
<awygle>
I knew this once but forget now
<ZirconiumX>
x32
<TD-Linux>
it is pretty cursed and therefore inevitable someone on here is going to try it
<sorear>
the ISA is not an obstacle here, you can just use 32-bit instructions to load and store addresses
<sorear>
but the ABI is a can of worms
<sorear>
if you want to use 32-bit pointers _exclusively_ in a single process, that's x32
<sorear>
if you have a VM that reinvents the wheel on pointer handling and doesn't share data structures with anything else, you can make that work too, although it's a lot of work and I've only seen a few examples
<sorear>
depending on what the code does you could rewrite it to use array indices
<awygle>
yeah i was thinking array indices or mmap() a huge swath of memory and roll your own 32-bit pointers as offsets from one 64-bit base pointer
<awygle>
that x32 is not what x86 actually is annoys me deeply
<awygle>
stupid neologisms lol
<ZirconiumX>
See also: IA32 vs IA64
<awygle>
surely wasm isn't limited to 4 gigs of memory per process tho? does it have segments or something?
<sorear>
can we agree that IA32e is the worst of the group
<sorear>
awygle: there are "wasm32" and "wasm64" targets
<sorear>
wasm32 is limited to 4 gigs of memory
<sorear>
nm that was mentioned already
<awygle>
do the wasm64 targets use 64-bit pointers? does wasmtime support wasm64?
<sorear>
called "vaporware for now I think" 3h ago
<awygle>
o
<awygle>
i missed that oops
Getorix has quit [Ping timeout: 260 seconds]
Getorix has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 246 seconds]