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