What is "__fltused" symbol?

[Douglas J Leavitt]

In article <1990Feb21.192534.22925 at eci386.uucp> jmm at eci386.UUCP (John Macdonald) writes:
>In article <25da2b6b:900.1comp.unix.i386;1 at vpnet.UUCP>
>    hb at vpnet.UUCP (hank barta) writes:
>| Could it mean "floating point used?" 
>| 
>| Some compilers generate these symbols to cause portions
>| of libraries to be loaded when they are otherwise not referenced. ...
>|
>| Disclaimer: The above is an educated guess. Perhaps there is another
>| reason for this symbol.
>| 
>You are basically right, although the usage that I have seen has been
>slightly different.  What ends up being loaded by the __fltused
>reference is a version of the low-level printf routines that has full
>support for floating point.  If the reference is not present, then
>after loading printf, a different low-level set of routines will be
>used that only support integer.  ...

These statements are also close (and based on past reasons for other C
compiler systems), but are not the true reason it existed for the 386.

I can state this with some confidence as I was the original author
of the 386 C compiler on the System V/386 release.  I was also the person
that had to make the decision to put the variable in the compiler in
the first place.

Basically the variable is an aberation and is totally unnecessary for
any 386 C compiler that people who have ever received an offical AT&T or
AT&T related release would have ever seen.

The story goes like this.  When ISC was originally hired by AT&T and Intel
to do the initial port to the 386, the contract called for a C compiler
to run on a 386/287 [<--- NOTE I said 287] combo.  This was due to the
estimated dates of the release of the 386 and unix as compared to the
release dates of the 387 and the already existing of the 287.  At the time
it was estimated that the 387 would be something like a year after the
first release of System V/386.  [ As I recall from 4 years ago memory].

I proposed that the best way to get performance out of the 386/287
combination was to treat the 287 as a register set and not a stack
model.  This has to do with the fact that the 287 is EXTREMELY slow
getting in or out memory for loading values.  Hooking a 287 to a 386
only makes it worse.  Treating the 287 as a register set [by performing
an abnormal number of fxchg instructions and other stuff] can actually
make the 386/287 combo signifcantly faster [like 50%] over treating it
like the generic Intel stack format.

Anyways, the proposal was approved by all the necessary parties, and the
compiler was written as such.  To make this system work effectively the unix
kernel at program startup time performed 8 fld 0.0's to the floating point
stack.  [The compiler assumed the stack was full not empty at startup time].

This compiler lasted up till approximately System V/386 Beta time frame.

At this point, it was discovered that the 387 timeframe was much less and
in fact 387's would be available by the official System V/386 release from
AT&T.

Now we had a problem.  The 387 timings had changed sufficiently [IE the
memory in/out times had increased significantly over and above the
timings of the pother parts of the 387 chip] to make the stack scheme
look more appropriate once again.  For instance fxchg instructions timings
only increased in a manner appropiate with the clock timings, while the
actual fld/fstor timings dropped at least 60% over and above the clock
timings.  Clearly the compiler needed chaning.

So, for an interm amount of time, between System V/386 beta and final
release, the register based 387 code was ripped out of the compiler
and the 8 fld's were ripped out of the kernel.  Unfortunately an interm
solution [while there was no stack based compiler and the kernel didn't
have the fld's] was needed.  The solution was to add the __fltused
flag, to temporarily use the old pdp11 fp emulator trick with libc
[as described by others above] to have 8 fld's be executed by the
program at start up.

When the final version fo the C compiler was completed, the libc routines
were pulled, but by a fluke the 2 or 3 C source lines in the compiler
were forgotten.  Hence, AT&T didn't get a chance to remove them for the
first official release of System V/386 [IE the 5.3.0 release], and by the
System V/386 Release 2  [IE 5.3.2] they forgot altogether.

At ISC, somewhere between our 5.3.0 release 1.0.0 and our last 5.3.0
release 1.0.6 while fixing an obscure C compiler bug we realized that
the 2 or 3 statements still existed and yanked them.

When 5.3.2 came out we realized that AT&T had never yanked the lines,
however we have never had sufficient reason to go back into the C compiler
to do any bug fixes since somewhere in the 1.0.* days, so we have never
yanked the lines again.

I expect that most likely we won't, as making unnecessary gratuitious
C compiler changes is not sufficient reason to warrant the amount of
regression testing we would have to do because of this.

So, in summary, it doesn't really matter because it's never used and
should be pulled out, and maybe someday AT&T will do so if they so
incline, and I doubt that they'll ever get down that far on the
bug/enhancement list to make it matter.


		Douglas J Leavitt
		386/ix X11 windowing system development group
		Formerly the the System V/386 C compiler developer
		at:
		Interactive Systems Corp.
		Santa Monica Ca.
		dougl at ism.isc.com
		dougl at ism780c.isc.com
		{ ico, ima, amdahl, oliveb, uunet } !ism780c!dougl