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

[Mark Morgan Lloyd]

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 
> registers
> 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 
> hardware,
> 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 
> hardware;
> 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 
> compilers
> 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 
excerpted at 
http://wiki.lazarus.freepascal.org/Assembler_and_ABI_Resources#zSeries_.28S.2F390.29_2 
Also see the assembler examples at 
http://wiki.lazarus.freepascal.org/Assembler_and_ABI_Resources#zSeries_.28S.2F390.29 
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 
> tools,
> 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 
> cross-compiler
> 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 
> environment?

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]