[fpc-other] Stanford Pascal Compiler successfully ported to Windows, OS/2 and Linux

[Alexander Stohr]

Am 2016-12-24 um 15:20 schrieb Bernd Oppolzer:
> 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).
>
> I converted all relevant sources (including the compiler itself) to ->,
> so this would be ok for me.
This is indeed a very well known C style.
> PTRADD, PTRDIFF and so on ...
This is not C style but with a minor macro helper something like this is 
quickly added to a typical C program.
The difference between two pointers is defined as the number of elements 
of the pointer type.
The addition or sum of two pointers is missing a bit of a straight 
forward logic for me.
Advanced coding style recommendations (e.g. MISRA standards) would tell 
you not to use such pointer math
because such constructs have a higher chance to sometimes mislead the 
performing programmer and thus would more likely lead up to codes with 
functional bugs.
The first answer for such operators often is: use the right container 
for the value you are in need and avoid all those operators.
And the second answer is: If you are really in the true rare need (e.g. 
for system programming, ring buffers, atomic operations, code sizes + 
register savings + extreme efficiency) then keep these codes and data 
very isolted, very well documented and finally deeply tested for all 
operating conditions.
> 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.
Is the your lower end of those module touching on a system API level for 
that?
(e.g. the Linux ABI, OS/2 system peronality, WIN32 api - rather than 
malloc()/free() as a C standard library provides it)
> 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).
 From a C program portability view I would futher "tick" for the support 
of  the "//" comment operator as a single sided one.
On the other side, even for ages there is the option of pascal-2-c 
converters (p2c) that do the other way around, but would have some 
smaller problem if such a token was suddenly added. If sources of the 
tool are available then someone that is in need for support could solve 
it easily.

just my 2 euro cents.

regards and good christmas times.
-Alex.