91-03865 - dtic.mil · certificate information the following ada implementation was tested and...

REPORT DOCUMENTATION PAGE FOnApW .Povd

r" urd" wima~~e lst or any oittior asped of thi coaifcn f hEriaticn.hr audi m eto for to" his burwden. to Wet ii

mn A D owb 2 3 3 1 imn Davis Higway. Suke 1204,." on VA222 402.4M and to Uw Office di Itnadon and Pagulawy Aake, Office of

1. A 'T DATE 3 EOTTP N AE OEE

4 TI. --- ,~u ouoii LI: 5. FUNDING NUMBERS

Tartan Inc., Tartan Ada VMS/960MC, Version 4.0, VAXstation 3100 (Host ) to IntelICE960/25 on an VMS 5.2 (Target), 90121211 .11120

6. AUTHOR(S)

IABG-AVFT IOttobrunn, Federal Republic of Germany

7 PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) N-1 --- JL lJ 1t, 8. PERFORMING ORGANIZATION

IABG-AVF, Industrieanlagen-Betriebsgeselschaft itRPRTNMEDept. SZT/ Einsteinstrasse 20 0D-8012 OttobrunnFEDERAL REPUBLIC OF GERMANY9 SPONSORINGMONITORING AGENCY NAME(S) AND ADDRESS( ES) 10. SPONSORING/ONITORING AGENCY

Ada Joint Program Office REPORT NUMBER

United States 'lepartment of DefensePentagon, RmjE1 14'Washington, D.C. 20301-308111. SUPPLEMENTARY NOTES

1 2a. DISTRIBUTIONAVAILABILITY STATEMENT 12b. DISTRIBUTION CODE

Approved for public release; distribution unlimited.

13. ABSTRACT (Maximum 200 words)

Tartan Inc., Tartan Ada VMS/960MC, Version 4.0, Ottobrunn, Germany, VAXstation 3100 (Host) to Intel ICE960/25 on anVMS .2 (Target), ACVC 1. 11.

91-03865

14. SUBJECT TERMS 15. NUMBER OF PAGES

Ada programming language, Ada Compiler Val. Summary Report, Ada Compiler Val. 16.___PRICE __CODE_

Capability, Val. Testing, Ada Val. Office, Ada Val. Facility, ANSI/MIL-STD-1815A, AJPO. 6 RIECO

17. SECURITY CLASSIFICATION 18 SECURITY CLASSIFICATION 19. SECURITY CLASSIFICATION 20. LIMITATION OF ABSTRACTOF REPORT I OF ABSTRACT

UNCLASSIFIED IUNCLASSI FED IUNCLASSIFIED _________

NSN 7540-01-280.550 Standard Form 298. (Rev. 2-89)Prescribed by ANSI Std. 239-128

0 c-14

Certificate Information

The following Ada implementation was tested and determined to pass ACV'-1.11. Testing was completed on December 12, 1990.

Compiler Name and Version: Tartan Ada VMS/960 version 4.0

H-ost Computer System: VAXstation 3100 VMS 5.2

Target Computer System: Intel ICE960/25 on an IntelEXV80960MC board

See Section 3. for any additional information about the testingenvironment.

As a result of this validation effort, validation Certificate90121211.11120 is awarded to Tartan Inc. This certificate expires on1 March, 1993.

This report has been reviewed and is approved.

J,& j -A LIABG, Abt. ITEMichael TonndorfEinsteinstr. 20W-8012 OttobrunnGermany

D, Dietr,I omputer & Software Engineering Division Ad**S2I14 w

Institute for Defense Analyses !' IIAlexandria VA 14231- -0TU

Justif-eto -

Ada Joint Program Office i! ti /Dr. John Solomond, Director .Av~llabilitT, CodesDepartment of Defense . veil anad/erWashington DC 20301 Di st SPsoiel

AVF Control Number: IABG-VSR 0799 January, 1991

== based on TEMPLATE Version 90-08-15 ==

Ada COMPILERVALIDATION SUMMARY REPORT:

Certificate Number: 90121211.11120Tartan Inc.

Tartan Ada VMS/960MC Version 4.0

VAXstation 3100 => Intel ICE960/25 on an

VMS 5.2 Intel EXV80960MC board

Prepared By:

IABG, ABT. ITE

DECLARATION OF CONFORMANCE

Customer: Tartan, l,.

Certificate Awardee: Tartan, Inc.

Ada Validation Facility: IA

ACVC Version: 1. 1

Ada Implementation:

Ada Compiler Name and Version: Tartan Ada VMS/960MC Version 4.0

Host Compiler System: VAXstation 3100 VMS 5.2

Target Computer System: Intel 1CE960/25 on an Intel ,EXV80960MC Board

Declaration:

[I/we] the undersigned, declare that [1/we] have no knowledge of deliberate deviations from theAda Language Standard i.fNSI/MIL-STD-1815A ISO 8652-1987 in the implene 1tation listed above.

