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/26 Message-ID: #1/1 X-Deja-AN: 275774468 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: <342AD4BA.283F@gsfc.nasa.gov> Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1997-09-26T00:00:00+00:00 List-Id: Stephen Leake (Stephen.Leake@gsfc.nasa.gov) wrote: : I assume size clauses control both the external and internal : representation; see below. You would be wrong if you made that assumption. : > 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... : Or complain about it :). Surely the intent of 'Read is to put the : _memory_ image of a type into the stream, not the _register_ image? Because 'Write/'Read are designed to handle the *base* range of the type, rather than the range of the first subtype, the stream representation is in some sense more related to the "register" image than the memory image. : > 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... : This is definitely what I expect a size clause to mean; I'm telling the : compiler I want exactly 16 bits, anyplace it matters (including : streams). I assume that's what GNAT does now, although maybe GNAT is : also doing 16 bit arithmetic. A size clause currently has *no* effect on the base range of the type. I am thinking that perhaps it ought to have such an effect, though that "thought" is pretty radical. And there are some problems with the idea. For example, given: type I16 is range 0..2**16-1; for I16'size use 16; Clearly the base range of this type is required by the RM to be at least -2**16+1 .. 2**16-1, since it is a signed integer type (even though the first subtype's range includes no negative values). So what should be the stream representation for this type? Presuming each stream element is 8 bits, probably at least 3 stream elements, and more likely 4 stream elements, would be the expected stream representation. 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... : -- : - Stephe -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA