[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FPE Demand?
- Subject: Re: FPE Demand?
- From: toddpw@liquefy.ugcs.caltech.edu (Todd P. Whitesel)
- Date: 21 Jan 1995 09:52:33 GMT
- Newsgroups: comp.sys.apple2
- Organization: California Institute of Technology, Pasadena
- References: <3fe015$r8s@usenet.INS.CWRU.Edu> <bazyarD2IG5B.BoD@netcom.com>
bazyar@netcom.com (Jawaid Bazyar) writes:
> Sane's slow speed tends to be due to its heavy use of 'extended'
>10-byte values. SANE requires input as 'extended', so languages
>such as ORCA/C have to convert smaller floats into extended values
>before performing calculations. Slow.
This is because SANE is a software emulation of the 68881/68882, whose
registers are all extended precision. Nearly every 6888x instruction can
fetch a byte/word/long/single/double/extended from memory/register and
convert it to extended precision before doing the actual instruction
operation with/into a destination register. Very CISCy -- on purpose.
The 6888x and 80287 did well on classic benchmarks that predate SPECfp.
If you are using SANE, read all variables that are used more than once
into extended size variables, crunch on things in extended, and store the
results back out to smaller variables when you're finished. This is what
6888x code does. Mac programmers who want 68k software SANE performance
have done this for years.
Software SANE was never supposed to be particularly fast. It was
supposed to be compatible with hardware 6888x SANE which _is_ supposed
to be fast. (It's even faster if you turn off IEEE compliant exception
checking, but that's a general problem with IEEE floating point.)
Todd Whitesel
toddpw @ ugcs.caltech.edu