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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 115aec,f41f1f25333fa601 X-Google-Attributes: gid115aec,public X-Google-Thread: 103376,a3ca574fc2007430 X-Google-Attributes: gid103376,public From: johnd@islandnet.com (John Dammeyer) Subject: Re: Ada and Automotive Industry Date: 1996/11/26 Message-ID: <329a0e52.1824102721@news.islandnet.com> X-Deja-AN: 200741640 references: <579i9d$ch0@news.nyu.edu> organization: Automation Artisans Inc. newsgroups: comp.lang.ada,comp.realtime Date: 1996-11-26T00:00:00+00:00 List-Id: 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 Richard Riehle 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; <>,= 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