|Porting lex scanner on EBCDIC machine. c1veeru@WATSON.IBM.COM (Virendra K. Mehta) (1995-04-01)|
|Re: Porting lex scanner on EBCDIC machine. email@example.com (1995-04-03)|
|Re: Porting lex scanner on EBCDIC machine. firstname.lastname@example.org (1995-04-03)|
|Re: Porting lex scanner on EBCDIC machine. email@example.com (1995-04-03)|
|Re: Porting lex scanner on EBCDIC machine. firstname.lastname@example.org (1995-04-04)|
|Re: Porting lex scanner on EBCDIC machine. email@example.com (1995-04-05)|
|Re: Porting lex scanner on EBCDIC machine. firstname.lastname@example.org (1995-04-15)|
|Re: Porting lex scanner on EBCDIC machine. email@example.com (1995-04-18)|
|From:||firstname.lastname@example.org (Gary Merrill)|
|Organization:||SAS Institute Inc.|
|Date:||Sat, 15 Apr 1995 04:04:54 GMT|
email@example.com (Anavai G Ramesh) writes:
|> Lex introduces character constants like 'a' in the generated file (I
|> cannot understand why). Scan the generated files and replace all
|> constants by their ASCII values.
|> This works. I had used this technique to build a COBOL
|> parser for an IBM machine a few years ago.
We did the same thing for the prototype of our mainframe C++
compiler (which was developed on a UNIX system and then ported
to MVS). I too never understood why character constants are used,
and it is a *major* irritant. Having been through this sort of
thing, I have a couple of recommendations:
1) Don't use Lex, use C (In general I prefer to write
the lexical analyzer directly in C.), or
2) Don't use Lex, use Flex.
As I recall, things did not go as smoothely as we would have
expected with Flex, but this was some years ago and I don't
recall the details. So another alternative is:
3) Port Flex to the target machine and run it there to
produce the scanner.
The problem with using Lex on an ASCII machine and then porting
the resulting code is that every time you change it in some
little way you have to go through the hideous editing changes
that have been described. At least option 3) avoids this.
I don't know what the current state of Flex is in terms of just
dropping it on (say) MVS and making it.
Gary H. Merrill [Principal Systems Developer, Compiler and Tools Division]
SAS Institute Inc. / SAS Campus Dr. / Cary, NC 27513 / (919) 677-8000
firstname.lastname@example.org ... !mcnc!sas!sasghm
Return to the
Search the comp.compilers archives again.