(~ ~~~__ _ __ _ Date: 'i .Customer Signature

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 IMPLEMENTA2ION DEPENDENCIES

2.1 WITHDR..AWN 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

CHAPTER 1

TNTRODUCTION

The Ada implementation described above was tested according to. the AdaValidation Procedures [Pro90) 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 (UG89].

1.2 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 identified inthis 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

Question5 regarding this report or the validation test results should bedirezted to the AVF which performea this validation cr to:

Ada Validation OrganizationInstitute for Defense Analyses1801 North Beauregard StreetAlexandria VA 22311

1-!.

INTRODUCTION

1.2 REFERENCES

[Ada83] Reference Manual for the Ada ProqramminQ LanQuage,ANSI/MIL-STD-1815A, February 1983 and ISO 8652-1987.

[Pro90] Ada Comniler Validation Procedures, Version 2.1, Ada JointProgram Office, August 1990.

(UG89] Ada Comoiler 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 compileLoptimizations 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 CHECKFILE is used to check the contents oftext fil.es 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 ofexe'ntable 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 St-andard 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.

:n some tests of the ACVC, cercain 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 between the tests and implementation-dependent characteristics. The modifications required for thisimplementation are described in Section 2.3.

1-2

INTRODUCTION

For each Ada implementation, a customized test suite is produced by the AVF.This customization consists of making the modifications described in thepreceding paragraph, removing withdrawn tests (see Section 2.1) and,possibly some inapplicable tests (see Section 2.2 and (UG89J).

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 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, consisting of one or more computers and

System associated software, that uses common storage for all or partof a program and also for all or part of the data necessaryfor the execution of the program; executes user-written oruser-designated programs; performs user-designated datamanipulation, including arithmetic operations and logic

operations; and that can execute programs that modifythemselves during execution. A computer system may be astand-alone unit or may consist of several inter-connectedunits.

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

1-3

INTRODUCTION

Customer An individual or corpoiate entity who enters into an agreementwith an AVF which specifies the terms and condition, for AVFservices (of any kind) to be performed.

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

which validation status is realized.

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

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

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 or completehardware 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 programmir languaye and of issuing a certificate forthis 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, or containserroneous or illegal use cf the Ada programming language.

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 AVO or the AVF. Thepublication date for this list of withdrawn tests is November 21, 1990.

E28005C B28006C C34006D C35702A B41308B C43004AC45114A C45346A C45612B C45651A C46022A B49008AA74006A C74308A B83022B B83022H B83025B B83025DB83026B B85001L C83026A C83041A C9,116A C98003BBA2011A CB7001A CB7001B CB7004A CC1223A BC1226ACC1226B BC3009B ADlB08A BDlB02B BD1B06A BD2AO2ACD2A21E CD2A23E CD2A32A CD2A41A CD2A41E CD2A87ACD2B15C BD3006A BD4008A CD4022A CD4022D CD4024BCD4024C CD4024D CD4031A CD4051D CD5111A CD7004CED7005D CD7005E AD7006A CD7006E AD7201A AD7201ECD7204B BD8002A BD8004C CD9005A CD9005B CDA201ECE21071 CE2117A CE2117B CE2119B CE2205B CE2405ACE3111C CE3116A CE3118A CE3411B CE3412B CE3607BCE3607C CE3607D CE3812A CE3814A CE3902B

2.2 INAPPLICABLE TESTS

A test is inapplicable if it contains test objectives which are irrelevant

for a given-Ada implementation. Reasons for a test's inapplicability maybe supported by documents issued by !SO 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 159 tests have floating-point type declarations requiring more

digits than SYSTEM.MAXDIGITS:

C241130..Y (11 tests) C357050. .Y (11 tests)C357060..Y (11 tests) C357070. .Y (11 tests)C357080..Y (11 tests) C358020. .Z (12 tests)C1 ,2410..Y (11 tests) C453210. .Y (11 tests)C454210..Y (11 tests) C455210. .Z (12 tests)C455240..Z (12 tests) C456210. .Z (12 tests)C456410..Y (11 tests) C460120. .Z (12 tests)

C35713B, C45423B, B86001T, and C86006H check for the predefined typeSHORTFLOAT.

C45531M. .P (4 tests) and C45532M,.P (4 tests) check fixed-point ooerationsfor types that require a SYSTEM.MAX MANTISSA of 47 or greater; for thisimplementation, there is no such type.

C45536A, C46013B, C46031B, C46033B, and C46034B contain 'SMALLrepresentation clauses which are not powers of two or ten.

C45624A and C45624B are not applicable as MACHINEOVERFLOWS is TRUE forfloating-point types.

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

CA2009A, CA2009C..D (2 tests), CA2009F and BC3009C instantiate generic unitsbefore their bodies are compiled; this implementation creates a dependence ongeneric units as allowed by AI-00408 & AI-00506 such that the compilation ofthe generic unit bodies makes the instantiating units obsolete. (see 2.3.)

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

CD2A53A checks operations of a fixed-point type for which a length clausespecifies a poweL-of-ten type'small; this implementation does not support

decimal smalls. (see 2.3.)

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

CD2B15B checks that STORAGE ERROR is raised when the storage size specifiedfor a collection is too small to hold a single value of the designated type;this implementation allocates more space than what the length clausespecified, as allowed by AI-00558.

The following 264 tests check for sequential, text, and direct access files:

CE2102A..C (3) CE2102G. .H (2) CE2102K CE2102N. .Y (12)CE2103C..D (2) CE2104A..D (4) CE2105A..B (2) CE2106A..B (2)CE2107A..H (8) CE2107L CE2108A..H (8) CE2109A..C (3)

2-2


CE2110A..D (4) CE2111A..I (9) CE2115A..B (2) CE2120A..B (2)

CE2201A..C (3) EE2201D..E (2) CE2201F..N (9) CE2203A

CE2204A..D (4) CE2205A CE2206A CE2208B

CE2401A..C (3) EE2401D CE2401E..F (2) EE2401G

CE2401H..L (5) CE2403A CE2404A..B (2) CE2405B

CE2406A CE2407A..B (2) CE2408A..B (2) CE2409A..B (2)

CE2410A..B (2) CE2411A CE3102A..C (3) CE3102F..H (3)

CE3102J..K (2) CE3103A CE3104A..C (3) CE3106A..B (2)

CE3107B CE3108A..B (2) CE3109A CE311ACE3111A..B (2) CE3111D..E (2, CE3112A..D (4) CE3114A..B (2)CE3115A CE3119A EE3203A EE3204ACE3207A CE3208A CE3301A EE3301BCE3302A CE3304A CE3305A CE3401ACE3402A EE3402B CE3402C..D (2) CE3403A..C (3)

CE3403E..F (2) CE3404B..D (3) CE3405A EE3405BCE3405C..D (2) CE3406A..D (4) CE3407A..C (3) CE3408A..C (3)CE3409A CE3409C..E (3) EE3409F CE3410A

CE3410C..E (3) EE341OF CE3411A CE3411CCE3412A EE3412C CE3413A..C (3) CE3414ACE3602A..D (4) CE3603A CE3604A..B (2) CE3605A..E (5)CE3606A..B (2) CE3704A..F (6) CE3704M..O (3) CE3705A..E (5)CE3706D CE3706F..G (2) CE3804A..P (16) CE3805A..B (2)

CE3806A..B (2) CE3806D..E (2) CE3806G..H (2) CE3904A..B (2)CE3905A..C (3) CE3905L CE3906A..C (3) CE3906E..F (2)

CE2103A, CE2103B and CE3107A require NAMEERROR to be raised when an attemptis made to create a file with an illegal name; this implementation does not

support external files and so raises USEERROR, (see 2.3.)

2.3 TEST MODIFICATIONS

Modifications (see Section 1.3) were required for 114 tests.

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

expected by the original tests.

B22003A B24007A B24009A B25002B B32201A B33204A

B33205A B35701A B36171A B36201A B37101A B37102AB37201A B37202A B37203A B37302A B38003A B38003B

B38008A B38008B B38009A B38009B B38103A B38103B

B38103C B38103D B38103E B43202C B44002A B48002A

B48002B B48002D B48002E B48002G B48003E B49003A

B49005A B49006A B49006B B49007A B49007B B49009A

B4AO10C B54A20A B54A25A B58002A B58002B B59001A

B5900!C B590011 B62006C B67001A B67001B B67001CB67001D B74103E B74104A B74307B B83EOlA B83EO1B

B85007C B85008G B85008H B91004A B91005A B95003AB95007B B95031A B95074E BC1002A BC1109A BC1109C

2-3


BCl206A BC2001E BC3005B BD2AO6A BD2BO3A BD2DO3A

BD4003A BD4006A BD800jA

E28002B was graded inapplicable by Evaluation and Test Modification as

directed by the AVO. This test checks that pragmis may have unresolvable

arguments, and it includes a check that pragma LIST has the required effect;

but for this implementation, pragma LIST has no effect if the compilation

results in errors or warnings, which is the case when the test is processed

without modification. This test was also processed with the pragmas at lines

46, 58, 70 and 71 commented out so that pragma LIST had effect.

Tests C45524A..N (14 tests) were graded passed by Test Modification as

directed by the AVO. These tests expect that a repeated division will result

in zero; but the standard only requires that the result lie in the smallest

safe interval. Thus, the tests were modified to check that the result was

within the smallest safe interval by addi-g the following code after line

141; the modified tests were passed:

ELSIF VAL <= F'SAFE SMALL THEN COMMENT ("UNDERFLOW SEEMS GRADUAL");

C83030C and C86007A were graded passed by Test Modification as directed by

the AVO. These tests were modified by inserting "PRAGMA ELABORATE (REPORT);"

before the package declarations at lines 13 and 11, respectively. Without the

pragma, the packages may be elaborated prior to package report's body, and

thus the packages' calls to function Report. IdentInt at lines 14 and 13,

respectively, will raise PROGRAMERROR.

B83EOlB was graded passed by Evaluation Modification as directed by the AVO.

This test checks that a generic subprogram's formal parameter names (i.e.

both generic and subprogram formal parameter names) viust be distinct; the

duplicated names within the generic declarations are marked as errors,

whereas their recurrences in the subprogram bodies are marked as "optional"

errors--except for the case at line 122, which is marked as an error. This

implementation does not additionally flag the errors in the bodies and thus

the expected error at line 122 is not flagged. The AVO ruled that the

implementation's behavior was acceptable and that the test need not be split

(such a split would simply duplicate the case in B83EOlA at line 15).

CA2009A, CA2009C..D (2 tests), CA2009F and BC3009C were graded inapplicable

by Evaluation Modification as directed by the AVO. These tests instantiate

generic units before those units' bodies are compiled; this implementation

creates dependences as allowed by AI-00408 & AI-00506 such that the

compilation of the generic unit bodies makes the instantiating units

obsolete, and the objectives of these tests cannot be met.

2-4


BC3204C and BC3205D were graded passed by Processing Modification as directedby the AVO. These tests check that instantiations of generic units withunconstrained types as generic actual parameters are illegal if the genericbodies contain uses of the types that require a constraint. However, thegeneric bodies are compiled after the units that contain the instantiations,and this implementation creates a dependence of the instantiating units onthe generic units as allowed by AI-00408 & AI-00506 such that the compilationof the generic bodies makes the instantiating units obsolete--no errors aredetected. The processing of these tests was modified by compiling theseperate files in the following order (to allow re-compilation of obsoleteunits), and all intended errors were then detected by the compiler:

BC3204C: CO, Cl, C2, C3M, C4, C5, C6, C3M

BC3205D: DO, D2, DIM

BC3204D and BC3205C were graded passed by Test Modification as directed bythe AVO. These tests are similar to BC3204C and BC3205D above, except thatall compilation units are contained in a single compilation. For these twotests, a copy of the main procedure (which later units make obsolete) wasappended to the tests; all expected errors were then detected.

CD2A53A was graded inapplicable by Evaluation Modification as directed by theAVO. The test contains a specification of a power-of-ten value as small fora fixed-point type. The AVO ruled that, under ACVC 1.11, support of decimalsmalls may be omitted.

AD9001B and AD9004A were graded passed by Processing Modification as directedby the AVO. These tests check that various subprograms may be interfaced toexternal routines (and hence have no Ada bodies). This implementationrequires that a file specification exists for the foreign subprogram bodies.The following command was issued to the Librarian to inform it that theforeign bodies will be supplied at link time (as the bodies are not actuallyneeded by the program, this command alone is sufficient:

AL960> interface/system AD9004A

CE2103A, CE2i03B and CE3107A were graded inapplicable by EvaluationModification as directed by the AVO. The tests abort with an unhandledexception when USEERROR is raised on the attempt to create an external file.This is acceptable behavior because this implementation does not supportexternal f.les (cf. AI-00332).

2-5

CHAPTER 3

PROCESSING INFORMATION

3.1 TESTING ENVIRONMENT

The Ada implementation tested in this validation effort is describedadequately by the information given in the initial pages of this report.

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

Mr Ron DuursmaDirector of Ada Products

Tartan Inc.300, Oxford Drive,Monroeville, PA 15146,USA.Tel. (412) 856-3600

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

Mr Bill GeeseDirector of Sales

Tartan Inc.300, Oxford Drive,Monroeville, PA 15146,USA.Tel. (412) 856-3600

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 with the Ada ProgrammingLanguage Standard, whether the test is applicable or inapplicable;otherwise, the Ada Implementation fails the ACVC (Pro90].

3-1


For all processed tests (inapplicable and applicable), a result was

obtained that conforms to the Ada Programming Language Standard.

a) Total Number of Applicable Tests 3628

b) Total Number of Withdrawn Tests 83

c) Processed Inapplicable Tests 36

d) Non-Processed I/O Tests 264

e) Non-Processed Floating-Point

Precision Tests 159

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

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

The above number of I/O tests were not processed because this implementationdoes not support a file system. The above number of floating-point tests werenot processed because they used floating-point precision exceeding that

supported 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 2.1 had been withdrawn because of testerrors. The AVF determined that 459 tests were inapplicable to thisimplementation. All inapplicable tests were processed during validationtesting except for 159 executable tests that use floating-point precisionexceeding that supported by the implementation and 264 executable tests thatuse file operations not supported by the implementation. In addition, themodified tests mentioned in Section. 2.3 were also processed.

A Magnetic Tape Reel containing the customized test suite (see Section 1.3)was taken on-site by the validation team for processing. The contents of the

tape were loaded directly onto the host computer.

After the test files were loaded onto the host computer, the full set of

tests was processed by the Ada implementation.

The tests were compiled and linked on the host computer system, as

appropriate. The executable images were transferred to the target computersystem by the cornmunications link, an RS232 interface, 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. The options invoked explicitly for validation testingduring this test were:

3-2


options used for compilingf

/replace forces the compiler to accept an attempt to compile a unitimported from another library which is normally prohibited.

/nosive source suppresses the creation of a registered copy of the sourcecode in the library directory for use by the REMAKE and MAKEsubcommands.

/list=always forces a listing to be produced, default is to only producea listing when an error occurs.

No explicit Linker options were used.

Test output, compiler and linker listings, and job logs were captured onMagnetic Tape Reel and archived at the AVF. The listings examined on-site bythe validation team were 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 (UG89]. Theparameter values are presented in two tables. The first table lists thevalues that are defined in terms of the maximum input-line length, which isthe value for $MAX IN LEN--also listed here. These values are expressed

here as Ada string aggregates, where "V"I represents the maximum input-line

length.

Macro Parameter Macro Value

SBIGIDI (1..V-I => 'A', V => '1')

$BIGID2 (. .V-1 => 'A', V => '2')

-BIGiD3 (1..V/2 => 'A') & '3' &(1..V-l-V/2 => 'A')

SBIGID4 (1..V/2 => 'A') & '4' &(1..V-!-V/2 => 'A')

SBIGINTLIT (1..V-3 => '0') & "298"

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

$BIGSTRINGI '"' & (1..V/2 => 'A') & '"'

$BIGSTRING2 '"' & (I..V-1-V/2 => 'A') & 'I' & '"'

