Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!uwm.edu!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!apple!metaphor!dragon!djh From: djh@dragon.metaphor.com (Dallas J. Hodgson) Newsgroups: comp.sys.amiga.tech Subject: MC68881/2 Support (hello, Dave Haynie) Message-ID: <1181@metaphor.Metaphor.COM> Date: 30 May 90 23:05:00 GMT Sender: news@metaphor.Metaphor.COM Reply-To: djh@dragon.metaphor.com (Dallas J. Hodgson) Organization: Metaphor Computer Systems, Mountain View, CA Lines: 29 If you're like me, you're tired of all the software that doesn't take advantage of your FFP. The way things work right now, we've got too many floating point standards, such as : mathffp.library ieee.library (double precision) ieee.library (new single precision, recognizes 6888x for 2.0) compiler-specific math libraries in-line FFP instructions Since the FFP instructions trap out thru the FLINE vector anyway (if there's no coprocessor present) why don't we EMULATE a 6888x when the traps occur? Put this support in the RKM, and let all the compilers generate in-line FFP instructions. Yes, there's a small amount of overhead for non-FFP users, but it's no different from the PC way of doing things - and very system-friendly! Let's say GOODBYE to the math libraries; if a user wants to install a Weitek in the future, the vendor(s) can supply the driver software themselves - and everything will still work. Just a thought. +----------------------------------------------------------------------------+ | Dallas J. Hodgson | "This here's the wattle, | | Metaphor Computer Systems | It's the emblem of our land. | | Mountain View, Ca. | You can put it in a bottle, | | USENET : djh@metaphor.com | You can hold it in your hand." | +============================================================================+ | "The views I express are my own, and not necessarily those of my employer" | +----------------------------------------------------------------------------+