New GNAT ports (was Re: Ada and Automotive Industry)

New GNAT ports (was Re: Ada and Automotive Industry)

[Robert Dewar]

obert Eachus says

  >"   Amen!  If it wasn't clear before, that was exactly my point.  The
  >cost of the port can be academic if you can't guarantee that the
  >compiler will be ready in time.  I'd want a lot of time for an 8051
  >GNAT target, but for many other potential targets (especially if gcc
  >has already been ported) it is possible to get something up and
  >running in a week.  You may spend the next several months getting it
  >thoughly wrung out and tested, getting the some of the annex support
  >working, building high-level bindings to OS specific libraries, etc.,
  >but without much schedule risk involved.  (In case that last part is
  >confusing, there are parts of the annexes that you can spend a lot of
  >time on if you care, for example Interfaces to COBOL, or tweaking the
  >numerics performance.  But there shouldn't be any schedule risk early
  >in a project from that.  Most of the GNAT annex code ports with the
  >compiler with no extra effort.)"


I would amend that slightly to say "get something up and running in a week",
if you do not include tasking. The tasking may be easy if you have a system
that is very close to Posix compliant, but in our experience there are lots
of variations in threads packages that complicate this task, and I would
more comfortably restrict the "in a week" to exclude tasking.

Also, this is assuming everything goes smoothly, and depends on the quality
of the GCC port, and also how unusual the machine is. GNAT tends to excercise
some aspects of a port which are not excercised by GNU C, and so you can find
that a port needs more work than you thought.

Still the bottom line is certainly that GNAT technology can be ported much
more rapidly than other technologies which require a new code generator to
be written.

Re: New GNAT ports

[John Howard]

On 24 Dec 1996, Robert Dewar wrote:
> Still the bottom line is certainly that GNAT technology can be ported
> much more rapidly than other technologies which require a new code
> generator to be written.

I saw in a recent SEIC Reuse announcement that ACT has a new GNAT compiler
designed for targeting real-time embedded systems.  It had a version
number around 2.01 or so.

Please provide any information you can about it.

------------------------------------------------------------------------
-- John Howard <jhoward@sky.net>               -- Team Ada  Team OS/2 --

Re: New GNAT ports (was Re: Ada and Automotive Industry)

