TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Proportional 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
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Subject:
From:
Philip Johnson <[log in to unmask]>
Date:
Wed, 13 Nov 1996 11:41:16 -0600
X-To:
Ken Garlington <[log in to unmask]>
Reply-To:
Parts/Attachments:
text/plain (146 lines)
>Ken Garlington wrote:
>> Sy Wong wrote:

[deleted stuff]

> I was actually planning on trying (on my own time) to create an Ada subset
> using GNAT, that would be applicable to 8-bit and 16-bit microcontroller
> software. Right now, we have to ask for waivers for a lot of these
> applications. If someone has already done some work on defining such a
> subset, I'd like to know how it was derived. Certainly, if we don't come up
> with a version of Ada that doesn't require much (if any RAM), we'll never
> get past using C and assembly for these tiny processors, which seem to pop up
> in all sorts of applications.

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.

>
> It would be nice if the tasking model could be used where appropriate; for
> example, as interrupt handlers. I don't know if direct task interactions
> could be supported or not. I think a limited form of protected records is
> also supportable. In some form, generics and exception handling would also be
> useful. Text_IO is probably out (although a Low_Level_IO package would be
> nice). Machine code insertions are a must.

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.  I am
probably missing something but I do not see why a task should be
implemented as an interrupt handler.
I can see tasking using an interrupt structure in the rendezvous
mechanism to prevent
race conditions from occuring.

>
> I actually don't see the problem with building a "tiny Ada" or CDL compiler
> under the current rules. You can certainly pass validation using a subset of
> tests, if you can show that the other tests are inappropriate for a given
> target. I would think a target with 256 bytes of RAM, for example, would be
> reasonable grounds for not supporting heap management, etc. However, without
> someone having a compelling reason to try to build such a product, we'll
> never know for sure. The developers of such systems won't use Ada because (a)
> they are usually writing less than 4K of source code. so the advantages of
> Ada are less obvious, and (b) there's no compilers. Compiler vendor's won't
> build compilers because the users aren't begging them to build something.

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.

> By the way, I can't claim Lockheed Martin is behind me on this; I had hoped
> to demonstrate the feasibility of "tiny Ada" on a microcontroller, and then
> show how extending Ada to those kinds of systems could be a Good Thing.
> However, it's just a hobby for me at the moment; I haven't had time to do
> much work on this.

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.

It is my belief that on reason to use Ada [fully implemented for each of
the different architectures) provide portability.  I really do not want
to have to beat
my brains out porting my code to different processors.  Porting Ada
should ONLY
require slight adjustments due to architecture and system differences.

[deleted stuff]

> > Purpose. To extend Ada use to the commercial sector
> > where nobody touches Ada or mentions Ada, particular in the areas of
> >   a. SSS
> >   b. the Electronic Design Automation and
> >   c. hard real-time embedded applications.

I must be mistaken.  I am a developer in the commercial sector and
writting a "HARD,
Real-time" system in Ada.  I do not remember exactly but believe I saw
on PAL a
hardware definition language base in Ada.

In a past life I worked for a small company her in Huntsville, Alabama
named Intergraph
Corp.  We did (they still do) EDA.  The modeling language was
standardized on VHDL long
ago.  There are several other imtermediate modeling languages but do not
see any advantage in pushing Ada as an EDA modeling language.  Please
elaborate why this would
be a good thing.

> >
> > What follows applies only to the commercial sector which, unlike the
> > military market the Ada vendor depends on, it is a competitive
> > environment where any drag on economy cannot be tolerated.

It is an economic drag to produce language subsets that causes
portability to be
diminished.  In the commercial sector we must be ready to move to
different system
architecture when the customers demand it.  Non-portability has a higher
probability
of killing a commercial product that require more memory or a larger
ROM.

[Deleted Annex-H stuff]

Phil Johnson
--
 _______________________________________________________________________
|
|
|                Ada, Perl, and Java! It can't get any better.
|
|
|
|Philip Johnson                             Telco: (205) 890-1178
|
|Sr. Software Engineer                      Fax  : (205) 890-1174
|
|International Space Systems Inc.           email: [log in to unmask]
|
|Huntsville, AL
|
-----------------------------------------------------------------------

ATOM RSS1 RSS2