Re: Memory organisation of the Z80 Turbo Pascal compiler

Hans-Peter Diettrich <DrDiettrich1@netscape.net>
Sun, 3 Oct 2021 02:06:36 +0200

          From comp.compilers

Related articles
Memory organisation of the Z80 Turbo Pascal compiler lhp+news@toft-hp.dk (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 lhp+news@toft-hp.dk (Lasse =?iso-8859-1?q?Hiller=F8e?= Petersen) (2021-10-02)
Re: Memory organisation of the Z80 Turbo Pascal compiler gah4@u.washington.edu (gah4) (2021-10-02)
Re: Memory organisation of the Z80 Turbo Pascal compiler anton@mips.complang.tuwien.ac.at (2021-10-02)
Re: Memory organisation of the Z80 Turbo Pascal compiler DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2021-10-03)
| List of all articles for this month |
From: Hans-Peter Diettrich <DrDiettrich1@netscape.net>
Newsgroups: comp.compilers
Date: Sun, 3 Oct 2021 02:06:36 +0200
Organization: Compilers Central
References: 21-09-014 21-10-001 21-10-002
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="7075"; mail-complaints-to="abuse@iecc.com"
Keywords: architecture, history
Posted-Date: 02 Oct 2021 21:05:03 EDT
In-Reply-To: 21-10-002

On 10/2/21 12:38 PM, Lasse Hillerøe Petersen wrote:
> 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.


Much 68k software, particularly compilers, was poorly ported 8 bit (CP/M?)
code. E.g. one compiler only used the 68k address registers because "an
int is a pointer, a pointer is an int". For expression evaluation the
operands of each binary operation were copied from memory to the address
registers (A0, A1), from there to the data registers (D0, D1) and
afterwards back again, typically in subroutines at least for logical
operators. This way a simple single statement C function generated 3
pages of assembly listing, and that mess made me start the C decompiler
development. At that time C was very new to me, and none of the
compilers had ever heard about ANSI C. So I did all work in GfA Basic
and was happy with it. After a few years I had a decompiler for
executables and libraries of half a dozen C compilers, including Amiga
and HP-UX.


>> 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.


It was by accident, because at that time I couldn't know how it could be
done otherwise. All my practical experience with homecomputers was Basic
and machine language, having seen compilers (Algol, Cobol...) only as a
user on the TR-440. At least the Gfa method was such a clean and
efficient approach that Occams Razor...


DoDi


Post a followup to this message

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