Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!agate!spam!lippin
From: lippin@spam.berkeley.edu (The Apathist)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Endless inSANEity...
Message-ID: <25645@agate.BERKELEY.EDU>
Date: 21 Jun 89 00:39:30 GMT
References: <227700009@uxa.cso.uiuc.edu>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: lippin@math.berkeley.edu
Organization: Authorized Service, Incorporated
Lines: 66

Recently cjr20670@uxa.cso.uiuc.edu wrote:
[...]
>  I recently wrote a nifty do-dad program that some of you might have seen.
>It's called GDraw; it basically just whipped dots around the screen in
>facinating paths.  I'm now working on version 2, but I've run across
>a problem that I can't figure a way around. 
>   One of the more complicated new features I'm adding is the ability to
>switch math modes on the fly, for example from Fixed to SANE.  Presently,
>this is all it can do.  I had planned to also add Direct 881 access, BUT
>LightSpeed C is giving me qualms.

Types are pretty easy -- since you don't need to see the inside of a
number, you can declare a struct of the appropriate length to be the
extended size you don't have.

As for the math library, I say ditch it.  It isn't really doing much,
and it's going to get in your way.  Instead, get to the SANE routines
through fp68k() and elems68k().  There's a header file <sane.h> in LSC
that contains most of what you need; the Apple Numerics manual will
tell you how to use it, sort of.  To get you started, here are some
sample uses:

Given extended a,b,
b+=a		fp68k(&a,&b,FOADD|FFEXT)
a=sin(a)	elems68k(&a,FOSIN|FFEXT)

(This is from memory; you can check me against the source for the math
library.) 

It may be handy to make a set of macro definitions for these calls.

Once you understand how to use SANE, you have two options.  The "no
guts" way is to use the Math881 library for the 881 calls; there's no
insurmountable problem with this now that you don't use the regular
math library.  But you will have to live with double being 96 bits and
convert as necessary.  Also, be careful not to use any of the C
operators for +-/*=<> on floating point numbers in places where you
might be running without an FPU.  Finally, this will add a subroutine
jump/return to each operation, which may be noticeable when you're
running on the FPU.

The "guts" way is to write the assembler for elementary operations
yourself, and probably include them as macros, like this:

#ifdef useFPU
#define sin(a)		asm{ fsin a }
#else
#define sin(a)		elems68k(&a,FOSIN,FFEXT)
#endif

Then you can stick your floating point intensive routines in a
separate file, and make two copies, one defining useFPU and one not.
Of course, you'll still have to use two different names, and convert
any floating point numbers where these modules communicate with the
main program.

Good luck, and may the source be with you,

					--Tom Lippincott
					  lippin@math.berkeley.edu

		"You've got to know when to code it,
			       know when to log out,
			       know when to single step,
			       know when to run..."
					--The Hacker