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 separa
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 ...
Was curious about the following lines
Gopal V wrote:
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
If memory serves me right, Leopold Toetsch wrote:
> 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,r
Gopal V wrote:
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
If memory serves me right, Leopold Toetsch wrote:
> 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 int
Name clashes between parrots PASM language and imccs PIR syntax did
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 .retu