Bernd Oppolzer wrote:
Am 02.09.2013 10:37, schrieb Mark Morgan Lloyd:
That's obviously far friendlier to a language like Pascal than the
examples in most assembler-level treatises- I wonder how compatible it
is with the description of the Linux ABI informally at
http://linuxvm.org/present/SHARE99/S8139db.pdf ?
Some remarks regarding code generation:
if you have a language like C which doesn't support nested procedure
definitions,
it's perfectly simple. You can reach the local (auto) variables using
register R13, and
the parameters using R1. You only need another register to access the
static data
and some kind of heap management to support malloc() etc., and that's
about all.
I believe this sort of thing is also an issue when a function recurses.
With "classical" 360 machines, you had the problem that the offsets in
the machine
instructions only were 12 bits long, so you could only address 4 k from
the position
of a base register directly. That is, if your automatic data (of one
procedure) was
larger than 4 k, you were in trouble. Data after the 4 k barrier had to
be addressed
using two steps; first compute the address and the fetch the data - for
example.
With new z-Arch instructions, this is no problem any more.
Same goes for the procedure code itself; PASCAL/VS (an old IBM compiler
of the 1980 years) limited the size of procedures to 8 k - which is some
hundred
lines of source code. This, too, is no problem today any more, because,
when
you use the new relative branches, you don't need base registers for the
code area.
Anything that artificially limits function size, or forces the code
generator to jump through hoops to work around architecture issues, is a
problem /particularly/ when an external tool has automatically generated
(Pascal) source. I'm not sure how many people use that technique these
days but it was fairly popular in the era when Fortran was dominant, and
there are still tools that generate C or Java source.
A language like Pascal, which allows the nesting of procedures and the
access
of auto variables that are defined outside the local procedure (that is:
in procedures
above the local procedure), you need to retrieve the stack frame of that
procedure
first. This is done by walking up the chain of the save areas and load
the base address
of the stack frame of the interesting procedure into another base
register, different
from R13 (for example). This is a problem, that a C compiler doesn't
have - but it's
well known to PL/1, too.
This all is very well known and can be derived from the other compilers
that deal
with the z-Arch environment, for example the IBM commercial ones.
The z-Arch has evolved very much in the last 10 years, compared to 360
and 370 days,
and this makes code generation and the life of compiler builders much
easier.
[Nod] I believe that most of the above- as well as things like IEEE
floating point support- is in late-model 390s and in the Hercules emulator.
--
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
