[fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....
Mark Morgan Lloyd
markMLl.fpc-devel at telemetry.co.uk
Sun Sep 1 10:46:21 CEST 2013
Bernd Oppolzer wrote:
> Am 20.08.2013 16:54, schrieb Mark Morgan Lloyd:
>> > Just to name a few: you'll need to get parameter passing for functions
>> > correctly
>> Which leads to another issue: the 370 is a register-based system
>> without a stack as understood today. Parameters are mostly passed in
>> registers, but this is largely hidden since supervisor calls etc. are
>> usually hidden in macros.
>> My own feeling is that it would be best to start targeting a
>> late-model 390, which does have a stack etc., and to use the standard
>> GNU assembler and linker (as and ld) /initially/ targeting Linux. Any
>> other combination (i.e. a proprietary assembler etc. with an antique
>> MVS as target) is going to cause nothing but grief, since it makes it
>> very difficult for developers skilled with FPC but not with IBM
>> mainframes to give any practical help.
> Sorry, I don't follow some of the comments in this thread.
> First, what is a stack? A stack IMO consists of a stack pointer provided
> by the
> hardware, that is, a register. And even the old IBM machines have many
> that can be seen as stack pointers; you only have to select one. That is
> in fact the
> way that the stack has been implemented in "old" compilers on "old" IBM
> be it Fortran, Pascal, PL/1 or C. All those languages needed kind of
> stacks for
> local variables of procedures etc. So IMO there is no need to target new
> this will be very expensive and excludes the use of Hercules simulators and
> free versions of IBM operating systems for first tests. Even todays IBM
> don't use the "new" hardware stack.
I think that an initial port to Linux (targeting a late-model 390
emulated by Hercules) is unavoidable, and that also has the advantage of
being of immediate use to the wider community. That implies that it has
to be able to use the standard calling convention on that platform, as
Also see the assembler examples at
which show actual assembler sequences generated (one for the Linux
kernel, others for a "Hello, World").
So at the very least, we have to consistently simulate a stack- apart
from anything else, that's mandated by Pascal's use of recursion. But we
don't necessarily have to use the same calling convention for Linux and
for "classic" OSes (i.e. including those which are freely-available,
running on Hercules etc.).
Question (to save me digging into the manuals right now): where a recent
machine uses the dedicated stack instructions, is the stack pointer one
of the standard registers? In other words, can push/pop operations be
trivially and exactly simulated for older hardware?
> And then: I have some doubts about the linkage between FPC and the GNU
> like as and ld. Why is it easier to port FPC to a Linux based system?
Because the FPC sources are ASCII, all the RTL code assumes ASCII
(including collation order, behaviour of Pred() and Succ(), and so on)
and- most importantly- because almost all of the developers are either
using it or are familiar with it by necessity.
> If the compiler translates into an abstract intermediate language first
> and then into an abstract assembly language maybe - for an abstract machine
> like the P-machine - then the nature of the assembler and linker used
> should be irrelevant. Maybe there is some misunderstanding on my - or
> our - part;
Yes, but the compiler /doesn't/. The one possible getout here would be
to use one of the variants that already generates Java bytecodes or
(potentially) something like WebJS, but that would immediately exclude
any of the "classic" OSes unless a custom backend were written from scratch.
> I have the Wirth compilers in mind, and there is a clear separation between
> the machine independent parts - phase 1 - which generates P-code and
> the machine dependent parts - phase 2 and runtime. Even if there is no such
> separation in FPC, it should IMO be possible to develop and test the code
> generation separately.
I don't think that would work, there are too many quasi-circular
dependencies (I'm intermittently wrestling with a potential
code-generation problem, and hoo-boy).
> I, too, had the difficulties, like Paul Robinson, that I did not get the
> working. My goal was, for example, to have a cross compiler running on
> Windows, that produces Assembler output for MIPS for example, and
> for a second target S370, which is at the beginning simply a copy of MIPS,
> producing the identical output, but then I could make changes to the S370
> code generation and try to get the results running on a simulated or
> real 370 hardware.
> Could you maybe outline the steps that are necessary to create such an
I agree that the MIPS target is very similar, including Linux calling
conventions etc. (noting that there are several possible calling
conventions, and that information describing these might only be
available under NDA).
However note Florian's comment about there being an optimal sequence for
bringing things up, and also note that Sven has recently worked on the
68K port which might be sufficiently-similar to be relevant.
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
More information about the fpc-devel