Re: Ada and Automotive Industry

[johnd@islandnet.com (John Dammeyer)]

ken@nrtt.demon.co.uk (Ken Tindell) wrote:

>In article <579i9d$ch0@news.nyu.edu>
>kenner@lab.ultra.nyu.edu (Richard Kenner) wrote:
>
>> In article <Pine.GSO.3.95.961120154239.3026C-100000@nunic.nu.edu> Richard Riehle <rriehle@nunic.nu.edu> writes:
>>>  It is one of the most widely-used microprocessors
>>>  in U.S. industry. 
>> 
>> But why is this relevant to a *compiler*?  The number of microprocessors
>> in product isn't relevant there; what's relevant is the number of projects
>> that are writing code for it.
>
>Just so happens that the 8051 is one of the most popular project processor
>too (silicon vendors call them "design wins"). From the figures I've managed
>to get, the most popular design-win processor is the PIC from Microchip.
>
>Oh, and before anyone shouts "there's no reason why we can't get a good
>Ada 95 compiler for the PIC that's as least as good as C blah blah blah"
>actually take a look at the processor.

Ken has made what I believe is a key point here.

At the embedded system level, application implimentation language and
processor are far more inter-related than might first appear.  For
that very reason I don't believe an effective port of a complex
langauge such as ADA on some of the single chip varients can ever
occur.  

My justification for such a sweeping comment is that if the programmer
has to change or limit his/her language usage in order to comply with
the hardware restraints of the processor then the chosen language is
not longer the language as defined and the much touted power of a
particular language becomes a moot point.

For example whether we use C '=' or Pascal ':=' as an assignment token
matters not.  If the implimentation language also supports 

a) for (i=1;i<max;i++) {};
or
b) for x:= 1 to max do begin end;
or
c) for x = 1 to max 
   next x

and finally conditional evaluation such as ==,!=, <,>; <>,= etc.
we meet the criteria for solving all solvable algorithms.

The power of a particular language and its implimentation comes from
neatly and succinctly pressing the algorithms in such a way that the
code is maintainable (readable) at some point in the future and can be
considered reliable for mission critical projects.  The efficiency of
the end product comes from both the OS (or real time executive) and
the compiler.  

Take away some of the capabilities of a language or severely limit
them due to the underlying processor architecture and you no longer
have that language; a subset perhaps but then perhaps a simpler
language would be more readable than a subset.

I am currently busy with a project on a PIC 16C74 (440 bytes RAM and
4K code) and the customer insisted on C as the application language.
I agreed not realizing what I was getting into.  Initially I started
with MPLABC from Microchip.  This compiler was written by Bytecraft in
Waterloo Ontario and has some major problems (incorrectly generated
code).  The MPC compiler directly from Bytecraft is an upgraded
version of the same and has solved the majority of those problems but
the limitation list on what is allowed and what is not is really the
interesting part.

Part of the power of the C language, especially for Operating Systems
and embedded applications, stems from the rich use of pointers and
pointer arithmetic.  PIC architecture and this particular
implimentation severely limits pointer usage.  A particular danger
area in the PIC family is when a constant string overlaps a ROM page
boundry or a multi-byte variable overlaps a RAM page boundry.

Another powerful concept is passing parameters by value or by
reference.   This allows information hiding and generalized
subroutines.  The MPX implimentation limits parameters two two bytes
total; one far pointer(16 bits), long int(16 bite)  or two
integers/chars*8 bits each).  Those two bytes will then be stored in
global memory accessable only from within the function.  ie; each
parameter byte is lost RAM.  Local variables in functions can be
explicitly overlapped over other RAM memory but this, implies a lot of
work on either the compiler writers end or the applications
programmer.  The potential for an undetected error is frightening.

Yet, the code generated by MPC is fascinating.  The compiler is clever
enough to generate the same quantity of code for:

 arg1 = i;
 arg2 = j;
 k = func();

as for:

 k = func(i,j);

The difference is that if I can guarantee that arg1 and arg2 are never
used anywhere else at the same time (no direct or indirect recursion
or usage) than I can declare arg1 and arg2 as:

int arg1 @ temp1;
int arg2 @ temp2;

but this is no longer C or Pascal or Basic or etc... and... reduces
the readability of the code somewhat;  three or four paramters to a
function mean three or four lines of extra source code for every
function call and can lead to programming errors.  A good compiler
typechecks the parameters for me and prevents me from passing
incorrect arguments.

Even simple operating system structures like a Task Control Block
indexed by the Task ID implies an array of structures;  not allowed in
MPC.  Many other applications benefit from arrays of structures.

In order to write reliable code I've had to adopt the philosophy that
I am writing in a Small Basic rather than C.  That means no passing
parameters to functions in the function headers.  No complicated
structures or arrays of structures. One dimensional arrays always
indexed. etc. etc.

Perhaps some programming shops insist that their applications
programmers only use a minimal subset of the language.  If so then why
ADA or ALGOL-68 or C++.

I could pick on more of the deficiencies of the MPC implimentation but
it wouldn't be fair.  Lack of a stack based architecture and minimal
RAM severly limit any implimentation of a language that expects lots
of RAM.  I've had to totally change my programming style in order to
impliment this project within the hardware constraints.  I wouldn't
use the same style on an 80X86 or 68XXX embedded system.  Whether I
use '=' or ':=' or '<=' for an assignment statement is irrelevant.

In other words, I am no longer programming in C.  I am using a minimal
implimentation of a traditional alogorithmic language on a
microprocessor with limited resources but it's not C; it just
resembles the C syntax in a lot of places and often that is more of a
drawback than an advantage.  

And yes,  I would recommend MPC because for the most part the pseudo C
code is more readable than the assembler and it does take care of
details like page registers but it's NOT C.

IMHO

John.




Pioneers are the ones, face down in the mud,
with arrows in their backs.
Automation Artisans Inc.      Ph. 604-544-4950
6468 Loganberry Place         Fax 604-544-4954
Victoria BC CANADA V8Z 7E6