[fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....
bernd.oppolzer at t-online.de
Tue Sep 3 13:41:55 CEST 2013
Am 03.09.2013 08:45, schrieb Mark Morgan Lloyd:
>> if you have a language like C which doesn't support nested procedure
>> 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
> [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
More information about the fpc-devel