www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/12/16/18:21:15

Message-ID: <32B5F29A.88@gbrmpa.gov.au>
Date: Tue, 17 Dec 1996 09:08:43 +0800
From: Leath Muller <leathm AT gbrmpa DOT gov DOT au>
Reply-To: leathm AT gbrmpa DOT gov DOT au
Organization: Great Barrier Reef Marine Park Authority
MIME-Version: 1.0
To: DJ Delorie <dj AT delorie DOT com>
CC: Kevin AT Quitt DOT net, djgpp AT delorie DOT com
Subject: Re: Is DJGPP that efficient?
References: <199612161347 DOT IAA01261 AT delorie DOT com>

DJ Delorie wrote:
> 
> > > Without being too facetious, the problem is that the Intel architecture is
> > > so poorly suited for such calculations that the optimal is still none too
> > > good.  But yes, DJGPP is pretty good.
> >
> > Ummm...not meaning to start any wars... but your joking right? :)
> > The FPU in the pentium is pretty damn good... 3 cycles for a mul, 1
> > for an add, while being able to run in parallel with the integer
> > unit...seems pretty cool to me! :)
> 
> There are other considerations besides opcode speed.  For example, the
> fpu only has eight registers; other types have up to 32, and you must
> access the registers in a stack-like way, instead of through standard
> numbered register.  These may also affect the overall efficiency of
> any FPU code.

Well, the stack method is pretty crumby (I used to use the 040, and it
was nice... :) but it gains some forgivness with the fxch being free,
generally being the equivalent of being able to load into any register
(IMHO BTW).  I can't see this really ever changing though - Motorola
created a completely new CPU to get past the limit of the 680x0 range,
and I don't think Intel will be doing that... ;)

Leathal.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019