Re: ada and robots

["Marin David Condic, 561.796.8997, M/S 731-93" <condicma@PWFL.COM>]

Joe Gwinn <gwinn@RES.RAY.COM> writes:
>
>As for Ada83 experience, I have (or know of) both old and new experience,
>and most Ada83 compilers were very difficult to use for direct hardware
>control.  I suppose one could have made them work, but why would you?  If
>it's that hard, it won't be reliable.  We often reverted to assembly code
>for the machine control bits, long before C was a true option.  (We did
>the same when the base language was Fortran or Pascal, for the same
>reasons.)
>
    Again, I would ask for some real nice specific example of "here's
    a block of C code which does XYZ which Ada can't do - or can't do
    easily". I ask because I *have* been programming in Ada(83) for a
    long time, right down to controlling very specific hardware and
    never once did I consider it any harder than in any other
    language. (Often easier, in many cases.) And BTW, *reliability* is
    probably *THE MOST IMPORTANT* concern in producing a control
    computer for a jet or rocket engine. My experience has told me
    that it is neither difficult, nor unreliable - depending, of
    course, on exactly how you go about it. (Anybody can make things
    difficult and unreliable in any language of choice by trying to do
    things the hard way or by bad design.)

>
>As for Ada83 and shared memory, the problem was that the Ada83 compilers
>all believed that only they changed memory, so it was OK to cache data
>items in CPU registers for long periods of time.  For the most part, there
>was no reliable (and portable) way to tell the compiler different, so we
>performed various dances to ensure that Ada83 never knew the whole truth.
>
    Ahhhhhh! *Now* I understand what the complaint about shared memory
    is all about. Ada83 provided "pragma SHARED" which would handle
    this, sort of. The semantics of this pragma were a little overly
    restrictive if all you wanted to do was force the compiler not to
    optimize the storage into a register. (So a solution did exist,
    but not necessarly the best possible solution.) Our compiler
    vendors typically supplied us with a "pragma VOLATILE" (which I
    think is now standard in Ada95) which told the compiler not to
    optimize the value in a register. It worked pretty much as
    expected and we've got no complaints.

    BTW: What exactly does C provide to keep this from happening? I
    don't recall it ever being something defined in "standard" C - and
    why should it be? "Standard" C never defined any sort of
    multi-tasking and so never needed any sort of mechanism to tell
    the compiler that a variable should not be retained in a register.
    Is there some sort of mechanism to do this? (I recall it had the
    ability to tell the compiler you would *like* to have a given
    variable allocated to a register - and maybe it did and maybe it
    didn't. But I don't recall any way of saying "don't allocate this
    to a register behind my back, please.")

    MDC

Marin David Condic, Senior Computer Engineer     ATT:        561.796.8997
Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:        561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:   CONDICMA@PWFL.COM
===============================================================================
    "You spend a billion here and a billion there. Sooner or later it
    adds up to real money."

        --  Everett Dirksen
===============================================================================