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: "Robert I. Eachus" Subject: Re: Overlay allowability Date: 2000/05/02 Message-ID: <390F67DB.7AB83BD@earthlink.net> X-Deja-AN: 618482000 Content-Transfer-Encoding: 7bit References: <390D94FB.D23390D4@lmco.com> X-Accept-Language: en,pdf Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 957310930 63.24.60.203 (Tue, 02 May 2000 16:42:10 PDT) Organization: The MITRE Corporation MIME-Version: 1.0 NNTP-Posting-Date: Tue, 02 May 2000 16:42:10 PDT Newsgroups: comp.lang.ada Date: 2000-05-02T00:00:00+00:00 List-Id: "Marc A. Criley" wrote: This one should be in the FAQ... > 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.