RDROYA01@ULKYVX.BITNET (Robert Royar) (01/14/87)
The following code illustrates a problem with the Alcyon compiler (version
4.14). One of two errors may occur:
1. if you compile this with the line (if you compile anything with
the line)
c068 test.i test.1 test.2 test.3 -f
you get "intermediate code errors" from c168. C168.prg does not
seem to be able to compile *any* floating point code if the
-f option is given on the c068 command line.
2. if you compile without the -f option, c068 writes in the
appropriate lines for double conversion, but the final program
hangs in the printf() routine after writing "a[0] = " (no bombs,
no nothing).
I have code that compiles and works properly using floats, but not arrays
of floats. I compiled it *without* the -f option. It too bombed the C168
program with "intermediate code errors" when compiled *with* the -f option.
I tried compiling the code below using the old version of Alcyon with and
without -f. The code compiled fine and did not hang when run, but I could
not get double precision numbers (no double precision library). But to get
that code to work, I had to add an additional double variable (d) and
assign a[i] to d then rewrite the printf() to printf("a[%d] = %f\n",i,d).
It's difficult to tell whether the problem here is in printf() or in the
double precision number's format. But attempting to use ftoa() (which
printf calls) bombed before getting to printf. It's also difficult for a
non-math type to read a floating point number using the debugger.
The intermediate code error bothers me the most, as it means no program can
be compiled with Alcyon to use floats (doubles) properly. I have also
discovered that since c068 places code to sptodp in the output file, you
cannot link with 4.14 files and libf by itself (if floating point
operations are referenced) because you will get linker errors about
undefined terms. That's ok if you are not actually using floating point,
but if you are, then the program will bomb. If you link with both floating
point libraries (a suggestion made earlier), the program will link and will
not bomb, but the values returned by fp operations will be unpredictable
garbage. I intend to copy the old CP/M-68K IEEE library over to the atari
from my old computer within the next few days and see if that library will
allow doubles on the ST using the old Alcyon compiler. I imagine I'll run
into some trap problems, but if it works, I'll let you know. In the mean
time I hope that someone at Atari has a line to Alcyon and can look in to
this problem. Also, if someone else would try to compile the program below
using the -f option, and let me know if you get the same intermediate code
errors I did, I'd sure appreciate it. It's hard to believe an error so
blatant as this has not been discovered before. And I begin to wonder
whether I might just have gotten a bad copy of the compiler.
----------------- code to illustrate floating point bug --------------------
#include <stdio.h>
main()
{
static double a[15];
static double b, c;
int i;
c = 5.00;
b = 6.00;
for (i=0;i<14;i++)
{
c = c + 1.00;
b = b + 2.00;
a[i] = (b * c);
printf("a[%d] = %f\n",i,a[i]);
}
exit(0);
}
P.S changing %f to %lf in the printf does not change the precision of the
number.