Gopal V wrote:
If memory serves me right, Leopold Toetsch wrote:WOuld it help to split imcc.y into main/parser/parser_utils or are you doing this anyway?yes pushing some code from imcc.y into a seperate file is what I had in
mind ... But have not got to that yet ...
Ok, than I'll separate it.
Was curious about the following lines and sort of wasted that whole evening ...
|| return iANY(name, fmt, regs, 0);
if emit (last param) is zero when called from INS ... when does the code
actually get emitted ?
Yuu have to insert it somewhere into the instruction stream by either emitb() or insert_ins() or so. I could make a shortcut for emitb(INS()).
So can I just do this to emit *.pbc ? emit_open(...) ...... emit_close() to do my stuff ? (and how to do that without the interpreter interfering)
Yes, emit_open just defines the emitter type (pasm file or pbc stuff).
The emit_pbc (e_pbc_emit) stuff generates a unpacked packfile for the global interpreter ready for running or spitting out a PBC file to disc.
When you want to use this, have a look at imcc.y:
sub: sub_start statements ESUB {
allocate();
emit_flush();
clear_tables();
The instructions come from iANY or better from emitb(INS(...)). You would need only to fill the SymRegs with the param information a la mk_ident or mk_symreg ...
So I sort of concluded to leave the output to direct fprintf's . Roughing
it out with the changes in imcc seem easier than programming for this interface.... :-)
For a first try going via file is of course simpler and easier to debug too. You can always change this later, given some modularity is in place.
Gopal
leo
