www.delorie.com/archives/browse.cgi   search  
Mail Archives: pgcc/1998/03/17/18:39:12

X-pop3-spooler: POP3MAIL 2.1.0 b 3 961213 -bs-
Delivered-To: pcg AT goof DOT com
Message-ID: <19980317191425.17914@cerebro.laendle>
Date: Tue, 17 Mar 1998 19:14:25 +0100
From: Marc Lehmann <pcg AT goof DOT com>
To: beastium <beastium-list AT Desk DOT nl>
Subject: Re: paranoia & extra precision [was -fno-float-store in pgcc]
References: <19980314022303 DOT 40050 AT cerebro DOT laendle> <Pine DOT SOL DOT 3 DOT 96 DOT 980316165113 DOT 12843C-100000 AT stekt10>
Mime-Version: 1.0
X-Mailer: Mutt 0.88
In-Reply-To: <Pine.SOL.3.96.980316165113.12843C-100000@stekt10>; from Tuukka Toivonen on Mon, Mar 16, 1998 at 05:16:27PM +0200
X-Operating-System: Linux version 2.1.85 (root AT cerebro) (gcc version pgcc-2.91.06 980129 (gcc-2.8.0 release))
Status: RO
Lines: 53

On Mon, Mar 16, 1998 at 05:16:27PM +0200, Tuukka Toivonen wrote:
> 
> >> - If you want extended precision -> store values in memory with 10 bytes.
> >>   You'll get always 80 bits precision.
> >> - If you want to use `double' format with some extra precision,
> >>   just set high precision on and use doubles.
> >> - If you want IEEE-compliance, set FPU to low precision and everything is
> >>   right again.
> >
> >but imho, the very very large speed penalty of this approach renders
> 
> "this"? Which one of these? The first approach (using long doubles) is

sorry, for being so unlcear :(( the first is medium slow, the second is
wrong, and the third is what I meant with very large speed penalty.

> The third approach (setting low precision to FPU CW) doesn't slow
> at all -- if you use the same precision with same type of data
> (double/float) all the time and the compiler knows it.

which it can't. the other could tell it, but this is relatively wortheless,
I mean nobody ever complained about too much precision, and the ones that
did usually ran paranoia which isn't speed dependent.

> After I thought about floats & IEEE compliance last weekend I noticed that
> "just setting the CW right" isn't at all so simple unlike I first thought.

it's similar to mmx. sharing fpu and mmx register was... braindead (which is
also the name of the movie i'll watch tonight ;), and shifts the burden to
the compiler, which in turn has to shift the burden to the programmer.

There is a new, relatively small patch (I posted this some time ago), that
will add a new register letter for use in asm(), to have gcc pre-load mmx
registers. It would (in the future) also contain some heuristics of when to
switch between fpu and mmx, but I'm not very convinced that it will improve
performance.

compare this to the (now old) m68k technology, that was really clean (at
least in comparison).

also, for the idea of storing precalculcated cw in memory. yes, we'd
probably have to save the cw somewhere, so we would just "save" the
instructions that modify the cw, but we need another (costly) memory access.
Dunno wether which alternative is better, but (apart from code prefetches),
saving memory cycles usually pays off.

      -----==-                                              |
      ----==-- _                                            |
      ---==---(_)__  __ ____  __       Marc Lehmann       +--
      --==---/ / _ \/ // /\ \/ /       pcg AT goof DOT com       |e|
      -=====/_/_//_/\_,_/ /_/\_\                          --+
    The choice of a GNU generation                        |
                                                          |

- Raw text -


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