MrJoltCola wrote: > At 04:08 PM 3/28/2005, Ron Blaschke wrote: >> > On the one hand, IMCC doesn't really help you _run_ code, so I'm not >> > inclined to see it part of libparrot. On the other hand, I haven't >> > grokked the entire code base organization, so I could be Greatly >> > Missing The Point. >>I have left things as-is while getting linkage correctly. That is, >>most of IMCC is currently part of libparrot (only F<main.c> is not). >>In the beginning, I thought IMCC is part of the parrot executable, but >>reality left me puzzled, so I thought I'll leave the decision to you.
> IMCC is integral for Parrot in order to eval/compile new PASM and PIR at > runtime. If you ONLY want to support precompiled bytecodes you > can get by without it but for quite some time now IMCC _is_ the > Parrot front end.
> It might make sense to provide separate libparrotvm without dynamic eval > capability so you can leave out the actual compiler and register allocator > and have it loaded on demand (libparrotimcc or some such). > This would help save memory in the default case.
So, I guess the yacc stuff - yylex, yyparse, yyin and such - should be hidden somewhere inside IMCC, behind an interface, which would then be part of libparrot interface?
Yes, I think so. Of course I always wanted to write a pure parrot form of the
whole IMCC compiler, but nowadays Parrot is so reliant on C that it seems
a pointless exercise to go "Pure Parrot" until the whole community gets on-board.
-Melvin
