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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,379f9c2a66a5ddc8 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nntp.club.cc.cmu.edu!micro-heart-of-gold.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Question about package Interfaces. Date: Sun, 12 Sep 2010 23:54:29 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <4c8d7a8e$0$2408$4d3efbfe@news.sover.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1284350056 26721 192.74.137.71 (13 Sep 2010 03:54:16 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Mon, 13 Sep 2010 03:54:16 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:8+DA8cxDg2NPFXbV6KXJMOLDtZg= Xref: g2news1.google.com comp.lang.ada:14032 Date: 2010-09-12T23:54:29-04:00 List-Id: "Peter C. Chapin" writes: > Really two questions... > > My first question is about the types in package Interfaces such as > Integer_8, Unsigned_8, etc (I understand that the precise numbers > available depend on the implementation). The reference manual says this: > > "[They are] signed and modular types of n bits, if supported by the > target architecture, for each n that is at least the size of a storage > element and that is a factor of the word size." > > This is fine. However, I don't see anything in the reference manual that > requires these types to be represented by a specific number of bits. The > phrase "signed and modular types of n bits" is suggestive, I admit, but > does that also mean they are represented by exactly n bits in the > generated code? Would it be legal for a compiler to to store something > of type Unsigned_8 in a 16 bit object? > > I guess I'm asking if the implementation required to behave as if the > representation clause > > for Unsigned_8'Size use 8; > > was in effect? Unsigned_8'Size = 8. But that does not mean that all objects of subtype Unsigned_8 are 8 bits, nor that X'Size = 8 (where "X: Unsigned_8;"). For example, an object could be stored in a 64-bit register. A packed array A of Unsigned_8 will have A'Component_Size = 8, and A(I)'Size = 8 for all I. > My second question is about the intrinsic Shift and Rotate functions in > package Interfaces. For example: > > function Shift_Left > (Value : Unsigned_8; Amount : Natural) return Unsigned_8; > > About these functions the reference manual says: > > "They operate on a bit-by-bit basis, using the binary representation of > the value of the operands to yield a binary representation for the result." > > I don't see any description of what happens when the shift amount is > larger than the size of the object being shifted. For example; > > Value : Interfaces.Unsigned_8; > ... > Value := Interfaces.Shift_Left(Value, 1_000); > > The reference manual does say, "For shifting, zero bits are shifted > in..." However, it has recently come to my attention that some > processors, such as Intel architecture machines, have shift instructions > that mask the shift count. For example, shifting a 32 bit operand by 32 > bits results in an actual shift of 0 bits. Does that mean > implementations for such a system can't compile Interfaces.Shift_Left > into a single instruction but instead have to force "unlimited" shift > semantics on top of a hardware facility that doesn't do it that way? Yes, in general. However, if the compiler knows that the shift count is in a certain range it could optimize to a single machine instruction, even on when the hardware does something silly (as x86 does). > The C standards says that attempting to shift an object of n bits by an > amount greater than or equal to n results in "undefined behavior." Thus > C compilers can just do what the hardware does in this situation. I can > see the potential efficiency advantage there. Ada doesn't say "undefined behavior" for this. It prefers sensible answers over efficiency. But like I said, efficiency is not lost, if the compiler is smart, and you declare appropriate subranges. - Bob