>Ken Garlington wrote: >> Sy Wong wrote: [deleted stuff] > 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. Why do you need to implement a subset for 8 and 16 bit processors? I have used data types similar to those in Ada on 8 and 16 bit processors for years. What part of the Ada language do you believe cannot be supported on these processors? I have used assembler, C, Pascal, and Modula-2 on this class of processors for over 20 years. Ada does not present any feature that cannot be supported on the smaller data model processors. > > 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 implementation of Ada tasking should meet the system architecture. I have used Ada tasking on Unix that is implemented as child processes. The ObjectAda that I am using on WindowsNT implements tasks as treaded processes. I am probably missing something but I do not see why a task should be implemented as an interrupt handler. I can see tasking using an interrupt structure in the rendezvous mechanism to prevent race conditions from occuring. > > 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. This appears more of a DOD type embedded system rather that commercial. There are certainly commercial embedded controller systems that fit this model but I do not believe Ada is necessarily that correct language for this type architecture. > 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. Over the past 24 years I have seen and used "Tiny" and "Small" language implementations, such as "Small C", "Tiny Pascal", "PLM", etc. Every one of these subsets caused more problems that fully implemented versions of the target language. Every one created a problem because each implementation was slightly different, so source code was not completely portable. It is my belief that on reason to use Ada [fully implemented for each of the different architectures) provide portability. I really do not want to have to beat my brains out porting my code to different processors. Porting Ada should ONLY require slight adjustments due to architecture and system differences. [deleted stuff] > > 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. I must be mistaken. I am a developer in the commercial sector and writting a "HARD, Real-time" system in Ada. I do not remember exactly but believe I saw on PAL a hardware definition language base in Ada. In a past life I worked for a small company her in Huntsville, Alabama named Intergraph Corp. We did (they still do) EDA. The modeling language was standardized on VHDL long ago. There are several other imtermediate modeling languages but do not see any advantage in pushing Ada as an EDA modeling language. Please elaborate why this would be a good thing. > > > > 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. It is an economic drag to produce language subsets that causes portability to be diminished. In the commercial sector we must be ready to move to different system architecture when the customers demand it. Non-portability has a higher probability of killing a commercial product that require more memory or a larger ROM. [Deleted Annex-H stuff] Phil Johnson -- _______________________________________________________________________ | | | Ada, Perl, and Java! It can't get any better. | | | |Philip Johnson Telco: (205) 890-1178 | |Sr. Software Engineer Fax : (205) 890-1174 | |International Space Systems Inc. email: [log in to unmask] | |Huntsville, AL | -----------------------------------------------------------------------