Re: [fpc-other] Stanford Pascal Compiler successfully ported to Windows, OS/2 and Linux
On 24/12/16 14:30, Bernd Oppolzer wrote:
Am 24.12.2016 um 14:21 schrieb Mark Morgan Lloyd:
On 24/12/16 12:30, Bernd Oppolzer wrote:
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)
/* was the form used in the first edition of Wirth's description of
Pascal (might have been before Jensen was there to help out). However
I'd strongly suggest deprecating @ and replacing it with another
digraph, it's used as the address-of operator in Turbo Pascal and its
successors.
I don't like @, too. What you told me about the address-of operator
in Turbo Pascal etc. is a very strong reason to get rid of @; I will
think about it.
I converted all relevant sources (including the compiler itself) to ->,
so this would be ok for me.
Leave it in the compiler as long as possible, but explicitly mark it as
deprecated (/not/ depreciated :-)
The TopSpeed family used something like ADR() and SIZE() as functions
with ADDRESS as an untyped pointer; ADDRESS() acted as a cast. Their
Pascal compiler used :: as a type transfer that changed bit patterns
where necessary, and :> as one that didn't change bit patterns.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-other maillist - fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Stanford Pascal Compiler successfully ported to Windows, OS/2 and Linux
Am 24.12.2016 um 14:21 schrieb Mark Morgan Lloyd:
On 24/12/16 12:30, Bernd Oppolzer wrote:
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)
/* was the form used in the first edition of Wirth's description of
Pascal (might have been before Jensen was there to help out). However
I'd strongly suggest deprecating @ and replacing it with another
digraph, it's used as the address-of operator in Turbo Pascal and its
successors.
I don't like @, too. What you told me about the address-of operator
in Turbo Pascal etc. is a very strong reason to get rid of @; I will
think about it.
I converted all relevant sources (including the compiler itself) to ->,
so this would be ok for me.
I have a function ADDR, which gets the address of every variable (not only
heap elements), automatic and static variables (which I added), too.
ADDR returns an untyped pointer, which is compatible
to every other pointer type, much the same as the constant NIL.
There is a function PTRCAST, which casts every pointer type
to this untyped pointer type. And functions PTRADD, PTRDIFF and so on ...
I borrowed some of the names from PL/1.
Maybe pandora's box, but I need this to do some of the more systems related
work. For example: I rewrote the LE storage management in Pascal and
made it
available to the Stanford Pascal runtime (new functions ALLOC and FREE);
this works perfectly with Hercules and VM; it still has to be tested
with Windows - Linux - OS/2.
I added /* to the list of allowable symbols for comments, because it's
what I knew
from PL/1 and C. Comments have to be terminated by the same symbol which
started them, and: they may be nested (as with FPC).
Kind regards
Bernd
___
fpc-other maillist - fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Stanford Pascal Compiler successfully ported to Windows, OS/2 and Linux
On 24/12/16 12:30, Bernd Oppolzer wrote:
Am 24.12.2016 um 12:50 schrieb Mark Morgan Lloyd:
You are mentioning SUCC and PRED with CHAR; that is a very cood example.
It's not so much a good example as a specific sticking point that was
mentioned in earlier discussion on the ML.
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.
At least a-f are consecutive, and it's still possible to switch letter
case with an addition. I've used a tool in the past, written by what I
have to assume was one of the Three Wise Men, which made no assumptions
other than that 0-9 were consecutive: everything else was specified on
the first line of every file.
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,
Ouch :-(
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)
/* was the form used in the first edition of Wirth's description of
Pascal (might have been before Jensen was there to help out). However
I'd strongly suggest deprecating @ and replacing it with another
digraph, it's used as the address-of operator in Turbo Pascal and its
successors.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-other maillist - fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Stanford Pascal Compiler successfully ported to Windows, OS/2 and Linux
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
Re: [fpc-other] Stanford Pascal Compiler successfully ported to Windows, OS/2 and Linux
On 24/12/16 11:30, Bernd Oppolzer wrote: Hello Mark, on several occasions, I looked what FPC does, when I extended the Stanford compiler, for example when I added support for direct write of scalars. At one time I recall that I decided explicitly to take another direction; that was when I allowed shorter string constants to be assigned to longer ones, for example: var x: array [1 .. 200] of char; x := 'some string'; IIRC, FPC fills with hex zeroes, but I prefer blanks - the blank representation of the target system ... which is different on the target systems; this should show to some of the readers here which are not familiar with IBM mainframes some of the difficulties I had to get the P-Code really portable ... all I think the issue of padding partially-initialised data structures is something that merits wider discussion. Provided of course that we can avoid the sort of arcana that Paul/Kerravon is enmired in :-) 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... -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Stanford Pascal Compiler successfully ported to Windows, OS/2 and Linux
Hello Mark, on several occasions, I looked what FPC does, when I extended the Stanford compiler, for example when I added support for direct write of scalars. At one time I recall that I decided explicitly to take another direction; that was when I allowed shorter string constants to be assigned to longer ones, for example: var x: array [1 .. 200] of char; x := 'some string'; IIRC, FPC fills with hex zeroes, but I prefer blanks - the blank representation of the target system ... which is different on the target systems; this should show to some of the readers here which are not familiar with IBM mainframes some of the difficulties I had to get the P-Code really portable ... all 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. This changes had to be done in the first pass of the compiler, which translates the Pascal source to P-Code; the second pass (P-Code to machine instructions) and the P-Code interpreter had to be adjusted accordingly. See more information (including Pascal and P-Code examples) at the web site mentioned below. Regarding your question: There are - of course - some more incompatibilities between FPC and Stanford Pascal; first of all, Stanford Pascal, as of now, is a very small language, compared to FPC. My extensions of the last months are motivated by my own needs and interests (and by my C and Pascal/VS experience, to some degree); I wanted before all a Pascal based language that works the same on Windows, OS/2, Linux and IBM Mainframe. I didn't want to compete with FPC, not even in the long term. This looks impossible to me, from today's view. Kind regards Bernd Am 24.12.2016 um 08:44 schrieb Mark Morgan Lloyd: On 23/12/16 23:00, Bernd Oppolzer wrote: Hello FPC list, I would like to inform you, that I ported an improved version of the Stanford Pascal compiler (a descendant of the Wirth P4 compiler) to Windows, OS/2 and Linux. I improved this compiler, which comes from the IBM mainframe, by adding several features that I needed and that I found useful, in the past few months. You find some stories about my efforts of the last years and months on my web site: http://bernd-oppolzer.de/job9.htm Well done Bernd. I remember that you were having some difficulty with character array compatibility with FPC, are any of those still a problem? ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
