File: AA-13-3.html

package info (click to toggle)
ada-reference-manual 20021112web-3
  • links: PTS
  • area: main
  • in suites: etch, etch-m68k, lenny, sarge
  • size: 18,652 kB
  • ctags: 8,921
  • sloc: makefile: 52; sh: 20
file content (1147 lines) | stat: -rw-r--r-- 77,342 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<HTML>
<HEAD>
    <TITLE>AARM95 - Operational and Representation Attributes</TITLE>
    <META NAME="Author" CONTENT="JTC1/SC22/WG9/ARG, by Randall Brukardt, ARG Editor">
    <META NAME="GENERATOR" CONTENT="Arm_Form.Exe, Ada Reference Manual generator">
    <STYLE type="text/css">
    DIV.paranum {position: absolute; font-family: Arial, Helvetica, sans-serif; left: 0.5 em; top: auto}
    TT {font-family: "Courier New", monospace}
    DT {display: compact}
    DIV.Normal {font-family: "Times New Roman", Times, serif; margin-bottom: 0.6em}
    DIV.Wide {font-family: "Times New Roman", Times, serif; margin-top: 0.6em; margin-bottom: 0.6em}
    DIV.Annotations {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-bottom: 0.6em}
    DIV.WideAnnotations {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-top: 0.6em; margin-bottom: 0.6em}
    DIV.Index {font-family: "Times New Roman", Times, serif}
    DIV.SyntaxSummary {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-bottom: 0.4em}
    DIV.Notes {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-bottom: 0.6em}
    DIV.NotesHeader {font-family: "Times New Roman", Times, serif; margin-left: 2.0em}
    DIV.SyntaxIndented {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-bottom: 0.4em}
    DIV.Indented {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-bottom: 0.6em}
    DIV.CodeIndented {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-bottom: 0.6em}
    DIV.SmallIndented {font-family: "Times New Roman", Times, serif; margin-left:  10.0em; margin-bottom: 0.6em}
    DIV.SmallCodeIndented {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-bottom: 0.6em}
    DIV.Examples {font-family: "Courier New", monospace; margin-left: 2.0em; margin-bottom: 0.6em}
    DIV.SmallExamples {font-family: "Courier New", monospace; font-size: 80%; margin-left: 7.5em; margin-bottom: 0.6em}
    DIV.IndentedExamples {font-family: "Courier New", monospace; margin-left: 8.0em; margin-bottom: 0.6em}
    DIV.SmallIndentedExamples {font-family: "Courier New", monospace; font-size: 80%; margin-left:  15.0em; margin-bottom: 0.6em}
    UL.Bulleted {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-right: 2.0em; margin-top: 0em; margin-bottom: 0.5em}
    UL.SmallBulleted {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
    UL.NestedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-right: 4.0em; margin-top: 0em; margin-bottom: 0.5em}
    UL.SmallNestedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-right: 8.0em; margin-top: 0em; margin-bottom: 0.5em}
    UL.IndentedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-right: 8.0em; margin-top: 0em; margin-bottom: 0.5em}
    UL.CodeIndentedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
    UL.CodeIndentedNestedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-right: 8.0em; margin-top: 0em; margin-bottom: 0.5em}
    UL.SyntaxIndentedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-right: 4.0em; margin-top: 0em; margin-bottom: 0.5em}
    UL.NotesBulleted {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-right: 4.0em; margin-top: 0em; margin-bottom: 0.5em}
    UL.NotesNestedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
    DL.Hanging {font-family: "Times New Roman", Times, serif; margin-top: 0em; margin-bottom: 0.6em}
    DD.Hanging {margin-left: 6.0em}
    DL.IndentedHanging {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-top: 0em; margin-bottom: 0.6em}
    DD.IndentedHanging {margin-left: 2.0em}
    DL.HangingInBulleted {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-right: 2.0em; margin-top: 0em; margin-bottom: 0.5em}
    DD.HangingInBulleted {margin-left: 4.0em}
    DL.SmallHanging {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-top: 0em; margin-bottom: 0.6em}
    DD.SmallHanging {margin-left: 7.5em}
    DL.SmallIndentedHanging {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-top: 0em; margin-bottom: 0.6em}
    DD.SmallIndentedHanging {margin-left: 2.0em}
    DL.SmallHangingInBulleted {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
    DD.SmallHangingInBulleted {margin-left: 5.0em}
    DL.Enumerated {font-family: "Times New Roman", Times, serif; margin-right: 0.0em; margin-top: 0em; margin-bottom: 0.5em}
    DD.Enumerated {margin-left: 2.0em}
    DL.SmallEnumerated {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-right: 4.0em; margin-top: 0em; margin-bottom: 0.5em}
    DD.SmallEnumerated {margin-left: 2.5em}
    DL.NestedEnumerated {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-right: 2.0em; margin-top: 0em; margin-bottom: 0.5em}
    DL.SmallNestedEnumerated {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
    </STYLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFF0" LINK="#0000FF" VLINK="#800080" ALINK="#FF0000">
<P><A HREF="AA-TOC.html">Contents</A>&nbsp;&nbsp;&nbsp;<A HREF="AA-0-29.html">Index</A>&nbsp;&nbsp;&nbsp;<A HREF="AA-13-2.html">Previous</A>&nbsp;&nbsp;&nbsp;<A HREF="AA-13-4.html">Next</A></P>
<HR>
<H1> 13.3 <U>Operational and Representation Attributes</U><S>Representation Attributes</S></H1>
<DIV Class="Paranum"><FONT SIZE=-2>1/1</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{<I><A HREF="defect1.html#8652/0009">8652/0009</A></I>}
[<A NAME="I4378"></A> <A NAME="I4379"></A>The values of certain implementation-dependent
characteristics can be obtained by interrogating appropriate <U>operational
or </U>representation attributes. <A NAME="I4380"></A>Some of these attributes
are specifiable via an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>.]
</DIV>

<H4 ALIGN=CENTER>Language Design Principles</H4>
<DIV Class="Paranum"><FONT SIZE=-2>1.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>In general, the meaning of a given
attribute should not depend on whether the attribute was specified via
an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>,
or chosen by default by the implementation. </FONT></DIV>

<H4 ALIGN=CENTER>Syntax</H4>
<DIV Class="Paranum"><FONT SIZE=-2>2</FONT></DIV>
<DIV Class="SyntaxIndented"><FONT FACE="Arial, Helvetica">attribute_definition_clause<A NAME="I4381"></A>
::= </FONT><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<B>for</B>&nbsp;<A NAME="I4382"></A><FONT FACE="Arial, Helvetica">local_name</FONT>'<A NAME="I4383"></A><FONT FACE="Arial, Helvetica">attribute_designator</FONT>&nbsp;<B>use</B>&nbsp;<A NAME="I4384"></A><FONT FACE="Arial, Helvetica">expression</FONT>;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;<B>for</B>&nbsp;<A NAME="I4385"></A><FONT FACE="Arial, Helvetica">local_name</FONT>'<A NAME="I4386"></A><FONT FACE="Arial, Helvetica">attribute_designator</FONT>&nbsp;<B>use</B>&nbsp;<A NAME="I4387"></A><FONT FACE="Arial, Helvetica">name</FONT>;</DIV>

<H4 ALIGN=CENTER>Name Resolution Rules</H4>
<DIV Class="Paranum"><FONT SIZE=-2>3</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;For an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>
that specifies an attribute that denotes a value, the form with an <FONT FACE="Arial, Helvetica">expression</FONT>
shall be used. Otherwise, the form with a <FONT FACE="Arial, Helvetica">name</FONT>
shall be used.</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>4</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;<A NAME="I4388"></A>For an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>
that specifies an attribute that denotes a value or an object, the expected
type for the expression or <FONT FACE="Arial, Helvetica">name</FONT>
is that of the attribute. <A NAME="I4389"></A>For an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>
that specifies an attribute that denotes a subprogram, the expected profile
for the <FONT FACE="Arial, Helvetica">name</FONT> is the profile required
for the attribute. For an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>
that specifies an attribute that denotes some other kind of entity, the
<FONT FACE="Arial, Helvetica">name</FONT> shall resolve to denote an
entity of the appropriate kind. </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>4.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>For example,
the Size attribute is of type <I>universal_integer</I>. Therefore, the
expected type for Y in ``<B>for</B> X'Size <B>use</B> Y;'' is <I>universal_integer</I>,
which means that Y can be of any integer type. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>4.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>For attributes
that denote subprograms, the required profile is indicated separately
for the individual attributes. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>4.c</FONT></DIV>
<DIV Class="Annotations" Style="margin-bottom: 0.4em"><FONT SIZE=-1><B>Ramification:
</B>For an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>
with a <FONT FACE="Arial, Helvetica">name</FONT>, the <FONT FACE="Arial, Helvetica">name</FONT>
need not statically denote the entity it denotes. For example, the following
kinds of things are allowed: </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>4.d</FONT></DIV>
<DIV Class="SmallExamples"><TT><B>for</B>&nbsp;Some_Access_Type'Storage_Pool&nbsp;<B>use</B>&nbsp;Storage_Pool_Array(I);<BR>
<B>for</B>&nbsp;Some_Type'Read&nbsp;<B>use</B>&nbsp;Subprogram_Pointer.<B>all</B>;</TT></DIV>

<H4 ALIGN=CENTER>Legality Rules</H4>
<DIV Class="Paranum"><FONT SIZE=-2>5/1</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{<I><A HREF="defect1.html#8652/0009">8652/0009</A></I>}
<A NAME="I4390"></A><A NAME="I4391"></A>An <FONT FACE="Arial, Helvetica">attribute_designator</FONT>
is allowed in an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>
only if this International Standard explicitly allows it, or for an implementation-defined
attribute if the implementation allows it. <A NAME="I4392"></A>Each specifiable
attribute constitutes an <U><A NAME="I4393"></A>operational aspect or
</U>aspect of representation. </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>5.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>For each specifiable
attribute, we generally say something like, ``The ... attribute may be
specified for ... via an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>.''</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>5.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The above wording allows for T'Class'Alignment,
T'Class'Size, T'Class'Input, and T'Class'Output to be specifiable.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>5.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>A specifiable attribute is not
necessarily specifiable for all entities for which it is defined. For
example, one is allowed to ask T'Component_Size for an array subtype
T, but ``<B>for</B> T'Component_Size <B>use</B> ...'' is only allowed
if T is a first subtype, because Component_Size is a type-related aspect.
</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>6</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;For an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>
that specifies an attribute that denotes a subprogram, the profile shall
be mode conformant with the one required for the attribute, and the convention
shall be Ada. Additional requirements are defined for particular attributes.
<A NAME="I4394"></A></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>6.a</FONT></DIV>
<DIV Class="Annotations" Style="margin-bottom: 0.4em"><FONT SIZE=-1><B>Ramification:
</B>This implies, for example, that if one writes: </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>6.b</FONT></DIV>
<DIV Class="SmallExamples"><TT><B>for</B>&nbsp;T'Read&nbsp;<B>use</B>&nbsp;R;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>6.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>R has to be a procedure with two
parameters with the appropriate subtypes and modes as shown in <A HREF="AA-13-13-2.html">13.13.2</A>.
</FONT></DIV>

<H4 ALIGN=CENTER>Static Semantics</H4>
<DIV Class="Paranum"><FONT SIZE=-2>7</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;<A NAME="I4395"></A><A NAME="I4396"></A><A NAME="I4397"></A><A NAME="I4398"></A><A NAME="I4399"></A><A NAME="I4400"></A><A NAME="I4401"></A><A NAME="I4402"></A><A NAME="I4403"></A><A NAME="I4404"></A><A NAME="I4405"></A><A NAME="I4406"></A><A NAME="I4407"></A><A NAME="I4408"></A>A
<I>Size clause</I> is an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>
whose <FONT FACE="Arial, Helvetica">attribute_designator</FONT> is Size.
Similar definitions apply to the other specifiable attributes. </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>7.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>To be honest: </B><A NAME="I4409"></A><A NAME="I4410"></A>An
<FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT> is type-related
or subtype-specific if the <FONT FACE="Arial, Helvetica">attribute_designator</FONT>
denotes a type-related or subtype-specific attribute, respectively. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>8</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;<A NAME="I4411"></A><A NAME="I4412"></A>A <I>storage
element</I> is an addressable element of storage in the machine. <A NAME="I4413"></A>A
<I>word</I> is the largest amount of storage that can be conveniently
and efficiently manipulated by the hardware, given the implementation's
run-time model. A word consists of an integral number of storage elements.
</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>8.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>A storage element
is not intended to be a single bit, unless the machine can efficiently
address individual bits. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>8.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>For example,
on a machine with 8-bit storage elements, if there exist 32-bit integer
registers, with a full set of arithmetic and logical instructions to
manipulate those registers, a word ought to be 4 storage elements --
that is, 32 bits. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>8.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>The ``given
the implementation's run-time model'' part is intended to imply that,
for example, on an 80386 running MS-DOS, the word might be 16 bits, even
though the hardware can support 32 bits.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>8.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>A word is what ACID refers to
as a ``natural hardware boundary''.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>8.e</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Storage elements may, but need
not be, independently addressable (see <A HREF="AA-9-10.html">9.10</A>,
``<A HREF="AA-9-10.html">Shared Variables</A>''). Words are expected
to be independently addressable. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>9/1</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{<I><A HREF="defect1.html#8652/0009">8652/0009</A></I>}
<U>The following representation attributes are defined: Address, Alignment,
Size, Storage_Size, and Component_Size.</U><S>The following attributes
are defined:</S></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>10/1</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;For a <U><FONT FACE="Arial, Helvetica">prefix</FONT></U><S>prefix</S>
X that denotes an object, program unit, or label: </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>11</FONT></DIV>
<DL Class="Hanging"><DT>&nbsp;&nbsp;&nbsp;&nbsp;X'Address<DD Class="Hanging">
<A NAME="I4414"></A><A NAME="I4415"></A>Denotes the address of the first
of the storage elements allocated to X. For a program unit or label,
this value refers to the machine code associated with the corresponding
body or <FONT FACE="Arial, Helvetica">statement</FONT>. The value of
this attribute is of type System.Address. </DL>
<DIV Class="Paranum"><FONT SIZE=-2>11.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>Here, the
``first of the storage elements'' is intended to mean the one with the
lowest address; the endianness of the machine doesn't matter.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>12</FONT></DIV>
<DL Class="Hanging"><DD Class ="Hanging"><A NAME="I4416"></A><A NAME="I4417"></A>Address
may be specified for stand-alone objects and for program units via an
<FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>. </DL>
<DIV Class="Paranum"><FONT SIZE=-2>12.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>Address is
not allowed for enumeration literals, predefined operators, derived task
types, or derived protected types, since they are not program units.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>12.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The validity of a given address
depends on the run-time model; thus, in order to use Address clauses
correctly, one needs intimate knowledge of the run-time model.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>12.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>If the Address of an object is
specified, any explicit or implicit initialization takes place as usual,
unless a <FONT FACE="Arial, Helvetica">pragma</FONT> Import is also specified
for the object (in which case any necessary initialization is presumably
done in the foreign language).</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>12.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Any compilation unit containing
an <FONT FACE="Arial, Helvetica">attribute_reference</FONT> of a given
type depends semantically on the declaration of the package in which
the type is declared, even if not mentioned in an applicable <FONT FACE="Arial, Helvetica">with_clause</FONT>
-- see <A HREF="AA-10-1-1.html">10.1.1</A>. In this case, it means that
if a compilation unit contains X'Address, then it depends on the declaration
of System. Otherwise, the fact that the value of Address is of a type
in System wouldn't make sense; it would violate the ``legality determinable
via semantic dependences'' Language Design Principle.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>12.e</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>AI83-00305 -- If X is a task type,
then within the body of X, X denotes the current task object; thus, X'Address
denotes the object's address.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>12.f</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Interrupt entries and their addresses
are described in <A HREF="AA-J-7-1.html">J.7.1</A>, ``<A HREF="AA-J-7-1.html">Interrupt
Entries</A>''.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>12.g</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>If X is not allocated on a storage
element boundary, X'Address points at the first of the storage elements
that contains any part of X. This is important for the definition of
the Position attribute to be sensible. </FONT></DIV>

<H4 ALIGN=CENTER>Erroneous Execution</H4>
<DIV Class="Paranum"><FONT SIZE=-2>13</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;&nbsp;<A NAME="I4418"></A>If an Address is specified,
it is the programmer's responsibility to ensure that the address is valid;
otherwise, program execution is erroneous. </DIV>

<H4 ALIGN=CENTER>Implementation Advice</H4>
<DIV Class="Paranum"><FONT SIZE=-2>14</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;&nbsp;For an array X, X'Address should point at the
first component of the array, and not at the array bounds. </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>14.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>On the other
hand, we have no advice to offer about discriminants and tag fields;
whether or not the address points at them is not specified by the language.
If discriminants are stored separately, then the Position of a discriminant
might be negative, or might raise an exception. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>15</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;&nbsp;<A NAME="I4419"></A>The recommended level of
support for the Address attribute is: </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>16</FONT></DIV>
<UL Class="Bulleted" Style="margin-bottom: 0.3em"><LI TYPE=DISC>X'Address should produce a useful result if X is an object
that is aliased or of a by-reference type, or is an entity whose Address
has been specified. </LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>16.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>Aliased objects
are the ones for which the Unchecked_Access attribute is allowed; hence,
these have to be allocated on an addressable boundary anyway. Similar
considerations apply to objects of a by-reference type.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>16.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>An implementation need not go
to any trouble to make Address work in other cases. For example, if an
object X is not aliased and not of a by-reference type, and the implementation
chooses to store it in a register, X'Address might return System.Null_Address
(assuming registers are not addressable). For a subprogram whose calling
convention is Intrinsic, or for a package, the implementation need not
generate an out-of-line piece of code for it. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>17</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>An implementation should support Address clauses for imported
subprograms.</LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>18</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>Objects (including subcomponents) that are aliased or of
a by-reference type should be allocated on storage element boundaries.
</LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>18.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>This is necessary
for the Address attribute to be useful (since First_Bit and Last_Bit
apply only to components). Implementations generally need to do this
anyway, for tasking to work properly. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>If the Address of an object is specified, or it is imported
or exported, then the implementation should not perform optimizations
based on assumptions of no aliases. </LI></UL>
<DIV Class="NotesHeader"><FONT SIZE=-1>NOTES</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>20</FONT></DIV>
<DIV Class="Notes"><FONT SIZE=-1>1&nbsp;&nbsp;The specification of a
link name in a <FONT FACE="Arial, Helvetica">pragma</FONT> Export (see
<A HREF="AA-B-1.html">B.1</A>) for a subprogram or object is an alternative
to explicit specification of its link-time address, allowing a link-time
directive to place the subprogram or object within memory.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>21</FONT></DIV>
<DIV Class="Notes"><FONT SIZE=-1>2&nbsp;&nbsp;The rules for the Size
attribute imply, for an aliased object X, that if X'Size = Storage_Unit,
then X'Address points at a storage element containing all of the bits
of X, and only the bits of X. </FONT></DIV>

<H4 ALIGN=CENTER>Wording Changes from Ada 83</H4>
<DIV Class="Paranum"><FONT SIZE=-2>21.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The intended meaning of the various
attributes, and their <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>s,
is more explicit.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>21.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The <FONT FACE="Arial, Helvetica">address_clause</FONT>
has been renamed to <FONT FACE="Arial, Helvetica">at_clause</FONT> and
moved to <A HREF="AA-J.html">Annex J</A>, ``<A HREF="AA-J.html">Obsolescent
Features</A>''. One can use an Address clause (``for T'Address <B>use</B>
...;'') instead.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>21.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The attributes defined in RM83-13.7.3
are moved to <A HREF="AA-G.html">Annex G</A>, <A HREF="AA-A-5-3.html">A.5.3</A>,
and <A HREF="AA-A-5-4.html">A.5.4</A>. </FONT></DIV>

<H4 ALIGN=CENTER>Language Design Principles</H4>
<DIV Class="Paranum"><FONT SIZE=-2>21.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>By default, the Alignment of a
subtype should reflect the ``natural'' alignment for objects of the subtype
on the machine. The Alignment, whether specified or default, should be
known at compile time, even though Addresses are generally not known
at compile time. (The generated code should never need to check at run
time the number of zero bits at the end of an address to determine an
alignment).</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>21.e</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>There are two symmetric purposes
of Alignment clauses, depending on whether or not the implementation
has control over object allocation. If the implementation allocates an
object, the implementation should ensure that the Address and Alignment
are consistent with each other. If something outside the implementation
allocates an object, the implementation should be allowed to assume that
the Address and Alignment are consistent, but should not assume stricter
alignments than that. </FONT></DIV>

<H4 ALIGN=CENTER>Static Semantics</H4>
<DIV Class="Paranum"><FONT SIZE=-2>22/1</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;For a <U><FONT FACE="Arial, Helvetica">prefix</FONT></U><S>prefix</S>
X that denotes a subtype or object: </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>23</FONT></DIV>
<DL Class="Hanging"><DT>&nbsp;&nbsp;&nbsp;&nbsp;X'Alignment<DD Class="Hanging">
<A NAME="I4420"></A><A NAME="I4421"></A>The Address of an object that
is allocated under control of the implementation is an integral multiple
of the Alignment of the object (that is, the Address modulo the Alignment
is zero). The offset of a record component is a multiple of the Alignment
of the component. For an object that is not allocated under control of
the implementation (that is, one that is imported, that is allocated
by a user-defined allocator, whose Address has been specified, or is
designated by an access value returned by an instance of Unchecked_Conversion),
the implementation may assume that the Address is an integral multiple
of its Alignment. The implementation shall not assume a stricter alignment.</DL>
<DIV Class="Paranum"><FONT SIZE=-2>24</FONT></DIV>
<DL Class="Hanging"><DD Class ="Hanging">The value of this attribute is of type <I>universal_integer</I>,
and nonnegative; zero means that the object is not necessarily aligned
on a storage element boundary. </DL>
<DIV Class="Paranum"><FONT SIZE=-2>24.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>The Alignment
is passed by an <FONT FACE="Arial, Helvetica">allocator</FONT> to the
Allocate operation; the implementation has to choose a value such that
if the address returned by Allocate is aligned as requested, the generated
code can correctly access the object.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>24.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The above mention of ``modulo''
is referring to the &quot;<B>mod</B>&quot; operator declared in System.Storage_Elements;
if X <B>mod</B> N = 0, then X is by definition aligned on an N-storage-element
boundary.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>25</FONT></DIV>
<DL Class="Hanging"><DD Class ="Hanging"><A NAME="I4422"></A><A NAME="I4423"></A>Alignment
may be specified for first subtypes and [stand-alone] objects via an
<FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>; the
expression of such a clause shall be static, and its value nonnegative.
If the Alignment of a subtype is specified, then the Alignment of an
object of the subtype is at least as strict, unless the object's Alignment
is also specified. The Alignment of an object created by an allocator
is that of the designated subtype.</DL>
<DIV Class="Paranum"><FONT SIZE=-2>26</FONT></DIV>
<DL Class="Hanging"><DD Class ="Hanging">If an Alignment is specified for a composite subtype
or object, this Alignment shall be equal to the least common multiple
of any specified Alignments of the subcomponent subtypes, or an integer
multiple thereof. </DL>

<H4 ALIGN=CENTER>Erroneous Execution</H4>
<DIV Class="Paranum"><FONT SIZE=-2>27</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;&nbsp;<A NAME="I4424"></A>Program execution is erroneous
if an Address clause is given that conflicts with the Alignment. </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>27.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>The user
has to either give an Alignment clause also, or else know what Alignment
the implementation will choose by default. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>28</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;&nbsp;<A NAME="I4425"></A>If the Alignment is specified
for an object that is not allocated under control of the implementation,
execution is erroneous if the object is not aligned according to the
Alignment. </DIV>

<H4 ALIGN=CENTER>Implementation Advice</H4>
<DIV Class="Paranum"><FONT SIZE=-2>29</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;&nbsp;<A NAME="I4426"></A>The recommended level of
support for the Alignment attribute for subtypes is: </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>30</FONT></DIV>
<UL Class="Bulleted" Style="margin-bottom: 0.3em"><LI TYPE=DISC>An implementation should support specified Alignments that
are factors and multiples of the number of storage elements per word,
subject to the following:</LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>31</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>An implementation need not support specified Alignments
for combinations of Sizes and Alignments that cannot be easily loaded
and stored by available machine instructions.</LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>32</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>An implementation need not support specified Alignments
that are greater than the maximum Alignment the implementation ever returns
by default. </LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>33</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em">&nbsp;&nbsp;&nbsp;&nbsp;<A NAME="I4427"></A>The
recommended level of support for the Alignment attribute for objects
is: </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>34</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>Same as above, for subtypes, but in addition:</LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>35</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>For stand-alone library-level objects of statically constrained
subtypes, the implementation should support all Alignments supported
by the target linker. For example, page alignment is likely to be supported
for such objects, but not for subtypes. </LI></UL>
<DIV Class="NotesHeader"><FONT SIZE=-1>NOTES</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>36</FONT></DIV>
<DIV Class="Notes"><FONT SIZE=-1>3&nbsp;&nbsp;Alignment is a subtype-specific
attribute.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>37</FONT></DIV>
<DIV Class="Notes"><FONT SIZE=-1>4&nbsp;&nbsp;The Alignment of a composite
object is always equal to the least common multiple of the Alignments
of its components, or a multiple thereof. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>37.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>For default
Alignments, this follows from the semantics of Alignment. For specified
Alignments, it follows from a Legality Rule stated above. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>38</FONT></DIV>
<DIV Class="Notes"><FONT SIZE=-1>5&nbsp;&nbsp;A <FONT FACE="Arial, Helvetica">component_clause</FONT>,
Component_Size clause, or a <FONT FACE="Arial, Helvetica">pragma</FONT>
Pack can override a specified Alignment. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>38.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>Most objects
are allocated by the implementation; for these, the implementation obeys
the Alignment. The implementation is of course allowed to make an object
<I>more</I> aligned than its Alignment requires -- an object whose Alignment
is 4 might just happen to land at an address that's a multiple of 4096.
For formal parameters, the implementation might want to force an Alignment
stricter than the parameter's subtype. For example, on some systems,
it is customary to always align parameters to 4 storage elements.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>38.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Hence, one might initially assume
that the implementation could evilly make all Alignments 1 by default,
even though integers, say, are normally aligned on a 4-storage-element
boundary. However, the implementation cannot get away with that -- if
the Alignment is 1, the generated code cannot assume an Alignment of
4, at least not for objects allocated outside the control of the implementation.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>38.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Of course implementations can
assume anything they can prove, but typically an implementation will
be unable to prove much about the alignment of, say, an imported object.
Furthermore, the information about where an address ``came from'' can
be lost to the compiler due to separate compilation.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>38.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The Alignment of an object that
is a component of a packed composite object will usually be 0, to indicate
that the component is not necessarily aligned on a storage element boundary.
For a subtype, an Alignment of 0 means that objects of the subtype are
not normally aligned on a storage element boundary at all. For example,
an implementation might choose to make Component_Size be 0 for an array
of Booleans, even when <FONT FACE="Arial, Helvetica">pragma</FONT> Pack
has not been specified for the array. In this case, Boolean'Alignment
would be 0. (In the presence of tasking, this would in general be feasible
only on a machine that had atomic test-bit and set-bit instructions.)</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>38.e</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>If the machine has no particular
natural alignments, then all subtype Alignments will probably be 1 by
default.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>38.f</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Specifying an Alignment of 0 in
an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT> does
not require the implementation to do anything (except return 0 when the
Alignment is queried). However, it might be taken as advice on some implementations.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>38.g</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>It is an error for an Address
clause to disobey the object's Alignment. The error cannot be detected
at compile time, in general, because the Address is not necessarily known
at compile time (and is almost certainly not static). We do not require
a run-time check, since efficiency seems paramount here, and Address
clauses are treading on thin ice anyway. Hence, this misuse of Address
clauses is just like any other misuse of Address clauses -- it's erroneous.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>38.h</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>A type extension can have a stricter
Alignment than its parent. This can happen, for example, if the Alignment
of the parent is 4, but the extension contains a component with Alignment
8. The Alignment of a class-wide type or object will have to be the maximum
possible Alignment of any extension.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>38.i</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The recommended level of support
for the Alignment attribute is intended to reflect a minimum useful set
of capabilities. An implementation can assume that all Alignments are
multiples of each other -- 1, 2, 4, and 8 might be the only supported
Alignments for subtypes. An Alignment of 3 or 6 is unlikely to be useful.
For objects that can be allocated statically, we recommend that the implementation
support larger alignments, such as 4096. We do not recommend such large
alignments for subtypes, because the maximum subtype alignment will also
have to be used as the alignment of stack frames, heap objects, and class-wide
objects. Similarly, we do not recommend such large alignments for stack-allocated
objects.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>38.j</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>If the maximum default Alignment
is 8 (say, Long_Float'Alignment = 8), then the implementation can refuse
to accept stricter alignments for subtypes. This simplifies the generated
code, since the compiler can align the stack and class-wide types to
this maximum without a substantial waste of space (or time).</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>38.k</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Note that the recommended level
of support takes into account interactions between Size and Alignment.
For example, on a 32-bit machine with 8-bit storage elements, where load
and store instructions have to be aligned according to the size of the
thing being loaded or stored, the implementation might accept an Alignment
of 1 if the Size is 8, but might reject an Alignment of 1 if the Size
is 32. On a machine where unaligned loads and stores are merely inefficient
(as opposed to causing hardware traps), we would expect an Alignment
of 1 to be supported for any Size. </FONT></DIV>

<H4 ALIGN=CENTER>Wording Changes from Ada 83</H4>
<DIV Class="Paranum"><FONT SIZE=-2>38.l</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The nonnegative part is missing
from RM83 (for <FONT FACE="Arial, Helvetica">mod_clause</FONT>s, nee
<FONT FACE="Arial, Helvetica">alignment_clause</FONT>s, which are an
obsolete version of Alignment clauses). </FONT></DIV>

<H4 ALIGN=CENTER>Static Semantics</H4>
<DIV Class="Paranum"><FONT SIZE=-2>39/1</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;For a <U><FONT FACE="Arial, Helvetica">prefix</FONT></U><S>prefix</S>
X that denotes an object: </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>40</FONT></DIV>
<DL Class="Hanging"><DT>&nbsp;&nbsp;&nbsp;&nbsp;X'Size<DD Class="Hanging">
<A NAME="I4428"></A><A NAME="I4429"></A>Denotes the size in bits of the
representation of the object. The value of this attribute is of the type
<I>universal_integer</I>. </DL>
<DIV Class="Paranum"><FONT SIZE=-2>40.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>Note that
Size is in bits even if Machine_Radix is 10. Each decimal digit (and
the sign) is presumably represented as some number of bits. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>41</FONT></DIV>
<DL Class="Hanging"><DD Class ="Hanging"><A NAME="I4430"></A><A NAME="I4431"></A>Size may
be specified for [stand-alone] objects via an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>;
the expression of such a clause shall be static and its value nonnegative.
</DL>

<H4 ALIGN=CENTER>Implementation Advice</H4>
<DIV Class="Paranum"><FONT SIZE=-2>42</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em">&nbsp;&nbsp;&nbsp;&nbsp;<A NAME="I4432"></A>The
recommended level of support for the Size attribute of objects is: </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>43</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>A Size clause should be supported for an object if the
specified Size is at least as large as its subtype's Size, and corresponds
to a size in storage elements that is a multiple of the object's Alignment
(if the Alignment is nonzero). </LI></UL>

<H4 ALIGN=CENTER>Static Semantics</H4>
<DIV Class="Paranum"><FONT SIZE=-2>44</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em">&nbsp;&nbsp;&nbsp;&nbsp;For every subtype
S: </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>45</FONT></DIV>
<DL Class="Hanging" Style="margin-bottom: 0.4em"><DT>&nbsp;&nbsp;&nbsp;&nbsp;S'Size<DD Class="Hanging">
<A NAME="I4433"></A><A NAME="I4434"></A>If S is definite, denotes the
size [(in bits)] that the implementation would choose for the following
objects of subtype S: </DL>
<DIV Class="Paranum"><FONT SIZE=-2>46</FONT></DIV>
<UL Class="IndentedBulleted"><LI TYPE=DISC>A record component of subtype S when the record type is
packed.</LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>47</FONT></DIV>
<UL Class="IndentedBulleted"><LI TYPE=DISC>The formal parameter of an instance of Unchecked_Conversion
that converts from subtype S to some other subtype. </LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>48</FONT></DIV>
<DL Class="Hanging"><DD Class ="Hanging">If S is indefinite, the meaning is implementation
defined. The value of this attribute is of the type <I>universal_integer</I>.
<A NAME="I4435"></A><A NAME="I4436"></A>The Size of an object is at least
as large as that of its subtype, unless the object's Size is determined
by a Size clause, a component_clause, or a Component_Size clause. Size
may be specified for first subtypes via an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>;
the expression of such a clause shall be static and its value nonnegative.
</DL>
<DIV Class="Paranum"><FONT SIZE=-2>48.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation defined: </B>The
meaning of Size for indefinite subtypes.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>48.b</FONT></DIV>
<DIV Class="Annotations" Style="margin-bottom: 0.4em"><FONT SIZE=-1><B>Reason:
</B>The effects of specifying the Size of a subtype are: </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>48.c</FONT></DIV>
<UL Class="SmallBulleted"><FONT SIZE=-1><LI TYPE=DISC>Unchecked_Conversion works in a predictable manner.</LI></FONT></UL>
<DIV Class="Paranum"><FONT SIZE=-2>48.d</FONT></DIV>
<UL Class="SmallBulleted"><FONT SIZE=-1><LI TYPE=DISC>A composite type cannot be packed so tightly as to override
the specified Size of a component's subtype.</LI></FONT></UL>
<DIV Class="Paranum"><FONT SIZE=-2>48.e</FONT></DIV>
<UL Class="SmallBulleted"><FONT SIZE=-1><LI TYPE=DISC>Assuming the Implementation Advice is obeyed, if the specified
Size allows independent addressability, then the Size of certain objects
of the subtype should be equal to the subtype's Size. This applies to
stand-alone objects and to components (unless a <FONT FACE="Arial, Helvetica">component_clause</FONT>
or a Component_Size clause applies). </LI></FONT></UL>
<DIV Class="Paranum"><FONT SIZE=-2>48.f</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>A <FONT FACE="Arial, Helvetica">component_clause</FONT>
or a Component_Size clause can cause an object to be smaller than its
subtype's specified size. A <FONT FACE="Arial, Helvetica">pragma</FONT>
Pack cannot; if a component subtype's size is specified, this limits
how tightly the composite object can be packed.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>48.g</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The Size of a class-wide (tagged)
subtype is unspecified, because it's not clear what it should mean; it
should certainly not depend on all of the descendants that happen to
exist in a given program. Note that this cannot be detected at compile
time, because in a generic unit, it is not necessarily known whether
a given subtype is class-wide. It might raise an exception on some implementations.
</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>48.h</FONT></DIV>
<DIV Class="Annotations" Style="margin-bottom: 0.4em"><FONT SIZE=-1><B>Ramification:
</B>A Size clause for a numeric subtype need not affect the underlying
numeric type. For example, if I say: </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>48.i</FONT></DIV>
<DIV Class="SmallExamples"><TT><B>type</B>&nbsp;S&nbsp;<B>is</B>&nbsp;<B>range</B>&nbsp;1..2;<BR>
<B>for</B>&nbsp;S'Size&nbsp;<B>use</B>&nbsp;64;<BR>
&nbsp;&nbsp;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>48.j</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>I am not guaranteed that S'Base'Last
&gt;= 2**63-1, nor that intermediate results will be represented in 64
bits. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>48.k</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>There is no need
to complicate implementations for this sort of thing, because the right
way to affect the base range of a type is to use the normal way of declaring
the base range: </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>48.l</FONT></DIV>
<DIV Class="SmallExamples"><TT><B>type</B>&nbsp;Big&nbsp;<B>is</B>&nbsp;<B>range</B>&nbsp;-2**63&nbsp;..&nbsp;2**63&nbsp;-&nbsp;1;<BR>
<B>subtype</B>&nbsp;Small&nbsp;<B>is</B>&nbsp;Big&nbsp;<B>range</B>&nbsp;1..1000;<BR>
&nbsp;&nbsp;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>48.m</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>The Size
of a large unconstrained subtype (e.g. String'Size) is likely to raise
Constraint_Error, since it is a nonstatic expression of type <I>universal_integer</I>
that might overflow the largest signed integer type. There is no requirement
that the largest integer type be able to represent the size in bits of
the largest possible object. </FONT></DIV>

<H4 ALIGN=CENTER>Implementation Requirements</H4>
<DIV Class="Paranum"><FONT SIZE=-2>49</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;&nbsp;In an implementation, Boolean'Size shall be 1.
</DIV>

<H4 ALIGN=CENTER>Implementation Advice</H4>
<DIV Class="Paranum"><FONT SIZE=-2>50</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em">&nbsp;&nbsp;&nbsp;&nbsp;If the Size of
a subtype is specified, and allows for efficient independent addressability
(see <A HREF="AA-9-10.html">9.10</A>) on the target architecture, then
the Size of the following objects of the subtype should equal the Size
of the subtype: </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>51</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>Aliased objects (including components).</LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>52</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>Unaliased components, unless the Size of the component
is determined by a <FONT FACE="Arial, Helvetica">component_clause</FONT>
or Component_Size clause. </LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>52.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>Thus, on
a typical 32-bit machine, ``<B>for</B> S'Size <B>use</B> 32;'' will guarantee
that aliased objects of subtype S, and components whose subtype is S,
will have Size = 32 (assuming the implementation chooses to obey this
Implementation Advice). On the other hand, if one writes, ``<B>for</B>
S2'Size <B>use</B> 5;'' then stand-alone objects of subtype S2 will typically
have their Size rounded up to ensure independent addressability.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>52.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Note that ``<B>for</B> S'Size
<B>use</B> 32;'' does not cause things like formal parameters to have
Size = 32 -- the implementation is allowed to make all parameters be
at least 64 bits, for example.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>52.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Note that ``<B>for</B> S2'Size
<B>use</B> 5;'' requires record components whose subtype is S2 to be
exactly 5 bits if the record type is packed. The same is not true of
array components; their Size may be rounded up to the nearest factor
of the word size. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>52.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation Note: </B><A NAME="I4437"></A>On
most machines, arrays don't contain gaps between components; if the Component_Size
is greater than the Size of the component subtype, the extra bits are
generally considered part of each component, rather than gaps between
components. On the other hand, a record might contain gaps between components,
depending on what sorts of loads, stores, and masking operations are
generally done by the generated code.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>52.e</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>For an array, any extra bits stored
for each component will generally be part of the component -- the whole
point of storing extra bits is to make loads and stores more efficient
by avoiding the need to mask out extra bits. The PDP-10 is one counter-example;
since the hardware supports byte strings with a gap at the end of each
word, one would want to pack in that manner. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>53</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;&nbsp;A Size clause on a composite subtype should not
affect the internal layout of components. </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>53.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>That's what Pack
<FONT FACE="Arial, Helvetica">pragma</FONT>s, <FONT FACE="Arial, Helvetica">record_representation_clause</FONT>s,
and Component_Size clauses are for. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>54</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em">&nbsp;&nbsp;&nbsp;&nbsp;<A NAME="I4438"></A>The
recommended level of support for the Size attribute of subtypes is: </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>55</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>The Size (if not specified) of a static discrete or fixed
point subtype should be the number of bits needed to represent each value
belonging to the subtype using an unbiased representation, leaving space
for a sign bit only if the subtype contains negative values. If such
a subtype is a first subtype, then an implementation should support a
specified Size for it that reflects this representation.</LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>55.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation Note: </B>This
applies to static enumeration subtypes, using the internal codes used
to represent the values.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>55.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>For a two's-complement machine,
this implies that for a static signed integer subtype S, if all values
of S are in the range 0 .. 2<SUP><FONT SIZE=+1><FONT SIZE=-2><I>n</I></FONT></FONT></SUP>-1,
or all values of S are in the range -2<SUP><FONT SIZE=+1><FONT SIZE=-2><I>n-1</I></FONT></FONT></SUP>
.. 2<SUP><FONT SIZE=+1><FONT SIZE=-2><I>n-1</I></FONT></FONT></SUP>-1,
for some <I>n</I> less than or equal to the word size, then S'Size should
be &lt;= the smallest such <I>n</I>. For a one's-complement machine,
it is the same except that in the second range, the lower bound ``-2<SUP><FONT SIZE=+1><FONT SIZE=-2><I>n-1</I></FONT></FONT></SUP>''
is replaced by ``-2<SUP><FONT SIZE=+1><FONT SIZE=-2><I>n-1</I></FONT></FONT></SUP>+1''.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>55.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>If an integer subtype (whether
signed or unsigned) contains no negative values, the Size should not
include space for a sign bit.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>55.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Typically, the implementation
will choose to make the Size of a subtype be exactly the smallest such
<I>n</I>. However, it might, for example, choose a biased representation,
in which case it could choose a smaller value.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>55.e</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>On most machines, it is in general
not a good idea to pack (parts of) multiple stand-alone objects into
the same storage element, because (1) it usually doesn't save much space,
and (2) it requires locking to prevent tasks from interfering with each
other, since separate stand-alone objects are independently addressable.
Therefore, if S'Size = 2 on a machine with 8-bit storage elements, the
size of a stand-alone object of subtype S will probably not be 2. It
might, for example, be 8, 16 or 32, depending on the availability and
efficiency of various machine instructions. The same applies to components
of composite types, unless packing, Component_Size, or record layout
is specified.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>55.f</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>For an unconstrained discriminated
object, if the implementation allocates the maximum possible size, then
the Size attribute should return that maximum possible size. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>55.g</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>The Size
of an object X is not usually the same as that of its subtype S. If X
is a stand-alone object or a parameter, for example, most implementations
will round X'Size up to a storage element boundary, or more, so X'Size
might be greater than S'Size. On the other hand, X'Size cannot be less
than S'Size, even if the implementation can prove, for example, that
the range of values actually taken on by X during execution is smaller
than the range of S.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>55.h</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>For example, if S is a first integer
subtype whose range is 0..3, S'Size will be probably be 2 bits, and components
of packed composite types of this subtype will be 2 bits (assuming Storage_Unit
is a multiple of 2), but stand-alone objects and parameters will probably
not have a size of 2 bits; they might be rounded up to 32 bits, for example.
On the other hand, Unchecked_Conversion will use the 2-bit size, even
when converting a stand-alone object, as one would expect.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>55.i</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Another reason for making the
Size of an object bigger than its subtype's Size is to support the run-time
detection of uninitialized variables. <A NAME="I4439"></A>The implementation
might add an extra value to a discrete subtype that represents the uninitialized
state, and check for this value on use. In some cases, the extra value
will require an extra bit in the representation of the object. Such detection
is not required by the language. If it is provided, the implementation
has to be able to turn it off. For example, if the programmer gives a
<FONT FACE="Arial, Helvetica">record_representation_clause</FONT> or
Component_Size clause that makes a component too small to allow the extra
bit, then the implementation will not be able to perform the checking
(not using this method, anyway).</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>55.j</FONT></DIV>
<DIV Class="Annotations" Style="margin-bottom: 0.4em"><FONT SIZE=-1>The
fact that the size of an object is not necessarily the same as its subtype
can be confusing: </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>55.k</FONT></DIV>
<DIV Class="SmallExamples"><TT><B>type</B>&nbsp;Device_Register&nbsp;<B>is</B>&nbsp;<B>range</B>&nbsp;0..2**8&nbsp;-&nbsp;1;<BR>
<B>for</B>&nbsp;Device_Register'Size&nbsp;<B>use</B>&nbsp;8;&nbsp;--<I>&nbsp;Confusing!</I><BR>
My_Device&nbsp;:&nbsp;Device_Register;<BR>
<B>for</B>&nbsp;My_Device'Address&nbsp;<B>use</B>&nbsp;To_Address(16#FF00#);<BR>
&nbsp;&nbsp;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>55.l</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The programmer might think that
My_Device'Size is 8, and that My_Device'Address points at an 8-bit location.
However, this is not true. In Ada 83 (and in Ada 95), My_Device'Size
might well be 32, and My_Device'Address might well point at the high-order
8 bits of the 32-bit object, which are always all zero bits. If My_Device'Address
is passed to an assembly language subprogram, based on the programmer's
assumption, the program will not work properly. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>55.m</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>It is not reasonable
to require that an implementation allocate exactly 8 bits to all objects
of subtype Device_Register. For example, in many run-time models, stand-alone
objects and parameters are always aligned to a word boundary. Such run-time
models are generally based on hardware considerations that are beyond
the control of the implementer. (It is reasonable to require that an
implementation allocate exactly 8 bits to all components of subtype Device_Register,
if packed.) </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>55.n</FONT></DIV>
<DIV Class="Annotations" Style="margin-bottom: 0.4em"><FONT SIZE=-1><B>Ramification:
</B>The correct way to write the above code is like this: </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>55.o</FONT></DIV>
<DIV Class="SmallExamples"><TT><B>type</B>&nbsp;Device_Register&nbsp;<B>is</B>&nbsp;<B>range</B>&nbsp;0..2**8&nbsp;-&nbsp;1;<BR>
My_Device&nbsp;:&nbsp;Device_Register;<BR>
<B>for</B>&nbsp;My_Device'Size&nbsp;<B>use</B>&nbsp;8;<BR>
<B>for</B>&nbsp;My_Device'Address&nbsp;<B>use</B>&nbsp;To_Address(16#FF00#);<BR>
&nbsp;&nbsp;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>55.p</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>If the implementation cannot accept
8-bit stand-alone objects, then this will be illegal. However, on a machine
where an 8-bit device register exists, the implementation will probably
be able to accept 8-bit stand-alone objects. Therefore, My_Device'Size
will be 8, and My_Device'Address will point at those 8 bits, as desired.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>55.q</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>If an object of subtype Device_Register
is passed to a foreign language subprogram, it will be passed according
to that subprogram's conventions. Most foreign language implementations
have similar run-time model restrictions. For example, when passing to
a C function, where the argument is of the C type char* (that is, pointer
to char), the C compiler will generally expect a full word value, either
on the stack, or in a register. It will <I>not</I> expect a single byte.
Thus, Size clauses for subtypes really have nothing to do with passing
parameters to foreign language subprograms. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>56</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>For a subtype implemented with levels of indirection, the
Size should include the size of the pointers, but not the size of what
they point at. </LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>56.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>For example,
if a task object is represented as a pointer to some information (including
a task stack), then the size of the object should be the size of the
pointer. The Storage_Size, on the other hand, should include the size
of the stack. </FONT></DIV>
<DIV Class="NotesHeader"><FONT SIZE=-1>NOTES</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>57</FONT></DIV>
<DIV Class="Notes"><FONT SIZE=-1>6&nbsp;&nbsp;Size is a subtype-specific
attribute.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>58</FONT></DIV>
<DIV Class="Notes"><FONT SIZE=-1>7&nbsp;&nbsp;A <FONT FACE="Arial, Helvetica">component_clause</FONT>
or Component_Size clause can override a specified Size. A <FONT FACE="Arial, Helvetica">pragma</FONT>
Pack cannot. </FONT></DIV>

<H4 ALIGN=CENTER>Wording Changes from Ada 83</H4>
<DIV Class="Paranum"><FONT SIZE=-2>58.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The requirement for a nonnegative
value in a Size clause was not in RM83, but it's hard to see how it would
make sense. For uniformity, we forbid negative sizes, rather than letting
implementations define their meaning. </FONT></DIV>

<H4 ALIGN=CENTER>Static Semantics</H4>
<DIV Class="Paranum"><FONT SIZE=-2>59/1</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;For a <U><FONT FACE="Arial, Helvetica">prefix</FONT></U><S>prefix</S>
T that denotes a task object [(after any implicit dereference)]: </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>60</FONT></DIV>
<DL Class="Hanging"><DT>&nbsp;&nbsp;&nbsp;&nbsp;T'Storage_Size<DD Class="Hanging">
<A NAME="I4440"></A><A NAME="I4441"></A>Denotes the number of storage
elements reserved for the task. The value of this attribute is of the
type <I>universal_integer</I>. The Storage_Size includes the size of
the task's stack, if any. The language does not specify whether or not
it includes other storage associated with the task (such as the ``task
control block'' used by some implementations.) If a <FONT FACE="Arial, Helvetica">pragma</FONT>
Storage_Size is given, the value of the Storage_Size attribute is at
least the value specified in the <FONT FACE="Arial, Helvetica">pragma</FONT>.
</DL>
<DIV Class="Paranum"><FONT SIZE=-2>60.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>The value
of this attribute is never negative, since it is impossible to ``reserve''
a negative number of storage elements.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>60.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>If the implementation chooses
to allocate an initial amount of storage, and then increase this as needed,
the Storage_Size cannot include the additional amounts (assuming the
allocation of the additional amounts can raise Storage_Error); this is
inherent in the meaning of ``reserved.''</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>60.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The implementation is allowed
to allocate different amounts of storage for different tasks of the same
subtype.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>60.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Storage_Size is also defined for
access subtypes -- see <A HREF="AA-13-11.html">13.11</A>. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>61</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;&nbsp;[<A NAME="I4442"></A> A <FONT FACE="Arial, Helvetica">pragma</FONT>
Storage_Size specifies the amount of storage to be reserved for the execution
of a task.] </DIV>

<H4 ALIGN=CENTER>Syntax</H4>
<DIV Class="Paranum"><FONT SIZE=-2>62</FONT></DIV>
<DIV Class="SyntaxIndented" Style="margin-bottom: 0.2em">The form of
a <FONT FACE="Arial, Helvetica">pragma</FONT> Storage_Size is as follows:
</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>63</FONT></DIV>
<DIV Class="SyntaxIndented">&nbsp;&nbsp;<B>pragma</B> <A NAME="I4443"></A>Storage_Size(<A NAME="I4444"></A><FONT FACE="Arial, Helvetica">expression</FONT>);</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>64</FONT></DIV>
<DIV Class="SyntaxIndented">A <FONT FACE="Arial, Helvetica">pragma</FONT>
Storage_Size is allowed only immediately within a <FONT FACE="Arial, Helvetica">task_definition</FONT>.
</DIV>

<H4 ALIGN=CENTER>Name Resolution Rules</H4>
<DIV Class="Paranum"><FONT SIZE=-2>65</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;&nbsp;<A NAME="I4445"></A>The <FONT FACE="Arial, Helvetica">expression</FONT>
of a <FONT FACE="Arial, Helvetica">pragma</FONT> Storage_Size is expected
to be of any integer type. </DIV>

<H4 ALIGN=CENTER>Dynamic Semantics</H4>
<DIV Class="Paranum"><FONT SIZE=-2>66</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;&nbsp;A <FONT FACE="Arial, Helvetica">pragma</FONT>
Storage_Size is elaborated when an object of the type defined by the
immediately enclosing <FONT FACE="Arial, Helvetica">task_definition</FONT>
is created. <A NAME="I4446"></A>For the elaboration of a <FONT FACE="Arial, Helvetica">pragma</FONT>
Storage_Size, the <FONT FACE="Arial, Helvetica">expression</FONT> is
evaluated; the Storage_Size attribute of the newly created task object
is at least the value of the <FONT FACE="Arial, Helvetica">expression</FONT>.
</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>66.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>The implementation
is allowed to round up a specified Storage_Size amount. For example,
if the implementation always allocates in chunks of 4096 bytes, the number
200 might be rounded up to 4096. Also, if the user specifies a negative
number, the implementation has to normalize this to 0, or perhaps to
a positive number. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>67</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;&nbsp;<A NAME="I4447"></A><A NAME="I4448"></A><A NAME="I4449"></A>At
the point of task object creation, or upon task activation, Storage_Error
is raised if there is insufficient free storage to accommodate the requested
Storage_Size. </DIV>

<H4 ALIGN=CENTER>Static Semantics</H4>
<DIV Class="Paranum"><FONT SIZE=-2>68/1</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;For a <U><FONT FACE="Arial, Helvetica">prefix</FONT></U><S>prefix</S>
X that denotes an array subtype or array object [(after any implicit
dereference)]: </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>69</FONT></DIV>
<DL Class="Hanging"><DT>&nbsp;&nbsp;&nbsp;&nbsp;X'Component_Size<DD Class="Hanging">
<A NAME="I4450"></A><A NAME="I4451"></A>Denotes the size in bits of components
of the type of X. The value of this attribute is of type <I>universal_integer</I>.
</DL>
<DIV Class="Paranum"><FONT SIZE=-2>70</FONT></DIV>
<DL Class="Hanging"><DD Class ="Hanging"><A NAME="I4452"></A><A NAME="I4453"></A>Component_Size
may be specified for array types via an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>;
the expression of such a clause shall be static, and its value nonnegative.
</DL>
<DIV Class="Paranum"><FONT SIZE=-2>70.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation Note: </B>The
intent is that the value of X'Component_Size is always nonnegative. If
the array is stored ``backwards'' in memory (which might be caused by
an implementation-defined pragma), X'Component_Size is still positive.
</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>70.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>For an array
object A, A'Component_Size = A(I)'Size for any index I. </FONT></DIV>

<H4 ALIGN=CENTER>Implementation Advice</H4>
<DIV Class="Paranum"><FONT SIZE=-2>71</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em">&nbsp;&nbsp;&nbsp;&nbsp;<A NAME="I4454"></A>The
recommended level of support for the Component_Size attribute is: </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>72</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>An implementation need not support specified Component_Sizes
that are less than the Size of the component subtype.</LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>73</FONT></DIV>
<UL Class="Bulleted"><LI TYPE=DISC>An implementation should support specified Component_Sizes
that are factors and multiples of the word size. For such Component_Sizes,
the array should contain no gaps between components. For other Component_Sizes
(if supported), the array should contain no gaps between components when
packing is also specified; the implementation should forbid this combination
in cases where it cannot support a no-gaps representation. </LI></UL>
<DIV Class="Paranum"><FONT SIZE=-2>73.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>For example,
if Storage_Unit = 8, and Word_Size = 32, then the user is allowed to
specify a Component_Size of 1, 2, 4, 8, 16, and 32, with no gaps. In
addition, <I>n</I>*32 is allowed for positive integers <I>n</I>, again
with no gaps. If the implementation accepts Component_Size = 3, then
it might allocate 10 components per word, with a 2-bit gap at the end
of each word (unless packing is also specified), or it might not have
any internal gaps at all. (There can be gaps at either end of the array.)
</FONT></DIV>

<H4 ALIGN=CENTER>Static Semantics</H4>
<DIV Class="Paranum"><FONT SIZE=-2>73.1/1</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{<I><A HREF="defect1.html#8652/0009">8652/0009</A></I>}
<U>The following operational attribute is defined: External_Tag.</U></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>74/1</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{<I><A HREF="defect1.html#8652/0009">8652/0009</A></I>}
For every subtype S of a tagged type <I>T</I> (specific or class-wide)<S>,
the following attribute is defined</S>:</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>75/1</FONT></DIV>
<DL Class="Hanging"><DT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;S'External_Tag<DD Class="Hanging">
<A NAME="I4455"></A><A NAME="I4456"></A>{<I><A HREF="defect1.html#8652/0040">8652/0040</A></I>}
<A NAME="I4457"></A><A NAME="I4458"></A>S'External_Tag denotes an external
string representation for S'Tag; it is of the predefined type String.
External_Tag may be specified for a specific tagged type via an <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>;
the expression of such a clause shall be static. The default external
tag representation is implementation defined. See <A HREF="AA-3-9-2.html">3.9.2</A>
and <A HREF="AA-13-13-2.html">13.13.2</A>. <U>The value of External_Tag
is never inherited[; the default value is always used unless a new value
is directly specified for a type].</U> </DL>
<DIV Class="Paranum"><FONT SIZE=-2>75.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation defined: </B>The
default external representation for a type tag.</FONT></DIV>

<H4 ALIGN=CENTER>Implementation Requirements</H4>
<DIV Class="Paranum"><FONT SIZE=-2>76</FONT></DIV>
<DIV Class="Normal">&nbsp;&nbsp;&nbsp;&nbsp;In an implementation, the default external tag
for each specific tagged type declared in a partition shall be distinct,
so long as the type is declared outside an instance of a generic body.
If the compilation unit in which a given tagged type is declared, and
all compilation units on which it semantically depends, are the same
in two different partitions, then the external tag for the type shall
be the same in the two partitions. What it means for a compilation unit
to be the same in two different partitions is implementation defined.
At a minimum, if the compilation unit is not recompiled between building
the two different partitions that include it, the compilation unit is
considered the same in the two partitions. </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>76.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation defined: </B>What
determines whether a compilation unit is the same in two different partitions.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>76.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>These requirements
are important because external tags are used for input/output of class-wide
types. These requirements ensure that what is written by one program
can be read back by some other program so long as they share the same
declaration for the type (and everything it depends on).</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>76.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The user may specify the external
tag if (s)he wishes its value to be stable even across changes to the
compilation unit in which the type is declared (or changes in some unit
on which it depends).</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>76.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>We use a String rather than a
Storage_Array to represent an external tag for portability. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>76.e</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>Note that
the characters of an external tag need not all be graphic characters.
In other words, the external tag can be a sequence of arbitrary 8-bit
bytes. </FONT></DIV>
<DIV Class="NotesHeader"><FONT SIZE=-1>NOTES</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>77</FONT></DIV>
<DIV Class="Notes"><FONT SIZE=-1>8&nbsp;&nbsp;The following language-defined
attributes are specifiable, at least for some of the kinds of entities
to which they apply: Address, Size, Component_Size, Alignment, External_Tag,
Small, Bit_Order, Storage_Pool, Storage_Size, Write, Output, Read, Input,
and Machine_Radix.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>78</FONT></DIV>
<DIV Class="Notes"><FONT SIZE=-1>9&nbsp;&nbsp;It follows from the general
rules in <A HREF="AA-13-1.html">13.1</A> that if one writes ``<B>for</B>
X'Size <B>use</B> Y;'' then the X'Size <FONT FACE="Arial, Helvetica">attribute_reference</FONT>
will return Y (assuming the implementation allows the Size clause). The
same is true for all of the specifiable attributes except Storage_Size.
</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>78.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>An implementation
may specify that an implementation-defined attribute is specifiable for
certain entities. This follows from the fact that the semantics of implementation-defined
attributes is implementation defined. An implementation is not allowed
to make a language-defined attribute specifiable if it isn't. </FONT></DIV>

<H4 ALIGN=CENTER>Examples</H4>
<DIV Class="Paranum"><FONT SIZE=-2>79</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em">&nbsp;&nbsp;&nbsp;&nbsp;<I>Examples of
attribute definition clauses:</I> </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>80</FONT></DIV>
<DIV Class="Examples"><TT>Byte&nbsp;:&nbsp;<B>constant</B>&nbsp;:=&nbsp;8;<BR>
Page&nbsp;:&nbsp;<B>constant</B>&nbsp;:=&nbsp;2**12;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>81</FONT></DIV>
<DIV Class="Examples"><TT><B>type</B>&nbsp;Medium&nbsp;<B>is</B>&nbsp;<B>range</B>&nbsp;0&nbsp;..&nbsp;65_000;<BR>
<B>for</B>&nbsp;Medium'Size&nbsp;<B>use</B>&nbsp;2*Byte;<BR>
<B>for</B>&nbsp;Medium'Alignment&nbsp;<B>use</B>&nbsp;2;<BR>
Device_Register&nbsp;:&nbsp;Medium;<BR>
<B>for</B>&nbsp;Device_Register'Size&nbsp;<B>use</B>&nbsp;Medium'Size;<BR>
<B>for</B>&nbsp;Device_Register'Address&nbsp;<B>use</B>&nbsp;System.Storage_Elements.To_Address(16#FFFF_0020#);</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>82</FONT></DIV>
<DIV Class="Examples"><TT><B>type</B>&nbsp;Short&nbsp;<B>is</B>&nbsp;<B>delta</B>&nbsp;0.01&nbsp;<B>range</B>&nbsp;-100.0&nbsp;..&nbsp;100.0;<BR>
<B>for</B>&nbsp;Short'Size&nbsp;<B>use</B>&nbsp;15;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>83</FONT></DIV>
<DIV Class="Examples"><TT><B>for</B>&nbsp;Car_Name'Storage_Size&nbsp;<B>use</B>&nbsp;--<I>&nbsp;specify&nbsp;access&nbsp;type's&nbsp;storage&nbsp;pool&nbsp;size</I><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2000*((Car'Size/System.Storage_Unit)&nbsp;+1);&nbsp;--<I>&nbsp;approximately&nbsp;2000&nbsp;cars</I></TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>84</FONT></DIV>
<DIV Class="Examples"><TT><B>function</B>&nbsp;My_Read(Stream&nbsp;:&nbsp;<B>access</B>&nbsp;Ada.Streams.Root_Stream_Type'Class)<BR>
&nbsp;&nbsp;<B>return</B>&nbsp;T;<BR>
<B>for</B>&nbsp;T'Read&nbsp;<B>use</B>&nbsp;My_Read;&nbsp;--<I>&nbsp;see&nbsp;<A HREF="AA-13-13-2.html">13.13.2</A></I></TT></DIV>
<DIV Class="NotesHeader"><FONT SIZE=-1>NOTES</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>85</FONT></DIV>
<DIV Class="Notes"><FONT SIZE=-1>10&nbsp;&nbsp;<I>Notes on the examples:</I>
In the Size clause for Short, fifteen bits is the minimum necessary,
since the type definition requires Short'Small &lt;= 2**(-7). </FONT></DIV>

<H4 ALIGN=CENTER>Extensions to Ada 83</H4>
<DIV Class="Paranum"><FONT SIZE=-2>85.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><A NAME="I4459"></A>The syntax
rule for <FONT FACE="Arial, Helvetica">length_clause</FONT> is replaced
with the new syntax rule for <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>,
and it is modified to allow a <FONT FACE="Arial, Helvetica">name</FONT>
(as well as an expression). </FONT></DIV>

<H4 ALIGN=CENTER>Wording Changes from Ada 83</H4>
<DIV Class="Paranum"><FONT SIZE=-2>85.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The syntax rule for <FONT FACE="Arial, Helvetica">attribute_definition_clause</FONT>
now requires that the prefix of the <FONT FACE="Arial, Helvetica">attribute</FONT>
be a <FONT FACE="Arial, Helvetica">local_name</FONT>; in Ada 83 this
rule was stated in the text.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>85.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>In Ada 83, the relationship between
a <FONT FACE="Arial, Helvetica">representation_clause</FONT> specifying
a certain aspect and an attribute that queried that aspect was unclear.
In Ada 95, they are the same, except for certain explicit exceptions.
</FONT></DIV>

<HR>
<P><A HREF="AA-TOC.html">Contents</A>&nbsp;&nbsp;&nbsp;<A HREF="AA-0-29.html">Index</A>&nbsp;&nbsp;&nbsp;<A HREF="AA-13-2.html">Previous</A>&nbsp;&nbsp;&nbsp;<A HREF="AA-13-4.html">Next</A>&nbsp;&nbsp;&nbsp;<A HREF="AA-TTL.html">Legal</A></P>
</BODY>
</HTML>