TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Ken Garlington <[log in to unmask]>
Wed, 13 Nov 1996 17:05:39 +0000
Lockheed Martin Tactical Aircraft Systems
Ken Garlington <[log in to unmask]>
text/plain (80 lines)
Philip Johnson wrote:
> Why do you need to implement a subset for 8 and 16 bit processors?  I
> have used
> data types similar to those in Ada on 8 and 16 bit processors for years.
> What
> part of the Ada language do you believe cannot be supported on these
> processors?
> I have used assembler, C, Pascal, and Modula-2 on this class of
> processors for over
> 20 years.  Ada does not present any feature that cannot be supported on
> the smaller
> data model processors.

Strong type checking ("data types") would not generally be an issue, I
suspect. I am more concerned with maintaining task control blocks for
tasks/protected records and their associated queues. Although I haven't
received my copy of GNAT yet (I can't use the Internet to download it,
for reasons too perverse to explain), it's my understanding that the
implementation of tasks, etc. typically rely on the existence of an OS
that supports threads. For a bare-machine 8-bit microcontroller, you'll
have to roll your own. If you have to allocate dynamic memory for such
things as maintaining queue entries, etc. a general-purpose solution
might quickly overflow 256 bytes. On the other hand, if you're just
using tasks to connect to interrupts, then the resulting restrictions
should allow for very small (possibly no) TCBs.

Heap allocation is a little more uncertain. It can probably be done,
but on a machine with almost no dynamic memory, is it worth the effort?
Just maintaining a stack is probably going to be interesting...

Ada.Text_IO is kinda in the same boat. Why bother implementing a file
system on such a machine? It may not even have a port to connect to
a conventional I/O device like a terminal or a printer...

The short answer is: If it's easy to implement full Ada on an 8-bit
microcontroller, that's what I'll do. However, I suspect that when
converting all those OS calls, I'm going to hit some problems.

> The implementation of Ada tasking should meet the system architecture.
> I have used
> Ada tasking on Unix that is implemented as child processes.
> The
> ObjectAda that I
> am using on WindowsNT implements tasks as treaded processes.

"Unix"? "WindowsNT"? I think I could fit these strings in 256 bytes,
but that's about it... :)

> This appears more of a DOD type embedded system rather that commercial.
> There
> are certainly commercial embedded controller systems that fit this model
> but I
> do not believe Ada is necessarily that correct language for this type
> architecture.

Why not? (Actually, you can find these kinds of systems in both military
and commercial usage).

> Over the past 24 years I have seen and used "Tiny" and "Small" language
> implementations,
> such as "Small C", "Tiny Pascal", "PLM", etc.  Every one of these
> subsets caused more
> problems that fully implemented versions of the target language.  Every
> one created a
> problem because each implementation was slightly different, so source
> code was not
> completely portable.

Most of the current implementations are in assembly, so I don't think
I'm going to harm portability much :) However, certainly it would be
useful if the ARA or some other group defined a standard. Sy Wong argued
for this at the last TRI-Ada, and the vendor community said "no way".

LMTAS - "Our Brand Means Quality"
For more info, see or