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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a3ca574fc2007430 X-Google-Attributes: gid103376,public X-Google-Thread: 115aec,f41f1f25333fa601 X-Google-Attributes: gid115aec,public From: ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) Subject: Re: Ada and Automotive Industry Date: 1996/12/03 Message-ID: <580ec9$nq0$1@goanna.cs.rmit.edu.au>#1/1 X-Deja-AN: 202021518 references: <579i9d$ch0@news.nyu.edu> organization: Comp Sci, RMIT, Melbourne, Australia newsgroups: comp.lang.ada,comp.realtime nntp-posting-user: ok Date: 1996-12-03T00:00:00+00:00 List-Id: I'd like to make two observations about Ada and the 8051. (a) There is a claim that because the number of _projects_ using Ada-for-8051 would be small (which is not perfectly clear to me) even though the volume of systems _shipped_ containing code so produced might be astronomical, the return on investment to Ada compiler companies would not be sufficiently high to warrant them developing an Ada-for-8051 compiler. It could *still* be true that it would pay the automotive industry (or the smart-card industry; both of them are going to have very high reliability standards) to fund the development of such a compiler. (b) It is true that the 8051 is a small and strange machine, and that much of the stuff in Ada 95 might not be wanted. It could *still* be true that an Ada *subset* might be a very good fit to the 8051. What I have in mind here is that - there is a fair bit of stuff that happens at *compile* time in Ada which is useful for improving the maintainability of code. This stuff makes Ada *compilers* harder to write than C *compilers*, but it need have no adverse effects on *code* size. - there is a fair bit of stuff in *standard* Ada (detailed control over sizes and layouts of objects, even detailed control over placement of variables) which could be extremely useful for 8051 programming (because of its non-uniform memory and the importance of packing when you have so little memory), which is *not* standard in C. One such feature is machine-code insertions. I therefore believe that it would be perfectly possible to design a proper subset of Ada 95---call it Ada 8051---such that any legal Ada 8051 library unit would be a legal Ada 95 library unit with the same meaning, but sufficiently restricted to permit the automatic generation of code at least as good as C for the 8051 (probably better), with smooth escapes to machine code where necessary, but machine code subject to encapsulation. I hope someone does this; the thought of hundreds of millions of smart cards programmed in C or assembler really doesn't thrill me. -- Govt saves money by cutting legal aid, guilty plea rates soar; poverty is a crime! (See also recent Sci.Am.) Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.