|Memory organisation of the Z80 Turbo Pascal compiler firstname.lastname@example.org (Lasse =?iso-8859-1?q?Hiller=F8e?= Petersen) (2021-09-29)|
|Re: Memory organisation of the Z80 Turbo Pascal compiler DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2021-09-30)|
|Re: Memory organisation of the Z80 Turbo Pascal compiler email@example.com (Lasse =?iso-8859-1?q?Hiller=F8e?= Petersen) (2021-10-02)|
|Re: Memory organisation of the Z80 Turbo Pascal compiler firstname.lastname@example.org (gah4) (2021-10-02)|
|Re: Memory organisation of the Z80 Turbo Pascal compiler email@example.com (2021-10-02)|
|Re: Memory organisation of the Z80 Turbo Pascal compiler DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2021-10-03)|
|From:||Lasse =?iso-8859-1?q?Hiller=F8e?= Petersen <firstname.lastname@example.org>|
|Date:||02 Oct 2021 10:38:58 GMT|
|Organization:||SunSITE.dk - Supporting Open source|
|Injection-Info:||gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="89251"; mail-complaints-to="email@example.com"|
|Keywords:||architecture, history, comment|
|Posted-Date:||02 Oct 2021 13:35:42 EDT|
On Thu, 30 Sep 2021 11:15:32 +0200, Hans-Peter Diettrich wrote:
> 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.
Interesting. I'd have thought that on the 68K architecture you would
always prefer using stack based frames, given its many addressing modes
and address registers.
> 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
So you depended on the "feature"? I don't quite understand how you
managed to do that.
I just noticed that in the TP manual, the second paragraph down on the
page I quoted from actually says:
"Because of this technique, variables local to a subprogram must not
be used as var parameters in recursive calls."
I quoted the TP manual, as at the time I couldn't find the original
Danish COMPAS manual, and it was the "official" English translation.
However, the corresponding page in the COMPAS 2.0 manual(COMPAS 3.0
probably being equivalent to TP 1.0) does not have this caveat, so I
guess Anders Hejlsberg had not noticed this problem with the save-restore
method until then. Ah, the follies of youth. :-)
Given these problems, I suppose the method was not deemed very "useful"
by compiler designers. I still wonder if there are more examples of its
use, and if there is a name for it, or maybe literature describing it.
An "exercise" set that I guess I will try to figure out now, and which
others might find entertaining:
1. Is there a simple way to solve the problem, like figuring out where on
the routine stack the variable passed by reference will be during the
recusive call, and just pass that address instead?
2. How does nested subroutines fit into the method? Should locals of a
nested subroutine be considered part of the locals of the containing
subroutine? What is the situation with the case of indirect recursion,
where the inner calls its containing subroutine?
3. Are there other fun ways this method can be used, exploited or abused?
(Now where did I put my Z80 CP/M emulator? :-) )
[This isn't the same thing, but in IBM 360 Fortran, the suroutine prolog copied scalar
parameters into locals and epilog copied them out. It didn't have indirect
addressing so that let it use the same base register as for the other locals. Fortran
didn't allow recursive calls but if you used aliased arguments you could get confusing
Return to the
Search the comp.compilers archives again.