Hi,
Please disregard the previous mail. Hit the wrong shortcut key!!
I have been working on trying to make reenterant and/or thread-safe. There
are couple of things that have come up which might make it difficult to make
the existing implementation thread-safe/re-entrant.
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.
Audrey Tang recommended using re2c as an alternative to flex (Lemon Parser
replacement for Yacc). re2c generates reenterant/thread-safe parsers. I also
spend some time reading up on the paper published with re2c. Initial
indicators are that it produces scanners that run faster than flex.
So here are some options that I have come up with that we have. I would like
you guys and especially Allison and Chip to provide some feedback on how to
proceed further.
1st Option: Hack it and patch it to death !!!
-------------------------------------------------------
Since flex is not generating reeentrant 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.
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
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.
These are just some of my thoughts.
Please let me know what you guys think or do you have other options in mind.
Whatever it is we need to come to consensus to make the IMCC reenterany a
reality.
As usual please provide feedback.
--
Thanks,
Vishal
On 7/16/06, Vishal Soni <[EMAIL PROTECTED]> wrote:
Hi,
I have been working on trying to make reenterant and/or thread-safe. There
are couple of things that have come up which might make it difficult to make
the existing implemention thread-safe/re-entrant.
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 limation 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.
Audrey Tang reccomended using re2c as an alternative to flex (Lemon Parser
replacemet for Yacc). re2c generates reenterant/thread-safe parsers. I also
spend some time reading up on the paper published with re2c. Initial
indicators are that it produces scanners that run faster than flex.
So here are some options that I have come up with that we have. I would
like you guys and especially Allison and Chip to provide some feedback on
how to proceed further.
1st Option: Hack it and patch it to death !!!
-------------------------------------------------------
Since flex is not generating re-eentrant 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
2nd: Inaction is the best action !!!
-------------------------------------------
3rd Option: Back to drawing board !!!
------------------------------------------------
--
Thanks,
Vishal
--
Thanks,
Vishal
