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

[Paul Robinson]

I guess I should make a few qualifiers here.

I think that a mainframe port should be made, if for no other reason than to keep C from being the only choice for developing programs on mainframes (other than Cobol, of course, and dinosaurs like me that know it are rapidly becoming petroleum!)

I know the 370.  I know more-or-less how file I/O is done under OS/VS1 which MUSIC/SP provides an emulation mode for.  I don't (yet) know the machine code for the 390 processor and I do not know the interface for which services from Linux/390 are implemented, I mean, is it a set of different supervisor calls (the way OS/VS1 is) or is it a single supervisor call with lots of parameters (the way MS-DOS with (mostly) INT 21 and Windows 98/Me/XP and Linux on Intel are)?

Certainly I'll eventually learn them.  But for right now, for me to know it works right, I have to implement it for what I know works.  Then I can go on to improve what it does or expand the port to the more powerful mainframe.  As I said - or if I didn't say it, it needs saying - I have to crawl before I can walk or run.


There's another thing.  In at least a few parts of the compiler there are uses of naked, manifest constants which is always a bad idea.  I think someone once said that the only manifest constants that should be used in a program are 0 and 1 and maybe not even them.  


Changing from manifest constants to CONST definitions does two things, it ensures consistency, and, if your language has cross-reference capability, the cross-reference utility can tell you every place you've used an identifier; It can't tell you where you've used a constant.

I remember this from back when I first learned Assembly Language, probably around 1976-77, one of the things instructor Don Lacy taught us is to define registers by creating a set of names on the order of

R0               EQU     0
R1               EQU     1
thru
R15             EQU     15

So when you use

PROGRAM  START
                   BALR   R12,R0
                   USING *,R12

The assembler will list the usage of R12 and R0 here in the cross-reference.  It would not list anything if you'd just used 0 and 12.

As anyone who read this can remember a few messages ago when one guy read my error when I wanted to show how the $DEFINE parser only supports {$DEFINE and that (*$DEFINE doesn't work, but thought I didn't know you can't close {* with *) and thought when I did it wrong as {* instead of (* and thought I meant the { when I meant ( just goes to show how easy it is to confuse { and (.  

It's easy to confuse 0 (zero) and O (capital o) 1 and I (upper case i), 1 and l (lower case L), and sometimes 8 and 0.  Not using them as constants but as constant identifiers means it's easier to spot and to be consistent.   


There's also on piece of code - it's probably in SCANNER.PAS - where there's a construct of something like


    if CH in ['A'..'Z']
which won't work on some processors; EBCDIC doesn't define A-Z (or a-z) as a continuous set; there are non-alphabetic characters between I and J (and between i and J) and another intervening point.  This goes back to the days when code was entered on 029 keypunches.  (And yes, I remember those days, and NOT fondly!)

So I guess the question is, for submitting proposed changes, do I ask someone - and if so whom - for SVN access and a branch to use to put corrections in, or do I pick a specific person - and again, if so, whom - or place (and where) to submit source code changes to provide some fixes as I make them?  Not necessarily just for this, I noticed some things I think should be cleaned up.


Just under the presumption of always following rule #1: DON'T BREAK THE BUILD.  If it worked (built without an error) when you put your dirty hands on it, it had damn well better still work when you've pulled your greasy, sticky fingers away!


 
The Lessons of history teach us - if they teach us anything - that no one learns the lessons that history teaches us.