Am 21.08.2013 22:17, schrieb Steve:
Mark Morgan Lloyd wrote
> Otherwise we also rely on external tools (mostly the GNU linker)
> here. So as a first step you'd choose the approach of using an
> external assembler and linker, because simply calling a third party
> utility is easier than completely implementing an internal assembler
> and linker.
With the caveat here that as I understand it experienced IBM programmers
avoid the GNU assembler like the plague, since it doesn't have anything
like the sort of macro facilities they're used to. By implication, that
would imply that they prefer to avoid the GNU linker and related tools
as well.
There is a problem inherent in this discussion; zArch is not one
environment!
It's one architecture supporting multiple operating systems, much like
the
386/486/586/686 etc supports Linux or DOS or OS/2 or Windows (all 37
versions)
etc. zArch has MVS (in all it's varieties) VM, DOS, LINUX, MFT, MVT,
MUSIC/SP,
and loads of other more niche stuff. In addition to all this, later
versions of
MVS supply a POSIX compliant shell called OMVS. GNU anything is
available in
hardly any of these environments even if we can handle the brain-dead
assembler.
This is correct, but it should be possible to cover most of those
systems with
one RTL - much the same way as LE (language environment) does it in the
"big" IBM world, too.
> 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.
I am an MVS person so I can't speak for the other lot but parameter
passing
is mostly done in storage. The standard linkage conventions used allow
for
two 32-bit signed or unsigned integers (64-bit in later models). Anything
else is passed in a storage area pointed to by register 1. Where this
storage
area comes from is complex and variable. My guess that the other IBM
systems
have similar models. A further guess is that Linux based code
allocates an
area of storage, points a register at it, write a couple of mickey mouse
macros and bingo, a stack.
Ok. So what? This makes parameter passing just easier, because you don't
have to deal with special cases for - say - low number of parameters.
It's all the
same method. And Pascal has call by value and call by reference and -
for example -
not the strange descriptor and dope vector things that PL/1 has. The
stack is simulated
by simply incrementing and decrementing the stack pointer on procedure
entry and
return and addressing relatively to it. At least that is what is done in
the "classical"
compilers. I recently learned a bit about the MIPS architecture, and it
seemed to
me to have some similarities to IBM's, so I guess, a kind of
"translation" from MIPS
to IBM could be successful. Many people say that the IBM platform is the
only
remaining platform today that reasonably can be programmed using
assembly language,
because of the clear structure of the instruction set.
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.
Late-model 390's have a stack, but not as you know it. It's not something
you can go around lobbing arbitrary data at. It is reserved for data
saved
during subroutine linkage using the appropriate hardware instruction
(Branch
and Stack). This includes various register sets, PSW status info etc)
and an
additional two 32-bit signed or unsigned integers (64-bit in later
models).
Steve
I would strongly suggest not to use the "new" hardware stack, but
instead to
rely on the OS linkage conventions (save area chaining, register 13), which
in fact are used by most of the operating systems mentioned above - with
minor differences.
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
