Am 03.09.2013 08:45, schrieb Mark Morgan Lloyd:
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.
C supports recursion of functions, and it is without
problems possible with the scheme outlined above
and in the previous mails.
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.
Agreed. But although the limit of 8 k per procedure seems
strange from todays point of view, there were significant
projects done with this compiler, for example the first TCP/IP stack
for the 370 platform in the early 1980s (inside IBM, in Pascal !!).
I still have lots of tools generating source code, for example PL/1 and C.
XML validator definitions, derived from XSDs (to speed up my XML parser) -
well, that's definitions, not executable code, but ocassionnally very
large, if the
XSD is large - and database access routines ...
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.
yes !!
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
