Re: Restructuring of Ada (was RE: Ada on Cypress CY7C646 (8051)?)

["Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>]

Well, almost anything you do is going to make someone unhappy. Remember this
part though: The current Ada language is suitable for embedded programming
and many of the more difficult features were put there specifically as an
aid to embedded and realtime programming. (Tasks, protected types, etc.)
I've seen this sort of thing stuck on machines as small as a MilStd1750a (16
bit processor with on-board floating point) So it isn't that the language is
too big for most microcomputers (although you may need to be careful about
which features you use and how much you use them.) The problem comes when
you start talking about real small processors that might be able to support
an Integer-C implementation, but would have difficulty handling something
like tasking at the level required for validated Ada95.

I don't know if you'd ever succeed in getting consensus on drawing rings
around Ada features and having something like "Tiny Ada" for small
microcontrollers, "Ada" for normal sized microcomputers and "Super Ada" that
includes all annexes. Obviously, the annexes were a means of extending the
language without extending the language. It provides for subsets, if you
like. (Although the annexes are effectively defined in terms of the syntax &
semantics of the Ada language - so it doesn't really present new stuff for
the compiler to somehow parse & translate.) I definitely like the idea of
specialized annexes that can be implemented in the core language. It allows
for some product distinction and makes it easy to flesh out the language to
make it more useful. Where I stand on subsets, I'm not sure. If you can't
parse and translate the whole of Ada, that has significant problems & leads
to divergence in the community. OTOH, it allows the language to address more
markets.

Maybe the answer is to define a language (Call it "Soren" after one of my
favorite philosophers?) that is effectively a subset of Ada and just not
expect it to have anything to do with Ada, except for always trailing the
Ada standard around. If we picked the chapters/verses of the ARM that had no
unreasonable limitations for small machines as the standard for "Soren" and
ignored the rest, you'd effectively have a language that could pass through
any Ada compiler and work, yet could be the subject of specialized compilers
aimed at small machines.

I don't know. There isn't a really good answer here & one needs to ask if
there is sufficient interest from the intended market to make it worth the
trouble of devising some answer. I think most of the guys doing the
small-CPU job would rather not consider Ada - I could be wrong.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Beard, Frank" <beardf@spawar.navy.mil> wrote in message
news:mailman.991936511.7654.comp.lang.ada@ada.eu.org...
>
>
> It seems like Ada needs to be restructured a bit.  I like the idea
> of having Annexes, but, as others have pointed out, they're optional.
> We've had discussions in the past about adding new capabilities to
> the language, whether or not to add them to the core or annexes, and
> others had concerns that we would no longer have a language suitable
> for embedded programming if we added the features to the core.
>
> It seems to me that maybe we should take the approach of having the
> "core" be everything needed to support embedded programming, then have
> the "expanded core" be the additional features for general programming,
> and then the Annexes for the specialized enhancements.
>
> That way, Ada compilers for embedded systems would only need to support
> the embedded set.  Ada compilers for non-embedded applications would
> have to support through the "expanded core", and the Annexes would
> remain as they are.
>
> Just a thought.  I'll leave it to the Ada brain-trust to consider
> the feasibility.
>
> Frank Beard