1. Length clauses to allow user
specifications for size and length are supported. In
particular, overhead for user-specified sizes is
generally limited to that of zeroing out the extra
space. However, if the specified size is not
byte-aligned, some overhead could be incurred due to the
use of bit operations.
2. Record representation clauses do
allow representation at the bit level.
3. Record components of discrete types
ranging in size from one bit to the number of bits in a
storage unit, in increments of one bit, are fully
supported.
4. Address clauses are supported.
5. The ability to interrogate the
ADDRESS attribute of any object, (e.g., an individual
record component), or subprogram is supported.
6. The location of code, data, and
constant sections can be specified independently.
However, dynamic objects are understood not to be
specifiable in this manner.
7. The location of an object,
subprogram, task, or package in memory is user
selectable at compilation time through the use of
representation specifications. It is also selectable at
link time.
8. When storage is reserved for a
collection, it will contain user-allocated objects.
9. When storage is reserved for a task
activation, it is for stack space.
10. An alignment clause must request
alignment in powers of 2.
1. It is possible to perform unchecked
type conversions between source objects whose
representations in bit length are smaller than or equal
to those of the target objects.
2. No exceptions are raised from
Unchecked_Conversion.
3. Unchecked deallocation of dynamic
memory is supported. The result of calling an instance
of Unchecked_Deallocatlon is that exiting a scope which
declares an access type results in the deallocation of
each collection whose types are going out of scope. This
process results in automatic reclamation of storage that
is no longer referenced, except that within a declaring
scope.
1. All data lengths that are supported
by the underlying hardware for integers are supported by
the compiler.
2. All data lengths that are supported
by the underlying hardware for unsigned integers are
supported by the compiler. Support for emulation of
32-bit unsigned arithmetic without overflow checks is
provided in a package of compiler intrinsics.
3. All data lengths (e.g., single and
double precision) that are supported by the underlying
hardware for floating-point types are supported by the
compiler.
4. Multiply-dimensioned array objects
are stored in row-major order
5. All data representations are
documented in the user manual.
1. All run-time checks can be disabled
via a compiler switch or pragma.
2. Logical operations (AND, OR, XOR,
and NOT) on packed-bit arrays are performed in-line.
3. Unreachable code can be identified
and suppressed by the compiler.
4. Static valued constants can be
initialized prior to load time and fixed in ROM data
areas. (Our questioner defined static valued constants
as objects which are declared as constants and are
assigned permanent values which can be determined prior
to run-time at reasonable cost. These should include at
least Ada static expressions and aggregates whose
subtypes and scalar components are all static in the Ada
sense.)
5. An intermixed Ada source and
assembly code listing can be generated by the compiler.
6. The TADS system does support IEEE
695 object code format through a conversion tool that
converts TADS Object File Format (TOFF) files to IEEE
695 and many other industry standard formats. The TADS
compiler and linker generate TOFF, a format that
provides richer symbol table information than IEEE 695.
This information allows more Ada-specific information to
be preserved, for example, Ada type information.
7. On the VMS plafform, re-entrant
compiler operation is supported; that is, several users
can operate the compiler simultaneously from a single
copy rather than each user having an individual copy of
the compiler resident in memory.
8. The compiler does not support
conditional compilation, which the Ada standard does not
permit. Ada does permit a partial alternative -- folding
based on static expressions -- which TADS does support.
1. No overhead exists for generic
procedures and functions or for procedures and functions
in a generic package over their non-generic
counterparts.
2. Variants of discriminated records
do occupy the same amount of storage.
3. Information on the representation
of discriminants and the rules for the storage of
discriminated records is included in user documentation.
4. The heap allocation space can be
specified by the user.
5. Task creation is the only Ada
feature that implicitly results in calls to the storage
manager.
6. The user can specify a maximum
stack size.
7. Stack space can be allocated at
compile and/or link time.
8. The stack is dynamically
extensible:
The user gets a dynamic stack by default. This feature
may be disabled by applying a length clause to each
task. The user must also supply a pool of stacks at
linktime. They may be specified to be static or dynamic.
9. On the subject of overhead for
stack overflow detection:
When no additional stack space beyond that consumed by a
call is required, the minimum overhead for stack
overflow detection (per call) is zero. A more frequent
case is that a write to a stack is performed. The worst
case, occurring in rare instances, is that a runtime
call to a stack check routine is made.
The minimum is chosen automatically.
In any other case, stack checks can be suppressed by
pragma SUPPRESS or by a compilation switch.
10. Collections (i.e., access types to
which size clauses have been applied) are supported.
12. Separate assembly unit modules are
supported like separate Ada compilation units to
facilitate automatic linking of these modules. The user
should use the foreign or interface commands in the
librarian.
13. The compiler can decompose Ada
compilation units into separately linkable units by
subprogram and static data object. The compiler
separates subprograms in a compilation unit into
separate sections which are included or excluded at link
time depending upon whether they are referenced. It
separates individual static data items in a package only
if address representation specifications are given.
1. The current version of an obsolete
unit can be re-acquired through user control. The user
can perform a remake (to recompile the system) that
makes the unit consistent again. The remake command uses
the internal source -- the last source compiled or
parsed into the library. The user can also extract
source to get the source of the obsolete unit.
2. The library system supports
automatic inclusion of the "with" tree.
2. The following task scheduling
algorithms are supported:
Preemptive priority
Time-slicing
Round-robin
FIFO
The runtime system uses a
priority-driven preemptive scheduler. Time-slicing,
round-robin and FIFO schedules can be created using the
TADS ARTClient Package.
3. Interrupts that affect tasking (as
defined by PREEMPTER_ MASK) may be locked out for longer
than 12 instructions (the maximum for interrupts that do
not affect tasking) in order to protect the dispatch
code from mutiple entries.
4. The maximum number of tasks that
can be executing at one time is limited only by the
amount of memory available.
5.The conditions under which a task
reschedule occurs are: interrupts, preemptions, and
synchronization points. The user can, however, force a
reschedule by using of the ARTClient package.
6.The DELAY is configurable to any
number greater than 1 tick of Timer B. The default
setting is 20 ticks. The delay can be set by the user.
7. The compilation system and runtime
system avoid the cost of supported task termination and
aborting when these features are not used.
1. Unused subprogram elimination is
supported for any procedure by the linker, through weak
references and selective linking, under all
circumstances. However, a section that might be
otherwise eliminated may be designated as
"required" (not subject to exclusion because
it is not referenced) by a command in the linker control
file that forces it to be loaded.
The debugger supports interfacing Ada
with non-Ada routines, but only Ada is supported at the
source level. Non-Ada routines may still be debugged at
the machine code level.
AdaScope allows the user to insert
small code patches in Ada during the debugging process
so that some problems can be corrected without
recompiling. These patches can be logged and read in
when AdaScope is again started. Only after considerable
debugging, or as a final step, will a recompilation be
necessary to actually insert the new code in the source
files.
It is possible to restart an embedded
program without reloading it from ROM or the development
system loader through the AdaScope autoload feature.
AdaScope operates remotely from the
host to debug a program that is executing on the target
processor. Connection is usually through an RS-232
serial line. Other connections may be supported using
the optional AdaScope Link Retargeting Kit. This kit
provides the means for changing AdaScope's
communications format. See the technical summary for a
description of the Link Retargeting Kit.
A second kit called the AdaScope
Protocol Retargeting Kit is available for a complete
retarget of the AdaScope back end to a hardware device.
This kit would be used to retarget AdaScope to some
emulator-type device more complicated than a bare board
and not currently supported. See the technical summary
for a description of the Protocol Retargeting Kit.
Customer Quote:
"Thank you for the excellent support during our evaluation phase... I need to make special mention of Michael, the support and comments he made really put me on the track of finding solutions very fast."
