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
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.
> > 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
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