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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fe1de79a099115c5 X-Google-Attributes: gid103376,public From: Stephen Leake Subject: Re: 16 bit integers in streams Date: 1997/09/26 Message-ID: <342C09BA.269C@gsfc.nasa.gov>#1/1 X-Deja-AN: 275810130 References: <342AD4BA.283F@gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Reply-To: Stephen.Leake@gsfc.nasa.gov Newsgroups: comp.lang.ada Date: 1997-09-26T00:00:00+00:00 List-Id: Tucker Taft wrote: > ... > In general, the existence of the base subtype is more of an > interesting > frill than a core feature, but with streams, the characteristics of > the base subtype suddenly become more important. It's not clear > how to resolve this dilemma... If I can summarize: Stream attributes 'Read and 'Write need to work for the base type, because we can declare objects of type 'Base. A size clause specifies the size of the first subtype, not the base type. The base type can in general contain more bits than the first subtype. ObjectAda chooses 32 bit integers as the base type when I ask for 16 bit integers, and therefore reads and writes 32 bits in streams. This now makes sense (to me, anyway :). My original problem was that I want to read a 16 bit integer from a stream (where the stream format is dicated outside my Ada program). Clearly, if I was reading a 12 bit integer, I'd have to read two stream elements and then do a shift and an unchecked conversion, and keep track of the extra bits that are part of the next item in the stream. I can take the same approach when reading a 16 bit integer, but I don't have to if I use GNAT, which allows 16 bit base integers. The stream format assumes I can read 16 bit chunks; it does not use smaller chunks. Actually, I found another work around for ObjectAda; I can read Wide_Characters, which are 16 bits, and then use 'Pos to get an integer. But that's a bit of a kludge. This gets back to the question of why ObjectAda uses 32 bit base integers, when I give a range that fits in 16 bits and a size clause for 16 bits. Tucker said it was for "efficient arithmetic", but that's not what I want in this case. It seems to me that specifying a size clause should be enough of a hint to the compiler that I am willing to sacrifice efficiency for the sake of control over size (in streams, in this case). If you want more of a hint, I can add a pragma Optimize (Space) (which I suggested earlier). Tuck said this would be a "large semantic effect". I'm not clear what the problem is; the choice of base integer size affects three things (that I know of): 1) The time efficiency of integer arithmetic. 2) Whether CONSTRAINT_ERROR is raised for intermediate results that are outside the first subtype range. 3) The number of bits read/written in streams. What else does it affect? If we let size clauses influence the choice of base integer type, we have the following user control: For 1), to let the compiler to choose a time efficient arithmetic type, I just specify the range, and do NOT give a size clause. Similarly, for 2), I can specify a range that covers my intermediate results. For 3), I specify the number of bits I want, with the understanding that it will be rounded up to the next hardware-supported integer size. Perhaps a totally different solution would be to introduce yet another stream attribute: 'Write_Sized, which respects the size clause, and thus cannot be used on an object of a base type. > > : -- > : - Stephe > > -- > -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ > Intermetrics, Inc. Burlington, MA USA -- - Stephe