Date: Mon, 13 Jan 2003 22:21:59 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: Terry Lambert <tlambert2@mindspring.com>, Jake Burkholder <jake@locore.ca>, <sparc@FreeBSD.ORG>, <current@FreeBSD.ORG> Subject: Re: [PATCH] Re: fpsetmask on sparc64 Message-ID: <20030113211536.E11945-100000@gamplex.bde.org> In-Reply-To: <20030113100558.GA3423@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 13 Jan 2003, Marcel Moolenaar wrote: > On Mon, Jan 13, 2003 at 07:59:30PM +1100, Bruce Evans wrote: > > > > > The synopsis section of our manpage clearly states the inclusion > > > of <ieeefp.h>. That header file includes a machine dependent > > > counterpart <machine/ieeefp.h>. On alpha, ia64 and sparc64 > > > <machine/floatingpoint.h> is empty with the exception of the > > > inclusion of <machine/ieeefp.h>. > > > > > > Hence, I would like to see the prototypes and/or implementation > > > in <machine/ieeefp.h>. > > > > The prototypes are machine-independent, so they are correctly placed > > in <ieeefp.h>. > > Agreed in principle, not in practice. > > > This has the technical problem that it is difficult > > to implement declared functions as inlines (*), so we use an ugly > > i386 ifdef in <ieefp.h> to prevent them being declared. This seems > > least evil since inlining them doesn't seem to be useful and the > > wart only affects i386's, and these functions should be obsoleted > > by the C99 functions as soon as possible. > > This part is what makes me opt for moving the prototypes to the > MD header. These functions are trivial most of the time that > inlining them makes sense. I don't see why other platforms can't > or won't inline in the future. Hand-inlining things rarely makes sense, especially for little-used compatibility-cruft functions like these. A technical reason for not inlining some of them is that they may need to interact with signal handling. We currently avoid most signal-handling problems related to changing the FP environment by switching the critical part of the environment in setjmp/longjmp, at least on i386's, but C99 seems to forbid this. I think the functions that change the FP environment need to save their setting somehwere so that longjmp() can restore the default FP environment (not necessarily the one when setjmp() was called). I don't know how to do this properly reentrantly. > What about signaling the MI header about the existence (or non- > existence) of inline functions and/or macros in the MD header so > that the MI header can optionally provide the prototypes? This > can be done by having the MD header define (or undefine) some > macro (or set of macros). I'd like to have a simple general way to do this, but don't care about it for these functions. > Also, it appears to me that we always have to provide non-inlined > versions in libc for when inlining is disabled. See ctype.h. > I may misinterpret the comment though... Non-inline versions are needed for at least calling functions through function pointers if this is supported, and C requires it to be supported for most functions including the ctype 1's. This requirement causes some of the implementation complications in <ctype.h>. > > > Since on i386 <machine/floatingpoint.h> > > > also includes <machine/ieeefp.h>, we should be able to move > > > the implementation on i386 to <machine/ieeefp.h> as well. If > > > possible, I'd like to see <machine/floatingpoint.h> retired > > > unless there's a compelling reason to keep it... > > > > There is no good reason for these to be separate, but they may be > > required for compatibility. > > It appears to be mostly a FreeBSD-ism in its current form. Both > NetBSD and OpenBSD resist having it. Maybe the newer platforms > should just remove it before it grows code... That makes sense. floatingpoint.h was added to FreeBSD in 1993/08 (before FreeBSD-1.0R) and never picked up by OtherBSD. ieeefp.h in NetBSD seems to date from 1995/04. ieeefp.h was added to FreeBSD at the same time as floatingpoint.h. It was originally in a Sun- compatible place (<sys/ieeefp.h>), but had mostly-wrong contents (i386 bits). <sys> may be MD in SunOS but it isn't in BSD. This was "fixed" in FreeBSD-2 by moving it to <machine>. > Anyone object to remove the header on at least sparc64 and ia64? > (powerpc doesn't have it -- keep it that way :-) Not me. Then sparc64 and ia64 will give even better early warnings of broken ports :-). > Am I right when I say that removing floatingpoint.h (both the MD > file and the MI link) will fix the port, independent of how we > shape ieeefp.h? > > > - We implement <floatingpoint.h> as a link to <machine/floatingpoint.h> > > to get the MD and implementation details right and the MI details wrong. > > Perhaps the broken ports include this and not <machine/floatingpoint.h>. > > Then they would be less broken. > > Some configure scripts may check for <floatingpoint.h> for compatibility > with SunOS/Solaris. I doubt they will check <machine/floatingpoint.h> That's a good reason not to have it. Hopefully its nonexistence in OtherBSD has resulted in its use being correctly configured. However, I suspect most uses in ports are in hard-coded FreeBSD patches. This is confirmed by grepping for floatingpoint\.h and ieeefp\.h in ncvs/ports. > In summary: I like Terry's second patch but am sensitive to having > the MI prototypes in <ieeefp.h> as well as allowing inlining. > What about something like the following to keep the prototypes in > <ieeefp.h>, but still allow inlining (in combination with Terrys > patch): > > Index: ieeefp.h > =================================================================== > RCS file: /home/ncvs/src/include/ieeefp.h,v > retrieving revision 1.6 > diff -u -r1.6 ieeefp.h > --- ieeefp.h 23 Mar 2002 17:24:53 -0000 1.6 > +++ ieeefp.h 13 Jan 2003 09:59:08 -0000 > @@ -12,9 +12,9 @@ > #include <sys/cdefs.h> > #include <machine/ieeefp.h> > > -#ifdef __i386__ > -#include <machine/floatingpoint.h> > -#else /* !__i386__ */ > +#if !defined(_IEEEFP_INLINED_) > __BEGIN_DECLS > extern fp_rnd_t fpgetround(void); > extern fp_rnd_t fpsetround(fp_rnd_t); > @@ -23,6 +23,6 @@ > extern fp_except_t fpgetsticky(void); > extern fp_except_t fpsetsticky(fp_except_t); > __END_DECLS > -#endif /* __i386__ */ > +#endif /* !_IEEEFP_INLINED */ > > #endif /* _IEEEFP_H_ */ I like this. Bruce 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?20030113211536.E11945-100000>