!standard 13.03 (55) 97-04-11 AI95-00125/01 !class confirmation 96-04-04 !status WG9 approved (8-0-0) 97-07-04 !status ARG approved (6-0-1) 97-04-11 !status work item 96-04-04 !status received 96-04-04 !priority Medium !difficulty Medium !subject Order of Size and Small Clauses for Fixed Point Types !summary 96-09-08 A Size clause does not determine the values of an ordinary fixed point type. The values are determined either by the implementation, or by a Small clause; the legality of a Size clause is determined in part by the values chosen. !question 96-09-08 Consider: type Two_Bits_Spare is delta 4*System.Fine_Delta range -1.0..+1.0; for Two_Bits_Spare'Size use Size_For_Fine_Delta - 2; -- Legal? (Maybe.) where Size_For_Fine_Delta is the number of bits needed for a type whose delta is Fine_Delta. Does the Size clause force the implementation to choose the small of the type such that only Size_For_Fine_Delta - 2 bits are needed? (No.) 13.3(55) says that 'Size should/must be "the number of bits needed to represent each value belonging to the subtype ..." and that an implementation should/must support a specified 'Size for a first subtype that reflects this representation. 3.5.9(8) says "the set of values of a fixed-point type comprise[s] the integral multiples of a number called the small of the type" which if not specified "is an implementation-defined power of two ..." !response 96-09-08 Since there is no Small clause in the above example, 3.5.9(8) allows the implementation to choose various powers of two as the small, and the small determines what the values of the type are. A Size clause is required to specify enough bits to represent all those values. Thus, the Size clause in the above example is legal if the implementation chooses small=4*System.Fine_Delta, but illegal if the implementation chooses small=System.Fine_Delta. !appendix 96-09-04 !section 13.3(55) !subject Fixed-point'Size !reference RM95-13.3(55) !reference RM95-3.5.9(8) !from Dan Lehman 96-02-26 !keywords values !reference 96-5431.a Dan Lehman 96-2-26>> !discussion There is a chicken-&-egg problem with the 'Size of a fixed-point subtype (that is a first subtype): 13.3(55) says that 'Size should/must be "the number of bits needed to represent each value belonging to the subtype ..." and that an implementation should/must support a specified 'Size for a first subtype that reflects this representation; but 3.5.9(8) says "the set of values of a fixed-point type comprise[s] the integral multiples of a number called the small of the type" which if not specified "is an implementation-defined power of two ..." Must a user specify 'Small before specifying 'Size for a fixed-point type? ---Dan ------- * **************************************************************** !section 13.3(55) !subject AI-125/00: Order of Size and Small Clauses for Fixed Point Types !reference RM95-13.3(55) !reference RM95-3.5.9(8) !from Dan Lehman 96-08-21 !keywords values !reference 96-5632.a Dan Lehman 96-8-20>> In AI-125/00, the response that is written--to wit: !response 96-04-04 The Size clause and Small clause must both specify static values (see 13.3(41), 3.5.10(2)). Therefore, the compiler should have no trouble checking that they are consistent with each other, no matter which order they appear in. misses the point of my question in this AI, which is How may 'Size be specified (in general) for a fixed-point type, since the 'Size must allow for all *values of the type* and these are determined by the implementation (according to the 'Small it selects)? (In the case where both attributes are specified, the user should know what to expect.) The implication of the !response is that the 'Size clause determines the values of the fixed-point type (though nothing in the RM about this clause gives the impression that it has such power). Consider the declarations: type Two_bits_spare is delta 4*System.Fine_Delta range -1.0..+1.0; for Two_bits_spare'Size use - 2; By 3.5.9(8) the implementation may chose Fine_Delta to be the 'small of the type, which requires the full "", of course, and so would make the 'Size clause illegal. But I presume that this is really not an intended consequence!? Thus, 13.3(55) carries a strong Ada83 presumption of *coarsest-small* values. ---Dan Lehman -------------- * **************************************************************** !section 13.3(55) !subject AI-125/00: Order of Size and Small Clauses for Fixed Point Types !reference RM95-13.3(55) !reference RM95-3.5.9(8) !reference 96-5632.a Dan Lehman 96-8-20 !from Bob Duff !reference 96-5657.a Robert A Duff 96-8-27>> !discussion > In AI-125/00, the response that is written--to wit: > > !response 96-04-04 > > The Size clause and Small clause must both specify static values (see > 13.3(41), 3.5.10(2)). Therefore, the compiler should have no trouble > checking that they are consistent with each other, no matter which order > they appear in. > > misses the point of my question in this AI, Yes. I wrote that draft response, and I agree that I missed your point. >...which is How may 'Size be > specified (in general) for a fixed-point type, since the 'Size must allow > for all *values of the type* and these are determined by the implementation > (according to the 'Small it selects)? (In the case where both attributes > are specified, the user should know what to expect.) > > The implication of the !response is that the 'Size clause determines the > values of the fixed-point type (though nothing in the RM about this clause > gives the impression that it has such power). The !response just says you can give both a Size clause and a Small clause, and if you do, you can give them in either order. I think that's true, and should be true (although it wasn't exactly what you were asking). It seems to me that a Size clause should not affect the values of the type. I'm not sure how the current draft implies otherwise, but ... >... Consider the declarations: > > type Two_bits_spare is delta 4*System.Fine_Delta range -1.0..+1.0; > for Two_bits_spare'Size use - 2; > > By 3.5.9(8) the implementation may chose Fine_Delta to be the 'small of the > type, which requires the full "", of course, and so > would make the 'Size clause illegal. Right. It seems to me that in this case, it is implementation-defined whether or not the Size clause is legal. Since there is no Small clause, the implementation is free to choose various powers of two, which means that the Size clause might be enough for all the values, or it might not. If there were a Small clause, then that would determine the set of values, and the above Size clause would be legal or illegal accordingly. In this case, it doesn't matter which rep clause comes first, since the expressions involved are static. This implies that if you want a portable Size clause, you have to write a Small clause also. >... But I presume that this is really not > an intended consequence!? Well, ..., what's the problem with it? Yes, it makes Size clauses less portable, but that doesn't seem so harmful. It seems less harmful than saying Size clauses affect the values of the type. It's bad enough that Small clauses affect the values of the type (while pretending to merely affect "representation"). >... Thus, 13.3(55) carries a strong Ada83 presumption > of *coarsest-small* values. NOTE: During the language design I argued against including fixed point types in 13.3(55), on the grounds that fixed point just isn't important enough of a feature to be placing extra requirements on it, that never appeared in RM83. Tucker argued that fixed point is represented in essentially the same way as integers, and so the same rules should apply. Anyway, is what I said above acceptable? If so, I'll produce a new draft version of the AI that says so. And unless somebody complains, I'll leave the priority "medium", since I think the number of users affected is *small*. - Bob ****************************************************************