Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #2709
| From | Hans-Peter Diettrich <DrDiettrich1@netscape.net> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: Memory organisation of the Z80 Turbo Pascal compiler |
| Date | 2021-09-30 11:15 +0200 |
| Organization | Compilers Central |
| Message-ID | <21-10-001@comp.compilers> (permalink) |
| References | <21-09-014@comp.compilers> |
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
Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar
Memory organisation of the Z80 Turbo Pascal compiler Lasse Hillerøe Petersen <lhp+news@toft-hp.dk> - 2021-09-29 11:40 +0000
Re: Memory organisation of the Z80 Turbo Pascal compiler Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2021-09-30 11:15 +0200
Re: Memory organisation of the Z80 Turbo Pascal compiler Lasse Hillerøe Petersen <lhp+news@toft-hp.dk> - 2021-10-02 10:38 +0000
Re: Memory organisation of the Z80 Turbo Pascal compiler gah4 <gah4@u.washington.edu> - 2021-10-02 13:08 -0700
Re: Memory organisation of the Z80 Turbo Pascal compiler Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2021-10-03 02:06 +0200
Re: Memory organisation of the Z80 Turbo Pascal compiler anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2021-10-02 20:45 +0000
csiph-web