Re: Aonix ObjectAda and ETX

Re: Aonix ObjectAda and ETX

[Dave Wood]

I hesitate to provide an answer to the originating
post because the author is presumably looking for
objective information and I would be a suspect
source.   :)

However, in looking at the response below, it is
important to bear in mind the context of what is
described versus what was asked.  The question was
about an Ada 95 product called "ObjectAda Real-Time 
for Intel/ETS", which is a marriage of ObjectAda for
Windows with Phar Lap's ETS real-time kernel and 
toolset.  The response below is about an Ada 83 
product called "AdaWorld" (or perhaps its Windows-
hosted cousin "ActivAda") used in conjunction with 
Phar Lap's DOS extender.  

The former is intended specifically for the creation 
of hard real-time/ embedded applications with 
requirements for deterministic performance on
Intel target platforms.  The latter is intended 
to create DOS-compatible programs devoid of the 
vanilla DOS memory limitations.

In summary, the products have little in common
other than using the same Intel code generator.  
Everything else, including the environment,
look-and-feel, compiler front-end, library 
system, host tools, Ada runtime, target OS, 
target-specific tools, performance, determinism, 
packaging, installer, documentation, etc., is 
quite different.

This is not intended to invalidate the comments
below, only to put them in context.  I hope you
find this information useful.

-- Dave Wood, Aonix
-- Product Manager, Win32 and Java products


Michael F Brenner wrote:
> 
> Rather than answer the question about how reliable AONIX is, let me
> answer the question about how reliable its predecessor ALSYS Ada with
> PHARLAP is. Alsys Ada is an Ada-83 compiler, not an Ada compiler, and
> is no longer supported, but is still used on various projects.
> 
> On several projects, I maintain compatibility between Ada-83 and Ada
> by only using the compatible subsets and by switching package bodies
> in a few cases and package specs in the case of unsigned numbers.
> 
> This is needed because of the performance of gnat on packed arrays,
> which is critical to fast, predictable, realtime performance during
> games, simulations, graphical displays, and computation.
> 
> Alsys is numerically stable, although its trigonometric functions
> appear to be accurate only to about 9 decimal places. Its
> Pharlap functions appear to work correctly to get at the interrupts,
> files, ports, absolute memory, and most hardware functions.
> 
> On the kind of tasking these projects do, it is meeting its deadlines
> both for the cyclic tasks and for the interrupts.
> 
> It is unpredictible on the amount of delay it introduces from reading
> the serial ports, however, and this may be a runtime bug in either
> the Ada runtime or the Pharlap runtime interfering with the port I/O,
> something like what Linux or NT does to the ports to make them so much
> slower than pure DOS. However, it writes to the ports at the speed of the
> port without introducing any delay.
> 
> Speaking of DELAY, there is a varied response to the DELAY command,
> sometimes skipping delays that should have waited, and sometimes
> waiting indefinite periods of time, when used outside of a tasking context.
> 
> Text_io, sequential_io, and direct_io are not as fast as I/O operations
> that directly call on the Pharlap routines to do I/O (I have those
> calls if anybody wants them, working through the Alsys runtime library).
> 
> Performance is about equal to gnat except on packed arrays which are
> faster than gnat running the same code.
> 
> There are a couple of anomalies regarding the hierarchical library
> system, with the following workaround: ignore all the documentation
> and recompile the world any time you compile something in any
> parent library--you can only recompile things in the lowest level
> libraries without getting a MAC-dereference-buffer-level-0-library
> access error.
> 
> The compiles must be done in compilation order, unlike gnat which
> compiles during development in almost any order (all SEPARATE
> subprograms must be present to generate code). Alsys, on the other hand
> can compile and generate code for a subprogram with NONE of the
> SEPARATE subprograms present. Gnat, however, has the corresponding
> difficulty that you cannot compile an Alsys file (delivered as a
> single file), but must divide it into a file per unit with unique
> 8.3 names, and when the gnat algorithm for 8.3 names overlaps two names
> you MUST rename your units. Alsys compiles a little slower than gnat but
> links a lot faster; overall, compiling and linking together unoptimized
> is about twice as fast in gnat, but about the same at highest optimization
> level.
> 
> The setup for Alsys is much more complex than gnat. Gnat installs
> by just unzipping djgpp and some gnat zip files into a single directory,
> then setting some flags. Alsys comes replete with hidden files,
> scripts that require you never to move it to another directory, and
> other inconveniences. All programs should install using a batch file
> that unzips the program into the desired directory and APPENDS
> flags onto the autoexec.bat file with no other side effects, onto
> this kind of realtime machine (DOS plus extender, for example).
> 
> Some of the subsidiary tools in my version of Alsys have some bugs,
> such as MAKE and DEBUG.
> 
> In summary, Alsys works reliably and competes with gnat
> for speed of execution except Alsys is faster for packed arrays
> like VGA screens, VGA screen shadow arrays, and large data structure
> arrays without pointers.
> 
> I have nothing to report about pointers, since in realtime systems
> we only use them to trick the compile into pre-allocating storage
> on the heap for compilation systems that provide a limited amount of
> stack space. No dynamic allocation or deallocation is normally done
> in a realtime system.
> 
> Finally, the number of bugs in Alsys Ada is very low. Gnat is not far
> behind, but I am about 3 bugs away from saying that gnat is very low
> in bugs. Most important is the performance of packed arrays.
> 
> Hopefully, these observations will help you, even though they are
> for the predecessor product.