Re: Question about package Interfaces.

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Peter C. Chapin" <chapinp@acm.org> 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