$BLANKS (1..V-20 => '

$MAXLENINT BASED LITERAL"2:" & (l..V-5 => '0') & "I1:"

SMAXLENREALBASED LITERAL"16:" & (1..V-7 => '0') & "F.E:"

$MAXSTRING LITERAL '"' & (1..V-2 => 'A') & '"'

A-1

MACRO PARAMETERS

The following table lists all of the other macro parameters and theirrespe'-.tive values.

Macro Parameter Macro Value

SMAXINLEN 240

SACCSIZE 32

$ALIGNMENT 4

$COUNTLAST 2147483646

$DEFAULT MEMSIZE 2097152

$DEFAULTSTORUNIT 8

SDEFAULTSY3 -NAME 1960MC

$DELTADOC 2#1.0#E-31

SENTRYADDRESS SYSTEM.ADDRESS' (16#0000_00C8#)

$ENTRYADDRESS1 SYSTEM.ADDRESS' (16#0000_00C9#)

SENTRYADDRESS2 SYSTEM.ADDRESS' (16#0000_0OCA#)

$FIELDLAST 20

$FILETERMINATOR J

SFIXEDNAME NOSUCHTYPE

$FLOATNAME EXTENDEDFLOAT

$FORNSTRING i$

$FORMSTRING2 "CANNOTRESTRICTFILECAPACITY"I

$GREATERTHANDURATION

100_000.0

$GREATERTHANDURATION-2-ASELAST

1oo0ooo000.0

$GREATERTHA?4_FLOATBASELAST

1. 80141E+38

SGREATERTHANFLOATSAFELARGE

1.OE+38

A-2

MACRO PARAMETERS

$GREATERTHANSHORTFLOATSAFELARGE1. OE+38

$HIGH-PRIORITY 17

S ILLEGALEXTERNALFILENAME1

ILLEGALEXTERNALFILENAME1

$ILLEGALEXTERNALFILENAME2

ILLEGALEXTERNALFILENAME2

$ INAPPROPRIATE LINE LENGTH

-1.

S INAPPROPRIATEPAGELENGTH-1

$INCLUDEPRAGMAI "PRAGMA INCLUDE ("A28006D1 .TST")"

$INCLUDEPRAGMA2 "PRAGMA INCLUDE ("B28006F1.TST")'

$INTEGERFIRST -2147483648

$INTEGERLAST 2147483647

SINTEGERLASTPLUS_1 2147483648

$INTERFACELANGUAGE UseCall

SLESSTHANDURATION -100_000.0

$LESSTHANDURATIONBASEFIRST

-100_000_000.0

SLINETERMINATOR I

SLOWPRIORITY 2

$MACHINECODESTATEMENT

TwoFormat' (MOV, (Reg_Lit,5), (Reg,R5));

SMACHINECODETYPE Mnemonic

$MAhNTISSA DOC 31

S$4AXDIGITS 18

SMAXINT 9223372036854775807

SMAXINTPLUS_1 9223372036854775808

$MIN INT -9223372036854775808

A-- 3

MACRO PARAMETERS

$NAME BYTEINTE'SER

$NA14ELIST I960MC

$NAMESPECIFICATIONi DUA2: EACVC11. 960MC.TESTBEDJX212OA. ;l

SNAMESPECIFICATION2 DUA2: (ACVC11.96OMC.TESTBED)X2120B. ;2

$NAMESPECIFICATION3 DUA2: (ACVC11.960MC.TESTBED]X3119A.;1

SNEGBASF.DINT 16#FFFFFFFFFFFFFFFE#

$NEWMEMSIZE 20S 7152

$NEWSTORUNIT 8

SNEWSYSNAME 1960MC

$PAGETERMINATOR r

SRECORDDEFINITION record Operation: Mnemonic;

Operand_-1: Operand; Operand-2: Operand;

end record;

$RECORDNAME TwoFormat

STASKSIZE 32

$TASKSTORAGESIZE 4096

$TICK 0.015625

$VARIABLEADDRESS SYSTEM.ADDRESS' (16*0000_1000*)

$VARIABLEADDRESS1 SYSTEM.ADDRESS' (16*0000_1004#)

SVARIABLE -ADDRESS2 SYSTEM.ADDRESS' (16*0000_1008*)

$YOURPRAGMA NOSUCHPRAGMA

A- 4

APPENDIX B

COMPILATION SYSTEM OPTIONS

The compiler options of this Ada implementation, as described in thisAppendix, are provided by the customer, Unless specifically noted otherwise,references in this appendix are to compiler documentation and not to thisreport.

B-1

Compilation switches for Tartan Ada VMS 960.

/960MC Invoke the 80960MC-targeted cross compiler.This qualifier is mandatory to invoke the80960MC-targeted compiler.

/CALLS[=option] Controls the type of calls generated by thecompiler through the option supplied. Theavailable options are:

SHORT Generate all short calls in thecompiled code. Inappropriate useof this switch will cause a failureat link time.

LONG Generate all long calls in thecompiled code.

MIXED Generate short calls within ap-plication code and long calls fromapplications to runtime routines.This option is the default.

/DEBUG/NODEBUG [default] Controls whether debugging information is

included in the object code file. It is notnecessary for all object modules to includedebugging information to obtain a linkable,image, but use of this qualifier isencouraged for all compilations. Nosignificant execution-time penalty is in-curred with this qualifier.

/ERRORLIMIT=n Stop compilation and produce a listing aftern errors are encountered, where n is in therange 0..255. The default value for n is255. The /ERRORLIMIT qualifier cannot benegated.

/FIXUP=[option) When package MACHINECODE is used, controlswhether the compiler attempts to alteroperand address modes when those addressmodes are used incorrectly. The availableoptions are:

QUIET The compiler attempts to generateextra instructions to fix incorrectaddress modes in the array ag-gregates operand field.

WARN The compiler attempts to generateextra instructions to fix incorrectaddress modes. A warning messageis issued if such a ''fixup'' is

2

required.NONE The compiler does not attempt to

fix any machine code insertion thathas incorrect address modes. Anerror message is issued for anymachine code insertion that isincorrect.

WheD no form of this qualifier is supplied inthe co-and line, the default condition is/FIXUP=QUIET. For more infoimation onmachine code insertions, refer to section5.10 of this manual.

/LIBRARY=ibrary-name Specifies the library into which the file isto be compiled. The compiler reads anyADALIB. INI files in the default directory.

/LIST [=option]/NOLIST Controls whether a listing file is produced.

If produced, the file has the source filename and a .LIS .-tension. The availableoptions are:

ALWAYS Always produce a listingfile

NEVER Never produce a listingfile, equi'xalent to /NOLIST

ERROR Produce a listing file onlyif a compilation error orwarning occurs

When no form of this qualifier is supplied inthe comand line, the default condition is/LIST=ERROR. When the LIS11 qualifier issupplied without an option, the defaultoption is ALWAYS.

/MACHINECODE [=option]Controls whether the compiler produces anassembly code file in addition to an objectfile, which is always generated. Theassembly code file is not intended to beinput to an assembler, but serves asdocumentation only. The available optionsare:

NONE Do not produce anassembly code file.

INTERLEAVE Produce an assemblycode file which in-terleaves source codewith the machine code(see Section 4.5.4).

3

Ada source appears asassembly languagecomments.

NOINTERLEAVE Produce an assemblycode file withoutinterleaving.

When no form of this qualifier is supplied inthe command line, the default option is NONE.Specifying the MACHINE CODE qualifier withoutan option is equivalent to supplying/MACHINECODE=NOINTERLEAVE.

/NOENUMIMAGE Causes the compiler to omit data segmentswith the text of enumeration literals. Thistext is normally produced for exportedenumeration types in order to support thetext attributes ('IMAGE, 'VALUE and 'WIDTH).You should use /NOENUMIMAGE only when you canguarantee that no unit that will import theenumeration type will use any of its textattributes. However, if you are compiling aunit with an enumeration type that is notvisible to other compilation units, thisqualifier is not needed. The compiler canrecognize when the text attributes are notused and will not generate the supportingstrings .The /NOENUMIMAGE qualifier cannot benegated.

/OPT-n Controls the level of optimization performedby the compiler, requested by n. The /OPTqualifier cannot be negated. The optimiza-tion levels available are:

n = 0 Minimum - Performs contextdetermination, constantfolding, algebraic manipula-tion, and short circuitanalysis. Inlines are notexpanded.

n = 1 Low - Performs level 0optimizations plus commonsubexpression eliminationand equivalence propagationwithin basic blocks. Italso optimizes evaluationorder. Inlines are notexpanded.

n = 2 Best tradeoff for space/time- the default level. Per-forms level . optimizationsplus flow analysis which is

4

used for comon subexpres-sion elimination and equiv-alence propagation acrossbasic blocks. It alsoperforms invariant expres-sion hoisting, dead codeelimination, and assignmentkilling. Level 2 alsoperforms lifetime analysisto improve register alloca-tion. It also performsinline expansion of sub-'program calls indicated byPragma INLINE, if possible.

n =3 Time - Performs level 2optimizations plus inlineexpansion of subprogramcalls which the optimizerdecides are profitable toexpand (from an executiontime perspective). Otheroptimizations which improveexecution time at a cost toimage size are performedonly at this level.

n = 4 Space - Performs thoseoptimizations which usutllyproduce the smallest code,often at the expense ofspeed. This optimizationlevel may not always producethe smallest code, however,another level may producesmaller code under certainconditions.

/PHASES/NOPHASES [default] Controls whether the compiler announces each

phase of processing as it occurs. Thesephases indicate progress of the compilation.If there is an error in compilation, theerror message will direct users to a specificlocation as opposed to the more general/PHASES.

/RECOMPILESYSTEM Causes the compiler to accept non-Ada input,necessary to replace package SYSTEM. Thisqualifier should not be used for compilinguser-defined packages containing illegalcode. Changes of package SYSTEM must fullyconform to the requirements stated in ARM 4-513.7 and 13.7.1, and must not change the

5

given definition of type ADDRESS, in order topreserve validatability of the Ada system.

/REFINE/NOREFINE [default] Controls whether the compiler, when compiling

a library unit, determines whether the unitis a refinement of its previous verrion and,if so, does not make dependent unitsobsolete. The default is /NOREFINE.

/REPLACE Forces the compiler to accept an attempt tocompile a unit imported from another librarywhich is normally prohibited.

/SAVESOURCE [default]/NOSAVE_SOURCE Suppresses the creation of a registered copy

of the source code in the library directoryfor use by the REMAKE and MAKE subcommands toAL960.

/SUPPRESS[=(option, ... )]Suppresses the specific checks identified bythe options supplied. The parentheses may beomitted if only one option is supplied. Ifcontradictory options are specified (e.g./SUPPRESS= (NONE, OVERFLOWCHECK), the optionsthat are given last will override previousones. The absence of the /SUPPRESS qualifieron the cound line is equivalent to/SUPPRESS=NONE.

The available options are:

ALL Suppress allchecks. Thisis the defaultif thequalifier issupplied withno option.

ACCESS_CHECK As spo- " ied inthe Ad. LRM,Section 11.7.

CONSTRAINTCHECK Equivalent c5(ACCESS-CHECK,INDEX CHECK,DISCRIMINANT_CHECK,LENGTHCHECK,RANGE_C HECK).

DISCRIMIZANTCHECK As specified in

6

the Ada LRM,Section 11.7.

DIMSION CHECK Because the80960MC detectsdivision byzero, code forthis purpose isnot generatedby the com-piler. There-fore, thisqualifier hasno effect.

ELABORATIONCHECK As specified inthe Ada LRM,Section 11.7.

INDEXCHECK As specified inthe Ada LRM,Section 11 7.

LENGTHCHECK As specified inthe Ada LRM,Section 11.7.

NONE No checks aresuppressed.This is thedefault if thequalifier isnot supplied onthe commandline.

OVERFLOW CHECK Because the80960MC detectsoverflow, codefor this pur-pose is notgenerated bythe compiler.Therefore, thisqualifier hasno effect.

RANGE-CHECK As specified inthe Ada LRM,Section 11.7.

STORAGECHECK As specified inthe Ada LRM,Section 11.7.Suppresses onlystack checks ingenerated code,

7

not the checksmade'by theallocator as aresult of a newoperation.

/SYNTAXONLY Parses a unit and reports syntax errors, thenstops compilation without entering a unit inthe library.

/WARNINGS (default]/NOWARNINGS Controls whether the warning messages

generated by the compiler are displayed tothe user at the terminal and in a listingfile, if produced. While supresc'ng warningmessages also halts display of informationalmessages, it does not suppress Error,FatalError.

/WAITSTATES=n Defines the memory waitstates of the targetfor the compiler. The default value is 0.

LINKER OPTIONS

The linker options of this Ada implementation, as described in this Appendix,

are provided by the customer. Unless specifically noted otherwise,

references in this appendix are to linker documentation and not to this

report.

B-2

Linker switches for VMS hosted Tartan Ada compilers.

COMMAND QUALIFIERS

This section describes the command qualifiers available to a user who directlyinvokes the linker. The qualifier names can be abbreviated to uniqueprefixes; the first letter is sufficent for all cuurent qualifier names. Thequalifier names are not case sensitive.

/CONTROL=file The specified file contains linker control conmands.Only one such file may be specified, but it caninclude other files using the CONTROL command. Everyinvocation of the linker must specify a control file.

/OUTPUT=file The specified file is the name of the first outputobject file. The module name for this file will benull. Only one output file may be specified in thismanner. Additional output files may be specified inthe linker control file.

/ALLOCATIONS Produce a link map showing the section allocations.

/UNUSEDSECTIONS Produce a link map showing the unused sections.

/SYMBOLS Produce a link map showing global and externalsymbols.

/RESOLVEMODULES This causes the linker to not perform unused sectionelimination. Specifying this option will generallymake your program larger, since unreferenced datawithin object files will not be eliminated. Refer toSections RESOLVE CMD and USEPROCESSING for infor-mation on the way that unused section eliminationworks.

/MAP Produce a link map containing all information exceptthe unused section listings.

Note that several listing options are permitted. This is because link mapsfor real systems can become rather large, and writing them consumes asignificant : raction of the total link time. Options specifying the contentsof the link map can be combined, in which case the resulting map will containall the information specified by any of the switches. The name of the filecontaining the link map is specified by the LIST comand in the linker controlfile. If your control file does not specify a name and you request a listing,the listing will be written to the default output stream.

APPENDIX C

APPENDIX F OF THE Ada STANDARD

The only allowed implementation dependencies correspond to implementation-

dependent pragmas, to certain machine-dependent conventions as mentioned in

Chapter 13 of the Ada Standard, and to certain allowed restrictions on

representation clauses. The implementation-dependent characteristics 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 this report. Implementation-

specific portions of the package STANDARD, which are not a part of Appendix

F, are:

package STANDARD is

type BYTEINTEGER is range -128 .. 127;

type SHORTINTEGER is range -32768 .. 32767;

type INTEGER is range -2147483648 .. 2147483647;

type LONG-INTEGER is range -9223372036854775808 . 9223372036854775807;

type FLOAT . is digits 6 range-2#i.!Iiiiiiiiiiiiiiiiiiili#e126 .. 2#I.iiiiiiiiiii1iiiii1iiiii#e126;

type LONGFLOAT is digits 15 range-2#!.l!l11l1l1l1llllllllilliillllllillllllll1l!!ll1#e1022 .

2#1.!.IiiiiiiiiiilllAiiiliiiiiiilliiiii!!I!II#ei022;

type EXTENDEDFLOAT is digits 18 range-2#I.Iili-Iilliiliii1ii1i11iIII1i1iI1i1li'iIliliiIIliIli!IIliiIIliI#e16382 .

2#!.*!ii!I1II1i_!!iii!!iiiiiiiiiiiiiiiiiiiiiiiiiiii!Iii1.11iiiiiliiii#e16382;

type DURATION is delta 0.0001 range -86400.0 .. 86400.0;

..........

end STANDARD;

C-I

Chapter 5Appendix F to MIL-STD-1815A

This chapter contains the required Appendix F to the LRM which is Military Standard, Ada ProgrammingLanguage, ANSI/MIL-STD-1815A (American National Standards Institute, Inc., February 17, 1983).

5.1. PRAGMAS

5.1.1. Predefined PragmasThis section summarizes the effects of and restrictions on predefined pragmas.

* Access collections are not subject to automatic storage reclamation so pragma CONTROLLED has no effect.Space deallocated by means of UNCHECKEDDEALLOCATION will be reused by the allocation of newobjects.

* Pragna ELABORATE is supported.

* Pragma INLINE is supported.* Pragma INTERFACE is supported. A particular Ada calling sequence is associated with a subprogram

whose implementation is provided in the form of an object code module. LanguageName may beeither useCall or Use Bal as described in Section 5.1.2.2. Any other LanguageName will beaccepted, but ignored, and the default, UseCall will be used.

* Pragma LIST is supported but has the intended effect only if the command qualifier LIST=ALWAYS wassupplied for compilation, and the listing generated was not due to the presence of errors and/or warnings.

* Pragma MEMORYSIZE is accepted but no value other than that specified in Package SYSTEM (Section5.3) is allowed.

* Pragma OPTIMIZE is supported, but on a subprogram basis only. It does not affect code at the blocklevel.

" Pragma PACK is supported.

" Pragma PAGE is supported but has the intended effect only if the command qualifier LIST=ALWAYS wassupplied for compilation, and the listing generated was not due to the presence of errors and/or warnings.

" Pragma PRIORITY is supported." Pragma STORAGEUNIT is accepted but no value other than that specified in Package SYSTEM (Section

5.3) is allowed.

" Pragma SHARED is not supported. No warning is issued if it is supplied.

" Pragma SUPPRESS is supported.

" Pragma SYSTEM-NAME is accepted but no value other than that specified in Package SYSTEM (Section5.3) is allowed.

USER MANUAL FOR TARTAN ADA VMS 960

5.1.2. Implementation-Defined PragmasImplementation-d-tfined pragmas provided by Tartan are described in the following sections.

5.12.1. Pragma LINKAGENAME

The pragma LINKAGE NAME associates an Ada entity with a string that is meaningful externally; e.g., to alinkage editor. It takes the form

pragma LINKAGENAME (Ada-simple-name, string-constant)The Ada-simple-name must be the name of an Ada entity declared in a package specification. This entity must beone that has a runtime representation; e.g., a subprogram, exception or object. It may not be a named number orstring constant. The pragma must appear after the declaration of the entity in the same package specification.

The effect of the pragma is to cause the string-constant to be used in the generated assembly code as anexternal name for the associated Ada entity. It is the responsibility of the user to guarantee that this stringconstant is meaningful to the linkage editor and that no illegal linkname clashes arise.

This pragma has no effect when applied to a library subprogram or to a renames declaration; in the latter case,no warning message is given.

When determining the maximum allowable length for the external linkage name, keuep in mind that thecompiler will generate names for elaboration flags simply by appending the suffix #GOTO. Therefore, theexternal linkage name hae5 fewer significant characters than the lower limit of other tools that need to processthe name (e.g., 40 in the case of the Tartan Linker).

5.1.2.2. Pragma FOREIGNBODY

In addition to Pragma INTERFACE, Tartan Ada supplies Pragma FOREIGNBODY as a way to accesssubprograms in other languages.

Unlike Pragma INTERFACE, Pragma FOREIGNBODY allows access to objects and exceptions (in additionto subprograms) to and from other languages.

Some restrictions on Pragma FOREIGNBODY that are not applicable to Pragma INTERFACE are:

" Pragma FOREIGNBODY must appear in a non-generic library package." All objects, exceptions and subprograms in such a package must be supplied by a foreign object module." Types may not be declared in such a package.

Use of the pragma FOREIGN BODY dictates that all subprograms, exceptions and objects in the package areprovided by means of a foreign object module. I- order to successfully link a program including a foreign body,the object module for that body must be provided to the library using the AL960 FOREIGN command describedin sections 3.3.3 and 13.5.5. The pragma is of the form:

pragma FOREIGN._BODY (Languagename C, elaboration routine name])The parameter Language name is a string intended to allow the compiler to identify the calling convention usedby the foreign module (but this functionality is not yet in operation). Currently, the programmer must ensure thatthe calling convention and data representation of the foreign body procedures are compatible with those used bythe Tartan Ada compiler. Subprograms called by tasks should be reentrant.

The optional elaboration routinename string argument is a linkage name identifying a routine to initializethe package. The routine specified as the elaboration routine name, which will be called for the elaboration ofthis package body, must be a gloual routine in the object module provided by the user.

A specification that uses this pragma may contain only subprogram declarations, object decarations that usean unconstrained type mark, and number declarations. Pragmas may also appear in the package. The type markfor an object cannot be a task type, and the object declaration must not have an initial value expression. Thepragma must be given prior to any declarations within the package specification. If the pragma is not locatedbefore the first declaration, or any restriction on the declarations is violated, the pragma is ignored and a warningis generated.

APPENDIX F TO MIL-STD-1815A

The foreigr body is entirely responsible for initializing objects declared in a package utilizing pragmaFOREIGNBODY. In particular, the user should be aware that the implicit initializations described in LRM 3.2.1are not done by the compiler. (These implicit initializations are associated with objects of access types, certainrecord types and composite types containing components of the preceding kinds of types.)

Pragma LINKAGENAME should be used for all declarations in the package, including any declarations in anested package specification to be sure that there are no conflicting link names.

In the following example, we want to call a function plmn which computes polynomials and is written in C.package MATH FUNCTIONS is

pragma FOREIGN BODY ("C");function POLYNOMIAL (X: INTEGER) return INTEGER;

--Ada spec matching the C routinepragma LINKAGENAME (POLYNOMIAL, "plmn");

--Force compiler to use name "plmn" when referring to this-- function

end MATHFUNCTIONS;

with MATH FUNCTIONS; use MATHFUNCTIONS;procedure MAIN is

X:INTEGER :-- POLYNOMIAL(i0);-- Will generate a call to "plmn"

begin ...end MAIN;

To compile, link and run the above program, you do the following steps:

1. Compile MATH_FUNCTIONS

2. Compile MAIN

3. Obtain an object module (e.g. math. TOF) containing the compiled code for plmn.4. Issue the command

AL960 FOREIGNBODY math-functions MATH.TOF

5. Issue the command

AL960 LINK MAIN

Without Step 4, an attempt to link will produce an error message informing you of a missing package body forMATHFUNCTIONS.

Using an Ada body from another Ada program library. The user may compile a body written in Ada for aspecification into the library, regardless of the language specified in the pragma contained in the specification.This capability is useful for rapid prototyping, where an Ada package may serve to provide a simulated responsefor the functionality that a foreign body may eventually produce. It also allows the user to replace a foreign bodywith an Ada body without recompiling the specification.

The user can either compile an Ada body into the library, or use the command AL960 FOREIGN (seeSections 3.3.3 and 13.5.5) to use an Ada body from another library. The Ada body from another library musthave been compiled under an identical specification. The pragma LINKAGE NAME must have been applied toall entities declared in the specification. The only way to specify the linkname for the elaboration routine of anAda body is with the pragma FOREIGNBODY.

5.1.2.3. Pragma INTERFACE

The pragma INTERFACE associates a particular Tartan Ada calling sequence with a subprogram whoseimplementation is provided in the form of an object code module.

The form of the pragma is:pragma INTERFACE (Language-Name, SubprogramName)


Language Name may be either UseCall or UseBal as described in Section 5.1.2.2. Any otherLanguage Name will be accepted, but ignored, and the default, UseCall will be used.

While the BAL calling convention is faster than the standard calling convention, be aware that BAL must beused carefully. In particular, when a routine is called with BAL:

* No new stack frame is allocated. This means that the called routine must not change the stack pointer, ormust at least ensure that the stack pointer is restored before the routine returns.

* No new local registers are allocated.

* The called routine must return via a bx (reg) instruction. The BAL instruction will automatically storethe return address in register g14.

* If a called routine has more than 12 words worth of parameters, the compiler will store the argument blockpointer in g14. Since the BAL instruction will place the return address in g14, the called routine couldfind that its argument block pointer has been trashed.

Please see Chapter 6 for a complete list of BAL calling convention restiictions.

5.2. IMPLEMENTA TION-DEPENDENT ATTRIBUTESNo implementation-dependent attributes are currently supported.

5.3. SPECIFICATION OF THE PACKAGE SYSTEMThe parameter values specified for the 80960MC in package SYSTEM [LRM 13.7.1 and Appendix C] are:

package SYSTEM istype ADDRESS is new Integer;type NAME is (1960MC);

SYSTEM NAME : constant name :- 1960MC;STORAGE UNIT : constant : 8;MEMORYSIZE : constant 2_097_152;

MAXINT : constant 9_223_372_036_854_775_807;MININT : constant := -MAXINT - 1;

MAXDIGITS : constant := 18;

MAXMANTISSA : constant 31;FINE DELTA : constant 2#1.0#e-31;TICK : constant 0.015625;subtype PRIORITY is INTEGER range 2 .. 17;DEFAULT PRIORITY constant PRIORITY := PRIORITY'FIRST;RUNTIME ERROR exception;

end SYSTEM;

5.4. RFSTRICTIONS ON REPRESENTATION CLAUSESThe following sections explain the basic restrictions for representation specifications followed by additional

restrictions applying to specific kinds of clauses.

5.4.1. Basic RestrictionThe basic restriction on representation specifications [LRM 13.1] is that they may be given only for types

declared in terms of a type definition, excluding a generic typedefinition (LRM 12.1) and aprivatetypedefinition (LRM 7.4). Any representation clause in violation of these rules is not obeyedby the compiler, an error message is issued.


Further restrictions are explained in the following :;ections. Any representation clauses violating those restric-tions cause compilation to stop and a diagnostic message to be issued.

5.4.2. Length Clauses

Length clauses [LRM 13.2] are, in general, supported. For details, refer to the following sections.

5.4.2.1. Size Specifications for Types

The rules and restrictions for size specifications applied to types of various classes are described below.

The following principle rules apply:

L. The size is specified in bits and must be given by a static expression.

2. The specified size is taken as a mandate to store objects of the type in the given size wherever feasible.No attempt is made to store values of the type in a smaller size, even if possible. The following rulesapply with regard to feasibility:

An object that is not a component of a composite object is allocated with a size and alignment thatis referable on the target machine; that is, no attempt is made to create objects of non-referable sizeon the stack. If such stack compression is desired, it can be achieved by the user by combiningmultiple stack variables in a composite object; for example

type MyEnum is (A,B);for Myenum' size use 1;V,W: My_enum; -- will occupy two storage

-- units on the stack-- (if allocated at all)

type rec is recordV,W: Myenum;

end record;pragma Pack(rec);0: rec; -- will occupy one storage unit

* A formal parameter of the type is sized according to calling conventions rather than sizespecifications of the type. Appropriate size conversions upon parameter passing take placeautomatically and are transparent to the user.

* Adjacent bits to an object that is a component of a composite object, but whose size isnon-referable, may be affected by assignments to the object, unless these bits are occupied by othercomponents of the composite object; that is, whenever possible, a component of non-referable sizeis made referable.

In all cases, the compiler generates correct code for all operations on objects of the type, even if they arestored with differing representational sizes in different contexts.

Note: A size specification cannot be used to force a certain size in value operations of the type; forexample

type my_int is range 0..65535;for my_ant'size use 16; -- o.k.A,B: my-int;

.A + B... -- this operation will generally be-- executed on 32-bit values

3. A size specification for a type specifies the size for objects of this type and of all its subtypes. Forcomponents of composite types, whose subtype would allow a shorter representation of the component,no attempt is made to take advantage of such shorter representations. In contrast, for types without alength clause, such components may be represented in a lesser number of bits than the number of bitsrequired to represent all values of the type. Thus, in the example


type MY INT is range 0..2**15-1;for MY INT'SIZE use 16; -- (1)subtype SMALL MY INT is MYINT range 0..255;type R is record

X: SMALLMYINT;

end record;

the component R. X will occupy 16 bits. In the absence of the length clause at (1), R. X may berepresented in 8 bits.

Size specifications for access types must coincide with the default size chosen by the compiler for the type.

Size specifications are not supported for floating-point types or task types.

5.42.2. Size Specification for Scalar Types

The specified size must accommodate all possible values of the type including the value 0 (even if 0 is not inthe range of the values of the type). For numeric types with negative values the number of bits must account forthe sign bit. No skewing of the representation is attempted. Thus

type myint is range 100..101;

requires at least 7 bits, although it has only two values, while

type my_nt is range -101..-100;

requires 8 bits to account for the sign bit.

A size specification for a real type does not affect the accuracy of operations on the type. Such influenceshould be exerted via the accuracy._definition of the type (LRM 3.5.7, 3.5.9).

A size specification for a scalar type may not specify a size larger than the largest operation size supported bythe target architecture for the respective class of values of the type.

5.42.3. Size Specifwationfor Array Types

A size specification for an array type must be large enough to accommodate all components of the array underthe densest packing strategy. Any alignment constraints on the component type (see Section 5.4.7) must be met.

The size of the component type cannot be influenced by a length clause for an array. Within the limits ofrepresenting all possible values of the component subtype (but not necessarily of its type), the representation ofcomponents may, however, be reduced to the minimum number of bits, unless the component type carries a sizespecification.

If there is a size specification for the component type, but not for the array type, the component size isrounded up to a referable size, unless pragma PACK is given. This applies even to boolean types or other typesthat require only a single bit for the representation of all values.

5.42.4. Size Specification for Record Types

A size specification for a record type does not influence the default type mapping of a record type. The sizemust be at least as large as the number of bits determined by type mapping. Influence over packing of com-ponents can be exerted by means of (partial) record representation clauses or by Pragma PACK.

Neither the size of component types, nor the representation of component subtypes can be influenced by alength clause for a record.

The only implementation-dependent components allocated by Tartan Ada in records contain dope informationfor arrays whose bounds depend on discriminants of the record or contain relative offsets of components within arecord layout for record components of dynamic size. These implementation-dependent components cannot benamed or sized by the user.


A size specification cannot be applied to a record type with components of dynamically determined size.

Note: Size specifications for records can be used only to widen the representation accomplished by padding atthe beginning or end of the record. Any narrowing of the representation over default type mapping must beaccomplished by representation clauses or pragnm PACK.

5.4.2.5. Specification of Collection SizesThe specificat 3n of a collection size causes the collection to be allocated with the specified size. It is

expressed in storage units and need not be static; refer to package SYSTEM for the meaning of storage units.

Any attempt to allocate more objects than the collection can hold causes a STORAGEERROR exception to beraised. Dynamically sized records or arrays may carry hidden administrative storage requirements that must beaccounted for as part of the collection size. Moreover, alignment constraints on the type of the allocated objectsmay make it impossible to use all memory locations of the allocated collection. No matter what the requestedobject size, the allocator must allocate a minimum of 2 words per object. This lower limit is necessary foradministrative overhead in the allocator. For example, a request of 5 words results in an allocation of 5 words; arequest of 1 word results in an allocation of 2 words.

Furthermore, the allocator must round non-word sized requests up to the nearest word. For example, arequest of 11 bytes is rounded up to 12 bytes (3 words).

In the absence of a specification of a collection size, the collection is extended automatically if more objectsare allocated than possible in the collection originally allocated with the compiler-established default size. In thiscase, STORAGEERROR is raised only when the available target memory is exhausted. If a collection size ofzero is specified, no access collection is allocated.

5.4.2.6. Specification of Task Activation Size

The specification of a task activation size causes the task activation to be allocated with the specified size. Itis expressed in storage units; refer to package SYSTEM for the meaning of storage units.

If the storage specified for a task activation (T' Storage_.Size) is not a multiple of 4096 (one page), thecompiler allocates the next higher multiple of 4096, as permitted by the language.

Any attempt to exceed the activation size during execution causes a STORAGEERROR exception to beraised. Unlike collections, there is no extension of task activations.

5.4.2.7. Specification of' SMALLOnly powers of 2 are allowed for 'SMALL.

The length of the representation may be affected by this specification. If a size specification is also given forthe type, the size specification takes precedence; the specification of ' SMALL must then be accommodatablewithin the specified size.

5.4.3. Enumeration Representation Clauses

For enumeration representation clauses [LRM 13.3], the following restrictions apply:

" The internal codes specified for the literals of the enumeration type may be any integer value betweenINTEGER' FIRST and INTEGER' LAST. It is strongly advised to not provide a representation clause thatmerely duplicates the default mapping of enumeration types, which assigns consecutive numbers in as-cending order starting with 0, since unnecessary runtime cost is incurred by such duplication. It should benoted that the use of attributes on enumeration types with user-specified encodings is costly at run time.

" Array types, whose index type is an enumeration type with non-contiguous value encodings, consist of acontiguous sequence of components. Indexing into the array involves a runtime translation of the indexvalue into the corresponding position value of the enumeration type.


5.4.4. Record Representation ClausesThe alignment clause of record representation clauses [LRM 13.4] is observed.Static objects may be aligned at powers of 2 up to a page boundary. The specified alignment becomes the

minimum alignment of the record type, unless the minimum alignment of the record forced by the componentallocation and the minimum alignment requirements of the components is already more stringent than thespecified alignment.

The component clauses of record representation clauses are allowed only for components and discriminantsof statically determinable size. Not all components need to be present. Component clauses for components ofvariant parts are allowed only if the size of the record type is statically determinable for every variant.

The size specified for each component must be sufficient to allocate all possible values of the componentsubtype (but not necessarily the component type). The location specified must be compatible with any alignmentconstraints of the component type; an alignment constraint on a component type may cause an implicit alignmentconstraint on the record type itself.

If some, but not all, discriminants and components of a record type are d-cribed by a component clause, thenthe discriminants and components without component clauses are allocated after those with component clauses;no attempt is made to utilize gaps left by the user-provided allocation.

5.4.5. Address clausesAddress clauses [LRM 13.5] are supported with the following restrictions:

" When applied to an object, an address clause becomes a linker directive to allocate the object at the givenaddress. For any object not declared immediately within a top-level library package, the address clause isaccepted but meaningless. Please refer to section 8.10 for details on how address clauses relate to linking;refer to section 12.2 for an example.

" Address clauses applied to local packages are not supported by Tartan Ada. Address clauses applied tolibrary packages are prohibited by the syntax; therefore, an address clause can be applied to a package onlyif it is a body stub.

* Address clauses applied to subprograms and tasks are implemented according to Pie LRM rules. Whenapplied to an entry, the specified value identifies an interruipt in a manner customary for the target.Immediately after a task is created, a runtime call is made for each of its entries having an address clause,establishing the proper binding between the entry and the interrupt. Refer to section 10.2.7 for moredetails. A specified address must be an Ada static expression.

" Address clauses specify virtual, not physical, addresses." When specifying absolute addresses, please note that the compiler will treat addresses as an I14TEGER

type. ThL. means that specifications of addresses may raise arithmetic overflow errors; i.e., addresses mustbe in the range INTEGER' FIRST. . INTEGER' LAST. To represent an address greater thanINTEGER' LAST, use the neL-,ted radix-complement of the desired address. For example, to expressaddress 16#C00_0 00, specify instead -16#4000_000.

5.4.6. Pragma PACKPragma PACK [LRM 13.1] is supported. For details, refer to the following sections.

5.4.6.1. Pragma PACK for ArraysIf pragma PACK is applied to an array, the densest possible representation is chosen. For details of packing,

refer to the explanation of size specifications for arrays (Section 5.4.2.3).

If, in addition, a length clause is applied to


1. The array type, the pragma has no effect, since such a length clause already uniquely determines the arraypacking method.

2. The component type, the array is packed dei ily, observing the component's length clause. Note that thecomponent length clause may have the effect of preventing the cc .piler froni packing as densely aswould be the default if pragma PACK is applied where there was no length clause given for the com-ponent type.

5.4.6.2. The Predefined Type String

Package STANDARD applies Pragma PACK to the type string.

Hr-vever, when applied to character arrays, this pragma cannot be used to achieve denser packing than is thedefault for the target 4 characters per 32-bit word.

5.d.6.3. Pragma PACK for Records

If pragma PACK is applied to a record, the densest possible representation is chosen that is compatible withthe sizes and alignment constraints of the individual component types. Pragma PACK has an effect only if thesizes of some component types are specified explicitly by size specifications and are of non-referable nature. Inthe absence of pragma PACK, such components generally consume a referable amount of space.

It should b-. noted that the default type mapping for records maps components of boolean or other types thatrequire only a single bit to a single bit in the record layout, if there an nultiple such components in a record.Otherwise, it allocates a referable amount of storage to the component.

If pragma PACK is applied to a record for which a record representation clause has been given detailing theallocation of some but not all components, the pragma PACK affects only the components whose allocation hasnot been detailed. Moreover, the strategy of not utilizing gaps between explicitly allocated components stillapplies.

5.4.7. Minimal Alignment for TypesCertain alignment properties of values of certain types are enforced by the type mapping rules. Any represen-

tation specification that cannot be satisfied within these constraints is not obeyed by the compiler and is ap-propriately diagnosed.

Alignment constraints are caused by properties of the target architecture, most notably by the capability toextract non-aligned component values from composite values in a reasonably efficient manner. Typically, restric-tions exist that make extraction of values that crr certain address boundaries very expensive, especially incontexts involving array indexing. Permitting daL tayouts that require such complicated extractions may impactcode qual;y on a broader scale than merely in the local context of such extractions.

Instead of describing the precise algorithm of establishing the minimal alignment of types, we provide thegeneral rule that is being enforced by the alignment rules:

No object of scalar type including components or subcomponents of a composite type, may span a target-dependent address boundary that would mandate an extraction of the object's value to be performed by twoor more extractions.

5.5. IMPLEMENTATION-GENERATED COMPONENTS IN RECORDS

The only implementation-dependent components allocated by Tartan Ada in records contain dope informationfor arrays whose bounds depend on discriminants of the record. These components cannot be named by the user.


5.6. INTERPRETATION OF EXPRESSIONS APPEARING IN ADDRESS CLAUSESSection 13.5.1 of the Ada Language Reference Manual describes a syntax for associating interrupts with task

entries. Tartan Ada implements the address clausefor TOENTRY use at intlD;

by associating the interrupt specified by intID with the toentry entry of the task containing this addressclause. The interpretation of intID is both machine and compiler dependent.

The Ada runtimes provide interrupts that may be associated with task entries. These interrupts are of typeSystem.Address in the ranges 8..243, 252..255, 264..499, and 508..511. Refer to section 10.2.7 for furtherexplanation. If the argument is outside those ranges, the compiler will report an error.

5.7. RESTRICTIONS ON UNCHECKED CONVERSIONSTartan supports UNCHECKED CONVERSION with a restriction that requires the sizes of both source and

target types to be known at compile time. The sizes need not be the same. If the value in the source is wider thanthat in the target, the source value will be truncated. If narrower, it will be zero-extended. Calls on instantiationsof UNCHECKEDCONVERS ION are made inline automatically.

5.8. IMPLEMENTATION-DEPENDENT ASPECTS OF INPUT-OUTPUT PACKAGESTartan Ada supplies the predefined input/output packages DIRECT_10, SEQUENTIAL_ 10, TEXTio, and

LOW._LEVELIO as required by LRM Chapter 14. However, since 80960MC processor is used in embeddedapplications lacking both standard I/O devices and file systems, the functionality of DIRECTIO,SEQUENTIAL.iO, and TEXTIO is limited.

DIRECT IO and SEQUENTIAL 10 raise USEERROR if a file open or file access is attempted. TEXT 10is supported to CURRENTOUTPUT and from CURRENTINPUT. A routine that takes explicit file names raisesUSE_ERROR. LOW LEVELIO for 80960MC processor provides an interface by which the user may read andwrite from memory mapped devices. In both the SENDCONTROL and RECEIVECONTROL procedures, thedevice parameter specifies a device address while the data parameter is a byte, halfword, word, or doubleword ofdata transferred.

5.9. OTHER IMPLEMENTATION CHARACTERISTICSThe following information is supplied in addition to that required by Appendix F to MIL-STD-1815A.

5.9.1. Definition of a Main ProgramAny Ada library subprogram unit may be designated the main program for purposes of linking (using the

AL960 LINK command) provided that the subprogram has no parameters.

Tasks initiated in imported library units follow the same rules for termination as other tasks [described inLRM 9.4 (6-10)]. Specifically, these tasks are not terminated simply because the main program has terminated.Terminate alternatives in selective wait statements in library tasks are therefore strongly recommended.

5.9.2. Implementation of Generic UnitsAll instantiations of generic units, except the predefined generic UNCHECKED CONVERSION and

UNCHECKEDDEALLOCATION subprograms, are implemented by code duplications. No attempt at sharingcode by multiple instantiations is made in this release of Tartan Ada.

Tartan Ada enforces the restriction that the body of a generic unit must be compiled before the unit can beinstantiated. It does not impose the restriction that the specification and body of a generic unit must be providedas part of the same compilation. A recompilation of the body of a generic unit will casue any units thatinstantiated this generic unit to become obsolete.

APPENDDC F TO M1-SD-1815A

5.9.3. Attributes of Type DurationThe type DURATION is defined with the following characteristics:

Attribute Value

DURATION' DELTA 0.0001 sec

DURATION' SMALL 0.00061 sec

DURATION' FIRST -86400.0 sec

DURATION' LAST 86400.0 sec

5.9.4. Values of Integer AttributesTartan Ada supports the predefined integer type INTEGER. The range bounds of the predefined type

INTEGER are:

INTEGER' FIRST is -2*31INTEGER' LAST is 2*31-1

LONG INTEGER' FIRST is -2**63LONGINTEGER' LAST is 2*63-1

SHORT INTEGER' FIRST is -2"'15SHORTINTEIGER' LAST is 2"'15-1BYTE INTEGER' FIRST is -128

BYTEINTEGER' LAST iS 127

The range bounds for subtypes declared in package TEXTIO are:

COUNT' FIRST is 0COUNT' LAST is INTEGER' LAST - 1

POSITIVE CO3NT' FIRST is IPOSITIVECOUNT' LAST is INTEGER' LAST- 1

FIELD' FIRST is 0

F TLD' LAST is 20

The range bounds for subtypes declared in packages DIRECT.10 are:

COUNT' FIRST is 0COUNT' LAST is INTEGER' LAST

POSITIVE COUNT' FIRST is 1POSITIVECOUNT' LAST iS COUNT' LAST

5.9.5. Ordinal Types

Ordinal types are supported via a separate package, which is included with the standard packages. PackageOrdinalSupport provides support for unsigned arithmetic, including functions which convert betweenInteger and Ordinal types, and a complete set of Ordinal arithmetic operations. The specification of packageOrdinalSupport may be found in the appendix.


5.9.6. Values of Floating-Point AttributesTartan Ada supports the predefincd floating-point types FLOAT, LONGFLOAT, and EXTENDED-FLOAT.

Attribute Value for FLOAT

DIGITS 6

MANTISSA 21

EMAX 84

EPSILON 16#0. 1000_000#E4approximately 9.536743E-07

SMALL 16#0.8000_000#E-21approximately 2.58494E-26

LARGE 16#0.FFFF_F80#E+21approximately 1.93428E+25

SAFE EMAX 126

SAFE SMALL 16#0.2000_OOO#E-31approximately 5.87747E-39

SAFE LARGE 16#0.3FFF_.FEO#E+32approximately 8.50706+37

FIRST -16#0.7FFFFFC#E+32approximately -1.70141E+38

LAST 16#0.7FFF FFC#E+32approximately 1.70141E+38

MACHINERADIX 2

MACHINEMANTISSA 24

MACHINEEMAX 126

MACHINEEMIN -126

MACHINEROUNDS TRUE

MACHINEOVERFLOWS TRUE

APPENDIX F TO MEL-STD-1815A

Attribute Value for LONG FLOAT

DIGITS 15

MANTISSA 51

EMAX 204

EPSILON 16#0.4000_0000_0000_000#E-12approximately 8.8817841970013E-16

SMALL 16#0.8000_0000_0000_000#E-51approximately 1.9446922743316E-62

LARGE 16#0.FFFF_FFFFFFFF_EOO#E+51approximately 2.5711008708143E+61

SAFE EMAX 1022

.SAFESMALL 160.2000_0000_0000_000#E-255approximately 1.1125369292536-308

SAFELARGE 16#0.3FFFFFFFFFFF_F80#E+256approximately 4.4942328371557E+307

FIRST -16#0.7FFF_FFFF_FFFF_FE#E+256approximately -8.988465674312E+307

LAST 16#0.7FFFFFFyFFFFFE0#E+256approximately 8.9884656743115E+307

MACHINERADIX 2

MACHINEMANTISSA 51

MACHINEEMAX 1022

MACHINEEMIN -1022

MACHINEROUNDS TRUE



Attribute Value for EXTENDED FLOAT

DIGITS 18

MANTISSA 61

EMAX 244

EPSILON 16#0.1000_0000_0000_0000_O#E-14approximately 8.67361737988403547E- 19

SMALL 16#0.8000_0000_000_L0000_0OE-61approximately 1.76868732008334226E-74

LARGE 16#0.FFFFFFFFF....FFF80#E+61approximately 2.82695530364541493E+73

SAFE EMAX 16382

SAFESMALL 16#0.2000_0000_0-0000O_0#E-4096approximately 1.68105157155604675E-4932

SAFELARGE 16#0.3FFFFFFFFFFF_FFFF_0#E+4096approximately 2.97432873839307941E+4931

FIRST -16#0.7FFF_FFFF_FFFF_FFFF_8#E+4096approximately -5.94865747678615883E+4931

LAST 16#0.7FFFFFFFFFFF_FFFF_.8#E+4096approximately 5.94865747678615883E+4931

MACHINERADIX 2

MACHINEMANTISSA 63

MACHINE EMAX 16382

MACHINEEMIN -16382

MACHINEROUNDS TRUE



5.10. SUPPORT FOR PACKAGE MACHINE_CODEPackage MACHINE CODE provides the programmer with an interface through which to request the genera-

ton of any instruction that is available on the 80960. The Tartan Ada VMS 960 implementation of packageMACHINE CODE is similar to that described in Section 13.8 of the Ada LRM, with several added features. Referto appendix A of this manual for the specification for package MACHINECODE.

5.10.1. Basic InformationAs required by LRM, Section 13.8, a routine which contains machine code inserts may not have any other

kind of statement, and may not contain an exception handler. The only allowed declarative item is a use clause.Comments and pragmas are allowed as usual.

5.10.2. InstructionsA machine code insert has the form TYPEMARK' RECORDAGGREGATE, where the type must be one of the

records defined in package MACHINECODE. Package MACHINECODE defines four types of records. Eachhas an opcode and zero to 3 operands. These records are adequate for the expression of all instructions providedby the 80960.

5.10.3. OperandsAn operand consists of a record aggregate which holds all the information to specify it to the compiler. All

operands nave an address mode and one or more other pieces of information. The operands correspond exactly tothe operands of the instruction being generated.

5.10.3.1. Address Modes

Each operand in a machine code insert must have an Address Mode Name. The address modes provided inpackage MACHINECODE provide access to all address modes supported by the 80960.

In addition, package MACHINE CODE supplies the address modes Symbolic Address andSymbolic_ Value which allow the user to refer to Ada objects by specifying Object' ADDRESS as the valuefor the operand. Any Ada object which has the 'ADDRESS attribute may be used in a symbolic operand.SymbolicAddress should be used when the operand is a true address (that is, a branch target or the sourceof an LDA instruction). Symbolic_Value should be used when the operand is actually a value (that is, one ofthe source operands of an ADD instruction).

When an Ada object is used as a source operand in an instruction (that is, one from which a value is read), thecompiler will generate code which fetches the value of the Ada object. When an Ada object is used as thedestination operand of an instruction, the compiler will generate code which uses the address of the Ada object asthe destination of the instruction. See section 5.10.10 for further details.

5.10.4. ExamplesThe Tartan Ada VMS 960 implementation of package MACHINECODE makes it possible to specify

both simple machine code inserts such astwofor.nat' (MOV, (Reg-Lit, 5), (Reg, R5))

and more complex inserts such as

three format' (MULI,(SymbolicValue, ArrayVar(X, Y, 27)'ADDRESS),(Lit, 123456),(Symbolic-Address, Parameterl'ADDRESS))

In the first example, the compiler will emit the instruction mov 5, r5. In the second example, the compilerwill first emit whatever instructions are needed to form the address of ArrayVar (X, Y, 27), load thevalue found at that address into a register, load 123456 into a register, and then emit the muLl instruction. IfParameter 1 is not found in a reeister. the comnoiler will vut the result of the multiolication in a temporarv


register and then store it to Parameter_ ' ADDRESS. Note that the destination operand of the MULI instruc-non is given as a Symbolic._Address. This holds true for all destination operands. The various error checksspecified in the LRM will be performed on all compiler-generated code unless they are suppressed by theprogrammer (either through pragma SUPPRESS, or through command qualifiers).

5.10.5. Incorrect OperandsUnder some circumstances, the compiler attempts to correct incorrect operands. Three modes of operation

are supplied for package MACHINE CODE: /FIXUP=NONE, /FIXUP=WARN, and /FIXUP=QUIET. Thesemodes of operation determine whether corrections are attempted and how much information about the necessarycorrections is provided to the user. /FIXUP=QUIET is the default.

In /FIXUP=NONE mode, the specification of incorrect operands for an instruction is considered to be a fatalerror. In this mode, the compiler will not generate any extra instructions to help you to make a machine codeinsertion. Note that it is still legal to use 'ADDRESS constructs as long as the object which is used meets therequirements of the instruction.

In /FIXUP=QUIET mode, if you specify incorrect operands for an instruction, the compiler will do its bestto fix up the machine code to provide the desired effect. For example, although it is illegal to use a memoryaddress as the destination of an ADD instruction, the compiler will accept it and try to generate correct code. Inthis case, the compiler will allocate a temporary register to use as the destination of the ADD, and then store hornthat register to the desired location in memory.

In /FIXUP=WARN mode, the compiler will also do its best to correct any incorrect operands for an instruc-tion. However, a warning message is issued stating that the machine code insert required additional machineinstructions to make its operands legal.

The compiler will always emit the instruction named in the machine code insert -- even if it was necessary tofix up all of its operands. In extreme cases this can lead to surprising code sequences. Consider, for example, themachine code insert

TwoFormat' (MOV, (Reg_Ind, GO), (Reg_IndDisp, GI, 128))The MOV instruction requires two registers, but both operands are memory addresses. The compiler will generatea code sequence like

id (gO), g12mov g12, g13st g13, 128(gl)

Note that the MOV instruction is generated even though a LD ST combination would have been sufficient. As aresult of always emitting the instruction specified by the programmer, the compiler will never optimize awayinstructions which it does not understand (such as SENDSERV), unless they are unreachable by ordinary controlflow.

5.10.6. Assumptions Made in Correcting OperandsWhen compiling in /Fixup= [WARN, QUIET] modes, the compiler attempts to emit additional code to

move "the right bits" from an incorrect operand to a place which is a legal operand for the requested instruction.The compiler makes certain basic assumptions when performing these fixups. This section explains the assump-tions the compiler makes and their implications for the generated code. Note that if you want a correction whichis different from that performed by the compiler, you must make explicit machine-code insertions to performit.

For source operands:

" SymbolicAddress means that the address specified by the 'ADDRESS expression is used as thesource bits. When the Ada object specified by the 'ADDRESS instruction is bound to a register, this willcause a compile-time error message because it is not possible to "take the address" of a register.

" Symbolic_Value means that the value found at the address specified by the 'ADDRESS expression willbe' used as the source hits An Ada object which is bound to a register is correct here. because the contents

APPENDIX FTO MIL-STD-1815A

* Label indicates that the address of the label will be used as the source bits.

" Any other non-register means that the value found at the address specified by the operand will be used asthe source bits.

For destination operands:

" Symbolic _Address means that the desired destination for the operation is the address specified by the'ADDRESS expression. An Ada object which is bound to a register is correct here;. a register is a legaldestination on the 960.

* Symbolic-Value means that the desired destination for the operations is found by fetching 32 bits fromthe address specified by the ' ADDRESS expression, and storing the result to the address represented by thefetched bits. This is equivalent to applying one extra indirection to the address used in theSymbolic-Address case.

" All other operands are interpreted as directly specifying the destination for the operation.

Table 5-1 below describes the correction attempted for each possible instruction-operation combination. Theactions shown in the table have the following meanings:

Load to Register 1 The operand given represents a memory location, but the instruction requires a register.The operand is used as a source. The compiler wil load from the operand to a tem-porary register.

Load to Register 2 The operand given represents a register, but the instruction requires a memory location.The operand is a destination. The compiler will store the result value to a scratchmemory location, and then load it into the specified register.

Store to Memory 1 The operand given represents a register, but the instruction requires a memory location.The operand is a source. The compiler will store the value to a scratch memory locationso that it will be in the proper place for the instruction.

Store to Memory 2 The operand given represents a memory location, but the instruction requires a register.The operand is a destination. The compiler will allocate a scratch register, use that asthe destination for the instruction, and then store the result value to the specifiedmemory address.

Store to Memory 3 The operand given is not the address (.! a label. The operand will be stored to a scratchmemory location, and then used as the indirect branch target.

Error 1 The only incorrect operand for the source of an LDA is a register. It is not possible totake the address of a register on the 960.

Error 2 The operand must be a Label' Address.

lnst Opndl Opnd2 Opnd3addo, addi, addc, addr,addrl Load to Register 1 Load to Register I Store to Memory 2

alterbit Load to Register 1 Load to Register I Store to Memory 2

and, andnot Load to Register I Load to Register I Store to Memory 2

atadd Load to Register 1 Load to Register 1 Store to Memory 2

atanr, atanrl Load to Register 1 Load to Register I Store to Memory 2

atmc'd Load to Register I Load to Register I Store to Memory 2

Table 5-1: Machine-Code Fixup Operations


Inst Opndl Opnd2 Opnd3

b Error 2

bx Store to Memory 3

bal Error 2

balx Store to Memory 3

bbc, bbs Load to Register I Load to Register I Error 2

BRANCH IF Error 2

call Error 2

calls Load to Register 1

calix Store to Memory 3

chkbit Load to Register I Load tr Register 1

classr, classrl Load to Register 1

cibit Load to Register 1 Load to Register 1 Store to Memory 2

cmpi, cmpo Load to Register 1 Load to Register 1

cmpdeci, cmpdeco Load to Register 1 Load to Register 1 Store to Memory 2

cmpinci, cmpinco Load to Register 1 Load to Register 1 Store to Memory 2

cmpor, cmporl Load to Register 1 Load to Register 1

cmpr, cmprl Load to Register 1 Load to Register I

cmpstr Load to Register 1 Load to Register 1 Load to Register 1

COMPARE ANDBRANCH Load to Register I Load to Register I Error 2

concmpi, concmpo Load to Register 1 Load to Register I

condrec Load to Register I Load to Register I

condwait Load to Register 1

cosr, cosrl Load to Register I Store to Memory 2

cpyrsre, cpysre Load to Register 1 Load to Register I Store to Memory 2

Load to Register 1 (64cvtilr bits) Store to Memory 2

cvtir Load to Register I Store to Memory 2

cvtri Load to Register I Store to Memory 2

Store to Memory 2 (64cvtril Load to Register 1 bits)

cvtzri Load to Register 1 Store to Memory 2

Store to Memory 2 (64cvtzril Load to Register 1 bits)

daddc Load to Register 1 Load to Register I Store to Memory 2

divo, divi, divr, divrl Load to Register 1 Load to Register 1 Store to Memory 2


Inst Opndl Opnd2 Opnd3

dmovt Load to Register I Store to Memory 2

dsubc Load to Register I Load to Register I Store to Memory 2

Load to Register 1 (64 Store to Memory 2 (64ediv Load to Register I Bits) bits)

Store to Memory 2 (64emul Load to Register 1 Load to Register 1 bits)

expr, exprl Load to Register 1 Store to Memory 2

extract Load to Register 1 Load to Register 1 Store to Memory 2

FAULT IF

fill Load to Register I Load to Register I Load to Register 1

flushreg

fmark

inspacc Load to Register I Store to Memory 2

LOAD Store to Memory I Store to Memory 2

Ida Error 1 Store to Memory 2

ldphy Load to Register 1 Store to Memory 2

ldtime Store to Memory 2

logbnr, logbnrl Load to Register 1 Store to Memory 2

logepr, logeprl Load to Register I Store to Memory 2

logr, logrl Load to Register I Store to Memory 2

mark

modac Load to Register I Load to Register I Store to Memory 2

moc," Load to Register 1 Load to Register I Store to Memory 2

modify Load to Register 1 Load to Register 1 Store to Memory 2

modpc Load to Register I Load to Register I Store to Memory 2

modtc Load to Register I Load to Register I Store to Memory 2

MOVE Load to Register I Store to Memory 2

movqstr, movstr Load to Register I Load to Register I Load to Register I

mulo, mull, mulr,muil Load to Register 1 Load to Register 1 Store to Memory 2

nand Load to Register I Load to Register I Store to Memory 2

nor Load to Register I Load to Register I Store to Memory 2

not Load to Register I Store to Memory 2

notand Load to Register I Load to Register I Store to Memory 2

notbit Load to Register 1 Load to Register 1 Store to Memory 2

Talle S.1: MachineCode Fixup Operations


Inst Opndl Opnd2 Opad3

notor Load to Register 1 Load to Register 1 Store to Memory 2

or, ornot Load to Register 1 Load to Register I Store to Memory 2

recieve Load to Register I Load to Register 1

remo, remi, remr,remrl Load to Register I Load to Register I Store to Memory 2

resumprcs Load to Register 1

ret

rotate Load to Register 1 Load to Register 1 Store to Memory 2

roundr, roundri Load to Register 1 Store to Memory 2

saveprcs

scaler, scalerl Load to Register 1 Load to Register I Store to Memory 2

scanbit Load to Register 1 Store to Memory 2

scanbyte Load to Register 1 Load to Register 1

schedprcs Load to Register I

send Load to Register I Load to Register I Load to Register I

sendserv Load to Register 1

setbit Load to Register I Load to Register 1 Store to Memory 2

SHIFT Load to Register 1 Load to Register 1 Store to Memory 2

signal Load to Register 1

sinr, sinrl Load to Register I Store to Memory 2

spanbit Load to Register I Store to Memory 2

sqrt, sqrtrl Load to Register 1 Store to Memory 2

STORE Load to Register 1 Load To Register 2

subo, subi, subc, subr,subrl Load to Register I Load to Register 1 Store to Memory 2

syncf

synld Load to Register 1 Store to Memory 2

synmov, synmovl, syn-movq Load To Register 1 Load to Register 1

tanr, tanrI Load to Register 1 Store to Memory 2

TEST Store to Memory 2

wait Load to Reg I

xnor, xor Load to Register I Load to Register 1 Store to Memory 2 .

Table 5-1: Machine..Code Fixup Operations

APPENDIX F TO MIL.STD-1815A

5.10.7. Register UsageSince the compiler may need to allocate registers as temporary storage in machine code routines, there are

some restrictions placed on your register usage. The compiler will automatically free all the registers whichwould be volatile across a call for your use (that is, gO..g7, g13, and g14). If you reference any other register, thecompiler will reserve it for your use until the end of the machine code routine. The compiler will not save theregister automatically. This means that the first reference to a register which is not volatile across calls should bean instruction which saves its value in a safe place. The value of the register should be restored at the end of themachine code routine. This rule will help ensure correct operation of your machine code insert even if it is inlineexpanded in another routine.

The compiler may need several registers to generate code for operand fixups in machine code inserts. If youuse all the registers, fixups will not be possible. If a fixup is needed, the compiler may require up to threeregisters to guarantee success. In general, when more registers are available to the compiler it is able to generatebetter code.

5.10.8. Inline ExpansionRoutines which contain machine code inserts may be inline expanded into the bodies of other routines. This

may happen under programmer control through the use of pragma INLINE, or at Optimization IUvel 3 when thecompiler selects that optimization as an appropriate action for the given situation. The compiler will treat themachine code insert as though it was a call; volatile registers will be saved and restored around it, etc.

5.10.9. Unsafe Assumptions

There are a variety of assumptions which should not be made when writing machine code inserts. Violationof these assumptions may result in the generation of code which does not assemble or which may not functioncorrectly.

" Do not assume that a machine code insert routine has its own set of local registers. This may not be true ifthe routine is inline expanded into another routine. Explicitly save and restore any registers which are notvolatile across calls. If you wish to guarantee that a routine will never be inline expanded, you should usean Ada separate body for the routine and make sure that there is no pragma INLINE for it.

" Do not attempL to move multiple Ada objects with a single long instruction such as MOVL or STT.Although the objects may be contiguous under the current circumstances, there is no guarantee that laterchanges will permit them to remain contiguous. If the objects are parameters, it is v'rtualy certain thatthey will not be contiguous if the routine is inline expanded into the body of another routine. In the case oflocals, globals, and own variables, the compiler does not guarantee that objects which are declared tex-tually "next" to each other will be contiguous in memory. If the source code is changed such that itdeclares additional objects, this may change the storage allocation such that objects which were previouslyadjacent are no longer adjacent.

" The compiler will not generate call site code for you if you emit a call instruction. You must save andrestore any volatile registers which currently have values in them, etc. If the routine you call has outparameters, a large function return result, or an unconstrained result, it is your responsibility to emit thenecessary instructions to deal with these constructs as the compiler expects. In other words, when you emita call, you must follow the linkage conventions of the routine you are calling. For further details on callsite code, see Sections 6.4, 6.5 and 6.6.

" Do not assume that the 'ADDRESS on Symbolic Address or SymbolicValue operands meansthat you are getting an ADDRESS to operate on. The Address- or Value-ness of an operand is determinedby your choice of SymbolicAddress or Symbolic-Value. This means that to add the comems ofx to r3, you should write

ThreeFormat' (ADDI, (SymbolicValue, X'ADDRESS),(Reg, R3), (Reg, R3));

1,,, tr% qdt thP M,.414,,e f V tf, A Vr,, VhC,,,1,4 1,,"4

tP


ThreeFormat' (ADDI, (SymbolicAddress, X'ADDRESS),(Reg, R3), (Reg, R3));

