Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 Jan 2002 16:00:10 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Nate Williams <nate@yogotech.com>
Cc:        Daniel Eischen <eischen@pcnet1.pcnet.com>, Dan Eischen <eischen@vigrid.com>, k Macy <kip_macy@yahoo.com>, Peter Wemm <peter@wemm.org>, Julian Elischer <julian@vicor-nb.com>, arch@FreeBSD.ORG
Subject:   Re: KSE question
Message-ID:  <3C51F18A.C0D8D6B1@mindspring.com>
References:  <3C51D0B6.F6E04EBC@mindspring.com> <Pine.SUN.3.91.1020125164325.24428A-100000@pcnet1.pcnet.com> <15441.56832.170618.611705@caddis.yogotech.com> <3C51E888.FD13A18D@mindspring.com> <15441.59691.361172.394760@caddis.yogotech.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Nate Williams wrote:
> > Yes, that was my reservation as well.  You can do it from
> > first principles using the tool chain
> 
> Not easily.  The toolchain may not know the software is using the FPU in
> interpreted languages (at least, in any effecient manner).

#pragma flagsection("FPU=1")

Ugly, I know.  The other option is a linker flag.


> You could stick in all sorts of funky hooks, but because threads can be
> intererupted at any time, the amount of checking that still needs to
> occur at runtime would make a compile-time solution un-necessarily
> slow.  (MHO of course).

Actually, the runtime checking is incredibly easy, if you
*know* the program can use the FPU: just switch totally
away from lazy binding at all.  The reason it exists at
all is "in case someone uses the FPU".  If you know they
won't, it makes the rest of the code run faster, which is
probably an acceptable tradeoff.

The signalling overhead in the "didn't-use-it-now-I-do"
case is a real PITA to ensure that multiple CPU threded
programs DTRT.  8-(.  Better to eat the overhead by
default, and optimize later.  I think flagging the
programs at the toolchain level is "low hanging fruit",
where doing a full on dynamic binding of FPU state might
end up being a very long term project.

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C51F18A.C0D8D6B1>