[CVS ci] imcc syntax change
Leopold Toetsch
prohibit the mix of both flavors. Additionally imcc used "ret" to end
subroutine parsing, which didn't allow multiple return statements in
one sub.
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
Gopal V
> Therefore these changes were necessary:
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
Leopold Toetsch
> 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
Gopal V
> Yes, but I think, that incompatible changes shouldn't be necessary any
> more - sorry for breaking things.
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 ...
Leopold Toetsch
>>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
Gopal V
> 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 ...
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.... :-)
Leopold Toetsch
> 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