Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #2710
| From | Lasse Hillerøe Petersen <lhp+news@toft-hp.dk> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: Memory organisation of the Z80 Turbo Pascal compiler |
| Date | 2021-10-02 10:38 +0000 |
| Organization | SunSITE.dk - Supporting Open source |
| Message-ID | <21-10-002@comp.compilers> (permalink) |
| References | <21-09-014@comp.compilers> <21-10-001@comp.compilers> |
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 results. -John]
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