Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!ico!ism780c!madison!dougl From: dougl@madison.ism.isc.com (Douglas J Leavitt) Newsgroups: comp.unix.i386 Subject: Re: What is "__fltused" symbol? Message-ID: <39129@ism780c.isc.com> Date: 22 Feb 90 20:36:30 GMT References: <204@ncrday.Dayton.NCR.COM> <25da2b6b:900.1comp.unix.i386;1@vpnet.UUCP> <1990Feb21.192534.22925@eci386.uucp> Sender: news@ism780c.isc.com Reply-To: dougl@madison.ism.isc.com (Douglas J Leavitt) Organization: Interactive Systems Corp., Santa Monica, CA Lines: 109 In article <1990Feb21.192534.22925@eci386.uucp> jmm@eci386.UUCP (John Macdonald) writes: >In article <25da2b6b:900.1comp.unix.i386;1@vpnet.UUCP> > hb@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@ism.isc.com dougl@ism780c.isc.com { ico, ima, amdahl, oliveb, uunet } !ism780c!dougl