On Mon, 13 May 2002, Stefan Farfeleder wrote:
> On Mon, May 13, 2002 at 11:13:58AM -0700, Bill Fenner wrote:
> >
> > It's easy if it's easy to treat doubles as uint64_t's. Like, I think
> > signbit() might be something like
> >
> > #define signbit(d) (*((uint64_t *)&(d)) &
> > UINT64_C(0x8000000000000000))
> >
> > or maybe
> >
> > #define signbit(d) (*((uint64_t *)&(d)) >> 63)
> >
> > However, that assumes that d is an IEEE double (and there is a
> > possibly-incorrect assumption about byte order). I don't know how to
The current libm seems to make similar assumptions. It uses 2 32-bit
"words" instead of uint64_t, so it has to fight endianess problems
involving the inter-word order, but it doesn't do anything special for
the bits in the words. Does IEEE specify the bit order and/or sign
bit enough for this to actually be correct?
> > implement a macro that will take any real-floating type.
The macro could expand to a function call. That's how I would implement
it until/unless it is actually used enough for its efficiency to matter.
> signbit isn't limited to lvalues, is it? You'll have to handle eg
> signbit(3.0) too.
Right. This could be handled using a gcc macro that assigns the arg to
an lvalue if necessary.
Where did this thread start? ISTR a PR that implements all the new
floating point classification functions.
Bruce
To Unsubscribe: send mail to majordomo@xxxxxxxxxxx
with "unsubscribe freebsd-standards" in the body of the message
|
