Therefore these changes were necessary:
Tossed:
- push var ... use .arg or .return or save
- pop var ... .param, .result, restore
- ret (native)
Changed:
.sub
...
ret
is now
.sub
...
.end
Other resolved name clashes:
- if var, label
- unless var, label
- new var, .Type
- defined var, var
- clone var, var
Languages involved:
- perl6 (P6C/IMCC)
- cola
these are adapted accordingly
Further the commit contains one leftover piece from #18474 and the
proposed fix WRT the type clash on default action.
leo
Is there any other way to feed imcc code other than via writing to a
file and running it ?...
My work needs a lot of string substitutions to work with the new IMCC ...
Dan was saying something like a C interface to IMCC which bypasses the
parser and lexer phases was possible ?
(thankfully all I needed to fix could be done with a couple of regexps)
> Languages involved:
> - perl6 (P6C/IMCC)
> - cola
> these are adapted accordingly
The problem grows as the number of languages supported increases ...
I really would like something like this (shameless snitch)
IMCC_Var *tempVar ;
IMCC_Expr *expr;
tempVar = IMCC_GenTempVar(code,type);
expr = IMCC_GenAdd(code,myParam1,myParam2);
IMCC_GenAssign(code,tempVar,expr);
IMCC_GenIf(code,tempVar,thenStmt);
IMCC_ReleaseTempVar(code,tempVar);
IMCC_GenCode(code,fp);
I know this is a lot more complicated than fprintf , but IMHO such an
abstraction is worth it ... (any similarity to treecc's _create calls are
purely intentional ... :-)
Gopal
--
The difference between insanity and genius is measured by success
> If memory serves me right, Leopold Toetsch wrote:
>
> Is there any other way to feed imcc code other than via writing to a
> file and running it ?...
Not currently.
> Dan was saying something like a C interface to IMCC which bypasses the
> parser and lexer phases was possible ?
Yes. But there is nothing defined now.
The 2 basic structures of a parsed code stream in imcc are:
- struct _Instruction
- struct SymReg
along with some flags.
And there is (almost) only one function iANY() which takes a **SymReg
and an opcode to generate the instruction stream. So it probably
wouldn't be to hard to build the interface here.
> The problem grows as the number of languages supported increases ...
Yes, but I think, that incompatible changes shouldn't be necessary any
more - sorry for breaking things.
> I really would like something like this (shameless snitch)
>
> IMCC_Var *tempVar ;
> IMCC_Expr *expr;
> tempVar = IMCC_GenTempVar(code,type);
SymReg *r = mk_ident(char *name, char type)
> expr = IMCC_GenAdd(code,myParam1,myParam2);
iANY("add", R3(r0,r1,r2))
> IMCC_GenAssign(code,tempVar,expr);
iANY("set", R2(r, r0))
> IMCC_GenIf(code,tempVar,thenStmt);
iANY("if", R2(r, thenr))
> IMCC_ReleaseTempVar(code,tempVar);
namespace patch
> IMCC_GenCode(code,fp);
above iANY()s append the generated instructions to the double linked
instruction list.
> Gopal
leo
No problemo ... I just hate working on the same things again ...
> SymReg *r = mk_ident(char *name, char type)
....
> iANY("add", R3(r0,r1,r2))
Thanks, a shared library implementation of such a thing is what I'm
looking for ... I'll take a look at doing that ...
>>iANY("add", R3(r0,r1,r2))
Better use INS (the public interface of above functions)
> Thanks, a shared library implementation of such a thing is what I'm
> looking for ... I'll take a look at doing that ...
WOuld it help to split imcc.y into main/parser/parser_utils or are you
doing this anyway?
> Gopal
leo
yes pushing some code from imcc.y into a seperate file is what I had in
mind ... But have not got to that yet ...
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 ?
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)
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.... :-)
> 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