DU · The following Ada implementation was tested and determined to pass ACVC 1.11. Testing was completed on 29 November 1990. Compiler Name and Version: VADS Sun-4 => 68K, Sun OS

AD-A240 538 IENTATION PAGE hiiI~i~lII~lII~l(f0" 1 ¶hjx W' m.epon. nckO ft~ Orn.W tot q ru~.WO *sU~ dIE seucWN z do acu~ mmr QW" Sri faa"• lq btxdsl Wrden ot w yl of " aieid a o OiiiiO l ci 4lorrn , of W idm h ,ck qi suggto t If WM -,g " b~ME. to W l~*ion

1215 Jetrflon Dave H"Awy. S;uO 12C4. Ai0Ofl, VA 222024302 atn to ft Oti"e of IoRN n &M1 F110 li y k 0 1i1ce. oi

1. AGENCY USE ONLY (Leave Blank) 2 REPORT DATE 3. REPORT TYPE AND DATES COVERED

Final: 01 Aug 1991 to 01 Jun 1993

4 TITLE AND SUBTITLE 5. FUNDING NUMBERS

Verdix Corporation, VADS Sun-4=> 68k, Sun OS 4.0, VAda-110-40125, Version 6.0Sun-4/260 (Host) to MVME147 (Motorola 68030)(Target), 901129W1.11097

6 AUTHOR(S)

Wright-Patterson AFB, Dayton, OHUSA

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION

Ada Validation Facility, Language Control Facility ASD/SCEL REPORT NUMBER

Bldg. 676, Rm 135 AVF-VSR-407-0891Wright-Patterson AFBDayton. OH 45433

9. SPONSORINGCMONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSORINGA4ONITORING AGENCY

Ada Joint Program Office REPORT NUMBER

United States Department of DefensePentagon, Rm 3E114Washington, D.C. 20301-3081

11. SUPPLEMENTARY NOTES

12a. DISTRIBUTION. VAILABILITY STATEMENT 12b. DISTRIBUTION COOE

Approved for publ.- releze; distribution un!imited.

13 ABSTRACT (Maximum 200 words)

Verdix Corporation, VADS Sun-4=> 68K, Sun OS 4.0, VAda-110-40125, Version 6.0, Wright-Patterson AFB, Sun-4/260,our. OS 4.0 (Host) to MVME147 (Motorola 68030)(bare machine)(Target), ACVC 1.11.

DTI.CSEP 19 1991 Ut91-11074

DU14 SUBJECT TERMS 15. NUMBEROF PAGES

Ada programming language, Ada Compiler Val. Summary Report, Ada Compiler Val. 16._PRICECODE

Capability, Val. Testing, Ada Val. Offiice, Ada Val. Facility, ANSI/MIL-STD-1815A, AJPO. 16 PRICE COGE

17 SECURITY CLASSIFICATiON 18 SECUR;TY CLASSIFICATION 19 SECURITY CLASSIFICATION 20. LIMITATION OF ABSTRACTOF REPORT OF ABSTRACT

UNCLASSIFIED UNCLASSIFED UNCLASSIFIED

NSN 754001-280-550 Standard Form 298. (Rev 2-09)

9 1 o 9 2 Prescgbed by ANSI Sid 239-12a

AVF Control Number:AVF-VSR-407-0891I August 199190-09-25-VRX

Ada COMPILERVALIDATION SUMMARY REPORT:

Certificate Number: 901129W1.11097Verdix Corporation

VADS Sun-4 => 63K, Sun OS 4.0, VAda-110-40125, Version 6.0Sun.-4/260 => MVMEI47 (Motorola 68030)

Prepared By:Ada Validation Facility

ASD/SCELWright-Patterson AFB OH 45433-6503 I

Accesion ForNTIS CRA&I

OTIC TABU :ainou;ced LlJ.iZti cation

B y ... . .... ..... ....... .....Di. t ib tio. I

,/.3Idabh'ty Lo(Xos

"tV,1l1 J 0ior

i I.\

Certificate Information

The following Ada implementation was tested and determined to pass ACVC1.11. Testing was completed on 29 November 1990.

Compiler Name and Version: VADS Sun-4 => 68K, Sun OS 4.0,

VAda-llO-40125, Version 6.0

Host Computer System: Sun-4/260, Sun OS 4.0

Target Computer System: MVME147 (Motorola 68030) (bare machine)

Customer Agreement Number: 90-09-25-VRX

See Section 3.1 for any additional information about the testingenvironment.

As a result of this validation effort, Validation Certificate901129W1.11097 is awarded to Verdix Corporation. This certificate expireson 1 March 1993.

This report has been reviewed and is approved.

Ada Validation FacilitySteven P. WilsonTechnical DirectorASD/SCELWright-Patterson AFB OH 45433-6503

Ada Val at o__'0ganizationDirector, do o uer & Software Engineerinf Division

• Institute fo_-r efense AnalysesAlexandria VA 22311

Ada Joint Program OfficeDr. John Solomond, DirectorDepartment of DefenseWashington DC 20301

DECLARATION OF CONFORMANCE

Customer: Verdix Corporation

Ada Validation Facility: ASD/SCELWright-Patterson AFB OH 45433-6503

ACVC Version: 1.11

Ada Implementation:

Compiler Name: VADS Sun-4 => 68k, Sun OS 4.0, VAda. 110-40125, Version 6.0Host Computer: Sun-4/260, Sun OS 4.0

Target Computer: MVME147 (Motorola 68030)

I, the undersigned, representing Verdix Corporation, declare that Verdix Corporationhas no knowledge of deliberate deviations from the Ada Language StandardANSI/MIL.STD.1815A in the implementation listed in this declaration. I declare thatthe Verdix Corporation is the owner of the above implementation and the certificatesshall be awarded in the name of the Verdix Corporation.

Stephen Zeigler Date:1600 N W Compton Drive

e/Suite 357Beaverton, Oregon 97006

TABLE OF CONTENTS

CHAPTER 1 INTRODUCTION

1.1 USE OF THIS VALIDATION SUMMARY REPORT ......... .. 1-11.2 REFERENCES ............. .................... .. 1-21.3 ACVC TEST CLASSES ............................ .. 1-21.4 DEFINITION OF TERMS ........ ............... .. 1-3

CHAPTER 2 IMPLEMENTATION DEPENDENCIES

2.1 WITHDRAWN TESTS ................................ *2-12.2 INAPPLICABLE TESTS ......... ................ .. 2-12.3 TEST MODIFICATIONS ......... ............... .. 2-3

CHAPTER 3 PROCESSING INFORMATION

3.1 TESTING ENVIRONMENT ........ ............... .. 3-13.2 SUMMARY OF TEST RESULTS ...... ............. .. 3-13.3 TEST EXECUTION ............................... ..3-2

APPENDIX A MACRO PARAMETERS

APPENDIX B COMPILATION SYSTEM OPTIONS

APPENDIX C APPENDIX F OF THE Ada STANDARD

, • , r 'f ... i ~ • I =i- " i " -1- - i I- i- - i- ii I- -• i

CHAPTER 1

INTRODUCTION

The Ada implementation described above was tested according to the AdaValidation Procedures (Pro90J against the Ada Standard [Ada83] using thecurrent Ada Compiler Validation Capability (ACVC). This Validation SummaryReport (VSR) gives an account of the testing of this Ada implementation.For any technical terms used in this report, the reader is referred to[Pro90]. A detailed description of the ACVC may be found in the currentACVC User's Guide [UG9O].

1.1 USE OF THIS VALIDATION SUMMARY REPORT

Consistent with the national laws of the originating country, the AdaCertification Body may make full and free public disclosure of this report.In the United States, this is provided in accordance with the "Freedom ofInformation Act" (5 U.S.C. #552). The results of this validation applyonly to the computers, operating systems, and compiler versions identifiedin this report.

The organizations represented on the signature page of this report do notrepresent or warrant that all statements set forth in this report areaccurate and complete, or that the subject implementation has nononconformities to the Ada Standard other than those presented. Copies ofthis report are available to the public from the AVF which performed thisvalidation or from:

National Technical Information Service5285 Port Royal RoadSpringfield VA 22161

Ouestions regarding this report or the validation test results should beJirected to the AVF which performed this validation or to:

Ada Validation OrganizationInstitute for Defense Analyses1801 North Beauregard StreetAlexandria VA 22311

1-1

INTRODUCTION

1.2 REFERENCES

[Ada83] Reference Manual for the Ada Programming Language,ANSI/MIL-STD----5A,February 1983 and ISO 852-1987.

[Pro901 Ada Compiler Validation Procedures, Version 2.1, Ada Joint ProgramO-ice, AugusFt 9T0.

[UG89] Ada Compiler Validation Capability User's Guide, 21 June 1989.

1.3 ACVC TEST CLASSES

Compliance of Ada implementations is tested by means of the ACVC. The ACVCcontains a collection of test programs structured into six test classes:A, B, C, D, E, and L. The first letter of a test name identifies the classto which it belongs. Class A, C, D, and E tests are executable. Class Band class L tests are expected to produce errors at compile time and linktime, respectively.

The executable tests are written in a self-checking manner and produce aPASSED, FAILED, or NOT APPLICABLE message indicating the result when theyare executed. Three Ada library units, the packages REPORT and SPPRT13,and the procedure CHECK FILE are used for this purpose. The package REPORTalso provides a set of identity functions used to defeat some compileroptimizations allowed by the Ada Standard that would circumvent a testobjective. The package SPPRT13 is used by many tests for Chapter 13 of theAda Standard. The procedure CHECK FILE is used to check the contents oftext files written by some of the Class C tests for Chapter 14 of the AdaStandard. The operation of REPORT and CHECK FILE is checked by a set ofexecutable tests. If these units are not operating correctly, validationtesting is discontinued.

Class B tests check that a compiler detects illegal language usage. ClassB tests are not executable. Each test in this class is compiled and theresulting compilation listing is examined to verify that all violations ofthe Ada Standard are detected. Some of the class B tests contain legal Adacode which must not be flagged illegal by the compiler. This behavior isalso verified.

Class L tests check that an Ada implementation correctly detects violationof the Ada Standard involving multiple, separately compiled units. Errorsare expected at link time, and execution is attempted.

In some tests of the ACVC, certain macro strings have to be replaced byimplementation-specific values -- for example, the largest integer. A listof the values used for this implementation is provided in Appendix A. Inaddition to these anticipated test modifications, additional changes may berequired to remove unforeseen conflicts betveen the tests andimplementation-dependent characteristics. The modifications required forthis implementation are described in section 2.3.

1-2

INTRODUCTION

For each Ada implementation, a customized test suite is produced by theAVF. This customization consists of making the modifications described inthe preceding paragraph, removing withdrawn tests (see section 2.1) and,possibly some inapplicable tests (see Section 2.2 and [UG9O]).

In order to pass an ACVC an Ada implementation must process each test ofthe customized test suite according to the Ada Standard.

1.4 DEFINITION OF TERMS

Ada Compiler The software and any needed hardware that have to be addedto a given host and target computer system to allowtransformation of Ada programs into executable form andexecution thereof.

Ada Compiler The means for testing compliance of Ada implementations,Validation consisting of the test suite, the support programs, the ACVCCapability user's guide and the template for the validation summary(ACVC) report.

Ada An Ada compiler with its host computer system and itsImplementation target computer system.

Ada Joint The part of the certification body which provides policy andProgram guidance for the Ada certification system.Office (AJPO)

Ada The part of the certification body which carries out theValidation procedures required to establish the compliance of an AdaFacility (AVF) implementation.

Ada The part of the certification body that provides technicalValidation guidance for operations of the Ada certification system.Organization(AVO)

Compliance of The ability of the implementation to pass an ACVC version.an AdaImplementation

Computer A functional unit, consistin; of one or more computers andSystem associated software, that uses common storage for all or

part of a program and also for all or part of the datanecessary for the execution of the program; executesuser-written or user-designated programs; performsuser-designated data manipulation, including arithmeticoperations and logic operations; and that can executeprograms that modify themselves during execution. Acomputer system may be a stand-alone unit or may consist ofseveral inter-connected units.

1-3

INTRODUCTION

Conformity Fulfillment by a product, process or service of allrequirements specified.

Customer An individual or corporate entity who enters into anagreement with an AVF which specifies the terms andconditions for AVF services (of any kind) to be performed.

Declaration of A formal statement from a customer assuring that conformityConformance is realized or attainable on the Ada implementation for

which validation status is realized.

Host Computer A computer system where Ada source programs are transformedSystem into executable form.

Inapplicable A test that contains one or more test objectives found to betest irrelevant for the given Ada implementation.

ISO International Organization for Standardization.

Operating Software that controls the execution of programs and thatSystem provides services such as resource allocation, scheduling,

input/output control, and data management. Usually,operating systems are predominantly software, but partial orcomplete hardware implementations are possible.

Target A computer system where the executable form of Ada programsComputer are executed.System

Validated Ada The compiler of a validated Ada implementation.Compiler

Validated Ada An Ada implementation that has been validated successfullyImplementation either by AVF testing or by registration (Pro90].

Validation The process of checking the conformity of an Ada compiler tothe Ada programming language and of issuing a certificatefor this implementation.

Withdrawn A test found to be incorrect and not used in conformitytest testing. A test may be incorrect because it has an invalid

test objective, fails to meet its test objective, orcontains erroneous or illegal use of the Ada programminglanguage.

1-4

CHAPTER 2

IMPLEMENTATION DEPENDENCIES

2.1 WITHDRAWN TESTS

The following tests have been withdrawn by the AVO. The rationale forwithdrawing each test is available from either the 'VO or the AVF. Thepublication date for this list of withdrawn test: i: 12 October 1990.

E28005C B28006C C34006D B41308b C43004A C45114AC45346A C45612B C45651A C46022A B49008A A74006AC74308A B83022B B83022H B83025B B83025D B83026BB85001L C83026A C83041A C97116A C98003B BA2O11A

CB7001A CB7001B CB7004A CC1223A BC1226A CC1226BBC3009B BDIB02B BDIBO6A AD1BO8A BD2AO2A CD2A21ECD2A23E CD2A32A CD2A41A CD2A41E CD2A87A CD2B1SCBD3006A BD4008A CD4022A CD4022D CD4024B CD4024CCD4024D CD4031A CD4051D CD5111A CD7004C ED7005DCD7005E AD7006A CD7006E AD7201A AD7201E CD7204BBD8002A BD8004C CD9005A CD9005B CDA2O1E CE21071CE2117A CE2117B CE2119B CE2205B CE2405A CE3111CCE3118A CE3411B CE3412B CE3607B CE3607C CE3607DCE3812A CE3814A CE3902B

2.2 INAPPLICABLE TESTS

A test is inapplicable if it contains test objectives which are irrelevantfor a given Ada implementation. Reasons for a test's inapplicability maybe supported by documents issued by the ISO and the AJPO known as AdaCommentaries and commonly referenced in the format AI-ddddd. For thisimplementation, the following tests were determined to be inapplicable forthe reasons indicated; references to Ada Commentaries are included asappropriate.

2-1


The following 201 tests have floating-point type declarations requiringmore digits than SYSTEM.MAXDIGITS:

C24113L. .Y (14 tests) C35705L.,Y (14 tests)C35706L. .Y (14 tests) C35707L.,Y (14 tests)C35708L. .Y (14 tests) C35802L..Z (15 tests)r4r,' 4 iL, .Y (14 tests) C45321L..Y (14 tests)

.45421L, Y (14 tests) C45521L..Z (15 tests)C45524L. .Z (15 tests) C45621L..Z (15 tests)C45641L. .Y (14 tests) C46012L..Z (15 tests)

The following 21 tests check for the predefined type LONGINTEGER:

C35404C C45231C C45304C C45411C C45412CC45502C C45503C C45504C C45504F C45611CC45612C C45613C C45614C C45631C C45632CB52004D C55BO7A B55BO9C B86001W C86006CCD7101F

C35702B, C35713C, B86001U, and C86006G check for the predefined typeLONGFLOAT.

C35713D and B8600lZ check for a predefined floating-point type with aname other than FLOAT, LONGFLOAT, or SHORTFLOAT.

A35801E checks that FLOAT'FIRST..FLOAT'LAST may be used as a rangeconstraint in a floating-point type declaration; for this implementationthat range exceeds the safe numbers and must be rejected. (See section2.3)

C45531M..P (4 tests) and C45532M..P (4 tests) check fixed-pointoperations for types that require a SYSTEM.MAXMANTISSA of 47 orgreater.

C45624A..B (2 tests) check that the proper exception is raised ifMACHINE OVERFLOWS is FALSE for floating point types; for thisimplementation, MACHINEOVERFLOWS is TRUE.

C86001F recompiles package SYSTEM, making package TEXT 10, and hencepackage REPORT, obsolete. For this implementation, the package TEXT IOis dependent upon package SYSTEM.

B86001Y checks for a predefined fixed-point type other than DURATION.

C96005B checks for values of type DURATION'BASE that are outside therange of DURATION. There are no such values for this implementation.

CD1O09C uses a representation clause specifying a non-default size for afloating-point type.

CD2A84A, CD2A84E, CD2A84I..J (2 tests), ind CD2A84O use representationclauses specifying non-default sizes for access types.

2-2


The tests listed in the following table are not applicable because thegiven file operations are not supported for the given combination ofmode and file access method:

Test File Operation Mode File Access Method

CE2102D CREATE IN FILE SEQUENTIAL 1OCE2102E CREATE OUT FILE SEQUENTIAL 1o

CE2102F CREATE INOUT FILE DIRECT 10CE21021 CREATE IN FIEE DIRECT-IOCE2102J CREATE OUT FILE DIRECT-IOCE2102N OPEN IN FILE SEQUENTIAL 1OCE21020 RESET IN FILE SEQUENTIAL 1OCE2102P OPEN OUT FILE SEQUENTIAL 1OCE21020 RESET OUT FILE SEQUENTIAL_1OCE2102R OPEN INOUT FILE DIRECT 10CE2102S RESET INOUT-FILE DIRECT-IOCE2102T OPEN IN FILE DIRECT 1OCE2102U RESET IN FILE DIRECT -OCE2102V OPEN OUT FILE DIRECT-1OCE2102W RESET OUT-FILE DIRECT-IOCE3102E CREATE IN FILE TEXT I0CE3102F RESET Any Mode TEXT-IOCE3102G DELETE TEXT -OCE31021 CREATE OUT FILE TEXT-10CE31O2J OPEN IN PILE TEXT-IOCE3102K OPEN OUT FILE TEXT-IO

CE2203A checks that VRITE raises USE ERROR if the capacity of theexternal file is exceeded for SEQUENTIAL_10. This implementation doesnot restrict file capacity.

CE2403A checks that VRITE raises USE ERROR if the capacity of theexternal file is exceeded for DIRECT IO. This implementation does notrestrict file capacity.

CE3304A checks that USE ERROR is raised if a call to SET LINE LENGTH orSET PAGE LENGTH specifies a value that is inappropriate Tor the externalfile. This inplementation does not have inappropriate values for eitherline length or page length.

CE3413B checks that PAGE raises LAYOUT ERROR when the value of the pagenumber exceeds COUNT'LAST. For this implementation, the value ofCOUNT'LAST is greater than 150000 making the checking ot this objectiveimpractical.

2-3

IMPLEMENTATION DEPZNDENCIES

2.3 TEST MODIFICATIONS

Modifications (see section 1.3) were required for 21 tests.

The following tests were split into two or more tests because thisimplementation did not report the violations of the Ada Standard in the wayexpected by the original tests:

B24009A B33301B B38003A B38003B B38009AB38009B B85008G B85008H BC1303F BC3005BBD2BO3A BD2DO3A BD4003A

A35801E was graded inapplicable by Evaluation Modification as directed bythe AVO; the compiler rejects the use of the range FLOAT'FIRST..FLOAT'LASTas the range constraint of a floating-point type declaration because thebounds lie outside of the range of safe numbers (cf. ARM 3.5.7(12)).

CDiO09A, CDl009I. CD1C03A. CD2A24A, and CD2A31A..C (3 rests) were gradedpassed by Evaluation Modification as directed by the AVO. These tests useinstantiations of the support procedure LENGTHCHECK, which usesUnchecked Conversion according to the interpretation given in AI-00590.The AVO ruled that this interpretation is not binding under ACVC 1.11; thetests are ruled to be passed if they produce Failed messages only from theinstances of LENGTHCHECK--i.e, the alloyed Report.Failed messages have thegeneral form:

"* CHECK ON REPRESENTATION FOR <TYPE ID> FAILED."

2-4

CHAPTER 3

PROCESSING INFORMATION

3.1 TESTING ENVIRONMENT

The host and target computer systems for the Ada implementation wereconnected by Ethernet. The rest of this Ada implementation tested in thisvalidation effort is described adequately by the information given in theinitial pages of this report.

For a point of contact for technical information about this Adaimplementation system, see:

Steve HodgesVerdix Corporation14130-A Sully Field CircleChantilly VA 22021

For a point of contact for sales information about this Ada implementationsystem, see:

Steve HodgesVerdix Corporation14130-A Sully Field CircleChantilly VA 22021

Testing of this Ada implementation was conducted at the customer's site bya validation team from the AVF.

3.2 SUMMARY OF TEST RESULTS

An Ada Implementation passes a given ACVC version if it processes each testof the customized test suite in accordance vith the Ada ProgrammingLanguage Standard, whether the test is applicable or inapplicable;otherwise, the Ada Implementation fails the ACVC (Pro90].

3-1

PROCESSING INFORMATION

For all processed tests (inapplicable and applicable), a result wasobtained that conforms to the Ada Programming Language Standard.

a) Total Number of Applicable Tests 3816b) Total Number of Withdrawn Tests 81c) Processed Inapplicable Tests 72d) Non-Processed I/0 Tests 0e) Non-Processed Floating-Point

