<cde> hai
<lekernel> hi
<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> ok
<sb0> well, currently FN is only using about 25MB out of the 128MB of the M1, so we can bloat it a little :-)
<wpwrak> hehe :)
<wpwrak> ah yes, a bigger stack helps :)
<wpwrak> so the things in malloc.c don't work in the demo firmware ?
<sb0> they work
<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 :)