Sy Wong wrote:
> The Ada community is dead set against any form of subsetting. I am of
> the opinion that only a simplifed LRM and validation set will attract
> commercial users. My meager resources cannot go very far. If you with
> Lockheed behind you can force this issue, there might be some hope.
> Boeing had such a spec much earlier. BCAG Doc: D6-53339 Rev.A, 1991.
I'd be interested in seeing this spec. Do you have a contact at Boeing that
could supply it to me?
I was actually planning on trying (on my own time) to create an Ada subset
using GNAT, that would be applicable to 8-bit and 16-bit microcontroller
software. Right now, we have to ask for waivers for a lot of these
applications. If someone has already done some work on defining such a
subset, I'd like to know how it was derived. Certainly, if we don't come up
with a version of Ada that doesn't require much (if any RAM), we'll never
get past using C and assembly for these tiny processors, which seem to pop up
in all sorts of applications.
It would be nice if the tasking model could be used where appropriate; for
example, as interrupt handlers. I don't know if direct task interactions
could be supported or not. I think a limited form of protected records is
also supportable. In some form, generics and exception handling would also be
useful. Text_IO is probably out (although a Low_Level_IO package would be
nice). Machine code insertions are a must.
The idea of using it for hardware design is interesting, although I haven't
really done much in this area since college (which is where I used VHDL).
I actually don't see the problem with building a "tiny Ada" or CDL compiler
under the current rules. You can certainly pass validation using a subset of
tests, if you can show that the other tests are inappropriate for a given
target. I would think a target with 256 bytes of RAM, for example, would be
reasonable grounds for not supporting heap management, etc. However, without
someone having a compelling reason to try to build such a product, we'll
never know for sure. The developers of such systems won't use Ada because (a)
they are usually writing less than 4K of source code. so the advantages of
Ada are less obvious, and (b) there's no compilers. Compiler vendor's won't
build compilers because the users aren't begging them to build something.
By the way, I can't claim Lockheed Martin is behind me on this; I had hoped
to demonstrate the feasibility of "tiny Ada" on a microcontroller, and then
show how extending Ada to those kinds of systems could be a Good Thing.
However, it's just a hobby for me at the moment; I haven't had time to do
much work on this.
> legitimization of Annex H as a part of ISO standard will go a long way to
> promote commercial utilization. I asked Hal Hart to help me distribute a
> message but apparently he did not. The enclosed note to Jim Moore
> explains what I am trying to achieve.
My message to you was based on a message I saw on the Team-Ada list from Mr.
Hart, so he is trying to get the word out.
> I am preparing a paper for an EDA magazine showing examples of using Ada
> to define and implement logic from simple nand gate to a ripple counter.
> Do you realize "Gar Ling-Ton" could be a Chinese name?
No. Does it have a perverse meaning? If not, I would be very disappointed. :)
It's actual roots are from England, meaning someone who comes from the "tun"
(town) of Gyrling. Gyrling is now just a pile of rocks on a hillside,
> SY Wong
> ----- copy -----
> To: Jim Moore, ACM Techn. Stds Comm. Chair <[log in to unmask]> 1996.11.2
> Hal Hart told me that either you are or you know who is the WG9 convener.
> Please voice my petition to have the following matter put on the agenda
> for discussion.
> Subject: Ada-95 Annex-H for Safety and Security Software (SSS).
> Purpose. To extend Ada use to the commercial sector
> where nobody touches Ada or mentions Ada, particular in the areas of
> a. SSS
> b. the Electronic Design Automation and
> c. hard real-time embedded applications.
> What follows applies only to the commercial sector which, unlike the
> military market the Ada vendor depends on, it is a competitive
> environment where any drag on economy cannot be tolerated.
> Annex-H listed a number of "restrictables" for the purpose to facilitate
> proof of correctness of SSS, with apologies in the Rationale that it is
> not subsetting because Ada compiler must be validated for the entire
> language anyhow. This is a faulty reasoning that ignored the competitive
> issue with supports for other languages. Logic do not prevail for a
> vendor that only caters to the SSS market to develope a compiler for full
> Ada-95 solely to get validation and then make sure that the customer
> cannot use the restricted constructs. The other two listed application
> areas have similar requirements for the SSS sector where Annex-H
> restricted compiler can have a market. In particular, in the EDA market,
> this subset can serve both as Hardware Design/Description Language (HDL)
> in addition to programming and can be used as hw/sw Co-Design Language
> It is requested that the following measures be taken.
> 1. Write a clarification for Annex H, not couching subsetting in terms of
> "restrictable" type wordings.
> 2. Edit the LRM accordingly to remove all restricted constructs or
> mention of them plus possibly a manual for learning purposes.
> 3. Separate the ACVC into "must have" and "must not have" parts, possibly
> offer validation service in S.U. for Annex-H restricted compilers, since
> the U.S. resists any attempt that subsets Ada.
> 4. Possibly edit ASIS after the above are in place.
> An official response is requested.
> SY Wong
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com