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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ab36006a122bb868 X-Google-Attributes: gid103376,public From: "Marc A. Criley" Subject: Re: Overlay allowability Date: 2000/05/03 Message-ID: <39102044.74E163CE@lmco.com> X-Deja-AN: 618666897 Content-Transfer-Encoding: 7bit References: <390D94FB.D23390D4@lmco.com> <390F67DB.7AB83BD@earthlink.net> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@news.vf.lmco.com X-Trace: knight.vf.lmco.com 957357371 22109 166.17.131.243 (3 May 2000 12:36:11 GMT) Organization: Lockheed Martin M&DS Mime-Version: 1.0 NNTP-Posting-Date: 3 May 2000 12:36:11 GMT Newsgroups: comp.lang.ada Date: 2000-05-03T12:36:11+00:00 List-Id: Bob, Thanks for doing the analysis of this little example, I agree that the FAQ would be well-served by including your writeup within it (with, of course, the inadvertent omission of the 'Address on "for SN'Address use N;" corrected :-) In the real code where this would be used, "N" is actually the parameter that is received into the procedure that does the overlaying, and is an instance of a generic formal type, of which nothing concerning its content and constituents are known. (BTW, no references to this variable other than remapping it into a Stream_Element_Array occur.) This of course bolsters your analysis that the developer then needs to specify exactly what is expected of such instances in a context, rather than requiring developers to re-perform the analysis to understand the conditions under which this executes. Thanks again, Marc "Robert I. Eachus" wrote: > > This one should be in the FAQ... > > "Marc A. Criley" wrote: > > > A few times in my career I've encountered situations where two different > > representations of the same set of bits are desired in a high > > performance application, and this has been effected with the aid of the > > 'Address representation attribute. In Ada 95, an example of this would > > be: > > > > N : Natural; > > > > SN : Stream_Element_Array(1..N'Size / System.Storage_Unit); > > for SN'Address use N; > > > > This has always struck me as somewhat iffy, but I confess I've used > > it as well on a couple occasions with Ada 83. I've always found that > > it works as one intuitively expects, so long as all alignment, layout > > and sizing aspects are fully thought through and accommodated. > > > > So, is this within the definition of Ada 95? Or is it well-defined > > only for certain constructs, say scalars and non-tagged types, and > > dicey for others? Are there type constructs for which relying on it > > is clearly a reliance on undefined behavior, is the whole construct a > > reliance on undefined behavior? Is there a de facto, in place of a > > formal, expectation that this should work as expected? > > Hmmm. The RM is very clear about this: > > "If an Address is specified, it is the programmer's responsibility > to ensure that the address is valid; otherwise, program execution is > erroneous." RM 13.3(13). > > So first off, your example has a bug in it, and will almost > certainly result in erroneous execution. I'm sure you intended to > write: > > for SN'Address use N'Address; > > correct? Your code fragment as written would be erroneous or not > depending on whether or not the value in N corresponded to a legitimate > address when the representation clause was elaborated. > > Now let's go to the much more interesting case of what you > intended to write. First, N'Address is likely to be a valid address, so > the program execution will not be erroneous (or at least, not due to the > elaboration of this construct). Note, that just being the result of an > 'Address clause is not sufficient to make an address valid, you could, > for example, say "use Main_Program'Address;" "use Bit_Array(7)'Address;" > or even "Some_Constant'Address;" but the clause above should be safe, > unless an unfriendly compiler sticks N in a register. Most Ada > compilers are very friendly in this case, but why not warn maintainers > by making N explicitly aliased. > > You mentioned, alignment, layout, and sizing aspects, and > (surprise!) these are discussed in great detail in RM 13.3. There are > some things you can count on, some you can--and often should--specify, > and some which will be implementation defined. But there are some other > details that you should be aware of. You usually don't want any default > initializations that are associated with the subtype of SN to be > performed. The fact that you don't provide a default value, doesn't > prevent the compiler from initializing something behind your back. > (Everyone knows that access values are initialized to null in the > absence of other initializations, but compilers may choose to initialize > records with gaps to make comparisions easier, and you certainly don't > want your code to fail if someone compiles it with pragma > Normalize_Scalars, or adds a default initialization to some subtype.) > > Also, if you are using both representations of the data in the same > code, you need to think seriously about which declarations will require > pragma Volatile, Atomic, Volatile_Components or Atomic_Components. Note > that these are in Annex C, and that the use of one of these pragmas may > result in the program being rejected. A "nice" compiler will note the > aliasing, and not put N in a register. But the real issues you have to > worry about are much more subtle. Assuming that you used the right > pragma for your code, and that the compiler doesn't have a serious bug, > the compiler will--instead of producing what you will consider to be > buggy code--tell you that, on this hardware, your code cannot be > correctly implemented. In your example, assuming that the > Stream_Element_Array comes from Ada.Streams, it is likely that you can > safely apply pragma Atomic to N and pragma Volatile_Components to SN. > All this may not be necessary, and in fact Ada compilers do try to be > friendly, but you should require the behavior that you actually require, > if only for documentation. So the general template for the idiom is: > > N : aliased Natural; > pragma Atomic(N); > > SN : Stream_Element_Array(1..N'Size / System.Storage_Unit); > for SN'Address use N'Address; > pragma Volatile_Components(SN); > pragma Import(SN); > > I made N atomic, since you probably do want to insist that you don't > see "half" of an update. If N was for example a double word scalar, the > pragma might be necessary. (And compilers can often do double loads and > stores on hardware which only supports single word integers--think long > float.) I used Volatile_Components on SN because it is much more likely > to be accepted, and you would probably only need to use > Atomic_Components if you had multiple tasks involved. This is the type > of thinking which the programmer/software engineer needs to do as part > of the design. Not putting the pragmas in--or a comment as to why they > are not there--requires that every reader or maintainer do that analysis > all over again.