|
DataMuseum.dkPresents historical artifacts from the history of: Rational R1000/400 Tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about Rational R1000/400 Tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - downloadIndex: ┃ M T ┃
Length: 47012 (0xb7a4)
Types: TextFile
Names: »MC68020_OS2000_RELEASE7_2_2_LPT«
└─⟦afbc8121e⟧ Bits:30000532 8mm tape, Rational 1000, MC68020_OS2000 7_2_2
└─ ⟦77aa8350c⟧ »DATA«
└─⟦0e555866a⟧
└─⟦this⟧
Rational Cross-Development Facility:
M68020/OS-2000
Release Information
Rev7_2_2 Release
\f
Copyright 1992 by Rational
Part Number: 508-003218-007
October 1992 (Software Release Rev7_2_2)
Motorola is a registered trademark of Motorola, Inc.
Rational is a registered trademark and Rational Environment is a
trademark of Rational.
Rational
3320 Scott Boulevard
Santa Clara, California 95054-3197
\f
Rev7_2_2 Release
1. Overview
Rev7_2_2 is a release of the Rational M68020/OS-2000
Cross-Development Facility (CDF). This release note lists new
features added, problems fixed, and problems still outstanding
since the previous release of the CDF.
The main features of this release are:
* Support for shared-code generics
* Support for spec/load views
* Support for code views
* Integration with "Program_Library" facilities, providing
faster prelinking
* Reduced compilation times
* Object files are now generated directly by the compiler
This release REQUIRES environment release D_12_4_7 or later.
This release generates code that is incompatible with code
generated by previous versions of the CDF.
1.1. Views in This Release
This release includes the following views:
* !TARGETS.IMPLEMENTATION.MC68020_OS2000_DEBUGGERS.REV11_SPEC
* !TARGETS.IMPLEMENTATION.MC68020_OS2000_DEBUGGERS.REV11_0_3
* !TARGETS.IMPLEMENTATION.MC68020_OS2000_TARGET.REV11_SPEC
* !TARGETS.IMPLEMENTATION.MC68020_OS2000_TARGET.CODE11_0_3
* !TARGETS.IMPLEMENTATION.MOTOROLA_68K.REV7_2_SPEC
* !TARGETS.IMPLEMENTATION.MOTOROLA_68K.CODE7_2_20
* !TARGETS.IMPLEMENTATION.MOTOROLA_68K_HOST.REV11_5_SPEC
* !TARGETS.IMPLEMENTATION.MOTOROLA_68K_HOST.CODE_REV7_13
* !TARGETS.IMPLEMENTATION.MOTOROLA_68K_TRANSFER.REV3_SPEC
* !TARGETS.IMPLEMENTATION.MOTOROLA_68K_TRANSFER.REV3_1_1
* !TARGETS.IMPLEMENTATION.OBJECT_CONVERSION.REV7_2_SPEC
* !TARGETS.IMPLEMENTATION.OBJECT_CONVERSION.CODE7_2_0
RATIONAL October 1992 1\f
Rational Cross-Development Facility:
M68020/OS-2000 Release Information
* !TARGETS.IMPLEMENTATION.OBJECT_MODULE.REV7_2_SPEC
* !TARGETS.IMPLEMENTATION.OBJECT_MODULE.CODE7_2_0
* !TARGETS.IMPLEMENTATION.MC68020_OS2000_RUNTIMES.REV7_2_3
* !TARGETS.IMPLEMENTATION.MOTOROLA_68K_MACHINE.OS2000_11_0_6
1.2. Changed Predefined Units
The predefined units themselves have not changed, but their
location has. See Section 17, "Code Views and the Predefined
Subsystem," for more information.
2. Status of Software Problems in This Release
2.1. Reported Problems Fixed
* 0-0251-6
The compiler now deals more efficiently with constant strings.
* 1181016-Shei-Lsj
Internal_error - float constant out of range. This has been
fixed.
* 4814499-Etoi-Kjm
Pragma Pack on unconstrained arrays of booleans caused code
generation error. This has been fixed.
* 5307212-Stan-Mv
There were problems when declaring subtypes of short integer.
This has been fixed.
* 721413-Etoi-Mv
Internal error during phase: LAB. This has been fixed.
* 9883117-Etoi-Mv
The code generator caused an error when it encountered certain
combinations of multiply nested loops and case statements.
This has been fixed.
* 9723630-0104-6
Support for pragma Inline in compilation tools. Comp.Make now
codes bodies as quickly as possible after the spec. This is
not a full solution, but makes the problems much less likely
to occur.
* 0-0248-9
Combined views required because of inlining and generics.
Since shared-code generics are no longer proscribed from spec
views, it is now feasible to use spec-load subsystems with the
2 October 1992 RATIONAL\f
Rev7_2_2 Release
Mc68020_Os2000 target. Inlining subprogram calls through spec
views is not supported, but this does not prevent the use of
spec-load subsystems.
* 9723630-0022-1
Instantiation in limited private task type. Fixed in this
release.
* 9723630-0120-2
Slow compilation and linking. The
Cross_Cg.Linker_Generate_Map switch can now be used to control
whether a link map file is generated when a main program is
coded.
* 2887093-Shei-Jst
Middle pass problem with spliced contexts. Fixed in this
release.
* 5003830-Euse-Lsj
Constraint Error is no longer raised when compiling
Nosc.Speller.
* 1680472-Shei-Lsj
Constraint Error in stmt_gen.gen_stmt. This has been fixed.
* 4031776-Shei-Jst
Array inequality on packed arrays of discretes failed. This
has been fixed.
* 8518071-Etoi-Mv
Evaluation of 3D boolean array failed. This has been fixed.
* 3244099-Rati-Pbk
A request to zero only the portions of records which are
unused because of alignment issues; the loops that are
currently generated are expensive. This has been fixed.
* 7582583-Etoi-Mv
A representation clause was accepted after the default
determination of an entity. Since this situation is illegal
(according to the LRM), this should have been flagged as an
error. Fixed in Delta 3.0.
* SPR#900515-3
CDF Code generation error (internal error in WRI)
* SPR#900822-16, 900822-24
Deadlock or crash of operating system/ada runtime
* SPR#900928-3
Constraint Error when assigning integer
* SPR#911003-10
Unexpected Traps
RATIONAL October 1992 3\f
Rational Cross-Development Facility:
M68020/OS-2000 Release Information
* SPR#911230-1
Package Command_Line cannot handle long lines
* SPR#920130-5
Compiler error in coding stage
* SPR#920203-24
Priorities of main programs and tasks
* SPR#920205-2
Rational allows pragma shared on records
* SPR#920305-1
CDF Linker aborts with errors (Undefined symbol)
* SPR#920323-13
Error in dead code elimination
* SPR#920505-17, 920522-13
Collection sizes too large - waste of heap memory
* SPR#920505-23
Elaboration fails (Array incorrectly initialized)
* MFP 74
[ITX] Illegal operand combination for Am.Move
* MFP 73
Program_Error in Piwg
* MFP 72
runtime problem
* MFP 71
[ITX] E-Stack underflow
* MFP 69
[WTR] Bad pc relative address
* MFP 68
[WTR] Compiler capacity exceeded
* MFP 67
[MID] in Decl_Gen.Gen_Decl - Constraint_Error (Null Access)
* MFP 66
[MID] Access_Gen.Operations.Unchecked_Deallocation:
Formal_Private_Class.
* MFP 64
[MID] Attempt to reconstruct object in current unit
* MFP 63
[MID] in Stmt_Gen.Gen_Stmt - Constraint_Error (Null Access)
4 October 1992 RATIONAL\f
Rev7_2_2 Release
* MFP 62
Sedt runtime problem
* MFP 60
[MID] in Stmt_Gen.Gen_Stmt - !Lrm.System.Assertion_Error
* MFP 59
[CSE] Internal error (Unhandled Exception => Constraint_Error
(Array Index)
* MFP 58
CDF accepts fixed point in out object, which leads to infinite
loop and storage leak
* MFP 57
[MID] in Decl_Gen.Gen_Decl - !Lrm.System.Assertion_Error
* MFP 55
[MID] in Code_Generation.Generate - Constraint_Error (Null
Access)
* MFP 54
Incorrect raise of Numeric_Error
* MFP 53
[MID] in Decl_Gen.Gen_Decl - Program_Error (prompt executed)
* MFP 53a
ERROR [LNK] Can't process library ...
* MFP 51
Debugger puts wrong indicies for arrays in record
* MFP 50
[MID] in Stmt_Gen.Gen_Stmt - !Lrm.System.Assertion_Error
* MFP 49
[ITX] Illegal operand combination for Am.Move.
* MFP 48
[MID] Context.Enclosing_Generic_Package_Id failed.
* MFP 46
[CHK] Not a valid exp_tree node
* MFP 45
[ITX] Illegal operand combination for Am.Move.
* MFP 44
[CHK] Null pointer.
* MFP 43
[MID] Shared instance subprogram lacks Original_Node
attribute: 0.DN_VOID.
RATIONAL October 1992 5\f
Rational Cross-Development Facility:
M68020/OS-2000 Release Information
* MFP 42
[CHK] Object is down-level addressed.
* MFP 41
[MID] Unexpected Diana: Types.Arrays. Reconstruct_Array_Info
DN_IN_ID.
* MFP 40
[MID] Unexpected Diana: Types.Arrays. Reconstruct_Array_Info
DN_IN_ID.
* MFP 39
[CHK] dot does not have a basetype
* MFP 38
[MID] in Stmt_Gen.Gen_Stmt - !Lrm.System.Assertion_Error [This
is really the same as Mfp_35]
* MFP 37
[MID] in Code_Generation.Generate - Constraint_Error (Null
Access)
* MFP 36
[MID] Shared instance subprogram lacks Original_Node
attribute: 0.DN_VOID.
* MFP 35
Unimplemented feature: Task entry as shared generic actual
subprogram.
* MFP 34
Unimplemented feature: Shared generic subprogram skins over
Unchecked Conversion
* MFP 33
[ITX] Illegal address mode for Am.Add.
* MFP 32
[MID] Shared instance subprogram lacks Original_Node
attribute: 0.DN_VOID.
* MFP 31
[MID] Float_Util.Comparison_Operation: bad class.
* MFP 30
WARNING [MID] Reconstruction of instantiation base not
implemented
* MFP 29
[MID] Unimplemented Feature: Tasks in outermost level of
shared generic
* MFP 28
[MID] Unimplemented Feature: In-out array objects
6 October 1992 RATIONAL\f
Rev7_2_2 Release
* MFP 27
[MID] Attempt to reconstruct object in current unit
* MFP 26
Debugger Problem
* MFP 25
[Cse] Constraint_Error (Null Access) At #41b503, #4ff
* MFP 23
Bad code for variant record
* MFP 22
[ITX] Exception in CODER while coding routine _RECORD ...
* MFP 21
[CSE] Constraint_Error (Null Access) at #52A902, #5C6
* MFP 20
Execution-time misuse of base register
* MFP 18
[CSE] Constraint_Error (Type Range) at #3A4104, #4BC
* MFP 16
Ada runtime traps not handled as exceptions
* MFP 15
[ASY] Value for constant block does not fit element size
* MFP 14
[ITX] Exception in CODER while coding routine _RECORD ...
* MFP 13
[ITX] E-Stack underflow.
* MFP 11
[Cse] Constraint_Error (Type Range) At #320902, #C60
* MFP 10
[Itx] Attempt To Restore Spilled Register ...
* MFP 9
[Lab] Constraint_Error (Null Access) At #383102, #Be6
* MFP 8
[Evo] Internal Error In Phase Evo At ...
* MFP 7
[Mid] Unexpected Diana: Instantiation_Checking.Get_Indices
* MFP 6
[Itx] Internal Coder Stack Inconsistency
RATIONAL October 1992 7\f
Rational Cross-Development Facility:
M68020/OS-2000 Release Information
* MFP 4
[Mid] In Stmt_Gen.Gen_Stmt - !Lrm.System.Assertion_Error
* MFP 1
[Mid] In Dec_Gen.Gen_Decl Assertion_Error At #3aa902, #B09
2.2. Reported Problems Not Fixed in This Release
The following problems reported against previous revisions are
not fixed in the current release:
* SPR#910614-1
Memory allocated in a declare block is not reused in
subsequent non-overlapping declare blocks.
* SPR#910731-1
Text_Io.Get_Line skips a line of input.
* MFP 65
[MID] Unimplemented Feature: Unchecked_Conversion of a formal
private type used as a formal subprogram.
* MFP 54a
The debugger can be invoked correctly, but the directory of
the program must be given as part of the name of the program.
* MFP 47 Debugger unable to put complex packed object
* MFP 24 Unimplemented Feature: Formal fixed point types
* MFP 19 Size representation clause failed to compile
* MFP 17 [WTR] Lost symbol. when coding task body
* MFP 12 [Chk] Object Is Down-Level Addressed.
* MFP 5 Representation Clause Permitted After Forcing Occurrence
* MFP 3 [Mid] In Decl_Gen.Gen_Decl Assertion_Error At #3abd02,
#C9
* MFP 2 Undefined Symbol Referenced During Link Time
2.3. Other Issues Not Dealt With in This Release
This section contains suggestions and errors that need further
clarification or evaluation.
* 9723630-0020-9, 9723630-0067-2, SPR#890627-3, SPR#980731-3
Odd length of modules. Will be considered for a future
release.
8 October 1992 RATIONAL\f
Rev7_2_2 Release
* 4815206-Etoi-Kjm
Stack usage for main programs have changed radically. The
scheme for determining the size of discriminated records was
improved, causing an object which used to be allocated on the
heap to be allocated on the stack. It appears from the PRS
that the customer has a tool which thinks that this storage is
never assigned to, although the generated code does seem to be
doing the assignment. This may no longer be a problem.
* 0-0215-1
Warning messages "Tree_Check_Error" still remain. Waiting for
test case from customer.
* 9723630-0105-1
An assignment statement that doesn't work. This is not
reproduceable. Waiting for test case from customer.
* SPR#881116-1
Minimize run-time library checks of linker command file
* SPR#881212-2
Error path starting at /h0 costs memory
* SPR#881222-3
Add option "CPU" to Debug.Invoke
* SPR#890509-1
Debugger support for tuning heap and stack sizes
* SPR#890518-2
Incremental change of pragma main
3. Changes and New Features
The following features have been changed or added. Consult your
Rational technical representative for more details.
3.1. Improvements in Compiler Operation
3.1.1. Incremental Changes
Support for incremental operations has been improved; in
particular, the user may now make incremental changes in coded
package specifications. As a result, the OS-2000 compiler now
supports all incremental operations provided by the R1000's
native compiler.
RATIONAL October 1992 9\f
Rational Cross-Development Facility:
M68020/OS-2000 Release Information
3.1.2. Compile-Time Improvements
Compile-time when handling floating point literals has been
greatly reduced. This is especially visible with large array
aggregates consisting of float literals.
The Build_Conflict_Graph algorithm now runs 2ver fewer nodes,
which improves performance because it is an O(N) algorithm.
Several expensive optimizer algorithms were improved to reduce
compile times.
The assembly-code writer has been replaced with an object-code
writer. This eliminates the step of running the assembler, which
was previously a bottleneck in the code generation process, and
results in a substantial reduction in compile time. If the
Cross_Cg.Asm_Listing switch is set to True, a listing file is
generated by running the assembly-code writer in addition to the
object-code writer.
3.1.3. More Efficient Use of Compiler Streams
Invocations of the CDF back ends have always been serialized;
that is, each compiler stream can only handle a single
compilation at a time. This is still true, but it is now the
case for main programs that the serialization lock is
relinquished as soon as the linker is invoked. This means that
the compilation stream on which a main program is being coded is
freed for another compilation as soon as the linker is invoked,
rather than after it completes.
3.1.4. Address Clause Support
Support for address clauses on objects has been improved:
* The address need not be determinable at compile time if the
object is an array or record.
* Addresses clauses may now be used on arrays and records whose
size is not determinable at compile time.
The address given in the address clause must be determinable at
compile time unless the specified object is an array or record,
in which case the address may be dynamic. An address is
considered to be determinable at compile time only if it takes
the form of a call to System.To_Address with a compile-time
determinable argument.
An object may not have both pragma Import_Object and an address
clause.
10 October 1992 RATIONAL\f
Rev7_2_2 Release
An address clause with a static address will cause the object to
be addressed using absolute addressing. Pragma Import_Object
will cause the object to be addressed A5-relative, with the
linker resolving the external symbolic name to get the offset.
An object having an address clause is NOT subject to default
initialization unless this is explicitly requested using pragma
Initialize. Pragma Initialize has the following format:
pragma INITIALIZE(simple_name);
This pragma causes the imported or address-claused object denoted
by simple_name to become subject to default initialization.
The parameter to pragma Initialize, simple_name, must denote a
variable declared earlier in the same declarative part. The
variable must be an array or record and must have an address
clause or pragma Import_Object applied to it before the
occurrence of pragma Initialize. The object must not have an
explicit initial value.
3.1.5. <Elab_Order_Listing> file
If the Cross_Cg.Elab_Order_Listing switch is set to True, the
Os2000 CDF now generates an <Elab_Order_Listing> file when a main
program body is coded. This file consists of a list of the fully
qualified names of the units in the closure of the main program,
listed in the order of their elaboration. The file also includes
comments indicating how a unit came to be included in the
closure. The format of this file is suitable for use as an
indirect file in a naming expression, although names of any units
out of code views will not be resolvable.
When the main program is demoted to installed, the
<Elab_Order_Listing> file is destroyed.
3.1.6. Object-Module Converter
The object-module converter is now run automatically as part of
coding a main program, generating an <Os2000> file. When a main
program is demoted from coded to installed, the <Os2000> file is
automatically deleted.
Since the <Os2000> file is now automatically generated, the
compiler no longer creates a <Exe> file by default. An <Exe>
file can be created by setting the Cross_Cg.Produce_Full_Exe
switch to true.
RATIONAL October 1992 11\f
Rational Cross-Development Facility:
M68020/OS-2000 Release Information
3.2. Improvements in Generated Code
Compiler code generation has been improved in the following areas
(among others):
* The propagation of constraint information has been improved.
This improves the elimination of unnecessary overflow and
constraint checks.
* To reduce overall register costs, the allocation of common
subexpressions has been integrated with that of other objects.
* The allocation of volatile registers has been improved. This
increases the number of opportunities for stack frame
elimination when the debugging level is PARTIAL or NONE.
* Object preferencing has been improved, reducing the number of
move instructions.
* Processing of case statements by the optimizer has been much
improved. The optimizer chooses from a number of different
techniques to implement each case statement, depending on
factors such as its size and density. Different techniques
are combined when appropriate, for example to handle a large,
generally sparse case statement having small regions of high
density.
* Constant folding has been expanded. In particular, constant
folding of floating point expressions has been improved.
3.3. Shared-Code Generics
Users may request that all instantiations of a given generic
share the same general code, that all instantiations of a given
generic have their own custom code, or that all instantiations by
default share the same code but that specified instantiations
have their own code. Two new pragmas, Generic_Policy and
Instance_Policy, are used to specify the manner in which code is
to be generated for generics.
3.3.1. Pragma Generic_Policy
pragma GENERIC_POLICY ([GENERIC_UNIT =>] simple_name,
[CODE =>] REPLICATED | SHARED)
The simple name must denote a generic package or subprogram.
The pragma and the declaration of the named generic must occur
immediately within the same declarative part or package
specification; the generic declaration must occur before the
pragma. Only one Generic_Policy pragma may be applied to a
generic.
12 October 1992 RATIONAL\f
Rev7_2_2 Release
The pragma specifies how code should be generated for the
generic. If the Shared option is selected, code will be
generated for the generic itself; this code will be used for all
instantiations of the generic (except as noted below). If the
Replicated option is selected, code will not be generated for the
generic, but rather for each instantiation of the generic. The
replicated code for an instantiation will be smaller and faster
than the shared code for the corresponding generic.
Demoting the body of a replicated generic to installed causes all
instantiations of that generic to also be demoted to installed,
whereas demoting the body of a shared generic to installed does
not cause demotion of any instantiations (except those that were
explicitly made replicated using pragma Instance_Policy).
If pragma Generic_Policy is not specified, the compiler decides
between Shared and Replicated. At present, the default is always
Replicated.
Replicated generics are not permitted in spec views (therefore, a
generic in a spec view must also have a generic policy pragma
specifying that the code is to be shared). The generic policy
must be the same for corresponding generics in a load view and
spec view. This is currently not enforced, so care should be
taken to ensure that all generics which appear in a spec view are
implemented as shared-code generics.
To simplify the rules for spec/load view compatibility, and
because complete control is afforded by the pragmas defined here,
pragma Optimize does not play a role in selecting between shared
and replicated code.
3.3.2. Pragma Instance_Policy
When a policy of shared has been selected for a generic, the user
may still wish for certain instantiations to have replicated code
for performance reasons. Pragma Instance_Policy allows this to
be specified for a particular instantiation.
pragma INSTANCE_POLICY ([INSTANTIATION =>] simple_name,
[CODE =>] REPLICATED)
The simple name must denote an instantiation of a generic (which
may be either shared or replicated).
The pragma and the declaration of the named instantiation must
occur immediately within the same declarative part or package
specification; the instantiation must occur before the pragma.
If the simple_name names several overloaded subprogram
instantiations in the current declarative part or package
specification, the pragma applies to all of them. Only one
Instance_Policy pragma may be applied to a single instantiation.
RATIONAL October 1992 13\f
Rational Cross-Development Facility:
M68020/OS-2000 Release Information
The pragma is ignored if the instantiation refers to a generic in
a spec view.
3.3.3. Shared-Code Generic Features
The following subset of shared-code generic features is supported
in this release:
* Formal floating point types
* Formal private and limited private types
* Formal access types
* Formal subprograms
* Formal objects of mode IN
* Formal arrays
* Formal discrete and integer types
* Formal scalar objects of mode IN OUT
* Formal nondiscriminated record objects of mode IN OUT
* Formal array objects of mode IN OUT
* Generics (shared or replicated) nested immediately within
shared generic packages
* Subunits, and subunits of subunits
A Generic_Policy pragma with a policy of Shared will be rejected
of the generic has any of the following formal parameters:
* Formal fixed point types
* Formal discriminated private and limited private types
* IN OUT discriminated objects
* IN OUT formal private or limited private objects
Exceptions declared in shared generics are not handled strictly
correctly. The Ada language requires that such exceptions be
replicated for each instantiation (as happens naturally when a
macro-expansion technique is used); at the present time, this
does not occur for shared generics.
There is a temporary restriction on the use of bodiless library
unit generic packages. Use of this construct will result in an
error at code generation time.
14 October 1992 RATIONAL\f
Rev7_2_2 Release
The temporary restriction concerning the declaration of task
types and objects in shared generic package specs and bodies has
been removed; such declarations will now be correctly processed.
3.3.4. Guidelines for Using Shared Code Generics
This section discusses the performance impact of shared code
generics and offers some suggestions on when to use them and how
to optimize performance when they are used. In general, shared
code generics will be less time efficient than replicated
generics, but will often be more space efficient as well as
permitting the spec of the generic to be placed in a spec view.
The code is less efficient because code is generated to handle
all the parameters with which a generic can be instantiated,
rather than only the code necessary for the specific parameters
which are available at the instantiation site (where code for
replicated generics is generated). Shared generics must also
manage the state of a generic package (i.e., objects declared in
the package). This is always less efficient, since it requires
an extra level of indirection, and sometimes more than one. In
general, shared code generics will be more space efficient
because code will only be generated once rather than at each of
the instatiation sites, but only if there are several
instantiations of the generic (it is always more efficient to use
replicated generics if there is only one instantiation).
It is also possible that a shared code generic will allocate more
heap or stack than the same generic replicated. This occurs when
the shared generic needs to allocate space but has less
information about how much space to allocate than it would if it
were replicated. For instance, suppose a generic has a formal in
object which is used as a bound in an array. If the generic is
replicated, the compiler may be aware of the value that has been
give to the object, in which case it will allocate the array
statically. If the generic is shared, however, the array must be
allocated dynamically, since the compiler must generate code
without knowing the bounds of the array. Whether more space will
be used because of a given generic depends heavily on what kinds
of generic parameters it takes, so here is a type by type list of
some of the effects.
* Formal Floating Point Types
All simple objects of a formal floating point type will cause
more stack space to be allocated, since the compiler allocates
enough space to store a double-word value. Arrays of formal
floats will be only as long as is needed, but they will be
dynamic in all cases, since the size of the element cannot be
known at compile time.
* Formal Subprograms
All formal subprograms are implemented by passing a compiler
generated subprogram which does any needed type conversions
and then calls the actual subprogram. They have little effect
on the stack or heap used, although they do cause an extra
RATIONAL October 1992 15\f
Rational Cross-Development Facility:
M68020/OS-2000 Release Information
stack frame to be allocated.
* Formal Access Types
No extra space is allocated for an object of a formal access
type, but extra master layers may be created in some cases
where we are unable to tell whether the access type is an
access to a task type.
* Formal Objects of Mode IN
Formal IN objects have no significant effect on the amount of
space allocated.
* Formal Arrays
Formal arrays cause little difference in the amount of space
allocated on either heap or stack.
* Formal Private Types
Formal private types can incur much more overhead with shared
code generics than with replicated generics. This is because
the compiler must now allow for the possiblity of any type.
In general, objects of a formal private type will be allocated
a single word on the stack. If the actual type is a simple
type (i.e. a scalar), the word will contain the value of
object. If the actual type is more complex, the word will
point to another object allocated dynamically which will
contain the actual data, or possibly more pointers to other
dynamic objects. With this scheme, little more space is
allocated that is necessary, but space which would have been
on the stack in a replicated generic will now be allocated
dynamically, sometimes on the heap. Also, since pointers must
be dereferenced (in some cases a chain of pointers must be
followed), operations on formal private types will be slower
than in replicated generics. In many cases, runtime calls are
made to perform operations (e.g., equality tests, assignment,
function return of formal privates, etc).
* Formal Discrete and Integer Types
The only effect of formal discrete and integer types is that
some arrays which would be allocated statically will become
dynamic.
* Formal Scalars of Mode IN OUT
In out objects cause little change in the amount of space
allocated.
With all types an effort has been made to ensure that shared code
generics behave in the same way as the same generic does when
replicated, including raising the same errors at the same
locations. The only exception to this is that in some cases with
formal floating point types Constraint_Error will be raised where
Numeric_Error was previously raised.
16 October 1992 RATIONAL\f
Rev7_2_2 Release
3.4. Code Views and the Predefined Subsystem
Prior to this release, code views could not be transferred
between machines because the link names of the predefined units
(e.g. system) were not the same on different machines. This has
been corrected by placing the predefined units in a subsystem
view called !Targets.Predefined. As a result, new models are
required which point to the new predefined units.
This new organization permits worlds which were compiled with
previous compilers to coexist on the same machine with worlds
compiled with the new compiler. Note, however, that modules
produced by one version of the compiler cannot be linked with
modules produced by another version.
Existing subsystem views which are to be compiled with the new
compiler must have their models replaced. The links in other
worlds must be changed to point to the new predefined units. A
tool is provided with this release which will demote units in
existing worlds and update these worlds for the Rev7_2 compiler -
see the installation notes for more details.
3.5. Other New Features
3.5.1. Pragma Assert
pragma ASSERT([Predicate =>] boolean_expression
[, [Class =>] integer_expression]);
When the pragma is encountered, boolean_expression is evaluated.
If the resulting value is FALSE, the exception
System.Assertion_Error is raised; otherwise, no further action is
taken. If System.Assertion_Error is not defined, Program_Error
is raised instead.
The integer_expression is ignored; for the moment, it is allowed
only for compatibility with the R1000 Ada code generator.
This pragma may appear wherever a statement or declaration would
be legal.
3.5.2. Pragma Collection_Policy
The pragma Collection_Policy can be used to customize storage
management. The complete syntax for this pragma is:
pragma COLLECTION_POLICY (Access_Type => access_type,
Initial_Size => integer_expression
[, Extensible => boolean_expression]
[, Extension_Size =>
integer_expression]);
RATIONAL October 1992 17\f
Rational Cross-Development Facility:
M68020/OS-2000 Release Information
This pragma must appear in the same declarative region as the
access type that it applies to, and the access type's full type
declaration must occur before the pragma. This implies that, in
order to use a private type for the Access_Type argument, the
pragma must be given in the private part after the complete
access-type declaration. At most one such pragma is allowed for
a given access type.
The Collection_Policy pragma is ignored when:
* a `Storage_Size clause is given for the access type; in this
case, the Storage_Size takes precedence. This is because a
statement of the form:
for X'Storage_Size use size;
is equivalent to:
pragma Collection_Policy (Access_Type => X,
Initial_Size => size,
Extensible => False);
* the pragma follows a forcing occurrence of the access type
(LRM 13.1.6).
Access_Type and Initial_Size are required. Extensible and
Extension_Size are optional. All arguments must be specified
using named association, as shown in all examples in this
pragma's discussion.
If Extensible is False, the collection is nonextensible. If
Extensible is True, which is the default if not specified, then
the collection will be extended by a certain number of storage
units when it fills up, if it is possible to do so. The number
of storage units in the extension size is chosen by the runtime
system unless the Extension_Size is specified.
Extension_Size allows the user to specify the number of storage
units to be allocated whenever the collection needs to be
extended. This parameter is ignored if Extensible is False.
Initial_Size gives the size in storage units of the collection
created at the point of the type declaration. If no pragma
Collection_Policy is used, the initial size of the collection is
determined by the runtime system. A nonpositive Initial_Value on
a nonextensible collection raises the Storage_Error exception in
the situations described below. Currently,
for X'Storage_Size use 0;
means that no collection should be created for X. The same
effect is achieved with pragma Collection_Policy by giving:
18 October 1992 RATIONAL\f
Rev7_2_2 Release
pragma Collection_Policy (Access_Type => X,
Initial_Size => 0,
Extensible => False);
In both of the above cases, an attempt to use an allocator will
result in a Storage_Error exception. However, you could also
say:
pragma Collection_Policy (Access_Type => x,
Initial_Size => 0,
Extensible => True,
Extension_Size => 100);
which means "do not create a collection until an allocation is
performed." When the first allocator is executed, the collection
is created with the extension size.
3.5.3. New Attribute: 'Homogeneous
Applicable to an access type; yields a Boolean value. The value
returned is False if the designated type given in the access type
declaration is an unconstrained array type or an unconstrained
discriminated record type, and True otherwise.
If the attribute is True, then all objects in the collection must
have the same size. The converse, however, is not true.
Note that the attribute is a property of the type, not of the
subtype. Thus, for any access type T, T'Homogeneous =
T'Base'Homogeneous.
For example:
type T1 is access String;
type T2 is new T1 (1 .. 10); -- T2'Homogeneous = False
At the implementation level, the attribute indicates whether or
not constraint information needs to be stored with allocated
objects.
3.5.4. Object Writer
The compiler now generates an object file directly. Previously,
the compiler generated an assembly file and invoked the assembler
to obtain an object file. This change results in code generation
times that are approximately 25% faster. As a consequence, the
Cross_Cg.Asm_Source switch is now obsolete. To obtain an assembly
listing, use the Cross_Cg.Listing switch.
RATIONAL October 1992 19\f
Rational Cross-Development Facility:
M68020/OS-2000 Release Information
3.5.5. Elaboration Checks
The CDF now supports the Suppress_Elaboration_Objects switch,
which eliminates all elaboration objects and the code to test and
set them. When this new switch is set to true, the compiler
behaves as if the user had inserted:
pragma Suppress (Elaboration_Check, On => Snaggle);
for each subprogram 'snaggle' in each compilation unit in the
library. This significantly reduces the amount of initialization
code in Ada units.
Because the prelinker guarantees that spec/load subsystems are
elaborated in layers, the compiler never generates elaboration
checks on cross-subsystem calls to subprograms that are imported
via a spec view. Due to this, it is not necessary that the
Suppress_Elaboration_Objects switch have the same value in
corresponding spec and load views.
Elaboration objects for generics are NOT affected by the
Suppress_Elaboration_Objects switch.
20 October 1992 RATIONAL\f
Rev7_2_2 Release
Contents
1. Overview 1
1.1. Views in This Release 1
1.2. Changed Predefined Units 2
2. Status of Software Problems in This Release 2
2.1. Reported Problems Fixed 2
2.2. Reported Problems Not Fixed in This Release 8
2.3. Other Issues Not Dealt With in This Release 8
3. Changes and New Features 9
3.1. Improvements in Compiler Operation 9
3.1.1. Incremental Changes 9
3.1.2. Compile-Time Improvements 10
3.1.3. More Efficient Use of Compiler Streams 10
3.1.4. Address Clause Support 10
3.1.5. <Elab_Order_Listing> file 11
3.1.6. Object-Module Converter 11
3.2. Improvements in Generated Code 12
3.3. Shared-Code Generics 12
3.3.1. Pragma Generic_Policy 12
3.3.2. Pragma Instance_Policy 13
3.3.3. Shared-Code Generic Features 14
3.3.4. Guidelines for Using Shared Code Generics 15
3.4. Code Views and the Predefined Subsystem 17
3.5. Other New Features 17
3.5.1. Pragma Assert 17
3.5.2. Pragma Collection_Policy 17
3.5.3. New Attribute: 'Homogeneous 19
3.5.4. Object Writer 19
3.5.5. Elaboration Checks 20
RATIONAL October 1992 iii\f
Rational Cross-Development Facility:
M68020/OS-2000 Release Information
iv October 1992 RATIONAL\f