<
sb0>
hm, why is struct sched_ctx so big...
<
wpwrak>
sb0: it has a bunch of pointers and integers for each instruction
<
wpwrak>
sb0: on 64 bit, it's even almost half a megabyte :)
<
wpwrak>
on 64 bit, each instruction has a 216 bytes data structure. and there are up to 2048 instructions ...
<
wpwrak>
(FPVM_MAXCODELEN)
<
wpwrak>
the 216 bytes structure is  struct insn
<
sb0>
well, currently FN is only using about 25MB out of the 128MB of the M1, so we can bloat it a little :-)
<
wpwrak>
ah yes, a bigger stack helps :)
<
wpwrak>
so the things in malloc.c don't work in the demo firmware ?
<
sb0>
you can use malloc() if you want... but try to avoid the non-reentrant global variable for the state
<
wpwrak>
ah, so you expect to use this from threads
<
sb0>
using the stack is fine... if you have working code with the stack atm, don't change it
<
wpwrak>
yeah, right now i have it with the stack. need to get rid of the global "sc", though
<
sb0>
struct vm_reg regs[frag->nbindings-frag->next_sur]; ? :)
<
wpwrak>
mmh ? dynamic arrays. available since C99 :)
<
wpwrak>
btw, i only tested with FN, not with the demo. still need to work on the prerequisites of it.
<
wpwrak>
and now, off to the next barbecue :)