Am 24.12.2016 um 12:50 schrieb Mark Morgan Lloyd:
On 24/12/16 11:30, Bernd Oppolzer wrote:
chars in
the (character) P-Code file had to be converted to character
constants; all
places where character A - for example - was represented as numeric 193
(which is EBCDIC 'A') had to be found and corrected. Even such places
where
the reference to 193 was not recognized at first sight, that is:
offsets in
branch tables and bit strings representing sets.
I think you've made creditable progress in a difficult area. What are
you doing about PRED() and SUCC() as applied to CHARs?
Anybody with any sort of interest in mainframes is going to have to
consider EBCDIC for quite some while, but unfortunately there are
still people who insist that it's flawless. One of our wiki pages has
somebody confirm that EBCDIC has ^, but he then goes on to admit that
it's not in all codepages...
Thank you.
I think about "portability" in a certain way; to make it clear:
of course it is possible to write programs that are not portable
using my "new" compiler.
You are mentioning SUCC and PRED with CHAR; that is a very cood example.
These functions are implemented based on the underlying character set;
that means, that SUCC('R') is not 'S' on EBCDIC, because there is a gap
between
'R' and 'S in the EBCDIC codepage (six other characters between 'R' and 'S'
which are not alphabetic).
This is a portability problem which appears at the source code level (!)
and cannot be healed by the compiler. It is the same with the C language,
and the sensible programmer has to deal with this, if he or she wants to
have his or her programs really portable.
My problems with the Stanford compiler were different; if the compiler
generates
code which will not run on a platform using a different code page,
because it generates
branch tables when implementing case statements that imply a certain
code page,
this is a big problem and has to be fixed. The compiler implementor has
to find a
representation (in the P-Code, in this case), which will work on every
platform, that is:
which is independent of the code base - and does not prevent the
optimizations
done by the later stages of the compiler.
Same goes for the bit string representation of sets of char; in this
case, the construction
of the bit string has to be deferred until the code page can be determined
(P-Code translation or interpretation time). On Windows etc., the P-Code
interpreter
"translates" the P-Code to an internal representation on startup, and
that's the
time when the "portable" representation of set constants (of char) are
translated
to the bit string representation. See my web site for details.
Regarding ^:
"my" compiler supports different representations for the pointer symbol,
and for other
critical symbols, too:
^ @ -> for the pointer symbol (I use -> most of the time)
[ (. (/ for arrays
{ (* /* for comments ("comment" is supported, too, for historic
reasons)
no problem with EBCDIC. I do the editing on Windows most of the time and
move the
files to Hercules using the socket reader.
BTW: you find the compiler sources and a history of the extensions that
I applied in the last
months (or years) on the web site, too.
Kind regards
Bernd
___
fpc-other maillist - fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