The compiler will not prevent you from writing register r3 (which is used to hold the address of the currentexception handler). This provides you the opportunity to make a custom exception handler. Be aware,however, that there is considerable danger in doing so. Knowledge of the details on the structure ofexception handlers will help; see the Tartan Ada Runtime Implementor's Guide.

5.10.10. Limitations

" When specifying absolute addresses in machine..code inserts, please note that the compiler will treataddresses as an INTEGER type. This means that specifications of addresses may raise arithmetic overflowerrors; i.e., addresses must be in the range INTEGER' FIRST.. INTEGER' LAST. To represent anaddress greater than INTEGER' LAST, use the negated radix-complement of the desired address. Forexample, to express address 16#COOO_000, specify instead -16#4000_000.

" The current impl.mentation of the compiler is unable to fully support automatic fixup of certain kinds ofoperands. In particular, the compiler assumes that the size of a data object is the same a' the number ofbits which is operated on by the instruction chosen in the machine code insert. This means that the insert

ThreeFormat' (ADDO, (SymbolicValue, ByteVariable'ADDRESS),(Reg, RO), (Reg, RI))

will not generate correct code when Byte Variable is bound to memory. The compiler will assumethat ByteVariable is 32 bits, when in fact it is only 8, and will emit an LD instruction to load thevalue of Byte Variable into a register. If, on the other hand, Byte-Variable was bound to aregister the insertion will fur ,tion properly, as no fixup is needed.

