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

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

[Beard, Frank]

-----Original Message-----
From: Marin David Condic [mailto:marin.condic.auntie.spam@pacemicro.com]

> I think the problem with subsets is quite a tangled web. Not having an
> "official" subset for small computers means that a) nobody uses Ada for
> small computers or b) at best you end up with hundreds of incompatible
> subsets. History has been more towards A. You can't get Ada for most small
> machines. Hence the guys using those sorts of small machines have no
> interest in Ada. I don't know that there is any good answer to this.
> Demanding "One and only one Ada" is a good thing in many respects, but how
> does one then make it possible to have Ada on a tiny computer?
> 
> MDC

> > "Brian Catlin" <briancatlin@mindspring.com> wrote in message
> > news:9fmfju$43n$1@slb0.atl.mindspring.net...
> > I know that Robert Dewar had a conniption back in '95
> > when someone suggested subsetting Ada to get it onto an
> > 8051.
> >
> >  -Brian
> >

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

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

[Marin David Condic]

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

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

[Philip Anderson]

Marin David Condic wrote:
<snip> 
> 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.

Replace "small machines" with "safety-related systems" and you'll get
the rationale for SPARK.  It's a subset of Ada, since certain constructs
are not allowed, although extended by annotations in the form of Ada
comments.  So it passes through any Ada compiler, which generates the
required assembly code, but the SPARK rules are checked by SPARK tools.

Of course, it's not quite the same since you need a specialist compiler
to generate the small machine code, but I wonder whether an Ada compiler
generating C as an intermediate level is an answer?


-- 
hwyl/cheers,
Philip Anderson
Alenia Marconi Systems
Cwmbr�n, Cymru/Wales

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

[Marin David Condic]

I was thinking about SPARK while writing the post. Its a fair example of
subsetting Ada - except for the catch that you observe: SPARK is intended to
avoid "dangerous" constructs within an existing implementation of Ada. I
could use SPARK when doing safety critical programming on a PC or Unix
system with an existing compiler with little or no special compiler
modifications. A language aimed at small computers would pretty much require
that a special compiler be built. (Or at least you'd have to heavily modify
an existing compiler to accept only some subset of Ada as input and to
generate the machine code for the computer of interest.)

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/


"Philip Anderson" <phil.anderson@amsjv.com> wrote in message
news:3B209AB8.51ECEEFA@amsjv.com...
>
> Replace "small machines" with "safety-related systems" and you'll get
> the rationale for SPARK.  It's a subset of Ada, since certain constructs
> are not allowed, although extended by annotations in the form of Ada
> comments.  So it passes through any Ada compiler, which generates the
> required assembly code, but the SPARK rules are checked by SPARK tools.
>
> Of course, it's not quite the same since you need a specialist compiler
> to generate the small machine code, but I wonder whether an Ada compiler
> generating C as an intermediate level is an answer?
>

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

[Marin David Condic]

I should have said something on this aspect as well: The generation of C and
subsequent running it through the C compiler starts becoming a difficult
sell. It can complicate the development process (not necessarily - if the
thing is so highly integrated as to make the C part invisible) and then you
get this question: "Well if its got to use the C compiler, why not just
program it in C and not support *two* languages?" Its a tough one when
you're looking at relatively small programs that tend to not benefit
humungously from the "Programming In The Large" concepts of Ada. The type
checking and constraint checking, etc. are all nice, but does it buy enough
benefit to justify added complexity in the development process? If it is
*really seamless* (you never see the C compiler and all the development
tools work as if Ada was their natural home) and the cost is not
significantly more, then maybe it flies. So far, I don't see this happening
a lot. (Try looking at the web sites of manufacturers who sell SBCs with
development kits. How many will you find that give the end user the choice
of using Ada?)

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/

"Philip Anderson" <phil.anderson@amsjv.com> wrote in message
news:3B209AB8.51ECEEFA@amsjv.com...
>
> Of course, it's not quite the same since you need a specialist compiler
> to generate the small machine code, but I wonder whether an Ada compiler
> generating C as an intermediate level is an answer?
>

Ada and SBC's, was: Re: Restructuring of Ada

[Simon Clubley]

On Fri, 8 Jun 2001 10:30:41 -0400, in article <9fqnij$nva$1@nh.pace.co.uk>,
Marin David Condic wrote:
>
>(Try looking at the web sites of manufacturers who sell SBCs with
>development kits. How many will you find that give the end user the choice
>of using Ada?)

So far I haven't found any. :-( I am always interested in hearing about any
combined SBC/development kits with Ada support, which are at prices that an
individual can afford. (At the moment, I'm looking at RTEMS and then MaRTE.)

Simon.

PS: I was amused to see that an Ada environment has been created for some Lego
toy called Mindstorms; it would be nice to see the same development for a
SBC. :-)


-- 
Simon Clubley, simon_clubley@remove_me.excite.com-Earth.UFP
Worrying idea #101: What if Microsoft goes into the Ada compiler business ?

Re: Ada and SBC's, was: Re: Restructuring of Ada

[Marin David Condic]

The Lego thingie was discussed here and appeared in Ada Letters (SIGAda/ACM)
and I think it is a good thing. There may be a few SBCs out there that offer
Ada. Green Hills would be one place to look since they tend to specialize in
embedded compilers. However, every time I've hit a website that had a nice,
cute little board that didn't cost much and could be used for a number of
clever little projects, invariably they offer a PC based C compiler &
development tools. How to get Ada more widespread in that market? I don't
know. Perhaps it involves figuring out who makes the development kits
(they're not all built by the SBC manufacturers, I'll bet) and see if they
could be talked into partnering to offer an Ada front end? If they thought
it wouldn't cost them a fortune & there were enough users out there
interested, they might see it as a product distinction quality.

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/


"Simon Clubley" <simon_clubley@remove_me.excite.com-Earth.UFP> wrote in
message news:7Q8U6.1223$pb1.42602@www.newsranger.com...
>
> So far I haven't found any. :-( I am always interested in hearing about
any
> combined SBC/development kits with Ada support, which are at prices that
an
> individual can afford. (At the moment, I'm looking at RTEMS and then
MaRTE.)
>
> Simon.
>
> PS: I was amused to see that an Ada environment has been created for some
Lego
> toy called Mindstorms; it would be nice to see the same development for a
> SBC. :-)
>
>
> --
> Simon Clubley, simon_clubley@remove_me.excite.com-Earth.UFP
> Worrying idea #101: What if Microsoft goes into the Ada compiler business
?