[Richard A. O'Keefe]

>  >"   Amen!  If it wasn't clear before, that was exactly my point.  The
>  >cost of the port can be academic if you can't guarantee that the
>  >compiler will be ready in time.  I'd want a lot of time for an 8051
>  >GNAT target,

I've been studying the 8051 recently.
I've convinced myself that with the aid of one more pragma [%]
an Ada *subset* can straightforwardly do everything that assembler
can do.  (Given a machine with 4k of code ROM (and _maybe_ up to
64k of external RAM) and < 256 bytes of data RAM (and _maybe_ up
to 64k of clumsily accessed external RAM) you clearly aren't going
to bother with interfaces to COBOL or floating point (my estimate
is that a good FP package would eat the entire ROM) and given the
way the 8051 does subroutine calls it's probably going to be a good
idea to ban recursion and so on.

It would of course be possible to achieve assembly code efficiency
using such an Ada subset, because with the aid of machine code
inserts your "Ada" code could *be* "assembler" code.  It would
still be useful to do because of packages and such.

Would there be any point in writing this up?
I've had wistful thoughts about a possible product.
Given that the two smart cards I've seen used 8051-like processors,
and given the range of applications for smart cards and "postage
stamp" computers (my word, the smart card chips are cheaper than
the concrete blocks my office is made from; the possibilities for
instrumentation are *awesome*) I suspect that the 8051 lookalikes
still have some useful lifespan, and that there is a bigger market
than one might think.  Example:  a lot of money hereabouts goes into
gambling.  How about hand-held bingo machines?  Or hand-held pokies?
What would happen if you had phone cards where you could gamble, and
the winnings would be free calls and the losses would be dead cards?
What about smart buildings with polymer-based chemical sensors hooked
up to postage stamp computers communicating over twisted pairs that
can *cheaply* monitor internal air pollutants?  I mean, we're talking
about systems where the wire would be the most expensive part!

[%] The pragma is
	pragma Origin(non-negative constant integer expression);
    saying that the first byte of the textually following statement
    is to be at the given address.  That was the only thing I saw in
    the 8051 book I was reading that I couldn't do in a reasonable
    Ada subset.

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

Re: New GNAT ports (was Re: Ada and Automotive Industry)

[Robert A Duff]

In article <5asvku$jtu$1@goanna.cs.rmit.edu.au>,
Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote:
>I've been studying the 8051 recently.
>I've convinced myself that with the aid of one more pragma [%]
>an Ada *subset* can straightforwardly do everything that assembler
>can do.

How would this subset compare to the Ada subset embedded in SPARK?

>...I mean, we're talking
>about systems where the wire would be the most expensive part!

Then why bother using a high-level language at all?  I mean, if the
software is small and cheap enough, then assembly works fine.

- Bob

Re: New GNAT ports (was Re: Ada and Automotive Industry)

[Robert Dewar]

Richard suggests:

[%] The pragma is
        pragma Origin(non-negative constant integer expression);
    saying that the first byte of the textually following statement
    is to be at the given address.  That was the only thing I saw in
    the 8051 book I was reading that I couldn't do in a reasonable
    Ada subset.

Well if we added this pragma, it is clear the argument should be of
type address, but in any case the pragma is redundant. The proper
diction is:

  for label'address use expression

and then you simply label the statement

It actually makes more conceptual sense to me to put a subprogram
at a particular address, rather than a statement, in which case you
can use

  for subprogram'address use expression

which is more familiar (and more likely to be supported out of the box,
although GNAT suports neither diction currently).

Re: New GNAT ports (was Re: Ada and Automotive Industry)

[Ken Garlington]

Richard A. O'Keefe wrote:
> 
> [%] The pragma is
>         pragma Origin(non-negative constant integer expression);
>     saying that the first byte of the textually following statement
>     is to be at the given address.  That was the only thing I saw in
>     the 8051 book I was reading that I couldn't do in a reasonable
>     Ada subset.

Couldn't this be handled via a combination of existing Ada support
(address
clauses, etc.) plus linker support? That's the way we usually handle
it with the MIL-STD-1750. I don't know if you want to specify origins
for
random code; usually, it's for a logically related set of
code/data/literals,
or for a specific object.

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: New GNAT ports (was Re: Ada and Automotive Industry)

[Robert Dewar]

Robert Duff asks (about a possible 8051 subset)

How would this subset compare to the Ada subset embedded in SPARK?


not comparable at all. The SPARK subset is not only aimed at reducing
runtime complexity, but also at reducing certification effort. If you
are interested in reducing runtime costs, then you are concerned with
things that have code generation impact (for instance, floating-point
might be out of the question, but generic instantiation and child
packages are irrelevant).

But if you are interested in certification, then floating-point may be
fine if you can find an acceptable formal model for floating-point, but
you may well decide to eliminate generics and child units on the grounds
that the complicate the formal models without providing any fudnamental
increase in expressive power.

By fudnamental here, I mean that you can always do generics yourself if
you have to for example,

Re: New GNAT ports (was Re: Ada and Automotive Industry)

[Karl Cooper]

Richard A. O'Keefe wrote:
> 
> I've been studying the 8051 recently.
> I've convinced myself that with the aid of one more pragma [%]
> an Ada *subset* can straightforwardly do everything that assembler
> can do.  snip 
> Would there be any point in writing this up?
> I've had wistful thoughts about a possible product.

We are deeply involved in a commercial product which depends heavily
on an 8051 derivative.  Over ten thousand lines of C code are being
maintained at the heart of this product.  Reliability and maintain-
ability issues have been raised.  Migrating the software to GNAT-
for-the-8051 might be a wise move for us.  Keep the group posted
as to progress.

Karl Cooper
contractor with
Additional Tech
Nashua, NH

Re: New GNAT ports (was Re: Ada and Automotive Industry)

[Richard A. O'Keefe]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>[%] The pragma is
>        pragma Origin(non-negative constant integer expression);

>Well if we added this pragma, it is clear the argument should be of
>type address, but in any case the pragma is redundant. The proper
>diction is:

>  for label'address use expression

>and then you simply label the statement

Ah.  I didn't know you could do that.  Where do you put it?
Can you provide an example?

>It actually makes more conceptual sense to me to put a subprogram
>at a particular address, rather than a statement, in which case you
>can use

>  for subprogram'address use expression

>which is more familiar (and more likely to be supported out of the box,
>although GNAT suports neither diction currently).

I agree, but remember, the question was not "what is more sense", or
"what is more familiar", or "what is more likely to be supported out
of the box" (the last because we're talking about a hypothetical _new_
compiler which _would_ support it).  The question was
	"is there anything you can do in 8051 assembler
	 [as shown by the examples in such-and-such an 8051 book]
	 that cannot be done, and done well, in Ada?"
Providing an address clause for a label is indeed a _much_ better
way to do it.

I note that AI-00336/05-ra-WJ says that
	"An address clause cannot be given for a subprogram
	 whose body acts as its declaration."
which I take to mean that a subprogram can have a normal body or
an address clause but not both.  A fortiori, I didn't expect
address clauses to work for labels either.  It certainly wasn't
legal syntax in Ada 83, according to LRM 13.5.

There is actually one more problem with the 8051, which is that
there are three kinds of addresses:
	- 16-bit instruction addresses
	- 16-bit external RAM addresses
	-  8-bit internal RAM addressse
However, this one _can_ be fixed using existing mechanisms:

	type Byte is mod 2**8;

	type Internal_Byte_Ptr is access Byte;
	for  Internal_Byte_Ptr'Size use  8;

	type External_Byte_Ptr is access Byte;
	for  External_Byte_Ptr'Size use 16;

	X: aliased Byte;
	for X'Address use System.R0'Address;	-- in Internal RAM
	PX: Internal_Byte_Ptr := X'Access;

	Y: aliased Byte;
	for Y'Address use System.Address'(External_RAM, 257);
	PY: External_Byte_Ptr := Y'Access;
	:

with System.Address being a suitable variant record type.  This really
shows off why Ada is better suited to this kind of thing than C.

So the net conclusion is that you can obtain a good language for 8051
programming by starting with Ada 95 and

 - adding for Label'Address use System.Address'(ROM, nnnnn);
   and/or allowing for Subprogram'Address use System'Address(ROM, nnnn);
   when a body is also provided.

 - enforcing restrictions.
   The set of restrictions in pragma Restrictions is implementation defined,
   so 8051-specific things like
	pragma Restrictions(No_Float);
   would be ok.

 - filling in the machine code facilities of the language suitably.

Does anyone else share my pleased surprise that so little is needed?

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

Re: New GNAT ports (was Re: Ada and Automotive Industry)

[Richard A. O'Keefe]

Ken Garlington <GarlingtonKE@lmtas.lmco.com> writes:
>Couldn't this be handled via a combination of existing Ada support
>(address clauses, etc.) plus linker support?
>I don't know if you want to specify origins for
>random code; usually, it's for a logically related set of
>code/data/literals, or for a specific object.

The only reason that I bothered about the placement of code at all
was that the 8051 book I was studying included a memory test program
that did this.  According to the Ada 83 LRM I had handy, you _couldn't_
supply address clauses for code.  I suggested a pragma because it seemed
to me that they were the _right_ way to add things like that; that
specific pragma wouldn't change the meaning of the code, so could be
stripped out for testing elsewhere.  When you are trying to make a
case that "language X can solve problem Y", opponents sometimes
regard appeal to "linker support" as a copout.

In the absence of an Ada-8051 compiler, if I had to write any microcontroller
code, I'd use Prolog or Lisp as a macro assembler, and build a lot of error
checking into it.

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

Re: New GNAT ports (was Re: Ada and Automotive Industry)

[Ken Garlington]

Robert Dewar wrote:
> 
> Richard suggests:
> 
> [%] The pragma is
>         pragma Origin(non-negative constant integer expression);
>     saying that the first byte of the textually following statement
>     is to be at the given address.  That was the only thing I saw in
>     the 8051 book I was reading that I couldn't do in a reasonable
>     Ada subset.
> 
> Well if we added this pragma, it is clear the argument should be of
> type address, but in any case the pragma is redundant. The proper
> diction is:
> 
>   for label'address use expression
> 
> and then you simply label the statement
> 
> It actually makes more conceptual sense to me to put a subprogram
> at a particular address, rather than a statement, in which case you
> can use
> 
>   for subprogram'address use expression
> 
> which is more familiar (and more likely to be supported out of the box,
> although GNAT suports neither diction currently).

I think you would also want to be able to control the placement of code,
and literal sections of a subprogram (and, for packages, static data)
indepedently,
but that's easily done via linker commands in many systems.

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: New GNAT ports (was Re: Ada and Automotive Industry)

[Robert Dewar]

Richard says

"I note that AI-00336/05-ra-WJ says that
        "An address clause cannot be given for a subprogram
         whose body acts as its declaration."
which I take to mean that a subprogram can have a normal body or
an address clause but not both.  A fortiori, I didn't expect
address clauses to work for labels either.  It certainly wasn't
legal syntax in Ada 83, according to LRM 13.5."


You are confused, the quoted sentence simly says that if you have
an address clause for a subprogram, it must have a separate spec. The
conclusion you draw does not follow. 

As for address on labels, in Ada 83, you could not specify the value
of attributes in general, but in Ada 95 you can with an attribute
definition clause. Since Address clearly aplies to labels:

11  X'Address
                Denotes the address of the first of the storage elements
                allocated to X. For a program unit or label, this value
                refers to the machine code associated with the corresponding
                body or statement.  The value of this attribute is of type
                System.Address.

This certainly means that an implementation *may* support the address 
clause for a label. 

The only requirement (well it is a requirement if Annex C is supported) is:

   17  An implementation should support Address clauses for imported
       subprograms.


So, you are not required to support address clauses for non-imported
subprograms, but in an embedded environment, it may well make sense
to support this.

Although it should be noted that an alternative mechanism to expressing
this kind of thing at the language level is to use what Intel would call
a locator to place code at specific locations in the final load image.

Re: New GNAT ports (was Re: Ada and Automotive Industry)

[Robert Dewar]

Richard said

"The only reason that I bothered about the placement of code at all
was that the 8051 book I was studying included a memory test program
that did this.  According to the Ada 83 LRM I had handy, you _couldn't_
supply address clauses for code."

That is wrong, Ada 83 did allow you to specify the address of a subprogram,
and in fact using this in conjunction with pragma Interface was a well
known way of fooling a compiler into providing a mechanism equiavlent to
an indirect call:


   procedure x;
   for x'address use expression; -- expression need not be static
   pragma interface (Ada, x);

now when you call x, you call the subprogram at the given address.
In fact CIFO specifically required this to work!

Re: New GNAT ports (was Re: Ada and Automotive Industry)

[Richard A. O'Keefe]

>Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote:
>I've been studying the 8051 recently.
>I've convinced myself that ...  an Ada *subset* can straightforwardly
>do everything that assembler can do.

bobduff@world.std.com (Robert A Duff) writes:
>How would this subset compare to the Ada subset embedded in SPARK?

I haven't yet found out what the SPARK subset is.
I believe SPARK omits exception handling, and it's not clear to me
that you need to do that.  With enough external ROM (often EPROM)
I think you can afford the tables and code to do it.  But it would
obviously be useful to exploit pragma Restrictions.

>>...I mean, we're talking
>>about systems where the wire would be the most expensive part!

>Then why bother using a high-level language at all?  I mean, if the
>software is small and cheap enough, then assembly works fine.

There is a serious non-sequitur there.  The wire would be the most
expensive *hardware* part (cheaper than the CPU chips).  That in no
way implies that the software would be cheap.  Using a high level
language is often a good way to make the software *cheaper*.
Then there is the distinction between _cost_ and _risk_.  A lot of
people got sucked into becoming "names" at Lloyd's; the _cost_ of
doing that was nowhere near as high as the _risk_, which turned out
to be catastrophic liability for asbestos claims for the foreseeable
future.  Even if using a high level language didn't reduce the
_immediate_ cost of the software, if it helped make it easier to
get it _right_, it could dramatically reduce subsequent liability
costs.  Suppose, for example, that there _were_ an Ada-8051
compiler that did a reasonable job, and that you wrote a program
in assembler, and it didn't quite work, and you got sued; would
you like it if the plaintiff's expert said in court that there
was a programming language around that _could_ have been used
which would have detected the error?

There've been a couple of occasions when I was asked to act as an
expert witness.  None of them came to court, but I promise you, I
was ready with a listing of 'lint' output...

A modern smart card may have, oh, 16k of code and 32k of EPROM, and
may run complicated encryption and/or compression algorithms.  Why
_not_ develop this code on a workstation with a good environment
first, and then bind it to the card chip later?

Bear in mind also that there are a couple of families of microcontroller
chips.  I've been thinking about the 8051 family, but it's a large family
with some odd members.  There _are_ potentially reusable components
(drivers for peripherals; security handshakes; compression code; ...)
that _might_ be more reusable in Ada+representation glue than in assembler.

And think about the things that a compiler can do for you.  The subroutine
call stack on the 8051 is very limited.  A compiler can
	- enforce a pragma Restrictions(No_Recursion);
	- expand in-line any subprogram that _happens_ to be called
	  in only one place
	- check that the final call graph does not exceed the usable
	  depth
	- perhaps even use some other calling mechanism for some
	  subprograms
When memory is so very tight, it would be nice to _know_ that you weren't
going to run out.


I am _not_ saying that developing an Ada-8051 compiler would be _easy_,
only that there appear to be no _technical_ barriers, only economic and
marketing ones.

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

Re: New GNAT ports (was Re: Ada and Automotive Industry)

[Robert Dewar]

Karl wrote:

"We are deeply involved in a commercial product which depends heavily
on an 8051 derivative.  Over ten thousand lines of C code are being
maintained at the heart of this product.  Reliability and maintain-
ability issues have been raised.  Migrating the software to GNAT-
for-the-8051 might be a wise move for us.  Keep the group posted
as to progress."

Just so no false hopes are raised here. The discussion so far has been
solely on feasibility. That I know of, no one is working on actually
doing a GNAT port. I do not even know if there is a gcc port, let alone
a good one, which is a prerequisite before even thinking about a GNAT port.

Soi

Re: New GNAT ports (was Re: Ada and Automotive Industry)

[Richard A. O'Keefe]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>Richard said

>"The only reason that I bothered about the placement of code at all
>was that the 8051 book I was studying included a memory test program
>that did this.  According to the Ada 83 LRM I had handy, you _couldn't_
>supply address clauses for code."

>That is wrong, Ada 83 did allow you to specify the address of a subprogram,

No, it is not wrong.  "code" is not a synonym of "subprogram".
The memory test program in question had reason to scatter _parts_ of
a subprogram around memory, and I appear to have got "Ada 83 didn't
let you supply address clauses for code _other_ than the start of a
subprogram" right.

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

Re: New GNAT ports (was Re: Ada and Automotive Industry)

[Richard A. O'Keefe]

I have recently been arguing that an Ada-8501 would be doable.

Karl Cooper <"X0723$"@mailgw.sanders.lockheed.com> writes:
>We are deeply involved in a commercial product which depends heavily
>on an 8051 derivative.  Over ten thousand lines of C code are being
>maintained at the heart of this product.  Reliability and maintain-
>ability issues have been raised.  Migrating the software to GNAT-
>for-the-8051 might be a wise move for us.  Keep the group posted
>as to progress.

I do hope I haven't misled anyone.
"wistful thoughts about a product" doesn't mean "concrete plans".
I *do* think it is doable.
I *would* be interested in doing it.
However, it's not the thing that I could reasonably do on my own in
my spare time.  There *are* some students talking to me about doing
a compiler project, but their previous experience consists of having
read the Dragon book.  (That's _good_ experience, but not enough, I
think.)

I've poked around in the GNAT sources from time to time, but have never
studied the whole thing.  People who _have_ studied it:  how long do you
think it would take to understand the GNAT front end well enough to
make an informed judgement about the difficulty of writing a non-GCC
back end for it?

As I see it, the main problems in a project to actually _do_ this include
 - making an informed judgement about whether the thing is possible
   in principle [done]
 - making an informed judgement about whether doing it by writing a new
   back end for GNAT (and adding some more Restrictions) [doable with
   present resources, save possibly time]
 - finishing the design of the pragmas, System additions, and machine
   code form.
 - producing some sample programs in Ada-8051 to arouse even more interest
   (say translating everything in the book I mentioned before) [a tiny bit
   done]
 - putting together a plan (even if it's people donating time,
   like the Linux project, how _many_ people? doing what exactly?)
 - getting together a group of volunteers 
 - making the necessary changes to the front end
 - building a back end (possibly adapting one from a free C-8051 to
   start with)
 - integrating and testing, which needs a preceding step of
 - producing test programs (new code + hand translated "real" code)
 ...

In the mean time, there's a statistics language which needs a compiler,
and I think that _is_ within the capabilities of the students and myself,
so unless someone offers me startup finance to do Ada-8051, I'd be doing
the other instead.

I guess that's the point:  the only barrier to Ada-8051 is _money_,
not technical issues.
-- 
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.

Re: New GNAT ports (was Re: Ada and Automotive Industry)

[Dr. Peter E. Obermayer]

Richard A. O'Keefe wrote:
> 
> >Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote:
> >I've been studying the 8051 recently.
> >I've convinced myself that ...  an Ada *subset* can straightforwardly
> >do everything that assembler can do.
> 
> bobduff@world.std.com (Robert A Duff) writes:
> >How would this subset compare to the Ada subset embedded in SPARK?
> 
> I haven't yet found out what the SPARK subset is.

Look at
   http://www.praxis.co.uk/technols/spark/sp_lang.htm#rationale

... lots of other things deleted

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

-- 
   _/_/_/ _/_/_/ _/_/_/ Dr. Peter E. Obermayer 
  _/     _/       _/                           Tel.:  (05931) 805-163
 _/     _/       _/     Lohberg 10             Fax:   (05931) 842-163
_/_/_/ _/_/_/ _/_/_/    D-49716 Meppen         E-Mail: obermayer@cci.de

Re: New GNAT ports (was Re: Ada and Automotive Industry)

[Robert Dewar]

Richard said

"I've poked around in the GNAT sources from time to time, but have never
studied the whole thing.  People who _have_ studied it:  how long do you
think it would take to understand the GNAT front end well enough to
make an informed judgement about the difficulty of writing a non-GCC
back end for it?"

The front end of GNAT is pretty accessible. Read the documentation in
sinfo and einfo to get a definition of the tree that is produced.
Writing a production quality backend for any machine from scratch is
a big project, of the order of person years for someone who knows what
they are doing. Adapting an existing backend (if one is available that
can be GPL'ed) is certainly a possibility, although sometimes clashes
in assumptions can make such a project harder than expected. Note that
the Ada Magic front end is more deliberately setup to provide for
interfacing with multiple backends (this is obviously not a criterion
for GNAT, since the assumption is that only one backend, GCC, will be
used).

Certainly building a small trial code generator hooked into the backend
of GNAT is practical. I am planning on having my students in my compiler
class do that this coming semester.

Re: New GNAT ports (was Re: Ada and Automotive Industry)

[Ken Garlington]

Richard A. O'Keefe wrote:
> 
> Ken Garlington <GarlingtonKE@lmtas.lmco.com> writes:
> >Couldn't this be handled via a combination of existing Ada support
> >(address clauses, etc.) plus linker support?
> >I don't know if you want to specify origins for
> >random code; usually, it's for a logically related set of
> >code/data/literals, or for a specific object.
> 
> The only reason that I bothered about the placement of code at all
> was that the 8051 book I was studying included a memory test program
> that did this.  According to the Ada 83 LRM I had handy, you _couldn't_
> supply address clauses for code.

As Dr. Dewar has already responded, you can (and we have) done this in
Ada 83.
In general, ROM tests can be done in Ada 83 (and in Ada 95, with the
ability
to manipulate addresses, it can be done _portably_ ;) Usually, rather
than attempting to place the Ada objects to be tested at certain areas,
we perform
address manipulations to scan a given area of memory, where the regions
are
specified as constants not related to the placement of Ada objects.

_RAM_ tests, on the other hand, are a little interesting in Ada (and a
lot
of other high-order languages). Consider, for example, a non-destructive
RAM
test involving writing a value to RAM, reading the value back, and
making sure
they match. A typical algorithm is to break RAM into blocks of a
particular size,
reserve one block for the RAM test, and then do the following:

  Test(Reserved_Block);
  for Block_Index in All_Blocks loop
    Reserved_Block := RAM_Block(Block_Index);
    Test(RAM_Block(Block_Index));
    RAM_Block(Block_Index) := Reserved_Block;
  end loop;

What gets interesting is that the stack and heap are going to be
destroyed as a part
of this procedure. If Test tries to access the stack/heap while it's
overwritten...
bad business! Perhaps

   pragma (Local_Values_in_Registers_Only)

would help? :)

Usually, we write such a routine in assembly. Since it's such a small
part of the
total system, the maintenance impacts are negligible.

> I suggested a pragma because it seemed
> to me that they were the _right_ way to add things like that; that
> specific pragma wouldn't change the meaning of the code, so could be
> stripped out for testing elsewhere.  When you are trying to make a
> case that "language X can solve problem Y", opponents sometimes
> regard appeal to "linker support" as a copout.

Realistically, however, there are always some low-level operations
that will require linker support, regardless of the language, for any
language which allows the compilation of components at different times.
So, I would say that someone who makes such an objection isn't going to
be swayed by any reasonable argument.

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: New GNAT ports (was Re: Ada and Automotive Industry)

[Robert I. Eachus]

In article <5avdtl$hir$1@goanna.cs.rmit.edu.au> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

 >  I note that AI-00336/05-ra-WJ says that
 >	   "An address clause cannot be given for a subprogram
 >	    whose body acts as its declaration."
 >  which I take to mean that a subprogram can have a normal body or
 >  an address clause but not both....

   Don't get confused by the RM-speak.  All this says is that if you
want to have such an address clause, the specification to which it
applies must be explicit.  In other works:

   procedure Foo;
   for Foo'Address use Some_Address;
   ...
   procedure body Foo is....

   The address clause has to appear after the declaration but before
the body, and that is difficult if they are the same unit.  (It is
also difficult to do right for generic instantiations.)  But, as far
as I can tell that is an Ada 83 rule only.  In Ada 95, an
implementation is allowed to--but not required to--support an address
clause for an implicitly defined procedure.  (But don't hold your
breath.)

    Note also that the addresses are not required by the language to
be static.  However, a compiler can put in such a restriction.  (The
sensible choice for an implementation would seem to be to support all
address clauses that can be resolved at link-time.)

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: New GNAT ports (was Re: Ada and Automotive Industry)

[Robert I. Eachus]

In article <dewar.852814793@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

  > Writing a production quality backend for any machine from scratch is
  > a big project, of the order of person years for someone who knows what
  > they are doing. Adapting an existing backend (if one is available that
  > can be GPL'ed) is certainly a possibility, although sometimes clashes
  > in assumptions can make such a project harder than expected.

   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.  But a
gcc version that targets are 386 or higher is probably a waste of
effort as a starting point.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: New GNAT ports (was Re: Ada and Automotive Industry)

[Robert Dewar]

Richard said

"No, it is not wrong.  "code" is not a synonym of "subprogram".
The memory test program in question had reason to scatter _parts_ of
a subprogram around memory, and I appear to have got "Ada 83 didn't
let you supply address clauses for code _other_ than the start of a
subprogram" right."

Well I still think it is wrong to try to do that at the source code level,
I prefer the kind of approach Intel uses with a separate locator, i.e. you
break the code into chunks, call them control sections or whatever, but
they are named chunks, and then the locator places these named chunks at
specified locations.

Re: New GNAT ports (was Re: Ada and Automotive Industry)

[Robert Dewar]

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.  But a
gcc version that targets are 386 or higher is probably a waste of
effort as a starting point."


This is a little confused. There is only one version of GCC, which is
common across all targets. What specializes GCC to a particular target
is the machine description file, which is essentially a formal description
of the semantics of the target architecture. I don't see that the 
MD file for the 8086 would be a particularly helpful starting point for
the 8051, except perhaps as a general indication of how MD files are
written, although if you are not already thoroughly familiar with the
mechanics of writing MD files for GCC, then you would be unlikely to
succeed anyway with the 8051, which as has often been discussed here,
is not an easy machine to target.

Now it is also the case that if you tried to do an efficient GCC port
to the 8051, you might well need to make some improvements in GCC, that's
a steady process, and often driven by requirements that are initially
generated by targetting to new architectures. The general idea here is
not to put in special kludges for particular architectures (there is almost
no specialization of this kind in GCC), but rather to abstract the general
features involved, and provide enhancements that will be useful to any
targets sharing the particular features involved.

So it is quite likely that the 8051 might suggest some general improvements
of this type, but there again, I doubt the 8086 would be a useful comparison
point.

Addresses of Subprograms (was: New GNAT ports)

[Larry Kilgallen]

In article <dewar.852774527@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Richard said
> 
> "The only reason that I bothered about the placement of code at all
> was that the 8051 book I was studying included a memory test program
> that did this.  According to the Ada 83 LRM I had handy, you _couldn't_
> supply address clauses for code."
> 
> That is wrong, Ada 83 did allow you to specify the address of a subprogram,
> and in fact using this in conjunction with pragma Interface was a well
> known way of fooling a compiler into providing a mechanism equiavlent to
> an indirect call:

Was that a requirement ?  The VAX Ada Version 2.0 manual I have from
DEC shows a little pentagon-shaped logo saying "Validated Ada" in the
middle and cites ANSI/MIL-STD 1815A as determined by the AJPO under
its current testing procedures.

But Section 13.5 after Paragraph 7 has vendor-specific (blue) text
saying "In VAX Ada, the simple name must be the name of an object."

Larry Kilgallen

Re: New GNAT ports (was Re: Ada and Automotive Industry)

[Richard A. O'Keefe]

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

Re: Addresses of Subprograms (was: New GNAT ports)

[Larry Kilgallen]

 In article <dewar.852774527@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Richard said
> 
> "The only reason that I bothered about the placement of code at all
> was that the 8051 book I was studying included a memory test program
> that did this.  According to the Ada 83 LRM I had handy, you _couldn't_
> supply address clauses for code."
> 
> That is wrong, Ada 83 did allow you to specify the address of a subprogram,
> and in fact using this in conjunction with pragma Interface was a well
> known way of fooling a compiler into providing a mechanism equiavlent to
> an indirect call:

These two uses for specifying the address of code (memory test vs.
indirect call) would seem to conflict in the case of Alpha VMS
where the "procedure value" commonly passed as the "address"
of a subprogram is quite different from the address of the first
instruction of the subprogram executable code.

I am curious regarding the approach ACT is taking in this regard.

The need for fooling the compiler goes away in Ada95, and the use
of a different mechanism in DEC Ada means code migrating from there
would not depend on that trick for indirect calls.

Macintosh 68K images depend heavily on a "jump table" where once
again the "address" of a routine is quite a different thing from
the location of its code (and, in fact, the location of the code
might not be resolved until call time).

Do other operating systems have this separation, and which is the
"true" meaning for specifying the address of a subprogram from an
Ada perspective ?

Larry Kilgallen

Re: Addresses of Subprograms (was: New GNAT ports)

[Richard A. O'Keefe]

kilgallen@eisner.decus.org (Larry Kilgallen) writes:
[There is a distinction between the "address" of a subprogram,
 meaning "what do I use for an indirect call"
 and the "address" of a subprogram,
 meaning "where does the executable code start".
 He cites the Alpha VMS and Macintosh 68k environments as examples,
 and asks
]
>Do other operating systems have this separation, and which is the
>"true" meaning for specifying the address of a subprogram from an
>Ada perspective ?

The Apollo systems did this too.  I never used Aegis, but the UNIX
systems they shipped had C function pointers being pointers to
indirect blocks, the actual code being elsewhere.  It was actually
a pain for us (Quintus) because we wanted to put a certain procedure
at a particular address (so we could use 16-bit addresses on a 68k)
and you could never expect a procedure to be in the same place twice
running.

Lisp systems have often done this (the "slow link" / "fast link"
distinction) in order to support run-time redefinition of procedures.

What do the Ada->J-code compilers do?

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

Re: Addresses of Subprograms (was: New GNAT ports)

[Fergus Henderson]

ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) summarizes
kilgallen@eisner.decus.org (Larry Kilgallen)'s query:
>[There is a distinction between the "address" of a subprogram,
> meaning "what do I use for an indirect call"
> and the "address" of a subprogram,
> meaning "where does the executable code start".
> He cites the Alpha VMS and Macintosh 68k environments as examples,
> and asks
>]
>>Do other operating systems have this separation, and which is the
>>"true" meaning for specifying the address of a subprogram from an
>>Ada perspective ?

I think RS/6000 systems running AIX also have this distinction.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Addresses of Subprograms (was: New GNAT ports)

[Richard Kenner]

In article <1997Jan13.102240.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
>These two uses for specifying the address of code (memory test vs.
>indirect call) would seem to conflict in the case of Alpha VMS
>where the "procedure value" commonly passed as the "address"
>of a subprogram is quite different from the address of the first
>instruction of the subprogram executable code.

This is also the case on most ABIs for the RS/6000 and PowerPC.