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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