Precision Tests 201

f) Total Number of Inapplicable Tests 273 (c+d+e)

g) Total Number of Tests for ACVC 1.11 4170 (a+b+f)

All I/0 tests of the test suite were processed because this implementationsupports a file system. The above number of floating-point tests were notprocessed because they used floating-point precision exceeding thatsupported by the implementation. When this compiler was tested, the testslisted in section 2.1 had been withdrawn because of test errors.

3.3 TEST EXECUTION

Version 1.11 of the ACVC comprises 4170 tests. When this compiler wastested, the tests listed in section ^.1 had been withdrawn because of testerrors. The AVF determined that 273 tests were inapplicable to thisimplementation. All inapplicable tests were processed during validationtesting except for 201 executable tests that use floating-point precisionexceeding that supported by the implementation. In addition, the modifiedtests mentioned in section 2.3 were also processed.

A magnetic tape containing the customized test suite (see section 1.3) wastaken on-site by the validation team for processing. The contents of themagnetic tape were not loaded directly onto the host computer. The tapewas loaded onto a Sun Workstation, and the tests were copied over Ethernetto the host machine.

After the test files were loaded onto the host computer, the full set oftests was processed by the Ada implementation.

The tests were compiled and linked on the hczt computer system, asappropriate. The executable images were transferred to the target computersystem by the communications link described above, and run. The resultswere captured on the host computer system.

