13.7.1 The Package System.Storage_Elements
Static Semantics
The following language-defined
library package exists:
type Storage_Offset
is range implementation-defined;
subtype Storage_Count
is Storage_Offset
range 0..Storage_Offset'Last;
type Storage_Element
is mod implementation-defined;
for Storage_Element'Size
use Storage_Unit;
type Storage_Array
is array
(Storage_Offset
range <>)
of aliased Storage_Element;
for Storage_Array'Component_Size
use Storage_Unit;
{
AI05-0229-1}
function "+"(Left : Address; Right : Storage_Offset)
return Address
with Convention => Intrinsic;
function "+"(Left : Storage_Offset; Right : Address)
return Address
with Convention => Intrinsic;
function "-"(Left : Address; Right : Storage_Offset)
return Address
with Convention => Intrinsic;
function "-"(Left, Right : Address)
return Storage_Offset
with Convention => Intrinsic;
{
AI05-0229-1}
function "
mod"(Left : Address; Right : Storage_Offset)
return Storage_Offset
with Convention => Intrinsic;
-- Conversion to/from integers:
{
AI05-0229-1}
type Integer_Address
is implementation-defined;
function To_Address(Value : Integer_Address)
return Address
with Convention => Intrinsic;
function To_Integer(Value : Address)
return Integer_Address
with Convention => Intrinsic;
Reason: {
AI05-0229-1}
The Convention aspects imply that the attribute Access is not allowed
for those operations.
The mod function is needed so that the
definition of Alignment makes sense.
Implementation defined: The range of
Storage_Elements.Storage_Offset, the modulus of Storage_Elements.Storage_Element,
and the declaration of Storage_Elements.Integer_Address.
Storage_Element represents a storage element. Storage_Offset
represents an offset in storage elements. Storage_Count represents a
number of storage elements.
Storage_Array
represents a contiguous sequence of storage elements.
Reason: The index subtype of Storage_Array
is Storage_Offset because we wish to allow maximum flexibility. Most
Storage_Arrays will probably have a lower bound of 0 or 1, but other
lower bounds, including negative ones, make sense in some situations.
Integer_Address is a [(signed or modular)] integer
subtype. To_Address and To_Integer convert back and forth between this
type and Address.
Implementation Requirements
Storage_Offset'Last shall be greater than or equal
to Integer'Last or the largest possible storage offset, whichever is
smaller. Storage_Offset'First shall be <= (–Storage_Offset'Last).
Paragraph 15 was
deleted.
Implementation Advice
Operations in System and its children should reflect
the target environment semantics as closely as is reasonable. For example,
on most machines, it makes sense for address arithmetic to “wrap
around”. Operations that do not make sense should raise Program_Error.
Implementation Advice: Operations in
System and its children should reflect the target environment; operations
that do not make sense should raise Program_Error.
Discussion: For example, on a segmented
architecture, X < Y might raise Program_Error if X and Y do not point
at the same segment (assuming segments are unordered). Similarly, on
a segmented architecture, the conversions between Integer_Address and
Address might not make sense for some values, and so might raise Program_Error.
Reason: We considered making Storage_Element
a private type. However, it is better to declare it as a modular type
in the visible part, since code that uses it is already low level, and
might as well have access to the underlying representation. We also considered
allowing Storage_Element to be any integer type, signed integer or modular,
but it is better to have uniformity across implementations in this regard,
and viewing storage elements as unsigned seemed to make the most sense.
Implementation Note: To_Address is intended
for use in Address clauses. Implementations should overload To_Address
if appropriate. For example, on a segmented architecture, it might make
sense to have a record type representing a segment/offset pair, and have
a To_Address conversion that converts from that record type to type Address.
Extensions to Ada 95
{
AI95-00362-01}
Package System.Storage_Elements is now Pure, so it
can be portably used in more places. (Ada 95 allowed it to be Pure, but
did not require that.)
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe