john@minster.york.ac.uk (11/17/88)
Will the Minix cc(1) ever fully implement floating point types? For
those of you who havn't tried compiling a program containing types
float and/or double, one gets the compiler message (PC Minix 1.2):
warning: dummy floating point constant(s)
An inspection of the code produced shows that all-zero bit constants
are output, but that plausible-looking C library subroutine calls are
produced for floating point operations. An examination of the C library
code shows that routine stubs are present.
This is not news to many Minix enthusiasts out there, I know. Is
there a good reason *not* to add floating point support? (I know only
of Dr. Tanenbaum's "I havn't used a number bigger than 32767 in years"
argument - which, I feel, misses the point, somewhat).
I believe that there is little point in adding all-software floating point
support (for the PC, at least), when all it would take is for the
owners of the cc(1) code generator to alter it to produce 80X87 (IEEE
standard) constants, and for someone to flesh out the C library routines
to use 80X87 operations. There wouldn't even be the need to alter asld(1)
to incorporate 80X87 operation mnemonics (need they be used anywhere
other than in the library routines?) - as `.byte' directives would do.
Naturally, the library would have to check (once) for the presence of the
floating point hardware.
-------------------------------------------------------------------------------
John A. Murdie "The End of our Foundation is the knowledge
Dept. of Comp. Sci. of Causes, and secret motions of things;
University of York and the enlarging of the bounds of
England Human Empire, to the effecting of all
things possible"
ukc!minster!john Francis Bacon, "The New Atlantis", 1627context@june.cs.washington.edu (Ronald Blanford) (11/20/88)
In article <595768844.26413@minster.york.ac.uk> john@minster.york.ac.uk writes: > ...all it would take is for the >owners of the cc(1) code generator to alter it to produce 80X87 (IEEE >standard) constants, and for someone to flesh out the C library routines >to use 80X87 operations. I suspect it would require changes to the kernel as well, to save and restore the state of the 80x87 on context switches. Those who don't use floating point might not want the overhead, so the kernel should try as well to identify the offending programs. Be that as it may, even software floating point would be nice. When people finally get around to doing graphics, they will find that representations of screen coordinates and color values are most naturally and portably expressed as floating point values in the interval [0,1]. Porting existing graphics packages will be difficult without it. -- Ron