Re: Ada and Automotive Industry

[Ken Garlington <GarlingtonKE@lmtas.lmco.com>]

granville@decus.org.nz wrote:
> 
>  A good idea in theory, but subset systems are not commercial, and such a
> 'std' is likely to bog in red tape.

Since the ARA is a commercial organization that has already defined some
informal standards pretty quickly, I would say they're your best bet.

> There are also Modula-2 superset features NOT in Ada we would hate to loose.
> Nested comments is one - ALL languages should have this. HEX support is
> another.

I guess I don't understand the issue. Ada comments are line based on
purpose, to avoid misleading the reader as to the difference between
"live" and commented code. As for Hex support, Ada does provide the
ability to define hex values, perform I/O with hax values, etc. What
do you need?

> These problems perhaps make an Ada -> Modula-2 translator more practical.
> 
> >> Remember that Heap, Pointer, and dynamic memory work is not a C51
> strongpoint
> >> Fast interrupts, and boolean control logic is.
> >Fortunately, Ada 95 supports both fast interrupts (e.g., using procedures as
> >interrupt handlers) and boolean control logic. It also provides generics and
> >strong typing, which can be used with minimal overhead with most compilers.
> >I've implemented Ada programs on several systems with no use of the heap, so
> >it should be doable for a C51 (assuming the selection of an appropriate subset
> >of the language).
> 
> Given a Modula-2 subset of Ada, it is doable - & we have done this for a
> number of years now - but Ada95 it is not.

Since my statement assumed the use of an appropriate subset, it sounds
like
we are talking about the same thing. Do you have an Ada subset toolset?

> 
> >granville@decus.org.nz wrote:
> >>
> >> Following some feedback on Ada in Automotive systems, which is somewhat
> >> 80c51 focused, I have included below a document we have on Ada / Modula-2
> >> in relation to the 80c51 core.
> >>
> >> [snip]
> >>
> >>  Ada and Modula-2 are both type-safe languages, with type check, import and
> >> scope control to simplify code design. Ada is generally a superset
> >> of Modula-2 - and full Ada support is not practical on a c51 core.
> >>
> >> [snip]
> >>
> >>  You can, however code in Ada, and use a Ada2Mod translator to output
> Modula-2
> >> code, which then will run on c51 cores.

Will Ada2Mod handle those parts of Ada that are outside of Modula-2, but
are easy to implement on a c51 core, like generics? If so, it sounds
like
you have already done the work to permit Ada to be implemented on a C51!

> >>  Modula-2 has more inherant types than Ada, ( eg BYTE, WORD, LONGWORD,
> BITSET)
> >> and many code MUCH better on a C51 than std INTEGER.
> >>  A subrange declaration in Ada, could create these types, for efficent
> >> translated Mod51 usage.

Actualy, you'd probably want to declare a new type, so that you could
specify the bitwidth.

> 
> >Have you looked at implementing Ada constructs that are not directly mappable
> >to Modula-2, but that should be implementable on a C51? For example, it
> appears
> >from your message that the following Ada code can be implemented on a C51
> (after
> >translation):
> 
>  Yes.  ( and also some Visual BASIC ones too ! )
> 
> >> --  Ada Code here    (* Modula-2 Code here  *)
> >> [snip]
> >> FUNCTION  Add(x, y: integer)      PROCEDURE Add(x, y: integer) : INTEGER;
> >>            RETURN integer IS
> >> value: integer;    VAR  value: integer;
> >> BEGIN                             BEGIN
> >>   value :=  ( x + y value :=( x + y );
> >>   RETURN value;                     RETURN value;
> >> END Add;                          END Add;
> 
> >It would seem that the following Ada code, which extends Add for types other
> than
> >Integer, would also be implementable...
> >
> >-- "Add" specification
> >generic
> >  type Item is private;
> >  function "+" (Left, Right : Item) return Item is <>;
> >function Add (Left, Right : Item) return Item;
> >
> >-- "Add" body
> >function Add (Left, Right : Item) return Item is
> >begin
> >
> >  return Left + Right;
> >end Add;
> 
> >I would hope that generics, child packages, and other parts of Ada that
> >are more "static" in nature can be implemented without respect to the
> >amount of memory, processor speed, etc. available on a target.
> 
> We did look at this, but features like this generic provide little gain to
> an embedded control programmer, and would more likely penalise code size.

I'm an embedded control programmer, and we use generics a lot for things
like
gains, lead/lags, etc. Our compilers generate very efficient code for
them.

>  The source might 'look simple', but what is being done is hidden and not
> obvious to another programmer. There is no code-size, or safety advantage
> to this feature.

I have a lot of practical experience to the contrary! Using standard
generics
makes the code a lot simpler to write and more reliable as well!

This is one of the best features of Ada, in our experience!

> 
>  We did see some others features that we would like to implement, especially
> as other PC/Win95 hosted Modula-2 supplier's have done this as well.
> 
>  Code portability ( cross development ) is important.
> 
>  Especially in the development phases where the prototype and test features
> of a std PC are very useful. eg user interface, Sin / Frequency / ADC algorithm
> testing etc.
> 
>  'Ada' ideas we have on a 'short list' to add to Mod51 are :-
> 
> ** .First, .Last  ->> MIN and MAX, with some extensions to std MIN,MAX.
>  Advantage : More readable code & further encourages the safe use of Enums.
>  Extends the lead over C.
> ** the IN operator in Ada looks to have wider context than Modula-2, but I
>  need to test this further.
>  Advantage : More readable, and smaller code
> ** Open CONST arrays,
>  Open CONSTS may be simpler to code, but not so safe! I have seen very nasty
>  C bugs caused by this 'feature'. Still, some M2's do have this extension.
> ** 'repeat fields'.
>  Repeat fields look safe, with no dangers, and make code more readable.
> ** Numerics allow #2#1111_0000 - ie CHAR '_' is legal (skipped ) in numbers.
>  This is also in IEC1131, and we support this already on BINARY NUMBERS.
>  We also ONLY accept multiples of 8 fields in BINARY Nums
> ** Initialised VARs
>  Significant code overhead. Suggested instead is Clr_RAM module, that clears
>  all C51 Data RAM to 00H, at a cost of << 10 Bytes.
> 
> - jim granville.
> ===== Mandeno Granville FAX +64 9 6301 720, 128 Grange Rd Auckland 3 NZ ======
> * Developers and suppliers of serious MicroController Embedded Control Tools *
> * 89c2051, 89c1051 Emulator / ChipreProgrammers                              *
> * x51 C, Pascal & Modula-2 Compilers, Simulators, Emulators & FLASH Pgmrs    *
> * Contact : Jim Granville . Email above.                                     *

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com