robison@uiucdcsb.cs.uiuc.edu (12/07/86)
I've heard of another scheme, but never tried it: Code generation emits a call to a floating point library. If the FP hardware is available, the library routine changes (at run time) the call instruction to the equivalent hardware instruction. This way you pay for the subroutine linkage only on the first call. The disadvantage is that self-modifying code is not allowed on some architectures. Arch D. Robison robison@uiucdcs University of Illinois at Urbana-Champaign
hutch@sdcsvax.UCSD.EDU (Jim Hutchison) (12/08/86)
In article <165100001@uiucdcsb> robison@uiucdcsb.cs.uiuc.edu writes: >Code generation emits a call to a floating point library. >If the FP hardware is available, the library routine changes >(at run time) the call instruction to the equivalent hardware >instruction. This way you pay for the subroutine linkage only >on the first call. The disadvantage is that self-modifying code >is not allowed on some architectures. An interesting notion. The ibm pc&at do this the other way 'round. They get a fault (interrupt) from the instruction faulting due to the missing floating point hardware, and insert the emulation call in its place. This is atleast the run-time environment provided by PC/IX, your mileage may very. In supervisor mode you can get away with anything, in this case there was no protected mode (but that is another nightmare altogether). Modifying code in this instance is not such a bad thing, after all what are the chances that the device will appear suddenly? It has the nice aspect of allowing for hardware upgrade without having to recompile the code (which you may have only a binary for). With the overhead only increased on the first call/execution, what is the big flaw in this design? Noting that in shared/retained text that this overhead is removed by the first execution over all uses. -- = Jim Hutchison UUCP: {dcdwest,ucbvax}!sdcsvax!hutch ARPA: Hutch@sdcsvax.ucsd.edu panic -- no witty phrase
tjk9747@acf3.UUCP (Tom Kessler) (12/09/86)
Another similar example is MVAXen (under ultrix) which fault on instructions (like crc polyf and some of the other silly ones) thus invoking software emulation.
jc@piaget.UUCP (John Cornelius) (12/11/86)
In article <165100001@uiucdcsb> robison@uiucdcsb.cs.uiuc.edu writes: > >Code generation emits a call to a floating point library. >If the FP hardware is available, the library routine changes >(at run time) the call instruction to the equivalent hardware >instruction. This way you pay for the subroutine linkage only >on the first call. The disadvantage is that self-modifying code >is not allowed on some architectures. > I wrote microcoded floating point for a machine that is now (mercifully) out of production that did that. The floating point library actally executed an instruction that replaced the call to the library with a real floating point instruction. That was 15 years ago and I've become somewhat wiser now. In the meantime, the microcode wound up in several hundred Meta-IVs, many of which are still floating around out there. -- John Cornelius (...!sdcsvax!piaget!jc)
db@cbosgd.ATT.COM (Deceased Bird) (12/17/86)
The original poster seems to be looking for automatic ways of handling floating point, so perhaps that's why nobody mentioned the obvious alternative: use a compiler switch (i.e., manual direction) to control the generation of the floating-point code. A related question: what percentage of C compilers for PC- type machines support floating-point hardware? Are there many out there that simply do not offer 8087 support? Or do the vast majority of compilers use one of the automatic schemes described on the net? (N.B. This question is academic -- I own a Mac and have no plans to write a compiler or upgrade to a Levco Prodigy any- time soon :-))
kissell@garth.UUCP (Kevin Kissell) (12/18/86)
In article <165100001@uiucdcsb> robison@uiucdcsb.cs.uiuc.edu writes: > >I've heard of another scheme, but never tried it: > >Code generation emits a call to a floating point library. >If the FP hardware is available, the library routine changes >(at run time) the call instruction to the equivalent hardware >instruction. This way you pay for the subroutine linkage only >on the first call. The disadvantage is that self-modifying code >is not allowed on some architectures. One would not have that problem if one patched the program as it was brought into memory, rather than on the first library call. But I doubt that anyone really wants to generate code that *assumes* that emulation libraries are in use. Kevin D. Kissell Fairchild Advanced Processor Division uucp: {ihnp4, decwrl, ucbvax}!hplabs!harvax!garth!kissell Disclaimer: All opinions expressed herein are either my own or a product of your imagination.