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

[Mark Morgan Lloyd]

Paul Robinson wrote:

 > 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!)

Or Java. And while it's conceivable that Oracle could make themselves 
sufficiently unpopular that the rest of the World junked Java, as I 
understand it IBM has so much invested in e.g. hardware assist engines 
that they'd be the last to jump ship.

 > 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

My understanding is that the 390 is backwards-compatible with the 370 
and 360. However you don't need to understand the binary code, since FPC 
emits assembler source which is processed by the standard GNU assembler 
as a backend. There are FPC command-line options that allow you to save 
this with varying levels of explanatory comments for later inspection, 
although some of the more juicy stuff requires that FPC be recompiled 
with EXTDEBUG=1 on the make command line.

 > 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)?

I'll see what I can dig out. However I think that 
http://linuxvm.org/present/SHARE102/S9236uw.pdf is a good starting 
point, and most if not all other Linux ports work on the basis of a 
single supervisor call with multiple parameters (nota bene: the 
constants identifying syscalls vary across architectures).

 > 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.

I want to be quite unambiguous about this: from the point of view of 
implementing a compiler, it is not that the 390 is more powerful but 
that the 370 is broken. Referring to 
ftp://sourceware.org/pub/gcc/summit/2003/Porting%20GCC%20to%20the%20IBM%20S390.pdf 
section 3.1, it was at least partially fixed in the 390 circa 1992, and 
if I recall correctly GCC doesn't support older systems. Now you're the 
guy with the relevant industry experience: are there still pre-'92 
mainframes in commercial or academic service? My understanding is that 
"big iron" of that vintage has been recycled for its precious metal, and 
that contemporaneous "micro mainframes" are woefully underpowered by 
today's standards- and I write as somebody who's got some fairly old 
kit, and who prefers not waiting 24 hours for a trial compilation to 
throw bugs.

 > 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.

Yes, but I'd suggest making sure that your architecture-specific code is 
clean before moving on to the generic stuff.

[Snip]

 > 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.

OK. Important point here: FPC uses gas (GNU Assembler) or equivalent as 
a backend, and so has to generate assembler that it's happy with. I came 
across exactly the same issue a few months ago with MIPS: it turns out 
that symbolic register names were only added to gas comparatively 
recently so if FPC wants to generate code that will assemble reliably it 
can't use them... at least for a few more years.

 > 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 (.

"The senator's still wrong." :-)

If you really want to be strict, I'd suggest that it would be reasonable 
to be able to close { with *) or (* with }, since (* and *) are digraphs 
for { and }. {$ works, (*$ should work, //$  /*$  -- $ and  ⍝$ don't 
work and probably never will. {*$ is just plain /wrong/.

However there are additional concerns here related to Pascal's inability 
to nest comments (unlike Modula-2 which by definition counts nesting 
depth) so let's just hope for a good compromise.

 > 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.

Agreed. But it's also good practice for a programmer to select typefaces 
that make the differences stand out. Or to put a new ribbon in his '029.

 > 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!)

Yes. And I'm the one who's trying to get you to avoid EBCDIC, at least 
to start with.

 > 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.

I think we need a core developer's input on this. I'd also like to be 
able to do something with the MIPS fixes I've done, particularly since 
they're likely to be of some use to you (i.e. you could start off with a 
compiler that would build on a PC, and then modify the code generator 
(in extremis I'll mail you).

 > 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!

For project as big as FPC+Lazarus (plus all the other tools and 
libraries they depend on) you start off with rule #0: DON'T UPSET ANYBODY.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]