Re: Ada and Automotive Industry

[Richard Riehle <rriehle@nunic.nu.edu>]

On 23 Nov 1996, Robert Dewar wrote:

In response to my skepticism regarding the feasibility of an Ada
compiler for the I8051 family of microcontrollers.

> Well I do not think you know enough about GCC or GNAT for your skeptical
> viewpoint to be significant.

  I am always impressed by your skill at formulating such exquisite
  ripostes.  

> I still have seen no one make a cogent
> technical argument that supports this viewpoint. Ken says that it
> must be impossible because he saw one half baked poor attempt,

  Agree that a half-baked poor attempt is not a good test.

> ... you are skeptical without even that much to back up your skepticism.

  Except perhaps a little bit of knowledge of how 8051 applications
  are developed and a more than passing awareness of the 8051 
  architecture.  

  Most 8051 programs are still written in assembler. Many are written
  in FORTH.  An 8051 programmer takes advantage of a bunch of Special
  Function Registers (SFR's) and uses these registers according to
  an idiom well-known among those who specialize in writing programs for
  the 8051 architecture.  Many 8051 programmers understand that even
  C is too high-level a language and comparisons of programs written
  in both assembler and C have shown that the corresponding C program
  is often too large for the targeted application and platform.

  ==================================================================
  One comparison:

                         8051 Assembler        8051 C Compiler
    
  SLOC                          31                 12
  Program Size (Bytes)          53                114
  ==================================================================
       
  This may not seem significant to anyone who programs computers which
  include a lot of memory. Typical 8051 applications are targeted to
  very small memories, even though the addressable memory is theoretically
  quite ample.  I am the first to admit that, for those 8051 targets
  with maximum available external code space (0..FFF) and maximum
  available external data space (0..FFFF), one need not be concerned
  about available memory.  Many 8051 applications use minimal external
  code and data space and are limited to the four segments of 
  internal "RAM," a smaller, directly addressable memory area which
  need not be detailed here. 

  Though an Ada compiler might be do-able for a fully configured 8051,
  complete with external code and data space, it would probably fail
  to satisfy the critical judgement of an experienced 8051 programmer.
  Parsimony is an overriding consideration for 8051 applications. If
  one intends to deploy several hundred thousand devices which depend
  on this processor, the scale of that deployment dictates that one
  keep the memory utilization low.  Speed is the other consideration.

  As to porting GNAT, it is my understanding that GNAT is based on the
  GCC technology.  As of right now, I do not know of any attempt to
  port any GCC language to the 8051.  I wonder why.
 
> As to the huge market opportunity, I do not see it at all. You cannot
> guage a particular Ada market by counting the number of processors sold,
> you have to look at the total number of lines of code written,

  [snip, snip, snip ]

  No disagreement with this point-of-view, Robert, if the market were
  as small as you suggest.  Isuspect you, along with many others,
  underestimate the number of 8051 projects in place
  around the world.  Here in Silicon Valley, I run into 8051 programmers
  all the time.  Perhaps I am in a strange part of the planet.  So I 
  picked up my most recent copy of Embedded Systems Programming Magazine
  and checked the Ads for 8051 (a la Greg Aharonian).  Sure enough, a 
  whole lot of companies seem to think there is a market for this
  processor and they are advertising products for development and support
  of applications.  

  Perhaps the market is larger than it might at first seem to be. It is
  likely to be larger than the market for MIL-STD 1750A development.

> and the
> likelihood that a significant number of projects would need a significant
> number of compilers. I don't see it at all.

  This is no surprise. You are not involved in the marketplace that
  focuses on this technology. That is not intended to be a criticism.
  You are exceptionally good in the arena you have chosen.  

> If some other vendor thinks
> they can make money here, fine, but I don't think you should hold your
> breath waiting for ACT to do this port.

  I'll be careful not to inhale, as well.  No such expectations of ACT.

> But it is important to realize
> that this is based on the estimate that there is an insufficient market,
> not on any judgment that a GCC/GNAT port is impossible.

  Probably not impossible.  But probably not competitive with other
  development languages already in use.  Perhaps someone could develop
  an optimizer that would produce executable code as small and as fast
  as that coded by an experienced 8051 programmer. I doubt it. And small
  and fast are the criteria for a large number of 8051 programs.
 
> Sure I understand that only the investment of the effort in producing
> such a port would settle the question, but any productized GNAT port
> is a big (but not daunting) effort -- yes much less effort than is
> the case if a completly separate code generator has to be written,
> as in many other tchnologies, but still far more than one might consider
> investing simply to prove a point :-)

  I certainly would not expect ACT to waste resources building
  an Ada compiler for the 8051.  Nor would I expect any other profit
  oriented company to devote funds to it. But it might make a very
  interesting project for some graduate student somewhere.  It would
  certainly be an original piece of work.  

  Richard Riehle