On Sunday 19 October 2008 14:02:58 Klaas-Jan Stol wrote: > when running code as this: > .sub main :immediate > load_bytecode "foo.pir" > .end > > (assuming you have a file 'foo.pir'), IMCC can't handle this. > > This is because in pbc.c, a global structure called 'globals' is used to > allow the different functions to share access to some data (in particular, > the code segment stuff).
It's actually IMCC_INFO(interp)->ghash. In particular, constant folding assigns register numbers to constant PMCs and STRINGs as addresses into the constant table. That's good. Those constants are still around for code loaded from :immediate subs. That's also good. The problem is that the SymReg structures which represent those constants keep their assigned register numbers. That's bad, because they only get added to the bytecode if they don't already have register numbers representing indices into the constant table. Thus, they don't get assigned. This is a problem when handling parameters or return values. The PCC section of IMCC creates a FixedIntegerArray to handle these arguments, and that's a constant PMC in the bytecode. If this doesn't get created somehow (in the case I just described), other parts of the PCC-handling code expect it's there and throw an assertion if it isn't. The right fix is to walk IMCC_INFO(interp)->ghash and reset the color of all constant SymRegs to -1 before running any pragma subs (e_pbc_end_sub() in compilers/imcc/pbc.c), but r32633 is a quicker workaround for now, to get this closed. I'll work on the prettier fix in the next couple of days, unless someone beats me to it. -- c
