From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,de555fb9935cdff1 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-06-07 12:05:59 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.cwix.com!newsfeed.icl.net!isdnet!psinet-france!psiuk-f4!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Restructuring of Ada (was RE: Ada on Cypress CY7C646 (8051)?) Date: Thu, 7 Jun 2001 14:43:03 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9fohvp$mp$1@nh.pace.co.uk> References: NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 991939385 729 136.170.200.133 (7 Jun 2001 18:43:05 GMT) X-Complaints-To: newsmaster@pace.co.uk NNTP-Posting-Date: 7 Jun 2001 18:43:05 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:8340 Date: 2001-06-07T18:43:05+00:00 List-Id: 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" 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