4th Option: fix flex. ;) -J
-- On Sun, Jul 16, 2006 at 10:57:07PM -0500, Vishal Soni wrote: > 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
pgpbyBqsUJNdT.pgp
Description: PGP signature
