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.3 required=5.0 tests=BAYES_00,INVALID_MSGID 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: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: 16 bit integers in streams Date: 1997/09/25 Message-ID: #1/1 X-Deja-AN: 275497385 Sender: news@inmet.camb.inmet.com (USENET news) References: <342A83A8.77AA@gsfc.nasa.gov> X-Nntp-Posting-Host: houdini.camb.inmet.com Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1997-09-25T00:00:00+00:00 List-Id: Stephen Leake (Stephen.Leake@gsfc.nasa.gov) wrote: : ... : But I DID use Integer_16'Base for Read (not for Write), at least with an : intevening subtype definition. I also tried: : for Integer_16'Base'Read use Read_16; : and that gave the error: : interface_streams.ads: Error: line 12 col 19 LRM:13.3(5), The BASE : attribute is not a specifiable attribute : Is this a bug in ObjectAda? My maintenance contract has run out, but : I'll report it anyway. No, this is not a bug. Per RM95 13.13.2(36), the subtype of the Item parameter in the spec for your Read_16 and Write_16 procedures must be the base subtype. The subtype in the rep-clause must be the first subtype (13.1(8)). Hence, to make this work, do something like: procedure Read_16( Stream : access Ada.Streams.Root_Stream_Type'Class; Item : Integer_16'Base -- *here* is where you need the 'Base ); for Integer_16'Read use Read_16; See RM95 13.13.2(40) for a very similar example of use. : ... : > One possibility is to "pretend" the base subtype is only 16 bits, : > even though 32-bit arithmetic and 32-bit registers are used : > for all calculations. This would bring the stream behavior : > back to where it only wrote 16 bits per item, but the meaning : > of 'Base would be somewhat muddied. : Ok, I understand the consistency issue. Apparently GNAT uses 16 bit base : integers when I request them. I hearby request an option on ObjectAda : (and therefore the AdaMagic front end?) to sacrifice efficient integer : arithmetic, and give me 16 bit base integers (when appropriate), and : therefore 16 bits in streams! Could pragma Optimize (Space) do this? Gulp. This would be a pretty big semantic effect for pragma Optimize. The problem is that the representation used on streams is in one sense a very important "high-level" external effect, and in another sense something almost analagous to internal representation. I suspect the "right" solution is to consider the base range to be a 16 bit range for types like this, even though 32-bit arithmetic is used for them. We have already considered doing this, but haven't done it yet. Of course, the longer we wait, the more people will begin to rely on the current behavior... Perhaps we could use an explicit size clause as a way to control the base range. We have frequently debated the meaning of a "confirming" size clause. Perhaps this could be one "real" effect of such a clause. It's an intriguing thought... : > The URG is no longer an active group. The ARG is taking up the slack, : > and there will probably be AIs that address implementation advice, : > as opposed to implementation requirements. : So does this qualify as an AI? I guess I should just submit it and see : what happens. Yes, it qualifies as an AI. : Thanks for your clear and detailed response; it is always a pleasure : when you post to comp.lang.ada. Your welcome. : -- : - Stephe -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA