Here are some of things that we have been working on over the past year or so:

• We have successfully completed validation of our three Janus/Ada 95 compiler packages under ACVC 2.0.1. Affordable validated Ada 95 packages for Microsoft Windows NT/95, 32-bit DOS Extender, and 80386 Unix are available now.
• Windows programmers will be thrilled to find out that we are introducing a new GUI environment soon, designed to give the same sort of look and feel seen in mainstream commerical Windows 95 products.
• We will also soon unveil Claw, built to provide Ada programmers with all of the capabilities that Microsoft Windows 95 and NT offer without having to use any other language's compilers.

Those of you that stayed in touch we thank you, and for those that haven't, we hope that you will take a minute to read the newsletter.

Here's how it works. Let's say you bought a Janus/Ada PDS for $500 back in 1992. Today you decide to get a validated Ada 95 compiler for your Pentium running Microsoft Windows NT. You check our web site and see that the Janus/Ada 95 Professional Development System for Windows 95/NT is priced at $495. Since the different in price between the two packages is negative, you pay just $100 to upgrade after getting a one-year Product Support Agreement for $150. Net result: you would pay just $250 for a brand new package with one year of product support.

Well, those days are over. Janus/Ada 95 version 3.1.0 includes a comprehensive and powerful project management system. Better still, the only thing you still need on your Path is the directory that the compiler is installed to. So now it is possible to install the compiler once, and forget it, with no annoying batch files to fiddle with.

The Janus/Ada project manager provides advanced features for structuring program development, without sacrificing the ease of use for which our compiler is famous. The project manager, combined with Corder, provides single command building and rebuilding of the most complex systems.

Many things can be done with the project manager, including: building systems with multiple executable programs with a single command; managing an application with separate versions for several target operating systems; creating libraries of reusable units for use in many applications; and even doing all of the above at once.

The project manager is not a separate program, but rather a module integrated into every Janus/Ada tool, including the compiler, linker, development environment, and compilation order tool.

Despite its power, the user need do nothing at all to use it! Simply by compiling an Ada source file, a library and project are created, with links to the appropriate Ada runtime. Easy to use options provide control over the library path and project name, allowing significant structures without ever using a special tool. The compilation order tool writes all of the information it determines into the project manager, so none of the information must be redetermined, and it can be shared with future builds of this and possibly other programs. The compilation order automatically determines dependencies and obsoleteness without user intervention, and may in many cases also determine the source files needed.

The project manager also automatically prevents problems which otherwise would occur when multiple compilations (or other tools) are working in the same location. This can happen on multi-user systems, but is even more likely on modern systems like Windows NT, which support multiple tasks for a single user, and may even have multiple CPUs available. In these circumstances, a user (or tool) launching multiple compilations at the same time is quite likely.

For more complex systems, explicit manipulation of the project management data is needed. For instance, to use a shared, reusable library of Ada units, a link to the library’s project needs to be created. This can be done via the enhanced version of JManager, (for links and projects only) by commands available in the compilation order tool, and (eventually) by new versions of the programming environment.

JManager commands are also enhanced to provide several smart deletion capabilities, which can delete all of the compiler-generated files for a particular source file, or an entire project and all of its (local) contents.

The use of JManager’s deletion facilities has always been recommended, and now is more important then ever, since the project management information must be updated when files are deleted. JManager also can display selected parts of the project management information, including the contents of SYM and JRL files. JManager can also add, modify, and delete the project management information directly (which should only be used for repair of the project management information).

The new project manager is part of all new Janus/Ada compilers. As always. new compiler versions will be sent to you automatically if your maintenance agreement is up to date.

A user sent following short Ada program which documents a nasty bug concerning floating point types. Equity operations for floating point values fail.

Back in the old days, FORTRAN programmers had a rule that you should never compare two real numbers for equality. This program illustrates why that rule is still good today. Simply put, comparing two independently derived floating point numbers for equality is playing with fire.

To see why, we need to look at Ada’s model number rules. (I’ll stick to the stricter model found in Ada 95, Ada 83’s model allows even more flexibility.) In Ada, a model number is a number which can be exactly represented by the bit pattern of the floating point number. 0.5 is an example of such a number. All other numbers are represented by a model interval - a range of two consecutive model numbers. A non-model value can be represented as either the model numbers, or a number in between. Normally, the only values representable are model numbers, so a value will be represented as some model number or other.

Ada allows either of two representations for most values, but does not say anything about how those values are chosen. In particular, there is no requirement to choose the ‘best’ value, nor even to choose the same value on successive executions of the same expression or literal. Therefore, Ada’s rules allow even X=X to fail for most representations as long as the value of X is not a model number. Thus, the program does not show a bug at all, just allowed behavior for an Ada compiler.

Why would any compiler intentionally produce a different answer for what amounts to string to float conversions? Ada requires exact evaluation of expressions at compile time, meaning that unlimited precision operations must be used in the compiler. To enforce this, the Ada validation suite contains tests like:

Obviously, the code which converts from an unlimited precision representation is complex and very different from code which converts from a string. What is less obvious is that is also quite slow. This does not matter at compile time, since most programs only contain a few static floating point expressions (which includes literals). A slow algorithm can’t be used in Text_IO, since it may be called on to read or write tens of thousands of values in a program Therefore, Text_IO uses a different algorithm to choose the value, and therefore can return a different result in some boundary cases.

The value 123_456.789 seems to be almost exactly midway between two model numbers, and therefore is more likely to result in different answers than numbers which are closer to one model number or the other.

We have recently tweaked the code in Ada.Text_IO to improve performance by using some new Ada 95 operations. These changes may improve the situation for our Ada 95 compilers, but it is very unlikely that every possible number would come out equal.

What to do if you can use equality? Well the best answer depends on what exactly you are trying to do. For many cases, you can use “<=” or “>=” instead, which eliminates the problem. For some algorithms, you are simply trying to get an answer that is close enough to another answer to quit the iteration. In that case, a test against Epsilon will work:

exit when Abs (Answer-Previous) Long_Float’Epsilon*Answer;

For Ada 95, the use of a membership and the ‘Pred and ‘Succ attributes allows a test against a model interval:

if A in Long_Float’Pred(8) .. Long_Float’Succ(8) then

It should be clear that most of these choices are more expensive at runtime than a simple equality test. That is the cost of floating point numbers.