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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c78177ec2e61f4ac X-Google-Attributes: gid103376,public From: "Marin David Condic, 561.796.8997, M/S 731-93" Subject: Re: ada and robots Date: 1997/06/16 Message-ID: <97061611223212@psavax.pwfl.com>#1/1 X-Deja-AN: 248854281 Sender: Ada programming language Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU X-Vms-To: SMTP%"INFO-ADA@VM1.NODAK.EDU" Newsgroups: comp.lang.ada X-Vms-Cc: CONDIC Date: 1997-06-16T00:00:00+00:00 List-Id: Joe Gwinn 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 ===============================================================================