1 ------------------------------------------------------------------------------
3 -- GNAT COMPILER COMPONENTS --
9 -- Copyright (C) 1992-2023, Free Software Foundation, Inc. --
11 -- GNAT is free software; you can redistribute it and/or modify it under --
12 -- terms of the GNU General Public License as published by the Free Soft- --
13 -- ware Foundation; either version 3, or (at your option) any later ver- --
14 -- sion. GNAT is distributed in the hope that it will be useful, but WITH- --
15 -- OUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY --
16 -- or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License --
17 -- for more details. You should have received a copy of the GNU General --
18 -- Public License distributed with GNAT; see file COPYING3. If not, go to --
19 -- http://www.gnu.org/licenses for a complete copy of the license. --
21 -- GNAT was originally developed by the GNAT team at New York University. --
22 -- Extensive contributions were provided by Ada Core Technologies Inc. --
24 ------------------------------------------------------------------------------
26 -- Expand routines for manipulation of packed arrays
28 with Rtsfind
; use Rtsfind
;
29 with Types
; use Types
;
33 -------------------------------------
34 -- Implementation of Packed Arrays --
35 -------------------------------------
37 -- When a packed array (sub)type is frozen, we create a corresponding
38 -- type that will be used to hold the bits of the packed value, and store
39 -- the entity for this type in the Packed_Array_Impl_Type field of the
40 -- E_Array_Type or E_Array_Subtype entity for the packed array.
42 -- This packed array type has the name xxxPn, where xxx is the name
43 -- of the packed type, and n is the component size. The expanded
44 -- declaration declares a type that is one of the following (sizes
45 -- below are in bytes):
47 -- For an unconstrained array with component size 1,2,4 or any other
48 -- odd component size. These are the cases in which we do not need
49 -- to align the underlying array.
51 -- type xxxPn is new Packed_Bytes1;
53 -- For an unconstrained array with component size greater than 2, that is
54 -- divisible by 2, but not divisible by 4. These are the cases in which
55 -- we can generate better code if the underlying array is 2-byte aligned
56 -- (see System.Pack_14 in file s-pack14 for example).
58 -- type xxxPn is new Packed_Bytes2;
60 -- For an unconstrained array with component size that is divisible
61 -- by 4, other than powers of 2 (which either come under the 1,2,4
62 -- exception above, or are not packed at all). These are cases where
63 -- we can generate better code if the underlying array is 4-byte
64 -- aligned (see System.Pack_20 in file s-pack20 for example).
66 -- type xxxPn is new Packed_Bytes4;
68 -- For a constrained array with a static index type where the number
69 -- of bits does not exceed the size of Unsigned:
71 -- type xxxPn is new Unsigned range 0 .. 2 ** nbits - 1;
73 -- For a constrained array with a static index type where the number
74 -- of bits is greater than the size of Unsigned, but does not exceed
75 -- the size of Long_Long_Unsigned:
77 -- type xxxPn is new Long_Long_Unsigned range 0 .. 2 ** nbits - 1;
79 -- For all other constrained arrays, we use one of
81 -- type xxxPn is new Packed_Bytes1 (0 .. m);
82 -- type xxxPn is new Packed_Bytes2 (0 .. m);
83 -- type xxxPn is new Packed_Bytes4 (0 .. m);
85 -- where m is calculated (from the length of the original packed array)
86 -- to hold the required number of bits, and the choice of the particular
87 -- Packed_Bytes{1,2,4} type is made on the basis of alignment needs as
88 -- described above for the unconstrained case.
90 -- When the packed array (sub)type is specified to have the reverse scalar
91 -- storage order, the Packed_Bytes{1,2,4} references above are replaced
92 -- with Rev_Packed_Bytes{1,2,4}. This is necessary because, although the
93 -- component type is Packed_Byte and therefore endian neutral, the scalar
94 -- storage order of the new type must be compatible with that of an outer
95 -- composite type, if this composite type contains a component whose type
96 -- is the packed array (sub)type and which does not start or does not end
97 -- on a storage unit boundary.
99 -- When a variable of packed array type is allocated, gigi will allocate
100 -- the amount of space indicated by the corresponding packed array type.
101 -- However, we do NOT attempt to rewrite the types of any references or
102 -- to retype the variable itself, since this would cause all kinds of
103 -- semantic problems in the front end (remember that expansion proceeds
104 -- at the same time as analysis).
106 -- For an indexed reference to a packed array, we simply convert the
107 -- reference to the appropriate equivalent reference to the object
108 -- of the packed array type (using unchecked conversion).
110 -- In some cases (for internally generated types, and for the subtypes
111 -- for record fields that depend on a discriminant), the corresponding
112 -- packed type cannot be easily generated in advance. In these cases,
113 -- we generate the required subtype on the fly at the reference point.
115 -- For the modular case, any unused bits are initialized to zero, and
116 -- all operations maintain these bits as zero (where necessary all
117 -- unchecked conversions from corresponding array values require
118 -- these bits to be clear, which is done automatically by gigi).
120 -- For the array cases, there can be unused bits in the last byte, and
121 -- these are neither initialized, nor treated specially in operations
122 -- (i.e. it is allowable for these bits to be clobbered, e.g. by not).
124 ---------------------------
125 -- Endian Considerations --
126 ---------------------------
128 -- The standard does not specify the way in which bits are numbered in
129 -- a packed array. There are two reasonable rules for deciding this:
131 -- Store the first bit at right end (low order) word. This means
132 -- that the scaled subscript can be used directly as a left shift
133 -- count (if we put bit 0 at the left end, then we need an extra
134 -- subtract to compute the shift count).
136 -- Layout the bits so that if the packed boolean array is overlaid on
137 -- a record, using unchecked conversion, then bit 0 of the array is
138 -- the same as the bit numbered bit 0 in a record representation
139 -- clause applying to the record. For example:
141 -- type Rec is record
147 -- for Rec use record
148 -- C at 0 range 0 .. 3;
149 -- D at 0 range 4 .. 10;
150 -- E at 0 range 11 .. 15;
153 -- type P16 is array (0 .. 15) of Boolean;
154 -- pragma Pack (P16);
156 -- Now if we use unchecked conversion to convert a value of the record
157 -- type to the packed array type, according to this second criterion,
158 -- we would expect field D to occupy bits 4..10 of the Boolean array.
160 -- Although not required, this correspondence seems a highly desirable
161 -- property, and is one that GNAT decides to guarantee. For a little
162 -- endian machine, we can also meet the first requirement, but for a
163 -- big endian machine, it will be necessary to store the first bit of
164 -- a Boolean array in the left end (most significant) bit of the word.
165 -- This may cost an extra instruction on some machines, but we consider
166 -- that a worthwhile price to pay for the consistency.
168 -- One more important point arises in the case where we have a constrained
169 -- subtype of an unconstrained array. Take the case of 20 bits. For the
170 -- unconstrained representation, we would use an array of bytes:
172 -- Little-endian case
173 -- 8-7-6-5-4-3-2-1 16-15-14-13-12-11-10-9 x-x-x-x-20-19-18-17
176 -- 1-2-3-4-5-6-7-8 9-10-11-12-13-14-15-16 17-18-19-20-x-x-x-x
178 -- For the constrained case, we use a 20-bit modular value, but in
179 -- general this value may well be stored in 32 bits. Let's look at
180 -- what it looks like:
182 -- Little-endian case
184 -- x-x-x-x-x-x-x-x-x-x-x-x-20-19-18-17-...-10-9-8-7-6-5-4-3-2-1
186 -- which stored in memory looks like
188 -- 8-7-...-2-1 16-15-...-10-9 x-x-x-x-20-19-18-17 x-x-x-x-x-x-x
190 -- An important rule is that the constrained and unconstrained cases
191 -- must have the same bit representation in memory, since we will often
192 -- convert from one to the other (e.g. when calling a procedure whose
193 -- formal is unconstrained). As we see, that criterion is met for the
194 -- little-endian case above. Now let's look at the big-endian case:
198 -- x-x-x-x-x-x-x-x-x-x-x-x-1-2-3-4-5-6-7-8-9-10-...-17-18-19-20
200 -- which stored in memory looks like
202 -- x-x-x-x-x-x-x-x x-x-x-x-1-2-3-4 5-6-...11-12 13-14-...-19-20
204 -- That won't do, the representation value in memory is NOT the same in
205 -- the constrained and unconstrained case. The solution is to store the
206 -- modular value left-justified:
208 -- 1-2-3-4-5-6-7-8-9-10-...-17-18-19-20-x-x-x-x-x-x-x-x-x-x-x
210 -- which stored in memory looks like
212 -- 1-2-...-7-8 9-10-...15-16 17-18-19-20-x-x-x-x x-x-x-x-x-x-x-x
214 -- and now, we do indeed have the same representation for the memory
215 -- version in the constrained and unconstrained cases.
217 ----------------------------------------------
218 -- Entity Tables for Packed Access Routines --
219 ----------------------------------------------
221 -- For the cases of component size = 3,5-7,9-15,17-31,33-63,65-127 we call
222 -- library routines. These tables provide the entity for the right routine.
223 -- They are exposed in the spec to allow checking for the presence of the
224 -- needed routine when an array is subject to pragma Pack.
226 type E_Array
is array (Int
range 1 .. 127) of RE_Id
;
228 -- Array of Bits_nn entities. Note that we do not use library routines
229 -- for the 8-bit and 16-bit cases, but we still fill in the table, using
230 -- entries from System.Unsigned, because we also use this table for
231 -- certain special unchecked conversions in the big-endian case.
233 Bits_Id
: constant E_Array
:=
249 16 => RE_Unsigned_16
,
265 32 => RE_Unsigned_32
,
297 64 => RE_Unsigned_64
,
362 -- Array of Get routine entities. These are used to obtain an element from
363 -- a packed array. The N'th entry is used to obtain elements from a packed
364 -- array whose component size is N. RE_Null is used as a null entry, for
365 -- the cases where a library routine is not used.
367 Get_Id
: constant E_Array
:=
496 -- Array of Get routine entities to be used in the case where the packed
497 -- array is itself a component of a packed structure, and therefore may not
498 -- be fully aligned. This only affects the even sizes, since for the odd
499 -- sizes, we do not get any fixed alignment in any case.
501 GetU_Id
: constant E_Array
:=
630 -- Array of Set routine entities. These are used to assign an element of a
631 -- packed array. The N'th entry is used to assign elements for a packed
632 -- array whose component size is N. RE_Null is used as a null entry, for
633 -- the cases where a library routine is not used.
635 Set_Id
: constant E_Array
:=
764 -- Array of Set routine entities to be used in the case where the packed
765 -- array is itself a component of a packed structure, and therefore may not
766 -- be fully aligned. This only affects the even sizes, since for the odd
767 -- sizes, we do not get any fixed alignment in any case.
769 SetU_Id
: constant E_Array
:=
902 procedure Create_Packed_Array_Impl_Type
(Typ
: Entity_Id
);
903 -- Typ is a array type or subtype to which pragma Pack applies. If the
904 -- Packed_Array_Impl_Type field of Typ is already set, then the call has
905 -- no effect, otherwise a suitable type or subtype is created and stored in
906 -- the Packed_Array_Impl_Type field of Typ. This created type is an Itype
907 -- so that Gigi will simply elaborate and freeze the type on first use
908 -- (which is typically the definition of the corresponding array type).
910 -- Note: although this routine is included in the expander package for
911 -- packed types, it is actually called unconditionally from Freeze,
912 -- whether or not expansion (and code generation) is enabled. We do this
913 -- since we want gigi to be able to properly compute type characteristics
914 -- (for the Data Decomposition Annex of ASIS, and possible other future
915 -- uses) even if code generation is not active. Strictly this means that
916 -- this procedure is not part of the expander, but it seems appropriate
917 -- to keep it together with the other expansion routines that have to do
918 -- with packed array types.
920 procedure Expand_Packed_Boolean_Operator
(N
: Node_Id
);
921 -- N is an N_Op_And, N_Op_Or or N_Op_Xor node whose operand type is a
922 -- packed boolean array. This routine expands the appropriate operations
923 -- to carry out the logical operation on the packed arrays. It handles
924 -- both the modular and array representation cases.
926 procedure Expand_Packed_Element_Reference
(N
: Node_Id
);
927 -- N is an N_Indexed_Component node whose prefix is a packed array. In
928 -- the bit packed case, this routine can only be used for the expression
929 -- evaluation case, not the assignment case, since the result is not a
930 -- variable. See Expand_Bit_Packed_Element_Set for how the assignment case
931 -- is handled in the bit packed case. For the enumeration case, the result
932 -- of this call is always a variable, so the call can be used for both the
933 -- expression evaluation and assignment cases.
935 procedure Expand_Bit_Packed_Element_Set
(N
: Node_Id
);
936 -- N is an N_Assignment_Statement node whose name is an indexed
937 -- component of a bit-packed array. This procedure rewrites the entire
938 -- assignment statement with appropriate code to set the referenced
939 -- bits of the packed array type object. Note that this procedure is
940 -- used only for the bit-packed case, not for the enumeration case.
942 procedure Expand_Packed_Eq
(N
: Node_Id
);
943 -- N is an N_Op_Eq node where the operands are packed arrays whose
944 -- representation is an array-of-bytes type (the case where a modular
945 -- type is used for the representation does not require any special
946 -- handling, because in the modular case, unused bits are zeroes).
948 procedure Expand_Packed_Not
(N
: Node_Id
);
949 -- N is an N_Op_Not node where the operand is packed array of Boolean
950 -- in standard representation (i.e. component size is one bit). This
951 -- procedure expands the corresponding not operation. Note that the
952 -- non-standard representation case is handled by using a loop through
953 -- elements generated by the normal non-packed circuitry.
955 function Involves_Packed_Array_Reference
(N
: Node_Id
) return Boolean;
956 -- N is the node for a name. This function returns true if the name
957 -- involves a packed array reference. A node involves a packed array
958 -- reference if it is itself an indexed component referring to a bit-
959 -- packed array, or it is a selected component whose prefix involves
960 -- a packed array reference.
962 procedure Expand_Packed_Address_Reference
(N
: Node_Id
);
963 -- The node N is an attribute reference for the 'Address reference, where
964 -- the prefix involves a packed array reference. This routine expands the
965 -- necessary code for performing the address reference in this case.
967 procedure Expand_Packed_Bit_Reference
(N
: Node_Id
);
968 -- The node N is an attribute reference for the 'Bit reference, where the
969 -- prefix involves a packed array reference. This routine expands the
970 -- necessary code for performing the bit reference in this case.