[clug] An EBCDIC lex ?

[Eyal Lebedinsky]

Yes, 'a' is naturally EBCDIC 'a' on a 370 C compiler. However, if you use 'a'
on an ASCII platform (e.g. PC) and generate a lex parser then the 'a' will
end up in the state machine tables as its ASCII value. When transferring
this lexer to the 370 it will not properly respond to EBCDIC data.

This is my understanding of what the OP wants to do - create a lexer on a
PC and then compile/use it on the mainframe in their language compiler.

The other approach is to build flex from source on the 370 (390? surely
not 360...).

<aside>
This reminds me of the pain I took when porting gcc 1 to a 370 environment.
It did not understand host/target distinction of character encoding so I
needed to write preparatory passes to replace all char/string data with
EBCDIC valued (so 'A' was replaced with '\xc1' etc.). I could then compile,
assemble the asm and use hercules (with more helper scripts) to actually run
this. printf was doing some WTOs etc. But it worked! I used this to cross
check a native asm implementation (since obsoleted) of our software to a
modern (for the early 80's) C version.

To be honest, it actually was a fun challenge :-)
<aside/>

cheers

On 14/08/10 18:20, steve jenkin wrote:
> Paul Matthews wrote on 14/08/10 5:48 PM:
>>   On 14/08/10 15:42, Eyal Lebedinsky wrote:
>>> Something like what in ASCII will say:
>>>      DIGIT    [0-9]
>>> should now say
>>>      DIGIT    [\xf0-\xf9]
>>> (I think this is how you escape hex in flex input)
>>>
>> Now that is a good idea Eyal.
>>
>> ( A lot less tedious than attempting a handwritten state machine. )
>>
>
> Paul,
>
> My recollection of using a C compiler on 370-series was constants of the
> form 'x' (ie char) would be encoded as EBCDIC.
>
> So cut-and-paste of Flex files, as long as state machine in chars, would
> work out-of-the-box.
>
> HTH
> s

-- 
Eyal Lebedinsky	(eyal at eyal.emu.id.au)