Date: Sun, 12 Jan 2003 00:23:42 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Bruce Evans <bde@zeta.org.au> Cc: Kris Kennaway <kris@obsecurity.org>, sparc@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: fpsetmask on sparc64 Message-ID: <3E21260E.CF088513@mindspring.com> References: <20030112165423.K5527-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote:
> > Is this an omission, or are the ports wrong?
>
> First answer:
> This is a bug in the ports. The non-i386 arches are apparently including
> <machine/floatingpoint.h> instead of the documented interface <ieeefp.h>.
Wow, gotta disagree with that; the problem doesn't magically go
away when you include the standard header file.
> I think the ports are only meddling the FP mask to hide their FP errors
> when running under FreeBSD-3.x and earlier anyway.
They are meddling with it because the FreeBSD default, while it is
permitted by the standard, is different from what most software
expects the default to be.
Yeah, it'd be nice if it weren't there, but the man page itself
specifically uses fpsetmask() in an example (to prevent some trap).
> Second answer:
> Ports should use the C99 interfaces fe{get,set}*() from <fenv.h>, and then
> only if C99 is supported. There might be problems with this too:
> - C99 isn't supported yet.
> - C99 doesn't have fesetmask(). This is partly because it would be
> very unportable. It is not an IEEE FP feature. C99 only has
> fesetenv(FE_DFL_ENV) to recover from any meddling with the FP
> environment.
> - Non-default FP environments should only be used in small sections
> of code, since large parts of libraries, etc. are entitled to assume
> that the environment is the default. So changing the FP mask to a
> non-default value at program startup time would give undefined
> behaviour if it were possible.
This is also really arguable, IMO. The problem with this is that
the assumption that they are "entitled to assume that the environment
is the default" is really bogus.
What this really comes down to is that Intel FP hardware sucks,
and should be redesigned to raise exceptions when they occur,
instead of on the next operation. It's like the old VT100's, or
other therminals with the "AM" attribute which is true, and they
wrap before the 81st character, rather than after the 80th.
I understand the pipeline stall that would happen on an exception,
if this is how they were handed; on the other hand, it's a little
bogus to assume that exceptions aren't going to be rare, what with
them being "exceptional" and all. 8-).
The C99 soapbox is a nice place to stand, if you want to criticize
all other implementations; but as you point out, C99 is not really
there yet, and even if it were, you could not really expect all
code to be changed to conform to it (or any other standard, for
that matter, considering the amount of legacy code everywhere).
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-sparc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E21260E.CF088513>