Vishal Soni wrote:
The current implementation is implemented using Flex and YACC. Flex
implementation has limitations in C mode. The C lexer generated by flex
cannot be reentrant/threadsafe. Flex generates thread-safe parsers only in
C++ mode. This limition of flex will defeat the whole effort of removing
global variables from IMCC. In my opinion if we cannot get global variable
free code from flex there is no sense in proceeding with cleaning up the
other global variables.
This is unfortunate, but not entirely surprising.
1st Option: Hack it and patch it to death !!!
-------------------------------------------------------
Since flex is not generating reentrant code, this option will get rid of
flex altogether and replace it with re2c. This would require significant
reworking on the code. So the plan of action would be as follows:
a. Remove flex and implement re2c
b. Remove static and global variables
Apart from this we also need to refactor the code to get rid of arrays to a
hash table implementation for macros.
All in all this would be over hauling lot of code.
The cost/benefit balance on this solution is not good. A lot of people
are depending on IMCC now, and a refactor of that magnitude will throw
several important projects on Parrot into a dead stall.
So, my answer is: No.
2nd: Inaction is the best action !!!
-------------------------------------------
Lets not do anything a leave the code as it is. Just say IMCC is not
re-entrant/thread-safe and leave it there We will address this issue in
future. I highly doubt it this is the route we want to take
For the short-term, this is the route we want to take. A new PIR/PASM
compiler isn't absolutely necessary for a 1.0 release. IMCC doesn't
really need to be reentrant, it just needs to produce bytecode.
So, my answer is: Yes, but...
3rd Option: Back to drawing board !!!
------------------------------------------------
This option would require a complete re-write of IMCC ( possibly could call
it PIRC). The cons of this approach is we will have to re-implement the
whole IMCC again. The programming languages will have to live with IMCC
limitations as long as the new version is ready.
The pros of this approach are
a. A clean implementation rather than a prototypish implementation
b. Make PIR compiler production release ready. The way the compiler sits
right now it is not a good release candidate.
c. Structure the code in a way that is easy to maintain and extend.
The 3rd option is lot of work but might be a good option in the long run.
IMCC was originally implemented as a separate compiler. After a while,
we found it to be so much better than the existing assembler that we
made it the primary way of producing bytecode. It's okay to repeat the
cycle by experimenting with a new compiler that produces bytecode, and
later decide if we want to replace IMCC with it. This doesn't interfere
with IMCC's development.
So, my answer is: Yes, but...
re2c and lemon aren't enough of an improvement over flex and bison to be
worth the pain of rewriting IMCC from scratch. If we do create a new way
of producing bytecode (and it's a safe bet that we will at some point),
I would lean toward using our own tools.
- Patrick is already looking into implementing a version of PGE in C.
This will be an infinitely better parser than any existing alternatives,
so it's worth waiting for.
- We already want an OST(opcode syntax tree)-to-bytecode compiler that
bypasses PIR for the compiler tools. That same compiler could be used to
implement PIR (combined with a lightweight version of TGE in C).
- IMCC is not a straight translator, it also performs optimizations.
These should be implemented in a modular way, with a standard interface,
so that developers can swap in new and improved optimizers as we go
along. The best place to hook them is probably off the OST-to-bytecode
compiler.
This approach does mean that the tools to start an IMCC rewrite aren't
available yet. It's a long-term solution (possibly post-1.0), so we can
afford to take a long-term view.
Allison
