Re: Memory organisation of the Z80 Turbo Pascal compiler

On 9/29/21 1:40 PM, Lasse Hillerøe Petersen wrote:
> I have been thinking about the old TurboPascal compiler (actually about
> its predecessor COMPAS Pascal, which I used long ago, but I believe the
> original Z80 CP/M TurboPascal was exactly the same in this regard.)
>
> In the TP 2.0 manual it says:
> "The recursion stack is used only by recursive procedures and
> functions, i.e. procedures and functions compiled with the
> A compiler directive passive (~A-}). On entry to a recursive
> subprogram it copies its workspace onto the recursion stack,
> and on exit the entire workspace is restored to its original
> state. The default initial value of RecurPtr at the beginning
> of a program, is 1 K ($400) bytes below the CPU stack pointer."


The famous GfA-Basic for Atari ST and Amiga used a similar strange
handling of local variables as global variables. On entry of a
subroutine all "local" variables were saved on the stack and restored on
exit. In between all references within the entire code used the local
variables of that subroutine instance in the global workspace. This way
every variable of a unique name and type had a fixed address at runtime.


[...]
> Other than the copying (which may be considered inefficient, but only
> applies to recursive procedures) and the possible issue with passing
> references ending up pointing to the wrong variable, what would be the
> pros and cons of this method?


I don't remember whether GfA Basic included pointers or distinct ref/val
parameters. At least it was a damn fast framework on those 68k
processors, in detail compared to 8086 processors of that time.


A con of the GfA method was found in the later PC version that used the
traditional and compatible way of storing local variables in the
stackframe. This broke some legacy code, sooner or later, and I ended up
with a set of subroutines that could not be converted into any other
language. Unfortunately this was the tricky analysis of complex
conditional expressions in IF (WHILE...) statements of my C decompiler :-(


DoDi

Return to the comp.compilers page.
Search the comp.compilers archives again.