Testing was performed using command scripts provided by the customer andreviewed by the validation team. See Appendix B for a complete listing ofthe processing options for this implementation. It also indicates thedefault options.

3-2

PROCESSING INFORMATIONTest output, compiler and linker listings, and Job logs were captured onmagnetic tape and archived at the AVF. The listings examined on-site bythe validation team vere also archived.

3-3

APPENDIX A

MACRO PARAMETERS

This appendix contains the macro parameters used for customizing the ACVC.The meaning and purpose of these parameters are explained in [UG891. Thefolloving macro parameters are defined in terms of the value V ofSMAX IN LEN vhich is the maximum input line length permitted for the testedimplementation. For these parameters, Ada string expressions are givenrather than the macro values themselves.

Macro Parameter Macro Value----------------------------------------------

$BIGIDI (I..V-1 0> 'A', V -> '1')

SBIG ID2 (I..V-l -> 'A', V -> '2')

$BIGID3 (l..V/2 .> 'A') & '3' &(l..V-l-V/2 -> 'A')

$BIG ID4 (1..V/2 0> 'A') & '14' &(1..V-1-V/2 -> 'A')

$BIGINTLIT (1..V-3 .> '0') & "298"

$BIGREALLIT (1..V-5 .> '0') & "690.0"

SBIGSTRING1 '"' & (1..V/2 -> 'A') & '"'

$BIGSTRING2 '"' & (l..V-l-V/2 .> 'A') & 'I' '"6

$BLANKS (l..V-20 -> '

SMAXLENINT BASED LITERAL"& (1..V-5 => '0') & "ii:"

$MAXLENREAL BASED LITERAL"16:" & (I..V-7 => '0') & "F.E:"

$MAX STRINGLITERAL 1'. & ( 1 .-.'-2 => 'A') & '"'

A-1

i ý-w

MACRO PARAMETERtS

The folloving table liSts all of the other macro parameters and theirrespective values-

Macro Parameter Macro Value---------------------------------------------------------$MAXIN LEN 499

$ACcSIZE 32

$ALIGNMENT 4

$COUN'r LAST 2 -147 -483 647

$DEFAULT MEN SIZE 16 -777 -216

$OEFAULT STOR UNIT 8

$DEFAULTSYSNAME SUN4_CROSS_68000

SDELTA-DOC 0.0000000004656612873077392578125

SENTRYADDRESS SYSTEM.-"."(16#40#)

SENTRY ADDRESS1 SYSTEM.111(68#

SENTRY ADDRESS2 SYSTEM.1+(6#0#

SFIELD-LAST 22147483647

$FILE-TERMINATOR fI

$FIXEDNAME NO SUCH TYPE

SFLOAT-NAME NOSUCB TYPE

SPORM-STRING

$FORI4 STRING2 CANTRSITFLECAPACITY"

$GREATEnTHAN DUPATI ON100 000.0

$GREATERTHAN DURATION BASE LAV1rT000?7ooo-o

$GREATERTHAN_FLOATBASE LASTI-9E+3O8

$GREATERTHANFLOATSAFE LARGE

5.OE.307

A-2

MIACRO PARAMETERS

$GREATER THANSHORT FLOAT SAFE LARGE9.0f+37

$HIGHPRIORITY 99

$ILLEGALEXTERAL-FILE NAMEl"/illegal/file~name/2)JZ21O2c.dat"

$ILLEGAL EXTERNAL FILE -NAME2"i/illegal/file naine/CE21O2C*.DAT"

S INAPPROPRIATELINELENGTH-1

$INAPPROPRIATE PACE LENGTH-1

SINCLUDE-PRAGMAl PRAGMA INCLUDE ("IA28006D1 TST-)

$INCLUDEPRAGMA2 PRAGMA INCLUDE (-B28006Dl.TST-)

$INTEGER-FIRST -2_147_483_648

$INTEGER-LAST 2_147_483_647

$INTEGER LASTPLUS_1 2_147_483_648

S INTERFACE-LANGUAGE C

SLESS THAN DURATION -100000.0

$LS-HNDUAINBS FIRST-15 000 000.0

SLINE-TERMINATOR ASCII.LF & ASCII.FF

SLOW PRIORITY 0

SHACHINE CODESTATEM ENTCODE 0'(OP .> NOP);

$MACHINE CODE TYPE CODE_0

SMANTISSA-DOC 31

SMAX-DIGITS 15

SMAX INT 2 147_483_647

SMAX INT PLUS 1 2 147 483 648

SHIN INT -2 147_483_648

A- 3

MACRO PARAMETERS

$NAME TINY-INTEGER

SHAMELIST SUN4 CROSS_68000

SHAMESPECIFICATIONi /nushuz/usr/kim/acvcl. 11/c/e/X2120A

SNAME-SPECIFICATION2 /nushuz/usr/kim//acvcl. 11/c/e/X2120B

ISNAME-SPECIFICATION3 /nushuz/usr/kim//acvcl. 11/c/e/X3119A

SNEGBASEDINT 16*FOOOOOOE#

SNEWHEMSIZE 16 777_216

$NEVSTORUNIT 8

$NEIJ SYS NAME SUN4 CROSS 68000

$PAGE TERMINATOR ASCII.FF

SRECoRD DEFINITION RECORD SrJBP: OPERAND; END RECORD;

$RECORD-NAME CODE 0

$TASK-SIZE 32

STASKSTORAGESIZE 1024

$TICK 0.01

SVARIABLE-ADDRESS VAR 3'ADDRESS

SVARIABLE-ADDRESS1 VAR_1'ADDRESS

SVARIAiBLE-ADDRESS2 VAR 21ADDRESS

$YOUR PRAGMA PRAGMA PASSIVE

APPENDIX B

COMPILATION SYSTEM OPTIONS

The compiler options of this Ada implementation, as described in thisAppendix, are provided by the customer. Unless specifically notedotherwise, references in this appendix are to compiler documentation andnot to this report.

B-1


ada VADS Reference ada

ada

Ada compiler

Syntax

ada [options] [source file]... [linkeroptions][object file.o]...

Description

The command ada executes the Ada compiler and compiles thenamed Ada source file, ending with the .a suffix. The filemust reside in a VADS library directory. The ada .lib file inthis directory is modified after each Ada unit is compiled.

The object for each compiled Ada unit is left in a file withthe same name as that of the source with 01, 02, etc.substituted for .a. The -o option can be used to produce anexecutable with a name other than a.out, the default. Forcross compilers, the default name is a.vox.

By default, ada produces only object and net files. If the-M option is used, the compiler automatically invokes a.ldand builds a complete program with the named library unit asthe main program.

Non-Ada object files (.o files produced by a compiler foranother language) may be given as arguments to ada. Thesefiles will be passed on to the linker and will be linkedwith the specified Ada object files.

Command line options may be specified in any order, but theorder of compilation and the order of the files to be passedto the linker can be significant.

Several VADS compilers may be simultaneous*.y available on asingle system. Because the ada command in anyVADS location/bin on a system will execute the correctcompiler components based upon visible library directives,the option -sh is provided to print the name of thecomponents actually executed.

Program listings with a disassembly of machine codeinstructions are generated by a.db or a.das.

Options

-a file name (archive) Treat file name as an objectarchive file created by ar. Since some archive files endwith .a, -a is used to distinguish archive files from Ada

B-2


source files.

-d (dependencies) Analyze for dependencies only. Do not dosemantic analysis or code generation. Update the library,marking any defined units as uncompiled. The -d option isused by a.make to establish dependencies among new files.

-e (error) Process compilation error messages using a.errorand send it to standard output. Only the source linescontaining errors are listed. Only one -e or -E optionshould be used.

-E

-E file

-E directory (error output) Without a file or directoryargument, ada processes error messages using a.error anddirects a brief output to standard output; the raw errormessages are left in ada source.err. If a file pathname isgiven, the raw error messages are placed in that file. If adirectory argument is supplied, the raw error output isplaced in dir/source.

err. The file of raw error messages can be used as input toa-error

-el (error listing) Intersperse error messages among sourcelines and direct to standard output.

-El

-El file

-El directory (error listing) Same as the -E option,except that source listing with errors is produced.

-ev (error vi(l)) Process syntax error messages usinga.error, embed them in the source file, and call theenvironment editor ERROR EDITOR. (If ERROR EDITOR isdefined, the environment variable ERROR PATTERN should alsobe defined. ERROR PATTERN is an editor search command thatlocates the first occurrence of '###' in the error file.) Ifno editor is specified, vi(l) is invched.

-K (keep) Keep the intermediate language (IL) fileproduced by the compiler front end. The IL file will beplaced in the .objects directory. with the file nameAda source.i

-L library_name (library) Operare in VADS librarylibraryname (the current v'orking dire'tor', is the default).

B-3


-Ifile abbreviation (library search) This is an optionpassed-to the UNIX linker, ld(l) telling it to search thespecified library file. (No space between the -1 and thefile abbreviation.)

For a description of the file abbreviations, see alsoOperating System documentation, ld(l).

-M unit name (main) Produce an executable program bylinking-the named unit as the main program. unit name mustalready be compiled. It must be either a parameterlessprocedure or a parameterless function returning an integer.The executable program will be named a.out unless overriddenwith the -o option.

-M source file (main) Produce an executable program bycompiling-and linking source file. The main unit of theprogram is assumed to be the root name of the .a file (forfoo.a the unit is foo). Only one .a file may be preceded by-M. The executable program will be named a.out unlessoverridden with the -o option.

-o executable file (output) This option is to be used inconjunction with the -M option. executable file is the nameof the executable rather than the default a.out.

-0(0-91 (optimize) Invoke the code optimizer (OPTIM3). Anoptional digit (there is no space before the digit) providesthe level of optimization. The default is -04.

-0 full optimization

-00 prevents optimization

-01 no hoisting

-02 no hoisting, but more passes

-03 no hoisting, but even more passes

-04 hoisting from loops

-05 hoisting from loops, but more passes

-06 hoisting from loops with maximum passes

-07 hoisting from loops and branches

-08 hoisting from loops and branches, more passes

-09 hoisting from loops and branches. maximum passes

Hoisting tr,.m branches (and cases alternatives) can be slow

B-4


and does not always provide significant performance gains, soit can be suppressed.

For more information about optimization, see COMPILING ADAPROGRAMS. See also pragma OPTIMIZECODE(OFF).

-P Invoke the Ada Preprocessor. See VADS ADAPREPROCESSOR REFERENCE.

-R VADSlibrary (recompile instantiation) Force analysisof all generic instantiations, causing reinstantiation ofany that are out of date.

-S (suppress) Apply pragma SUPPRESS to the entirecompilation for all suppressible checks. (See also pragmaSUPPRESS(ALLCHECKS))

-sh (shov) Display the name of the tool executable but donot execute it.

-T (timing) Print timing information for the compilation.

-v (verbose) Print compiler version number, date and timeof compilation, name of file compiled, command input line,total compilation time, and error summary line. Storageusage information about the object file is provided. WithOPTIM3 the output format of compression (the size ofoptimized instructions) is as a percentage of input(unoptimized instructions).

-w (warnings) Suppress warning diagnostics.

See also a.das; a.db; a.error; a.ld; a.mklib; andOperating System reference documentation for the ld(l) utility.

Diagnostics

The diagnostics produced by the VADS compiler are intendedto be self-explanatory. Most refer to the RH. Each RMreference includes a section number and, optionally, aparagraph number enclosed in parentheses.

B-5


LINKER OPTIONS

The linker options of this Ada implementation, as described in thisAppendix, are provided by the customer. Unless specifically notedotherwise, references in this appendix are to linker documentation and notto this report.a.ld VADS Reference a.ld

a.ld

prelinker

Syntax

a.ld [options) unitname [id_options]

Options

-DX (debug) Debug memory overflow (use in cases wherelinking a large number of units causes the error messagelocal symbol overflow" to occur).

-E unit name (elaborate) Elaborate unit-name as early inthe elaboration order as possible.

-F (files) Print a list of dependent files in order andsuppress linking.

-L library name (library) Operate in VADS librarylibrary naje (the current working directory is the defauit).

-o executable file (output) Use the specified file n,.me asthe name of the output rather than the default, a.out.

-sh (show) Display the name of the tool executable but donot execute it.

-U (units) Print a list of dependent units in order andsuppress linking.

B-6


-v (verbose) Print the linker command before executing it.

-V (verify) Print the linker command but suppress

execution.

Description

a.ld collects the object files needed to make unit name amain program and calls the UNIX linker ld(l) to linktogether all Ada and other language objects required toproduce an executable image in a.out.Unit name is the main program and must name a non-genericsubprogram. If unit name is a function, it must return avalue of the type STANDARD.INTEGER. This integer resultwill oe passed t' ck to the UNIX shell as the status code ofthe execution. The utility uses the net files produced bythe Ada compiler to check dependency information. A.ldproduces an exception mapping table and a unit elaborationtable and passes this information to the linker.

a.ld reads instructions for generating executables from theada. lih file in the VADS libraries on the search list.Besides information generated by the compiler, thesedirectives also include WITHn directives that allow theautomatic linking of object modules compiled from otherlanguages or Ada object modules not named in context clausesin the Ada source. Any number of WITHn directives may beplaced into a library, but they must be numberedcontiguously beginning at WITH'. The directives are recordedin the library's ada.lib file and have the following form.

WITHl:LINK:object file:

WITH2:LINK:archive file:

WITHn directives may be placed in the local Ada libraries orin any VADS library on the search list.

A WITHn directive in a local VADS library or earlier on thelibrary search list will hide the same numbered WITHndirecLive in a library later in the library search list.

Use the tool a.info to change or report library directivesin the current library.

All arguments after unit name are passed on to the linker.rhese may be options for it. archive libraries, libraryabbreviations, or object files.

VADS location/bin/a.ld is a vrakper program that executesthe correct executable based upcn directi:es visible in theada.lib file. This permits multiple VAPJ compilers to existon the same host. The -sh option prints The name of the

B-7


actual executable file.

Files

a.out default 9utput fileVADSlocation/staidard/,* startup and standard library routinesSee also Operating System documentation, ld(l).

Diagnostics

Self-explanator.,/ diagnostics are produced for missing files,etc. Additional messages are produced by the WIX linker id.

3-8

APPENDIX C

APPENDIX F OF THE Ada STANDARD

The only allowed ;mplementation dependencies correspond toimplementation-dependent pragmas, to certain machine-dependent conventionsas mentioned in Chapter 13 of the Ada Standard, and to certain allowedrestrictions on representation clauses. The implementation-dependentcharacteristics of this Ada implementation, as described in this Appendix,are provided by the customer. Unless specifically noted otherwise,references in this Appendix are to compiler documentation and not to thisreport. Implementation-specific portions of the package STANDARD, whichare not a part of Appendix F, are:

package STANDARD is

type INTEGER is range -.2147483648 .. 2147483647;

type SHORT INTEGER is range -32768 .. 32767;

type TINYINTEGER is range -128 .. 127;

type FLOAT is digits 15 range -1.79769313486E+308+1. 79769313486E+308;

type SHORT FLOAT is digits 6 range-3.40282E+38 .. 3.40282E+38;

type DURATION is delta 0.001 range -2147483.6482147483.647;

end STANDARD;

C-!


ATTACHMENT I

APPENDIX F. Implementation-Dependent Characteristics

1. Implementation-Dependent Pragmas

1.1. INLINE ONLY Pragma

The INLINE ONLY pragma, when used in the same way as pragmaINLINE, indicates to the compiler that the subprogram mustalways be inlined. This pragma also suppresses the genera-tion of a callable version of the routine which saves codespace. If a user erroneously makes an INLINE ONLY subpro-gram recursive, a warning message will be emitted and anPROGRAMERROR will be raised at run time.

1.2. BUILTIN Pragma

The BUILT IN pragma is used in the implementation of somepredefineU Ada packages, but provides no user access. It isused only to implement code bodies for which no actual Adabody can be provided, for example the MACHINECODE package.

1.3. SHARE CODE Pragma

The SHARE CODE r-igma takes the name of a generic instantia-tion or a genE _t. unit as the first argument and one of theidentifiers TRUE or FALSE as the second argument. Thispragma is only allowed immediately at the plaae of adeclarative item in a declarative part or package specifica-tion, or after a library unit in a compilation, but beforeany subsequent compilation unit.

When the first argument is a generic unit, *hs pragma appliesto all instantiations of that generic. 'hen the first argu-ment is the name of a generic instantiation. the pragmaapplies only to the specified instantiation, or overloadedinstantiations.

If the second argument is TRUE, the compiler will try toshare code generated for a generic instan'iation with codegenerated for other instantiations of the same generic.

C-2


When the second argument is FALSE, each instantiation willget a unique copy of the generated code. The extent towhich code is shared between instantiations depends on thispragma and the kind of generic formal parameters declaredfor the generic unit.

The name pragma SHARE BODY is also recognized by the imple-mentation and has The same effect as SHARE CODE. It isincluded for compatability with earlier versions of VADS.

1.4. NO IMAGE Pragma

The pragma suppresses the generation of the image array usedfor the IMAGE attribute of enumeration types. This elim-inates the overhead required to store the array in the exe-cutable image. An attempt to use the IMAGE attribute on atype whose image array has been suppressed will result in acompilation warning and PROGRAMERROR raised at run time.

1.5. EXTERNALNAME Pragma

The EXTERNAL NAME pragma takes the name of a subprogram orvariable delined in Ada and allows the user to specify adifferent external name that may be used to reference theentity from other languages. The pragma is allowed at theplace of a declarative item in a package specification andmust apply to an object declared earlier in the same packagespecification.

1.6. INTERFACENAME Pragma

The INTERFACE NAME pragma takes the name of a a variable orsubprogram defined in another language and allows it to bereferenced directly in Ada. The pragma will replace all

occurrences of the variable or subprogram name with anexternal reference to the second, link argument. The pragmais allowed at the place of a declarative item in a packagespecification and must apply to an object or subprogramdeclared earlier in the same package specification. Theobject must be declared as a scalar or an access type. Theobject cannot be any of the following:

a loop variable,a constant,an initialized variable,an array, ora record.

1.7. IMPLICITCODE Pragma

Takes one of the identifiers ON or OFF as the single argu-ment. This pragma is only allowed :ithin a machine code

C-3


procedure. It specifies that implicit code generated by thecompiler be allowed or disallowed. A yarning is issued ifOFF is used and any implicit code needs to be generated.The default is ON.

1.8. OPTIMIZE-CODE Pragma

Takes one of the identifiers ON or OFF as the single argu-ment. This pragma is only allowed within a machine codeprocedure. It specifies wheher the code should be optim-ized by the compiler. The default is ON. When OFF isspecified, the compiler will generate the code as specified.

2. Implementation of Predefined Pragmas

2.1. CONTROLLED

This pragma is recognized by the implementation but has noeffect.

2.2. ELABORATE

This pragma is implemented as described in Appendix B of the

Ada RM.

2.3. INLINE

This pragma is implemented as described in Appendix B of theAda RM.

2.4. INTERFACE

This pragma supports calls to 'C' and FORTRAN functions. TheAda subprograms can be either functions or procedures. Thetypes of parameters and the result type for functions mustbe scalar, access, or the predefined type ADDRESS in SYSTEM.All parameters mu!;t have mode IN. Record and array objectscan be passed by ieference using the ADDRESS attribute.

2.5. LIST


2.6. MEMORYSIZE

This pragma is recognized by the implementation. Th2 imple-mentation does not allow SYSTEM to be modified b, means ofpragmas; the SYSTEM package must be recompiled.

C-4


2.7. NON-REENTRANT

This pragma takes one argument which can be the name ofeither a library subprogram or a subprogram declared immedi-ately within a library package spec or body. It indicatesto the compiler that the subprogram will not be calledrecursively, allowing the compiler to perform specific optim-izations. The pragma can be applied to a subprogram or aset of overloaded subprograms within a package spec or pack-age body.

2.8. NOT ELABORATED

This pragma can only appear in a library package specifica-tion. It indicates that the package will not be elaboratedbecause it is either part of the RTS, a configuration pack-age, or an Ada package that is referenced from a languageother than Ada. The presence of this pragma suppresses thegeneration of elaboration code and issues warnings if ela-boration code is required.

2.9. OPTIMIZE


2.10. PACK

This pragma will cause the compiler to choose a non-alignedrepresentation for composite types. It will not causeobjects to be packed at the bit level.

2.11. PAGE


2.12. PASSIVE

The pragma has three forms:

PRAGMA PASSIVE;PRAGMA PASSIVE(SEHAPHORE);PRAGMA PASSIVE(INTERRUPT, <number>):

This pragma Pragma passive can be applied r- a task or tasktype declared immediately within a library package spec orbody. The pragma directs the compiler to oprimize certaintasking operations. It is possible that the statements in atask body will prevent the intended optimization; in thesecases, a warning will be generated at compile time and will

C -5


raise TASKINGERROR at runtime.

2.13. PRIORITY


2.14. SHARED


2.15. STORAGE UNIT

This pragma is recognized by the implementation. The imple-mentation does not allow SYSTEM to be modified by means ofpragmas; the SYSTEM package must be recompiled.

2.16. SUPPRESS

This pragma is implemented as described, except thatDIVISION CCHECK and in some cases OVERFLOWCHECK cannot besuppressed.

2.17. SYSTEM NAME

This pragma is recognized by the implementation. The imple-mentation does not allow SYSTEM to be modified by means ofpragmas; the SYSTEM package must be recompiled.

3. Implementation-Dependent Attributes

3.1. P'REF

For a prefix that denotes an object, a program unit, alabel, or an entry:

This attribute denotes the effective address of the first ofthe storage units allocated to P. For a subprogram, pack-age, task unit, or label, it refers to the address of themachine code associated with the corresponding body orstatement. For an entry for which an address clause hasbeen given, it refers to the corresponding hardware inter-rupt. The attribute is of the type OPERA_!',I defined in thepackage MACHINECODE. The atijib' te is only; allowed withina machine code procedure.

See section F.4.8 for more information on the use of thisattribute.

(For a package, task unit, or entry. the 'REF attribute isnot supported.)

C-6

APPRNDIX F OF THE Ada STANDARD

3.2. T'TASKID

For a task object or a value T, T'TASK IID yields the uniquetask id associated with a task. The value of this attributeis of the type ADDRESS in the package SYSTEM.

4. Specification of Package SYSTEM

-- Copyright 1987, 1988, 1989, 1990 Verdix Corporation

with unsigned_types;package SYSTEM is

pragma suppress(ALL CHECKS);pragma suppress(EXCEPTION_TABLES);pragma not elaborated;

type NAME is ( SUN4 CROSS_68000 );

SYSTEM NAME constant NAME :- SUN4_CROSS_68000;

STORAGE UNIT : constant :. 8;MEMORY SIZE constant :. 16 777 216;

-- System-Dependent Named Numbers

MIN INT : constant :a -2 147 483 648;MAX-INT : constant :. 2 147 483J47;MAX DIGITS : constant :- 15; -

MAX-MANTISSA constant := 31;FINE DELTA : constant :. 2.0**(-31);TICK : constant :F 0.01;

-- Other System-dependent Declarations

subtype PRIORITY is INTEGER range 0 .. 99;

MAX RECSIZE : integer := 64*1024;

type ADDRESS is private;

function ">" (A: ADDRESS; B: ADDRESS) return BOOLEAN;function "<" (A: ADDRESS; B: ADDRESS) return BOOLEAN;function ">="(A: ADDRESS; B: ADDRESS) return BOOLEAN;function "<="(A: ADDRESS; B: ADDRESS) return BOOLEAN;function "-" (A: ADDRESS; B: ADDRESS) return INTEGER;function "+" (A: ADDRESS: I: INTEGER) return ADDRESS;function "-" (A: ADDRESS; I: INTEGER) return ADDRESS;

C-7


function "+" (I: UNSIGNEDTYPES.UNSIGNEDINTEGER) return ADDRESS;function MEMORY ADDRESS

(I: UNSiGNEDTYPES.UNSIGNEDINTEGER) return ADDRESS renames "÷";

NO ADDR : constant ADDRESS;

type TASK ID is private;NO TASKID : constant TASK ID;

type PROGRAM ID is private;NO PROGRAM ID : constant PROGRAM ID;

private

type ADDRESS is new UNSIGNEDTYPES.UNSIGNEDINTEGER;

NO ADDR : constant ADDRESS :. 0;

pragma BUILTIN(">");pragma BUILT IN("<");pragma BUILTIN(">,,");pragma BUILT IN("<-");pragma BUILT IN("-");pragma BUILTIN("+"));

type TASK ID is new UNSIGNED TYPES.UNSIGNEDINTEGER;NO TASK ID : constant TASK ID :. 0;

type PROGRAM ID is new UNSIGNED TYPES.UNSIGNEDINTEGER;NO PROGRAM I1 : constant PROGRAM ID :. 0;

end SYSTEM;

5. Restrictions on Representation Clauses

5.1. Pragma PACK

In the absence of Pragma PACK, record components are paddedso as to provide for efficient access by the targethardware; pragma PACK applied to a record eliminates the pad-ding where possible. Pragma PACK has no other effect on thestorage allocated for record components: a record representa-tion is required.

5.2. Size Clauses

For scalar types, a representation clause 'w.ill pack to thenumber of bits required to represent the range of the sub-type. A size clause applied to a record type v'ill not cause

C-8


packing of components; an explicit record representationclause must be given to specify the packing of the com-ponents. A size clause applied to a record type will causepacking of components only when the component type is adiscrete type. An error vill be issued if there is insuffi-cient space allocated. The SIZE attribute is not supportedfor task, access, or floating point types.

5.3. Address Clauses

Address clauses are only supported for variables. Sincedefault initialization of a variable requires evaluation ofthe variable address, elaboratinn ordering requirementsprohibit initialization of variables which have addressclauses. The specified address indicates the physicaladdress associated with the variable.

5.4. Interrupts

Interrupt entries are not supported.

5.5. Representation Attributes

The ADDRESS attribute is not supported for the followingentities:

PackagesTasksLabelsEntries

5.6. Machine Code Insertions

Machine code insertions are supported.

The general definition of the package MACHINE CODE providesan assembly language interface for the target machine. Itprovides the necessary record type(s) needed in the codestatement, an enumeration type of all the opcode mnemonics,a set of register definitions, and a set of addressing modefunctions.

The general syntax of a machine code sta'emenrt is as fol-

lows:

CODE n'( opcode, operand (. operand );

where n indicates the number of operands in the aggregate.

A special case arises for a variable number -f operands.

C-9


The operands are listed vithin a subaggregate. The formatis as follows:

CODEN'( opcode, (operand (, operand)) );

For those opcodes that require no operands, named notationmust be used (cf. RM 4.3(4)).

CODE 0'( op .> opcode );

The opcode must be an enumeration literal (i.e., it cannot bean object, attribute, or a rename).

An operand can only be an entity defined in MACHINE CODE orthe 'REF attribute.

The arguments to any of the functions defined inMACHINE CODE must be static expressions, string literals, orthe functions defined in MACHINE CODE. The 'REF attributemay not be used as an aegument in any of these functions.

Inline expansion of machine code procedures is supported.

6. Conventions for Implementation-generated Names

There are no implementation-generated names.

7. Interpretation of Expressions in Adlress Clauses

Address expressions in an address clause are interpreted asphysical addresses.

8. Restrictions on Unchecked Conversions

None.

9. Restrictions on Unchecked Deallocations

None.

10. Implementation Characteristics of I/O Packages

Instantiations of DIRECT 10 use the value MAX REC SIZE asthe record size (expressed in STORAGE UNITS) when-the sizeof ELEMENT TYPE exceeds that value. For example, for uncon-strained arrays such as string, where ELEMENT TYPE'SIZE isvery large, MAX REC SIZE is used instead. MAX-RECORD SIZEis defined in SYSTEM and can be changed by a program beforeinstantiating DIRECT 10 to provide an upper limit on therecord size. In any-case, the maximum size supported is 1024x 1024 x STORAGE UNIT bits. DIPECT IO will raise USEERRORif MAXRECSIZE exceeds this absolute limit.

c- 10


Instantiations of 2?"ENTIAL 10 use the value MAX REC SIZEas the record s. o (expressed in STORAGE UNITS)-when thesize of ELEMENT TYPL exceeds that value. For example, forunconstrained arrEys such as string, where ELEMENT TYPE'SIZEis very large, MAX REC SIZE is used instead.MAX RECORD SIZE is definea in-SYSTEM and can be changed by aprogram beTore instantiating INTEGER I0 to provide an upperlimit on the record size. SEQUENTIALEI0 imposes no limit onMAX REC SIZE.

11. Implementation Limits

The following limits are actually enforced by the implemen-tation. It is not intended to imply that resources up to oreven nea these limits are available to every program.

11.1. Line Length

The implementation supports a maximum line length of 500characters including the end of line character.

11.2. Record and Array Sizes

The maximum size of a statically sized array type is4,000,000 x STORAGE UNITS. The maximum size of a staticallysized record type is 4,000,000 x STORAGE UNITS. A recordtype or array type declaration that e~ceeds these limitswill generate a warning message.

11.3. Default Stack Size for Tasks

In the absence of an explicit STORAGE SIZE length specifica-tion, every task except the main program is allocated a fixedsize stack of 10,240 STORAGE UNITS. This is the valuereturned by T'STORAGE SIZE for a task type T.

11.4. Default Collection Size

In the absence of an explicit STORAGE SIZE length attribute,the default collection size for an access type is 100 timesthe size of the designated type. This is the value returnedby T'STORAGE SIZE for an access type T.

11.5. Limit on Declared Objects

There is an absolute limit of 6,000.000 x STORAGE UNITS forobjects declared statically within a compilation unit. Ifthis value is exceeded, the compiler -ill terminate the com-pilation of the unit with a FATAL error message.

C-il

Documents

DU · The following Ada implementation was tested and determined to pass ACVC 1.11. Testing was completed on 29 November 1990. Compiler Name and Version: VADS Sun-4 => 68K, Sun OS