Date: Wed, 16 Dec 92 12:07:19 GMT
From: kuku AT acds DOT physik DOT rwth-aachen DOT de (Christoph Kukulies)
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: floating point woes

I solved my floating point problems (accuracy problems, asin() etc.) today
the following way:

I took libm.a from my 386BSD system to my DOS system, after renaming
\dj\lib\libm.a to \dj\lib\libmorig.a and  linked my objects with the
libm.a from 386BSD. Looks a lot better now.

This works on the objects directly because there seems to be total a.out
compatibility between 386BSD and djgpp.

One caveat: The libm.a from 386BSD lacks fabs(), so I added a simple
one liner fabs() to the library.

And another caveat: I did  an ar dv libm.a __.SYMDEF and an ar s libm.a
afterwards because initially the djgpp ld did not like the SYMDEF entry
of 386BSD. Adding a new one solved that problem.

Don't know what the 386BSD libm.a will import of new problems but for the
first I'm happy and wanted to leave that information here for others.

--Chris


rom djgpp-request  Wed Dec 16 08:57:32 1992
Received: by sun.soe.clarkson.edu (4.1/SMI-4.1)
	id AA11527; Wed, 16 Dec 92 07:50:28 EST
Received: from relay.philips.nl ([130.144.65.1]) by sun.soe.clarkson.edu (4.1/SMI-4.1)
	id AA11517; Wed, 16 Dec 92 07:50:18 EST
Return-Path: <kunst AT prl DOT philips DOT nl>
Received: from prFrom djgpp-request  Fri Dec 18 09:58:18 1992
Received: by sun.soe.clarkson.edu (4.1/SMI-4.1)
	id AA00500; Fri, 18 Dec 92 08:35:35 EST
Return-Path: <@ctron.com:dj AT express DOT ctron DOT com>
Received: from nic.near.net by sun.soe.clarkson.edu (4.1/SMI-4.1)
	id AA00495; Fri, 18 Dec 92 08:35:32 EST
Received: from ctron.com by nic.near.net id aa02739; 18 Dec 92 8:36 EST
Received: from express.ctron (express.ctron.com) by ctron.com (4.1/SMI-4.1)
	id AA13931; Fri, 18 Dec 92 08:37:30 EST
Received: from delorie.ctron by express.ctron (4.1/SMI-4.1)
	id AA03466; Fri, 18 Dec 92 08:29:18 EST
Date: Fri, 18 Dec 92 08:29:18 EST
From: DJ Delorie <dj AT express DOT ctron DOT com>
Message-Id: <9212181329 DOT AA03466 AT express DOT ctron>
Received: by delorie.ctron (4.1/SMI-4.1)
	id AA05353; Fri, 18 Dec 92 08:35:51 EST
To: kaminski AT netcom DOT com
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
In-Reply-To: Peter Kaminski's message of Thu, 17 Dec 92 23:45:23 -0800 <9212180745 DOT AA10984 AT netcom2 DOT netcom DOT com>
Subject: libgrx blit speed / SVGA bank switching

>libgrx appears to be doing a straightforward REP MOVSW for each row of
>the blit, in a tight assembly loop doing all the rows -- is 450K
>words/second really as fast as it should go?

Consider that IBM-PC compatible 8-bit I/O memory accesses *peak* at
1Mb/s, and your card may insert one or more wait states for channel
access, I think 450Kb/s is pretty good.  That's about as fast as a
medium performance hard drive.  If you're doing screen to screen
blits, you're really pulling 900Kb/s.  Don't forget you still have to
(1) access system memory, and (2) handle hardware interrupts.

>As I was doing this, I was wondering about the SVGA bank switching via
>page faults -- I presume page faults only occur when you're outside
>the current 64K bank, right?  I.e., I'm generating 9 page faults per
>screen (assuming the blit proceeds top to bottom) and not 307,200?

Correct.  Blits are optimized to reduce page faults.  For some cards,
ET4000 included, gr/grx take advantage of separate read & write pages
to limit screen to screen page faults also.

DJ
dj AT ctron DOT com
Life is a banana.