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.
> On the gripping hand, if you'd like to experiment with putting IMCC
> into libparrot, bison's "-p prefix" option seems relevant: "Rename the
> external symbols used in the parser so that they start with prefix
> instead of yy." Maybe "-p Parrot_imcc_"?
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.
-Melvin
