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:
Ken Garlington <[log in to unmask]>
Date:
Sat, 16 Nov 1996 15:35:05 +0000
X-To:
Michael Feldman <[log in to unmask]>
Organization:
Lockheed Martin Tactical Aircraft Systems
Reply-To:
Ken Garlington <[log in to unmask]>
Parts/Attachments:
text/plain (192 lines)
Michael Feldman wrote:
>
> We'll never know till we try, will we? I have had lengthy discussions with
> various validation gurus on this subject; these really went nowhere.
> Better, IMHO, to follow Sy's suggestion and test the desired compiler
> using the appropriate ACVC subset, and leave the politics of _actual_
> validation for a later stage.

Maybe I misunderstood. I thought Sy _wanted_ a formally-defined subset with
a validation suite? Isn't that how the issue got raised in the first place?

> In the TQM class my wife had to sit through, this was called "cutting
> the low-hanging apples first," that is, doing the stuff you can do, and
> not holding it hostage to resolving controversial issues.

As I said, this is the only way it's going to get done. This certainly
doesn't mean it's the _right_ way, however.

> I think the proper order is
>
> (1) define just what you want. Don;t tinker with the syntax, try to
>     define the desired set of valid programs using Annex H Restrictions.

Unfortunately, this can't be done without a significant amount of
support from the Ada community.

> (2) build the compiler as simply as possible. This means starting
>     with GNAT and building a back end for the desired platform; it would
>     be the height of foolishness to mess with the GNAT front end or try
>     to write a compiler from scratch (yet).

This is what I think the real #1 will have to be. A working model will
be built, and then the language subset (or restrictions, if that's all
it will take) will be defined from the working compiler.

> (3) see who's REALLY interested in it.
>
> (4) discuss validation _only_ after the thing has a track record.

Unfortunately, that's the only way it's going to work.

> >
> > We seem to have a lot of these "chicken-and-egg" situations. For example:
>
> Much of Ada has been "chicken and egg." We get into these deadly embraces -
> everyone has great ideas, but wants others to implement or pay for them.

But perhaps not always. For example, did Intermetrics really do a market
survey and find a lot of users wanting to write Ada applets, or did someone
at Intermetrics say, "Wouldn't it be neat to do this? Let's build a beta and
see if there's a market."

If the latter, it's unfortunate that an Intermetrics (or some other compiler
vendor) wouldn't do the same for these small processors: Build an Ada 95
implementation (or a subset, if required) for some popular 8-bit microsequencers,
advertise it in ESP and similar rags, and see who buys it.

> >
> > 1. Users don't use Ada for tiny processors because there's no Ada
> > implementation for their processor. So, they use assembly or C.
> >
> > 2. There's no Ada implementation because no vendor has built one.
> >
> > 3. No vendor has built one because (opinions vary among the following):
> >
> >    (a) There's no market for it (see 1 above).
> >    (b) It is technically difficult to implement full Ada on these
> >        processors.
>
> I don;t think this has ever been demonstrated. Ada was conceived for
> embedded systems, and based on the early experience with early compilers
> for bigger boxes with big OS-es on them, everyone seems to buy into this
> assumption.

Note the "opinions vary among the following." We can at least say there's
not a lot of evidence to the contrary for 8-bit systems, right?

>
> >        (i)  No one has implemented a subset compiler, because there's
> >             no definition of the subset
>
> Well, this list has a lot of smart people on it. I'll volunteer to host
> a small mailing list _just_ for those who are willing to get into serious
> discussions on _this_ subject. If in the next week I get a dozen e-mail
> notes from serious people (no lurkers or kibitzers, please!), I'll
> set up the list at GW. Maybe this will break the vicious circle.

OK with me!

>
> >        (ii) There's no definition of the subset, because there's no
> >             market to drive a subset (see 1 above).
>
> But we seem to have plenty of people on Team-Ada with expert opinions
> on the subject, don;t we? Who wants to get down to serious work?

Unfortunately, every time I've seen this issue raised (on comp.lang.ada,
or last year's TRI-Ada), the "expert opinions" seemed to mostly be "this
is a stupid idea."

I'm no language lawyer, but I've already posted some ideas, and I'm certainly
willing to participate to the extent of my knowledge and experience.

> >
> >    (c) Ada (even a subset) doesn't "make sense" for small processors
> >        (I don't buy this, but I could be wrong).
>
> This remains to be seen. There is, in my experience, no a priori reason
> to exclude a small-processor _target_, hosted on some other GNAT host
> (given the ease of setting up GNU crosses, _any_ GNAT host, even a DOS
> box, will do.)

I definitely think a DOS and/or Wintel host makes sense for these targets.
These seem to be the platforms of choice for C, etc. Given that developers
for these targets have development cost as a major issue, the cheaper the
host the better.

> >
> >    (d) All of the above.
> >
> > My personal belief is that the best way to fix this is at point 2.
> > Someone needs to build an implementation for a few popular tiny
> > processors (possibly as a subset), market it, and see if anyone buys
> > it.
>
> Step 1 is to define the desired language, as I outlined above.

Go for it! No one would be happier than I.

It just hasn't worked at all to date, unfortunately.

>
> > You can do this as a business venture, of course
> > (it's called "creating a market"), but I don't see any Ada vendor who
> > wants to create this market badly enough.
>
> Right.
>
> > So, it will be more likely that someone
> > will do this just for the challenge of seeing if it can be done.
>
> Right. This is how GNAT-Mac got started. A few of us decided to just
> do it, to break exactly the same kind of vicious circle. Midway through
> the doing, it turned out we found some funds to help it along, and
> we will end up with a VERY nice forthcoming commercial release.
>
> Earlier, we broke another vicious circle: a cheap, student-oriented
> compiler. A lot of volunteer work, augmented later with a teeny bit
> ($40k) of AJPO funding, produced the 2 GW-Ada/Ed's (DOS, Mac), which
> got many hundreds, if not thousands, of students started with Ada
> till these systems were superceded by GNAT.
>
> In both of these cases, what made it possible was _leveraging_
> existing compilers (Ada/Ed, GNAT) and adding value.
>
> Dunno - maybe it takes a few crazy CS professors to break the loop.
>
> > This has a low probability of success, but it seems to be the only way.
>
> It seems defeatist to say it has a low probability of success. Given
> a few people who know what they're doing and want to do it, it could
> succeed.

Exactly. You need a few people who both (a) know what they're doing and
(b) want to do it. There's a good supply of the former, pitifully few of the
latter (for the tiny processor support), and almost none in both categories.
Defeatist or realist? I'll let history judge that.

> >
> > > C compilers are not (in general) validated, and C++
> > > ones are certainly not, because there is no standard to validate against.
> >
> > Tom Peters calls this the "We're no worse than anyone else" problem. To break
> > into a new market, you need powerful competitive advantages. It's often smarter
> > to do things _because_ your competitors aren't doing them -- like having an
> > independent organization (e.g. NIST) make a statement about the quality of your
> > compiler, and/or working to a widely-accepted and formally controlled (if not
> > internationally standardized) specification of your product, and/or having the
> > support of a large group that "gets out the word" on a new project. For this
> > project (an Ada subset compiler for tiny processors), I would say we're 0 for 3.
>
> I agree, but you are forgetting that validation has an entrenched "culture"
> that is - at the moment, anyway, unfriendly to the idea. THat's a
> high-hanging apple; cut it down later!
> >
>
> Mike Feldman

--
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

ATOM RSS1 RSS2