From owner-freebsd-sparc Sun Jan 12 1:27:18 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEC3237B401; Sun, 12 Jan 2003 01:27:14 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C9AB43F1E; Sun, 12 Jan 2003 01:27:13 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id UAA23195; Sun, 12 Jan 2003 20:23:48 +1100 Date: Sun, 12 Jan 2003 20:24:19 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Terry Lambert Cc: Kris Kennaway , , Subject: Re: fpsetmask on sparc64 In-Reply-To: <3E21260E.CF088513@mindspring.com> Message-ID: <20030112194827.S6039-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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 > > instead of the documented interface . > > 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 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 . > > 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-sparc" in the body of the message