<conventia[m]>
I'm trying to migrate the old sync process tests over to testbenches and I get some failures. Does the sync process mechanism result in a different flow of clock cycles than the testbench one?
<whitequark[cis]>
yes
<whitequark[cis]>
all results are advanced by one cycle (i.e. can be read earlier now)
<conventia[m]>
Are there docs I can read that explain the difference? I'm not sure what the easiest way is to read the old version of the docs.
<whitequark[cis]>
big part of why it was done
<whitequark[cis]>
oh, there are no docs for the old method
<conventia[m]>
Did sync_process advance by multiple cycles at a time?
<whitequark[cis]>
no
<whitequark[cis]>
it basically included a pipeline stage
<whitequark[cis]>
(whether you wanted it or not)
<conventia[m]>
So, other than being you, is there a good way to figure out why a test is breaking when switching from one to the other?
<conventia[m]>
(I'm just trying to remove deprecating warnings.)
redstarcomrade has quit [Read error: Connection reset by peer]
zyp[m] has joined #glasgow
<zyp[m]>
studying the original code until you understand the intent of it could help
<galibert[m]>
I classify webasm and js in the same category of "language running in the browser"
<galibert[m]>
initially webasm was asm.js after all :-)
<whitequark[cis]>
that shows that you don't know much about browser architecture, yes
<galibert[m]>
I haven't kept updated for a while, that is true
<galibert[m]>
so many things to do, so little time
<whitequark[cis]>
wasm isn't even a particularly useful browser target on its own
<whitequark[cis]>
(it's a web architecture, in the broad sense that it's been designed to run untrusted applications safely and quickly, but it has no DOM integration at all to this day)
<whitequark[cis]>
we don't even have wasm gc intgration yet! (there's an experimental proposal that's getting there, but it's still used in very limited wayss)
<galibert[m]>
I suspect the lack of DOM integration is annoying everybody too
<whitequark[cis]>
s/wayss/ways/
redstarcomrade has quit [Read error: Connection reset by peer]
<whitequark[cis]>
dunno, the only thing i ever wanted DOM integration for is webusb
<whitequark[cis]>
most of my wasm deployment doesn't even have a javascript interpreter anywhere
<galibert[m]>
Doesn't it mean that you can't avoid js if you want to run webasm in a browser?
<whitequark[cis]>
that's correct
<whitequark[cis]>
but you end up with relatively minimal amounts of setup and glue code at the FFI boundary
<whitequark[cis]>
in general you can't avoid running <some other code> when using wasm in the same sense that you can't avoid using syscalls when writing usermode code
<whitequark[cis]>
except these are called hostcalls for wasm
<galibert[m]>
you don't have to write the kernel support for the syscalls though :-)
<whitequark[cis]>
there's WASI, which implements a tiny POSIX subset as Wasm hostcalls
<whitequark[cis]>
i deploy the FPGA toolchain as WASI builds
<whitequark[cis]>
there are engines (wasmtime, node) which natively support WASI, although in the browser i was unhappy with the existing implementation of FS virtualization and wrote my own
<galibert[m]>
syscalls and filesystem :-P
<whitequark[cis]>
hm?
<galibert[m]>
that you have to write yourself :-)
<whitequark[cis]>
that makes no sense
<whitequark[cis]>
the filesystem implementation is a set of syscalls
<galibert[m]>
forget it, failed joke
<whitequark[cis]>
a good mental model for webassembly is that it's a CPU architecture just like the usermode subset of MIPS or usermode subset of x86
<whitequark[cis]>
if you don't think too hard about why it's the way it is, there's nothing "web" about it, it's just a weird ISA and ABI
<conventia[m]>
Hopefully my changes to the tests make sense to someone who understands the old sync process. 🙂
<whitequark[cis]>
oh yeah let me look
<conventia[m]>
No rush.
<conventia[m]>
I'll try to update them to use async after I know they're ok.
<whitequark[cis]>
at a glance that doesn't quite look right
<whitequark[cis]>
but i'm too tired to review them in depth
<conventia[m]>
I just made changes until they passed without changing the code under test. That's not a particularly principled approach, but it's the best I can do without understanding it all. Take your time.
anubis has quit [Remote host closed the connection]
anubis has joined #glasgow
<AhmedCharles[m]>
I was able to read a 25x flash from webusb, though it gave an error after that. glasgow.support.usb.ErrorStall: Failed to execute 'selectAlternateInterface' on 'USBDevice': Unable to set device interface. And apparently, the console doesn't like ctrl-C...
<whitequark[cis]>
doesn't like how?
<AhmedCharles[m]>
I can't seem to get it to run commands anymore.
<whitequark[cis]>
odd. and the error is strange too
<whitequark[cis]>
debugging those issues is pretty annoying given how many moving parts are involved
<whitequark[cis]>
also webusb is relatively fresh still
<AhmedCharles[m]>
I guess I have ctrl-C muscle memory. It code be due to using Edge (which is like Chrome, but not Chrome).
<AhmedCharles[m]>
s/code/could/
<whitequark[cis]>
oh yes, that could be the cause
<whitequark[cis]>
try chrome
<AhmedCharles[m]>
Oh, simple usability question, is there a way to store pin configurations in a file so that you don't need to put them on the command line every time?
<whitequark[cis]>
you could put it in a shell variable and then do like $pins
<whitequark[cis]>
but not in the web port. there i recommend copy&paste until we get real.history
<whitequark[cis]>
s/./ /
<AhmedCharles[m]>
I'm definitely not using the web port long term, it was just a cool novelty to try.
<whitequark[cis]>
i might use it on other computers and such