o The compiler generates incorrect code when the BAL and BALX instructions are used with symbolicoperands which are not of the form Routine' ADDRESS. To get the effect of an unconditional branch,use the B or BX instructions instead.

e Note that the use of X' ADDRESS in a machine code insert does not guarantee that x will be bound tomenaory. This is a result of the use of' ADDRESS to provide a "typeless" method for naming Ada objectsin machine code inserts. For example, it is legal to say to (SymboicValue, X'ADDRESS) in aninsert even when X is a formal parameter of the machine code routine (and is thus found in a register).

5.10.11. Examplepackage mtest istype arytype is array(l..4) of integer;

procedure inline into me;ena mtest;

wi-n machine-code;use machine code;package body mtest is

ownva. : integer :=-1;

procedure machtest(x, y, z: in integer; ary: in out arytype) isbegin

-- The next instruction is only OK if this routine is not INLINED.-- If the routine is inlined; there is no guarantee that parm X will-- be either A) in an even numbered register, or B) "next to" parm-- Y. If the programmer uses an instruction like MOVLp here, he is-- assuming too much about the generaed code; his program is-- erroneous. On the other hand, the use of x'ADDRESS does guarantee-- that the instruction will use X even when this routine is inline

APPENDIX F TO MIL-STD-I815A

TwoFormaz' (MOVL, (Symbolic_Value, x'ADDRESS), (Reg, G6);Two .ormat' (MOV, (SymbolicValue, x'ADDRESS), (Reg, G6));TwoFormat' (MOV, (Symbolic-Value, y'ADDRESS), (Reg, G7));TwoFormat' (MOV, (SymbolicValue, z'ADDRESS), (Reg, G8));ThreeFormat' (ADDI, (Symbolic_Value, x'ADDRESS), (Reg, G8), (Reg, Gl));

