From: johnm@cory.Berkeley.EDU (John D. Mitchell)
Subject: Re: Math co-pros
Organization: University of California, at Berkeley
Date: Mon, 23 Nov 1992 18:24:20 GMT

In article <1epujtINNc64@golem.wcc.govt.nz> harvey_a@kosmos.wcc.govt.nz writes:
[...]
>Well I wasn't in a hurry to buy one, just hopeful of an easy jump to fast(er)
>performance (my PC is one of those with a essentialy non-replacable
>motherboard (ie built in ports, video, etc) and someday it will be
>replaced (when my money tree grows back... :-)) but till then....)

TANSTAAFL. :-)  Even with the FPU, a given piece of code may see no speed
improvement or even a slowdown.  It all depends on what you're doing and
how you've designed it to work.  Do you really need that sort of precision
in a sine routine when your only trying to draw a scaled circle?

[...]
>I know that the 'mulit-tasking' is limited, bur quatro-pro uses it to good
>effect to speed up it's recalcs.  I don't know of any other programs that use
>it like that. but you could do things like calculate the position of a
>co-ordinare for a redraw, whilst the main processor draws the previous
>pixel...).  This may all be simply not worth it in terms of performance
>gain, I was just intrigued to know what GEOS actually did... 

I don't think you're thinking of 'multi-tasking' in the same way as most
people (in this context anyways :-).  The 'multi-tasking' that you're
thinking of (running the CPU and FPU in parallel) isn't really what QPro is
doing.  It's got it's own built in tasking system that's internal to
itself.  It divides up the CPU amongst several tasks that it may have, one
of which is it's 'background re-calc' task.  Yes, it's possible to issue an
FPU instruction and then run a bunch of CPU instructions and then figure
out if the FPU is done or not and...  It's a nightmare.  The main thing
that people do is to issue the FPU instruction and then explicitly do an
FWAIT (which blocks the CPU until the FPU has finished) and then use the
value/result in some other computation.  Also, the FPU is controlled by the
CPU, it can't do much of anything but compute something and let the CPU
know that it's done so it's really a very limited/specific purpose chip.
As for what v2.0 will do, you'll have to wait and see...

[...]
>Ok, perhaps I wasn't very clear.... I assume that GEOS *MUST* have to do
>non-integer maths at some point, therefore it must have an emulator library. 
>as GEOS programs are so small it is a reasonable asumption that fp maths is
>provided as a central object that other programs can use.  If one has a
>co-pro, this object is either largely redundant, or could be greatly
>shrunk by calls to the built in stuff. ( as you said no co-pro support
>yet, I assume it doesn't do this..)

GEOS *mustn't* do anything that's slow. :-)  As I mentioned above, there
are a great many cases where a little (or maybe a lot) of thought has/will
lead to a faster version of some functionality for (ususally) less general
purpose cases (i.e., tailored to the specific task at hand).  You're
definitely on the right track though floating point math is something that
many programs certainly do rely on and part of GeoWorks' job is to make
porting those programs to the GEOS system as painless as possible.

Go wild,
	John
	johnm@cory.Berkeley.EDU

P.S.	Insert standard employee disclaimer text here.  GeoWorks speaks
	for itself.