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=0.7 required=5.0 tests=BAYES_00,MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,582882cfea9f35db X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-01-12 09:54:01 PST Path: supernews.google.com!sn-xit-03!supernews.com!news-feed.riddles.org.uk!newsfeed.direct.ca!look.ca!logbridge.uoregon.edu!arclight.uoregon.edu!newsfeed.cs.utexas.edu!galaxy.us.dell.com!news-feeds!nntp2.deja.com!nnrp1.deja.com!not-for-mail From: Robert Dewar Newsgroups: comp.lang.ada Subject: Re: Green Hiils AdaMULTI 2000 -> Motorola Coldfire Date: Fri, 12 Jan 2001 17:44:40 GMT Organization: Deja.com Message-ID: <93nfq5$nho$1@nnrp1.deja.com> References: <93igkj$grt$1@lure.pipex.net> <3A5DC6D5.5A8446D8@hercii.mar.lmco.com> <3A5EF610.66C153D2@earthlink.net> NNTP-Posting-Host: 205.232.38.14 X-Article-Creation-Date: Fri Jan 12 17:44:40 2001 GMT X-Http-User-Agent: Mozilla/4.61 [en] (OS/2; U) X-Http-Proxy: 1.0 x51.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 X-MyDeja-Info: XMYDJUIDrobert_dewar Xref: supernews.google.com comp.lang.ada:3960 Date: 2001-01-12T17:44:40+00:00 List-Id: In article <3A5EF610.66C153D2@earthlink.net>, "Marc A. Criley" wrote: > For > example: > > type Counts is range 0..128; > for Counts'size use 32; > > subtype Subcounts is Counts range 1..128; > > then > Counts'Size is 32 > Subcounts'Size is 8 > > This is caused by a gap in the Ada 95 definition regarding > "sizes", which I think Robert Dewar alluded to in an earlier > message. This is NOT a "gap" in Ada 95. The above behavior is specifically required by the Ada 95 RM, and any Ada 95 compiler that supports annex C that does NOT give this behavior is (rather seriously) non-conforming. The relevant RM section is 13.3 55 The Size (if not specified) of a static discrete or fixed point subtype should be the number of bits needed to represent each value belonging to the subtype using an unbiased representation, leaving space for a sign bit only if the subtype contains negative values. If such a subtype is a first subtype, then an implementation should support a specified Size for it that reflects this representation. Clearly this requires a size of 8 for the above subtype. Remember that recommendations of this kind become requirements if annex C is supported. > I don't recall the LRM reference that results in this > behavior, but it's defininely there and one is barred from > making the behavior otherwise. Yes, right, but that's not a "gap", it is well defined requirement. If anything it is Ada 83 that has the gap in leaving this unspecified (i.e. Ada 83 is equivalent to Ada 95 without the advice and without Annex C). The trouble is that the designers simply made a choice which was pragmatically wrong, since it did not match what almost all commonly used Ada 83 compilers did (I have been told, but do not know first hand that the Intermetrics compiler for IBM mainframes made the choice in the Ada 95 style, which if true, probably accounts for the mistake). It is an unfortunate mistake, since it is the source of a significant amount of porting problems. Making the situation worse, the Size attribute in Ada 95 is subtype specific. You might think that this means that you can specify it for subtypes, but no such luck (this was an intended feature, but (unwisely in my view) got removed rather late on). So compounding the design mistake here is that no only is the default size wrong in the above example, but you cannot override this incorrect size. In GNAT, we have added the Value_Size attribute, which can be specified for subtypes, so you could do: for Subcounts'Value_Size use 8; and then the value of Subcounts'Size would be 8 (yes, it would be neater if we could say: for Subcounts'Size use 8; but there is a rule in the RM prohibiting this extension. They are definitely out to make this as annoying as possible :-) :-) > I recall, though, ACT informing me that _objects_ of either > of those Counts or Subcounts types would occupy the requested > 32 bits (and they do in GNAT)--I believe there was some > implementation freedom regarding that aspect. Yes, there is implementation freedom here, and the decision in GNAT is to always inherit what we call the Object_Size from the parent type, since we found that was a very common assumption in legacy code. Furthermore, Object_Size is introduced as an attribute in GNAT so that you can control the object size (on a subtype by subtype basis). So as long as you are using GNAT, there are relatively easy ways of dealing with this. And if putting in a bunch of declarations is still too much, we have the: pragma Use_VADS_Size; configuration pragma, which duplicates (as closely as possible, the documentation is not entirely complete), the effect of both the size attribute and the size attribute definition clause in VADS Ada 83. > In the few places where we had to deal with this situation, > we simply replaced the subtype with the parent type at, and > only at, the place where the difference in size had an > effect. Everywhere else we continued to use the subtype to > ensure proper type constraining. Of course finding these places can be tricky. A particularly nasty case is the following: type x is record A : Natural; B : Natural; end record; for x use record A at 0 range 0 .. Natural'Size - 1; B at 0 range Natural'Size .. 2 * Natural'Size - 1; end record; for x'size use 2 * Natural'Size; The horrible thing about this declaration is that in almost all Ada 83 compilers it nicely lays out (assume 32 bit integer) the record as two 32-bit words, with a length of 64. In Ada 95, it silently lays out the record with the fields occupying 31 bits, the second field overlaps word boundaries, and the record has a size of 62 bits, likely leading to entirely horrible inefficiencies. Indeed a suggestion we have filed is to always generate a warning for Natural'Size on the grounds that it is almost certainly a nasty surprise of this type :-( Sent via Deja.com http://www.deja.com/