ThreeFormat' (MULI,(Reg, G7),(SymbolicValue, y'ADDRESS),(Reg, G12));

-Note the use of a complicated Ada object i this instruction.TwoFormat' (ST,

( Reg, G12),(SymbolicAddress, azy(l)ADDRESS))

-In this instruction, note that ary(1)ADDRESS is NOT kept in a-recister and is thus NOT a legal source for XORp. That's OK,-because the compiler can fix it up for the user.

Three Format' (XORi, (Symbolic -Value, ary(l)'ADDRESS),(SymbolicValue, aryMI)ADDRESS), (Reg, G12));

TwoFormat' (ST,(Reg, G12),(SymbolicAddress, ary(3)'ADDRESS));

Two Format' (ST,(Reg, G12),(SymbolicAddress, ary(x) 'ADFrPZSS));

TwoFormat' (ST,(Reg, GO),(SymbolicAddress, own var'ADDRESS));

TwoFormat' (LDA,(SymbolicValue, own-var'ADDRESS),(Reg, G147);

One -Format' (CALLX, (Symbolic-Address, inline into me'ADDRESS));end mach test;oragma inline(nach-test);

procedure mtestl(first, second, third: in integer; fourth: out ary type) isbegin

-Note the use of fourth(1)'ADDRESS as the destination of the MOV-instruction. The compiler will understand that the user "really-wanted" something moved to fourth(1)'ADDRESS, and will make sure-that the b-Its get there. The compiler does NOT assume that it-- knows enough to second guess the user's choice of instructions.-we generate the MOV, followed by a store to memory.

