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]
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
