[fpc-devel] Re: EBCDIC ( was On a port of Free Pascal to the IBM 370)

[Tomas Hajny]

On 30 Jan 12, at 21:34, Daniël Mantione wrote:
> Op Mon, 30 Jan 2012, schreef steve smithers:
> >> Hans-Peter Diettrich wrote on Mon, 30 Jan 2012 17:40:27 +0100
> >> Existing source code frequently assumes ASCII encoding. The obvious are
> >> upper/lowercase conversions, by and/or or add/sub constant values to the
> >> characters. It will be hell to find and fix all such code in the
> >> compiler and RTL, even if only the constants have to be modified for
> >> EBCDIC. Even code with the assumed order of common characters (' ' < '0'
> >> < 'A' < 'a') has to be found and fixed manually - how would you even
> >> *find* code with such implicit assumptions?
> >
> > It does indeed. Â I am aware of the problems inherent in this. Â But the RTL
> > has to be more or less rewritten anyway to support OS. Â OS is a very different
> > animal to Windows or Linux.
> 
> If you try to achieve a port by modifying all code that deals with 
> characters you will fail. The amount of work becomes then far too big for 
> a single person, and the modifications become too huge and wide-spread 
> that you will raise objections for merging it with the SVN trunk.
> 
> In other words, do yourself a favour and keep ALL processing in ASCII. You 
> can convert between ASCII & EBCDIC on input/output. That way the 
> modifications in order to support EBCDIC are well concentrated in a single 
> piece of code, which can be easily merged without risk of destabilizing 
> the code base.
> 
> You can then use your manpower, and you still need *a* *lot* of it, to 
> write a code generator & RTL.

Personally, I'd say that it depends on the goals. If the goals are 
primarily oriented to use of existing codebases on the new platform, 
ASCII might be the only real option (there are lots of such 
assumptions in most of the existing code designed for ASCII only). 
However, even in that case I'm still convinced that conversion on 
input/output _within_ the Pascal program means either restricting the 
programmer to using just certain parts of the standard RTL, or 
certain amount of changes in otherwise common files (mostly due to 
the fact that you need to restrict the conversion to text files, but 
some low-level parts of RTL do not distinguish text and binary I/O 
and treat both equally).

However, if creating programs specifically targetting the new 
platform is an important part of the goals (and the goal is 
targetting that mystic "OS" ;-) or MUSIC/SP, etc.) rather than Linux 
for S/390, I don't think that restricting I/O to ASCII is a viable 
option for achieving this goal.

Tomas