Two Format' (MOV,(Symbolic Value, First'Address),(Symbolic-Address, fourth(l) ADDRESS));

end mtesti;

procedure inline-into me isarray!l ary_type := (1, 2, 3, 4);

begi-nif arrayl(3) >= 0 then

-note Chat mach-test is inline expandedmach test(22, 41, arrayl(4), arrayl);

else-- but mtest is not at Op=2 (No praoimp inline)mtestl(1,, 2, 3, arrayl);


en~d inllne lntc-me;

end mtest;

APPENDIX PTO MIL-STD-1915A

Assembly code output:0 Generated from USER0l: [SMITH]MTEST.ADB;l# by TARTAN Ada Compiler VMS 80960MC, Version Pre-Release

.data

.align 2ADA.OWN: .space 4

.al-4gn 2ADA.GIOBAL: .space 1

.globl xxmtest~inline -into-me$QO

.globl xxmtest$declare

.globl xxmtest~body

.seto own varSOO,ADA.OWN,O.g'iobl xxmtestSinline into meSgotoSOO

.seco xxmtest$irnline_ir., o me~gotoSOO,ADA.GLOBAL,O

.text

.align 4

xxmtest~inline into '5me$OO:mov -O,r3

st sp,40(sp)ida 40(sp),spst gl2,1OO(fp)Ida .Ll9,r3

