comp.lang.ada
 help / color / mirror / Atom feed
From: ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe)
Subject: Re: New GNAT ports (was Re: Ada and Automotive Industry)
Date: 1997/01/13
Date: 1997-01-13T00:00:00+00:00	[thread overview]
Message-ID: <5bcb7t$plu$1@goanna.cs.rmit.EDU.AU> (raw)
In-Reply-To: dewar.852988704@merv


>Robert Eachus says
>"   For the 8051, starting with an the a version of gcc for the Intel
>8086, 80186, 80286, or even the Z-80 should be a good start.

The 8086 and the 8051 aren't all that much alike.
The 8086 is a 16 bit machine, extended with segments.
The 8051 is an 8 bit machine, without segments.

For example, suppose we have something like
	type R is record x: Byte end;
	RV: R;
and want to do
	RV.x := RV.x + 1;

Assuming that the address of RV is known at link time,
we can do
	inc RV'Address + 1
in the 8086.  In the 8051, it's

	load DPTR with (RV'Address + 1)
	ld A, @DPTR
	inc A
	st A, @DPTR

All external RAM references have to share a single 16-bit address
register, and the set of operations on that register is rather
restricted.  (For example, to add something to DPTR, you must
operate on its separate halves using 8-bit instructions.)  In
particular, the major reason why I would expect to use a
pragma No_Recursion for Ada-8051 is not that it _can't_ be done
(it can) but that it would seriously complicate the use of DPTR.

One reason why I would expect Ada-8051 code to be easier to write
than 8051 assembler is simply that the compiler would be able to
keep track of the contents of DPTR more reliably than I can, and that
it could schedule things in interesting ways to reduce DPTR reloads.

Another difference is the fact that the 8086 has 16-bit and 32-bit
pointers, both of which can point to the same memory locations,
while the 8051 has 8-bit and 16-bit pointers, that canNOT point to
the same memory locations.


The thing that makes something like this practical, in my view,
is that the goal is NOT to optimise arbitrary Ada code, but simply
to do a reasonable job with code written specifically for the 8051.
My claim is not that the 8051 is a good machine for Ada (which it
clearly is NOT) but that an Ada SUBSET is a good language for the 8051.

I believe that starting from a code generator for right machine (but
wrong compiler front end) would be better than starting from a code
generator for the wrong machine (but write compiler front end), since
converting between intermediate representations (which GNAT already
does) just takes compile time, while code generation affects the final
code.

-- 
My tertiary education cost a quarter of a million in lost income
(assuming close-to-minimum wage); why make students pay even more?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.




      reply	other threads:[~1997-01-13  0:00 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-12-24  0:00 New GNAT ports (was Re: Ada and Automotive Industry) Robert Dewar
1996-12-27  0:00 ` New GNAT ports John Howard
1997-01-07  0:00 ` New GNAT ports (was Re: Ada and Automotive Industry) Richard A. O'Keefe
1997-01-07  0:00   ` Robert A Duff
1997-01-07  0:00     ` Robert Dewar
1997-01-08  0:00     ` Richard A. O'Keefe
1997-01-09  0:00       ` Dr. Peter E. Obermayer
1997-01-07  0:00   ` Robert Dewar
1997-01-08  0:00     ` Ken Garlington
1997-01-08  0:00     ` Richard A. O'Keefe
1997-01-08  0:00       ` Robert Dewar
1997-01-07  0:00   ` Ken Garlington
1997-01-08  0:00     ` Richard A. O'Keefe
1997-01-08  0:00       ` Robert Dewar
1997-01-09  0:00         ` Richard A. O'Keefe
1997-01-11  0:00           ` Robert Dewar
1997-01-11  0:00         ` Addresses of Subprograms (was: New GNAT ports) Larry Kilgallen
1997-01-13  0:00           ` Larry Kilgallen
1997-01-14  0:00             ` Richard A. O'Keefe
1997-01-14  0:00               ` Fergus Henderson
1997-01-15  0:00             ` Richard Kenner
1997-01-09  0:00       ` New GNAT ports (was Re: Ada and Automotive Industry) Ken Garlington
1997-01-08  0:00   ` Karl Cooper
1997-01-08  0:00     ` Robert Dewar
1997-01-09  0:00     ` Richard A. O'Keefe
1997-01-09  0:00       ` Robert Dewar
1997-01-09  0:00   ` Robert I. Eachus
1997-01-10  0:00   ` Robert I. Eachus
1997-01-11  0:00     ` Robert Dewar
1997-01-13  0:00       ` Richard A. O'Keefe [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox