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: gwinn@res.ray.com (Joe Gwinn)
Subject: Re: ada and robots
Date: 1997/06/17
Message-ID: <gwinn-1706972242370001@dh5055155.res.ray.com>#1/1
X-Deja-AN: 249309243
References: <97061611223212@psavax.pwfl.com>
Organization: Raytheon Electronic Systems
Newsgroups: comp.lang.ada
Date: 1997-06-17T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <97061611223212@psavax.pwfl.com>, "Marin David Condic,
561.796.8997, M/S 731-93" <condicma@PWFL.COM> wrote:

> Joe Gwinn <gwinn@RES.RAY.COM> writes:

> >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.

"Sort of" is exactly right; neither correct nor consistent from compiler
to compiler.  Some compilers also provided pragma volatile, but
implementations varied, and some were deeply unclear on the concept of
volatile, so we couldn't use either shared or volatile.


>     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.").

All C compilers provide the "volatile" attribute, which one can apply to a
(static) variable, and I've never heard of a C compiler that got it wrong
surviving for long.  I don't recall if volatile is in Kernigan and Richie,
but it's probably in ANSI C.  I think I'll look it up.


We also had problems with different compilers handling generics
differently, especially with respect to the allowed nesting depth.

I believe these problems are fixed in the Ada95 standard, and should be
fixed in the Ada95 compilers.

Joe Gwinn