Re: Porting lex scanner on EBCDIC machine.

>, kkaempf@didymus.rmi.de (Klaus Kaempf) writes:
|> Virendra K. Mehta" <c1veeru@WATSON.IBM.COM> writes:
|>
|> >[...] However the mainframe uses EBCDIC
|> >while lex generated tables, state machines etc. expect an ASCII input.
|>
|> Hmm, this sounds easy. Just #define your own lex YYINPUT macro which
|> converts ebcdic to ascii. This could be done in a 256 char table with
|> YYINPUT defined as ebcdic2ascii[getchar()]. All you have to supply is
|> the proper conversion table. Have a look at oak.oakland.edu (former
|> simtel archive) in msdos/txtutl there is ebc2asc.arc for example.


      This approach (translation to ASCII on input) was taken some time
ago by the old Whitesmith's C compiler on MVS. It is not without
its problems, and really should be avoided except as a quick and
dirty temporary kludge. Assuming that you can settle on some
suitable translation (not obvious), other problems and infelicities
remain. Consider, for example, how you would approach emitting
informative error messages for errors in input (input is now in
ASCII, error messages should be in EBCDIC). The results can be
particularly perplexing to a user if the character set translation
is not 1-1 (as it surely won't be). With a *lot* of extra bookkeeping
you could probably do a good job of this, but then we aren't just
talking about converting to ASCII on input and you end up with
quite an inefficient I/O system at best. Better to spend your
time doing it right.


--
Gary H. Merrill [Principal Systems Developer, Compiler and Tools Division]
SAS Institute Inc. / SAS Campus Dr. / Cary, NC 27513 / (919) 677-8000
sasghm@theseus.unx.sas.com ... !mcnc!sas!sasghm
--

Return to the comp.compilers page.
Search the comp.compilers archives again.