mov 1,g13 # line 74

st gl3,80(fp)mov 2,g13st g13,84(fp)mov 3,gl3st g13,88(fp)mov 4,gl3st gl3,92(fp)ldq 80(fp),g4stq g4,64(fp)ld 72(fp),gl3 # line 76

cmpi.bg O,gl3, .L17 ne7id 76(fp),gI3 7

M ov 22,r4addo 31,10,r5Mov g!3,rE

'a 64(fp),r8Brmovi r4,g6

Irv r4,g6mov r5,g7

ov r6,98addi r4,g8,glmull g7,r5,gl2st gl2,96(fp)Id 96(fp),g!3

t g13, (r8)Id 4(r8),rxor gl3,r7,g12st gl2,8(rB)subi l,r4,g13 *line 46

cro o13.3


fa,.tcst g12,-4(r8) [r4*4!,

st gO,ADA.OWN,da ADA.0WN,g14

calix xxmtest~inline into meSOOo .LI9 # line 76

.L!-7: mov !,go # line 81

mov 2,c'mov 3,g2aa 64(ffp),g3

oai rntest'lSOO

'd 100(fp),gl2

ret

f Total tytes of code in the above routine =216

.align 4

mach-testS0C:mov C,r3

st sp 8 (sp)audo 8,spspst g12,68(fp)

.-a L2!,r3

.movi gO,g6mov gO,g6mov gi, g7

mov g2,g8addi gC'g8,glmull- g7,gi,g22st gl2,r,4(fp)id 64(fp),gl3st g13, (g3)

Id 4(g3),g5xor gl3,gS,g12

st g!2,8(g3)subi i,gO,gl3 *line 46

C.mpo g13,3

st aq2 2,-4 (c3)igO'41st go, ADA.OWNca A"DA.0WN,g14

ca-..x xxmtestSinline into meCZO

68(fp),g2

ret

*Total oytes of code 4-n the acove routine =124

.alian 4

mv g-4,g4Mov 0,914

mov q0,g13st g13, (g3)

APPENDX F TO MIL-STD-1815A

# Total oytes of code in the above routine = 20

.align 4

xxmtestSdeclare:

stob g!4,ADA.GLOBAL

ret

* Total bytes of code in the aoove routine = 12

.align 4

xxmtestSbody:

not 0,g13 # line 5

st g3,ADA.OWNmov l,g13stob g13,ADA.GLOBAL

ret

# Total bytes of coce in the above routine = 28

.text

.align 2*align 2

# Total bytes of code = 400# Total bytes of data = 5

91-03865 - dtic.mil · certificate information the following ada implementation was tested and...

Documents