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

[ok@goanna.cs.rmit.edu.au (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.