Re: Memory organisation of the Z80 Turbo Pascal compiler

From	Hans-Peter Diettrich <DrDiettrich1@netscape.net>
Newsgroups	comp.compilers
Subject	Re: Memory organisation of the Z80 Turbo Pascal compiler
Date	2021-10-03 02:06 +0200
Organization	Compilers Central
Message-ID	<21-10-006@comp.compilers> (permalink)
References	<21-09-014@comp.compilers> <21-10-001@comp.compilers> <21-10-002@comp.compilers>

Show all headers | View raw

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

Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

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