Question about package Interfaces.

["Peter C. Chapin" <chapinp@acm.org>]

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?

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?

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.

Peter