[fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....

Bernd Oppolzer bernd.oppolzer at t-online.de
Sun Sep 1 05:19:56 CEST 2013

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.

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?
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;
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, 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 

Kind regards


More information about the fpc-devel mailing list