marlene@ncrday.Dayton.NCR.COM (marlene) (02/13/90)
In Interactive Systems 386/ix 2.0.2 there is a symbol used in many of the routines in the C libraries called "__fltused". It is not in 386/ix 1.0.6. When using the 'nm' command I see it being an external symbol of value 0 everywhere, but I never see where it is really defined. Can anybody tell me its type and what it's used for? Marlene Schrand NCR - Dayton Systems Engineering m.schrand\@dayton.ncr.com
zmact61@doc.ic.ac.uk (D Spinellis) (02/14/90)
In article <204@ncrday.Dayton.NCR.COM> marlene@ncrday.UUCP () writes: >In Interactive Systems 386/ix 2.0.2 there is a symbol used in many of the >routines in the C libraries called "__fltused". It is not in 386/ix 1.0.6. >When using the 'nm' command I see it being an external symbol of value 0 >everywhere, but I never see where it is really defined. Can anybody tell me >its type and what it's used for? It is used by the Microsoft languages to indicate that a floating point library needs to be loaded. The symbol is declared as extern in all code that uses floating point and is defined in the floating point library. In this way it forces the library to be loaded when needed. This is needed because of the way a comprocessor is emulated. A program may be using floating point without having any external symbols defined in a floating point library. Diomidis -- Diomidis Spinellis Internet: dds@cc.ic.ac.uk Department of Computing UUCP: ...!ukc!iccc!dds Imperial College JANET: dds@uk.ac.ic.cc London SW7 2BZ #include "/dev/tty"
hb@vpnet.UUCP (hank barta) (02/15/90)
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. For example, the compiler could use a floating point emulator (software) and then compile instructions for the 80387. Then when the code runs on a machine w/o the 80387, the instructions cause a trap. The trap handler passes control to the floating point emulator which then does the computation in software. But the trap operation does not require an address the way a subroutine call would, so the compiler puts an unresolved (an otherwise do nothing) reference in the object which is resolved by the particular library module. Disclaimer: The above is an educated guess. Perhaps there is another reason for this symbol. Hank
jmm@eci386.uucp (John Macdonald) (02/22/90)
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. | For example, the compiler could use a floating point emulator | (software) and then compile instructions for the 80387. Then | when the code runs on a machine w/o the 80387, the instructions | cause a trap. The trap handler passes control to the floating point | emulator which then does the computation in software. But the | trap operation does not require an address the way a subroutine call | would, so the compiler puts an unresolved (an otherwise do nothing) | reference in the object which is resolved by the particular | library module. | | Disclaimer: The above is an educated guess. Perhaps there is another | reason for this symbol. | | Hank 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. This dates back to the days when the size of the code to support floating point input and output was significant compared to the size of programs and computer memories of the day. It is possible that the same sort of trick is being used to load a floating point emulator (but generally I have seen emulators loaded into the kernel, or compiler-generated invokations of software subroutines as the "normal" method of handling the abscence of floating point hardware. -- Algol 60 was an improvment on most | John Macdonald of its successors - C.A.R. Hoare | jmm@eci386
dougl@madison.ism.isc.com (Douglas J Leavitt) (02/23/90)
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
misko@abhg.UUCP (William Miskovetz) (02/24/90)
In article <39129@ism780c.isc.com>, dougl@madison.ism.isc.com (Douglas J Leavitt) writes: A whole bunch of stuff deleted... > > 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 I'm a little confused by this. I have an old (release 3.1) AT&T compiler, and a new (V4.1.5) ISC compiler. Doing a: nm libc.a | grep fltused I get a number of entries in the ISC libc.a library. But, doing the same command on the AT&T libc.a, I get no entries for fltused. This seems to indicate that AT&T did remove the fltused code, but ISC didn't. This makes it impossible to substitute the AT&T libc.a for the ISC libc.a since when linking you get an unresolved for __fltused. The ISC libraries have a bug in rounding when printing (fprintf) floating point numbers. I was hoping to try to substitute the AT&T libraries, but they are incompatible. Substituting them in just gets me unresolved __fltused. Do I have this backwards and AT&T removed the code but ISC didn't? Bill Miskovetz {uunet!lll-winken, apple!mathworks}!abhg!misko misko@mathworks.com abhg!misko@lll-winken.llnl.gov
richard@pegasus.com (Richard Foulk) (02/24/90)
> >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. > Author? Sounds like alot of re-inventing the wheel. Isn't the compiler a port of pcc or something? Just curious where it actually came from. -- Richard Foulk richard@pegasus.com
mike@antel.uucp (Michael Borza) (02/25/90)
In article <39129@ism780c.isc.com> dougl@madison.ism.isc.com (Douglas J Leavitt) writes: > [an interesting story about what __fltused was for...] As an aside, it appears that a symbol named _fltused was also used in the kernel of the 1.0.6 release which was set at boot time, based on the configuration information in CMOS RAM. This symbol had at least three legal values, as I recall, indicating the presence of either a '287, '387, or no coprocessor. (I believe kernel support for the Weitek chip was handled differently.) After piecing together a 386 system to run 386/ix on, I ported a number of integrated circuit simulation tools to my speedy new platform. Just for kicks, I went back to do a comparison to my home machine, a 286 with 287 running Microport SV/AT at the time. Makes and edits were blindingly fast, but my 286/287 combination was keeping up handily with the floating-point intensive simulation software. After a couple of days on the phone with HCR, my software vendor, we found out about _fltused, which we could inspect and change with crash. FP performance came up to expectations. It turns out that an early version of a Phoenix BIOS was to blame, which sometimes found the 387 at boot time, sometimes not (more times not, as it turned out). A quick switch to an AMI BIOS solved that problem. I've never gone back to see whether _fltused is used in the 2.0.x kernel. mike borza. -- Michael Borza Antel Optronics Inc. (416)335-5507 3325B Mainway, Burlington, Ont., Canada L7M 1A6 work: mike@antel.UUCP or uunet!utai!utgpu!maccs!antel!mike home: mike@boopsy.UUCP or uunet!utai!utgpu!maccs!boopsy!mike