From: sampson@cod.nosc.mil (Charles H. Sampson)
Subject: What Happened While I Wasn't Looking?
Date: 1997/04/02
Date: 1997-04-02T00:00:00+00:00 [thread overview]
Message-ID: <1997Apr2.202514.1843@nosc.mil> (raw)
The Prologue, being information fascinating to all and necessary to un-
derstand the author's position before reading The Questions:
I was unlucky enough to be heavily involved with "something else"
during most of the Ada 9X work. I know many people were, but in my case
it really minimized the time I could devote to even following the work,
much less trying to contribute to it. In spite of that, I have been
congratulating myself on understanding the major changes pretty well,
the OO features, child packages, etc. That self congratulation might be
well founded, but I've certainly been stung several times when I stum-
bled across little tweaks that I failed to notice. My most recent dis-
covery is that the Ada 83 injunction against using address clauses to
cause overlaying has been dropped.
The majority of my career has been spent in maintenance program-
ming, with almost all of that in FORTRAN and CMS-2. Based on my experi-
ence, the single greatest cause of maintenance problems (bugs) and
enhancement difficulties is the overlay. Colleagues agree with this
opinion. When I taught Ada 83 I pointed out this issue and used it as a
selling point, saying that overlaying was impossible in a non-erroneous
Ada program. I went on to extol the virtues of Unchecked_conversion, in
particular the point that it makes the "aliasing" obvious at the point
where it is being used. Now I will be forced to admit that the beast is
alive and kicking, at least to some degree, in Ada 95.
The Questions:
My primary question is, why was this change made? Was the negative
impact on maintenance considered? I haven't found anything on the issue
in the Rationale. I've misplaced my copy of the AARM, but I wouldn't
expect to find anything on it there. Robert Dewar has pointed out that
there are efficiency gains coming from never having to do a copy when
changing from one view to another. Was that the only consideration?
The Epilogue, being divers observations on the issue:
The saddest aspect of this mistaken change (my opinion, obviously)
is that it doesn't adequately support overlaying. Even if a compiler
implements the recommended level of support (RM 13.3(12-19)) it is only
required to do the right thing for the one of the overlaid data whose
address has been specified (RM 13.3(19)). To the response that a com-
piler implemented to minimally satisfy the requirement would be very
poor, consider the example used to demonstrate why overlays through ad-
dress clauses couldn't work in Ada 83: The overlaid data come from dif-
ferent package specifications. A conventional Ada compiler, retrieving
information about the packages from its library, would probably find
that only one of the data should be treated conservatively. (The much
maligned CMS-2, which raised aliasing to undreamed of heights, had a
rule preventing this kind of thing.) I suppose it would be possible
after compiling the second package specification (the one that contains
the address clause) to modify the library information for the first
package, but how many compilers do this kind of thing?
Robert has written that he always uses pragma(volatile) on both
data to make sure the overlay works. That should do the trick, but I
see two problems; there may be more. The first is that code that reads
the overlaid data becomes overly conservative, fetching them every time
rather than ever using an in-register value. (This seems to weaken the
claim of efficiencies made for the feature.) The second is that it
amounts to lying to the compiler and, more important, to the maintenance
programmer. According to RM C.6(1), pragma(volatile) is used to "con-
trol the use of shared variables". While it might seem like a harmless
white lie to tell the maintenance programmer that a non-shared variable
is shared, in my experience any lie in programming eventually comes back
to haunt you, usually at the most inopportune moment.
It's interesting to note that GNAT handles the two package example
"right". My guess is that that's a result of GNAT's treating package
specifications like include files. On the other hand, GNAT (PC version
3.07) allows one of the overlaid objects to be a constant and the other
to be variable. Furthermore, the generated code allows the value of the
constant to be changed. This is clearly a bug, either in GNAT or the
language specification. It is not prohibited in RM 13.3. Is it prohib-
ited elsewhere?
Charlie
next reply other threads:[~1997-04-02 0:00 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-04-02 0:00 Charles H. Sampson [this message]
1997-04-03 0:00 ` What Happened While I Wasn't Looking? Robert A Duff
1997-04-03 0:00 ` Robert Dewar
1997-04-03 0:00 ` Robert Dewar
1997-04-05 0:00 ` Overflows (lisp fixnum-bignum conversion) Clayton Weaver
1997-04-05 0:00 ` Robert Dewar
1997-04-08 0:00 ` Robert A Duff
1997-04-09 0:00 ` Charles H. Sampson
1997-04-06 0:00 ` Robert A Duff
1997-04-06 0:00 ` Nick Roberts
1997-04-07 0:00 ` Robert A Duff
1997-04-07 0:00 ` Robert Dewar
1997-04-07 0:00 ` Larry Kilgallen
1997-04-07 0:00 ` Robert Dewar
1997-04-09 0:00 ` Robert A Duff
1997-04-07 0:00 ` Nick Roberts
1997-04-07 0:00 ` Robert Dewar
1997-04-09 0:00 ` Joel VanLaven
1997-04-12 0:00 ` Architectures Nick Roberts
1997-04-05 0:00 ` What Happened While I Wasn't Looking? Nick Roberts
1997-04-07 0:00 ` Charles H. Sampson
1997-04-07 0:00 ` Charles H. Sampson
1997-04-09 0:00 ` Robert A Duff
1997-04-08 0:00 ` Overflows (lisp fixnum-bignum conversion) Jon S Anthony
-- strict thread matches above, loose matches on Subject: below --
1997-04-09 0:00 What Happened While I Wasn't Looking? Franco Mazzanti
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox