Date: Sun, 12 Jan 2003 20:24:19 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Terry Lambert <tlambert2@mindspring.com> Cc: Kris Kennaway <kris@obsecurity.org>, <sparc@FreeBSD.ORG>, <current@FreeBSD.ORG> Subject: Re: fpsetmask on sparc64 Message-ID: <20030112194827.S6039-100000@gamplex.bde.org> In-Reply-To: <3E21260E.CF088513@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 12 Jan 2003, Terry Lambert wrote:
> 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.
Yes it does (should). Including an implementation detail like
<machine/floatingpoint.h> gives undefined behaviour. In this case,
one aspect of the undefined behaviour is that fpsetmask() is not
declared in the MD file except in the i386 case as a side effect
of being implemented as a macro that calls an inline function there.
In all the other arches, it is an extern function that is only
declared in <ieeefp.h>.
> > 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
^^ iswas (1)
> permitted by the standard, is different from what most software
was (2)
> expects the default to be.
(1) was permitted by C90; is not permitted by C99, but C99 is not supported
yet.
(2) was different before FreeBSD-4.0. Are there any ports that still
support FreeBSD-3?
> 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).
The man page still supports FreeBSD-3 :-). It is version-agnostic. The
default setting is very MD, so software that actually cares must not
assume anything about the defaults.
> > [... in C99]
> > - 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.
Anything else would be very expensive both in source code complexity
and runtime costs. The environment would have to be switched for every
library function that uses FP. C99 only requires a few specialized
math functions to be aware of this.
> 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
This is not suckagae, but a normal consequence of pipelining. Intel
hardware is relatively nice here. It gives precise exceptions on the
next operation. Less-unmodern hardware like alphas has very imprecise
exceptions unless everything is pessimized using trap barriers. See
-mtrap-precision in gcc.info. But exceptions are now almost moot on
i386's since they don't cause traps. However, at least some alphas
need to cause traps to be IEEE conformant since traps are needed to
implement some parts of IEEE conformance in software, and the largest
of the -mtrap-precision pessimizations are needed for this to work.
See -mieee-conformant in gcc.info.
> 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-).
As far as I understand the hardware issues (not far), the stall would
be necessary after every FP instruction, not just ones which generate
the exception. FP performance would be reduced by approximately a
factor of (pipeline_length * number_of_concurrent_FP_ops_achieved).
I guess speculative execution code get near appearing to not stall
though.
> 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).
True. It just gives applications a chance of handling environment-
related FP stuff almost portably.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030112194827.S6039-100000>