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 From: james@cdac.com (James Thiele) Subject: Re: Ada and Automotive Industry Date: 1996/11/12 Message-ID: <1996Nov12.192850.16867@ole.cdac.com>#1/1 X-Deja-AN: 196045495 sender: news@ole.cdac.com (Usenet News) organization: Cascade Design Automation, Bellevue, WA newsgroups: comp.lang.ada Date: 1996-11-12T00:00:00+00:00 List-Id: Frank Manning writes: >In article <1996Nov6.210957.3070@ole.cdac.com> James Thiele > > >> I've never seen Ada for Intel 8051 or Motorola 6800 >> series microcontrollers, and these are common in the >> auto industry. >> [...] >> Why should they appreciate a bloated language that requires >> them to hire new or retrain old programmers to write >> programs that won't fit on the microcontrollers they use? > >It's a myth that Ada compilers are unrealistic for small >microcontrollers. There's nothing that prevents anybody from >implementing an Ada subset that could both (a) be validated and >(b) fit harmoniously on a small machine. > >I remember back in October 1995 when we had a big discussion about >the merits of Ada for small microcontrollers. Here's what Robert >Eachus and Mike Felman said at the time: > >In article >eachus@spectre.mitre.org (Robert I. Eachus) writes: > >> For Ada 83 we had AI-325: "Implementation-dependant limitations >> must be justified. An implementation-dependant limitation is >> justified if it is impossible to or impractical to remove it, given an >> implementation's execution environment." In Ada95 this has been >> incorporated into RM 1.1.3(6): "Contain no variations except those >> explicitly permitted by this International Standard, or those that are >> impossible or impractical to avoid given the implementation's >> execution environment." >> >> [...] >> >> So anyone who wants to retarget the GNAT compiler to an 8-bit >> environment go ahead. Validation should not be even your tenth >> biggest worry. > >In article <4920s0$kqd@felix.seas.gwu.edu> >mfeldman@seas.gwu.edu (Michael Feldman) writes: > >> [...] >> >> (1) it is premature to write off the potential for an Ada/8051; >> >> (2) some of the complaints about Ada being "too big" for the 8051 >> may well be made out of ignorance of the possibilities; >> >> (3) a GCC target and a port of the GNAT runtime is the way to go. An 8051 and other 8-bit processors are small even for C. I know of only one target of gcc to a machine of this class, 68HC11. This port has no floats or 4 byte longs. If you look at 8051 C compilers you will find that they have evolved over the years adding little "hints" to deal with quirks in the address space. The 8051 is a classic Harvard machine with different code and data spaces. In addition, and here is one of the problems, it handles on and off chip RAM differently. Since it has only one accumulator and one data pointer there is likely going to be code bloat just trying to move data around. If you read postings in the relevant newsgroups you will see postings about features of C to avoid on the 8051 because they are expensive. Originally C was designed around PDP-11 class machines: 16 bits, multiple registers, indirect addressing modes, etc. Since gcc has to dumb down C for an 8-bit machine, how much would GNAT have to dumb down Ada to target an 8051? Would you still think it was Ada? Just my 2 cents. -- James Thiele james@cdac.com (work) or jet@eskimo.com (home) http://www.eskimo.com/~jet