| Author |
Message |
Terje Mathisen
Guest
|
 Posted:
Fri Mar 04, 2005 2:39 pm Post subject:
Re: big-edian & little-endian |
|
|
Niels Jørgen Kruse wrote:
| Quote: | Terje Mathisen <terje.mathisen@hda.hydro.com> wrote:
I did mention that one. No, it only counts when/if an integer and fp
value with the same number of bits use different bit/byte ordering.
This would make it impossible to write portable code to generate fp
bitpatterns on the fly, you'd be forced to go via library code instead.
That is not portable anyway, as there are different FP formats.
|
"Portable to all machines supporting IEEE fp formats"
OK?
Terje
--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching" |
|
| Back to top |
|
 |
Dan Pop
Guest
|
| Posted:
Fri Mar 04, 2005 3:39 pm Post subject:
Re: big-edian & little-endian |
|
|
In <d09abr$qbr$1@osl016lin.hda.hydro.com> Terje Mathisen <terje.mathisen@hda.hydro.com> writes:
| Quote: | Niels Jørgen Kruse wrote:
Terje Mathisen <terje.mathisen@hda.hydro.com> wrote:
I did mention that one. No, it only counts when/if an integer and fp
value with the same number of bits use different bit/byte ordering.
This would make it impossible to write portable code to generate fp
bitpatterns on the fly, you'd be forced to go via library code instead.
That is not portable anyway, as there are different FP formats.
"Portable to all machines supporting IEEE fp formats"
OK?
|
I'm not aware of any such thing that is not either purely big endian
or purely little endian (except, maybe, some obscure embedded control
processors). The PDP-11 and the VAX didn't use IEEE floating point.
Dan
--
Dan Pop <Dan.Pop@ifh.de> |
|
| Back to top |
|
|
Jean-Marc Bourguet
Guest
|
| Posted:
Fri Mar 04, 2005 3:49 pm Post subject:
Re: big-edian & little-endian |
|
|
Terje Mathisen <terje.mathisen@hda.hydro.com> writes:
| Quote: | Niels Jørgen Kruse wrote:
Terje Mathisen <terje.mathisen@hda.hydro.com> wrote:
I did mention that one. No, it only counts when/if an integer and fp
value with the same number of bits use different bit/byte ordering.
This would make it impossible to write portable code to generate fp
bitpatterns on the fly, you'd be forced to go via library code instead.
That is not portable anyway, as there are different FP formats.
"Portable to all machines supporting IEEE fp formats"
|
Well, I know that Gabriel Dos Reis (who worked on that part of gcc)
says that there is more "evil in the details" than expected in the
IEEE FP representations. If I needed to know that, I'd look first at
that part of gcc.
Yours,
--
Jean-Marc |
|
| Back to top |
|
|
Niels Jørgen Kruse
Guest
|
| Posted:
Fri Mar 04, 2005 4:01 pm Post subject:
Re: big-edian & little-endian |
|
|
Terje Mathisen <terje.mathisen@hda.hydro.com> wrote:
| Quote: | Niels Jørgen Kruse wrote:
Terje Mathisen <terje.mathisen@hda.hydro.com> wrote:
I did mention that one. No, it only counts when/if an integer and fp
value with the same number of bits use different bit/byte ordering.
This would make it impossible to write portable code to generate fp
bitpatterns on the fly, you'd be forced to go via library code instead.
That is not portable anyway, as there are different FP formats.
"Portable to all machines supporting IEEE fp formats"
OK?
|
"Portable to all machines supporting IEEE fp formats without weird
byteorder"
Little difference. (I am not advocating a quest for perfect
portability.)
--
Mvh./Regards, Niels Jørgen Kruse, Vanløse, Denmark |
|
| Back to top |
|
|
Nick Maclaren
Guest
|
| Posted:
Fri Mar 04, 2005 4:18 pm Post subject:
Re: big-edian & little-endian |
|
|
In article <pxbd5ufptx1.fsf@news.bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> writes:
|>
|> Well, I know that Gabriel Dos Reis (who worked on that part of gcc)
|> says that there is more "evil in the details" than expected in the
|> IEEE FP representations. If I needed to know that, I'd look first at
|> that part of gcc.
Where you would find some hints at the problems, but not a full
description of the mess. I don't know why he didn't expect to
find chaos in that area, because it was very clear that there
would be. Admittedly, I have been batting around that area (and
going batty as a result) for 35 years now, and so have seen a
wide range of methods of getting things subtly wrong.
Regards,
Nick Maclaren. |
|
| Back to top |
|
|
D. J. Bernstein
Guest
|
| Posted:
Fri Mar 04, 2005 4:22 pm Post subject:
Re: big-edian & little-endian |
|
|
Terje Mathisen wrote:
| Quote: | Dan, in which way does this differ from the OP and the (sometimes
broken) assumption that you can cast a pointer from float * to char * to
move the bytes/bitpattern?
|
The code works with IEEE floating-point in _any_ byte ordering: 0123,
3210, 2301, whatever. As another example of the same technique, here's
the portable sqrtapprox() function you were asking for:
float sqrtapprox(float x)
{
float magic = 3.8204714345e-37;
unsigned int i = 3[(char *) &magic][(unsigned char *) &x];
unsigned int j = 2[(char *) &magic][(unsigned char *) &x];
3[(char *) &magic][(char *) &x] = 32 + ((i & 127) >> 1);
2[(char *) &magic][(char *) &x] = (j & 127) + (i << 7);
return x;
}
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago |
|
| Back to top |
|
|
Jean-Marc Bourguet
Guest
|
| Posted:
Fri Mar 04, 2005 5:19 pm Post subject:
Re: big-edian & little-endian |
|
|
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
| Quote: | In article <pxbd5ufptx1.fsf@news.bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> writes:
|
|> Well, I know that Gabriel Dos Reis (who worked on that part of gcc)
|> says that there is more "evil in the details" than expected in the
|> IEEE FP representations. If I needed to know that, I'd look first at
|> that part of gcc.
Where you would find some hints at the problems, but not a full
description of the mess. I don't know why he didn't expect to find
chaos in that area, because it was very clear that there would be.
|
I think he was assuming more homogeneity in the world of "IEEE fp" --
more or less what Terje seen to be doing --, I doubt he was expecting
anything outside that.
Yours,
--
Jean-Marc |
|
| Back to top |
|
|
Nick Maclaren
Guest
|
| Posted:
Fri Mar 04, 2005 5:48 pm Post subject:
Re: big-edian & little-endian |
|
|
In article <pxb7jknppr4.fsf@news.bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> writes:
|> > |>
|> > |> Well, I know that Gabriel Dos Reis (who worked on that part of gcc)
|> > |> says that there is more "evil in the details" than expected in the
|> > |> IEEE FP representations. If I needed to know that, I'd look first at
|> > |> that part of gcc.
|> >
|> > Where you would find some hints at the problems, but not a full
|> > description of the mess. I don't know why he didn't expect to find
|> > chaos in that area, because it was very clear that there would be.
|>
|> I think he was assuming more homogeneity in the world of "IEEE fp" --
|> more or less what Terje seen to be doing --, I doubt he was expecting
|> anything outside that.
"IEEE FP" is what I was referring to. You are free to call me a
cynical old sod :-)
Regards,
Nick Maclaren. |
|
| Back to top |
|
|
Terje Mathisen
Guest
|
| Posted:
Fri Mar 04, 2005 7:24 pm Post subject:
Re: big-edian & little-endian |
|
|
D. J. Bernstein wrote:
| Quote: | Terje Mathisen wrote:
This would make it impossible to write portable code to generate fp
bitpatterns on the fly, you'd be forced to go via library code instead.
float fromlittleendian(char in[4])
{
float magic = 3.8204714345e-37;
float result;
0[(char *) &result] = in[0[(char *) &magic]];
1[(char *) &result] = in[1[(char *) &magic]];
2[(char *) &result] = in[2[(char *) &magic]];
3[(char *) &result] = in[3[(char *) &magic]];
return result;
}
|
Huh?
Dan, in which way does this differ from the OP and the (sometimes
broken) assumption that you can cast a pointer from float * to char * to
move the bytes/bitpattern?
Terje
--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching" |
|
| Back to top |
|
|
Nick Maclaren
Guest
|
| Posted:
Fri Mar 04, 2005 8:03 pm Post subject:
Re: big-edian & little-endian |
|
|
In article <d09r2d$53p$1@osl016lin.hda.hydro.com>, Terje Mathisen <terje.mathisen@hda.hydro.com> writes:
|> D. J. Bernstein wrote:
|> > Terje Mathisen wrote:
|> >
|> >>This would make it impossible to write portable code to generate fp
|> >>bitpatterns on the fly, you'd be forced to go via library code instead.
|> >
|> >
|> > float fromlittleendian(char in[4])
|> > {
|> > float magic = 3.8204714345e-37;
|> > float result;
|> > 0[(char *) &result] = in[0[(char *) &magic]];
|> > 1[(char *) &result] = in[1[(char *) &magic]];
|> > 2[(char *) &result] = in[2[(char *) &magic]];
|> > 3[(char *) &result] = in[3[(char *) &magic]];
|> > return result;
|> > }
|>
|> Huh?
|>
|> Dan, in which way does this differ from the OP and the (sometimes
|> broken) assumption that you can cast a pointer from float * to char * to
|> move the bytes/bitpattern?
In C90, the above did not work, because there was considerable
vagueness over the required precision of the conversion of
floating-point constants. It was generally agreed that there
was no requirement for any particular precision, and compilers
varied.
In C99, even in full "IEEE 754" mode (don't ask), it is extremely
unclear whether that is allowed, because of the introduction of
"effective type" (see 6.5 #6, #7). Nobody knows what those
sections mean, and there are not enough C99 compilers to guess
how dissimilar they will be.
In all of K&R, C90 and C99 that is not defined, because it is
perfectly permissible for values to have different representations
in different objects. Float arguments and results were fairly
commonly promoted to double for the interface during the K&R->C90
transition, I believe still are. While it is permitted to treat
floating-point data as arrays of char, the effect of doing so is
undefined.
Regards,
Nick Maclaren. |
|
| Back to top |
|
|
Terje Mathisen
Guest
|
| Posted:
Sat Mar 05, 2005 12:11 am Post subject:
Re: big-edian & little-endian |
|
|
D. J. Bernstein wrote:
| Quote: | Terje Mathisen wrote:
Dan, in which way does this differ from the OP and the (sometimes
broken) assumption that you can cast a pointer from float * to char * to
move the bytes/bitpattern?
The code works with IEEE floating-point in _any_ byte ordering: 0123,
3210, 2301, whatever. As another example of the same technique, here's
the portable sqrtapprox() function you were asking for:
float sqrtapprox(float x)
{
float magic = 3.8204714345e-37;
unsigned int i = 3[(char *) &magic][(unsigned char *) &x];
unsigned int j = 2[(char *) &magic][(unsigned char *) &x];
3[(char *) &magic][(char *) &x] = 32 + ((i & 127) >> 1);
2[(char *) &magic][(char *) &x] = (j & 127) + (i << 7);
return x;
}
|
OK, I'll have to hand-translate that into asm to figure out how it works.
First, I suspect that your magic value will turn out to have an
'interesting' binary/hex representation. :-)
....
Yeah! It is 03020100h, so taking the individual bytes results in a
lookup table pointing at the proper location for each constituent part
of a float value.
However, as Nick have written, it isn't really guaranteed to work, due
to the missing clear specification of how the casts have to work (or not).
OTOH, I was quite impressed to see that Microsoft's C compiler was able
to propagate the magic bitpattern into the individual bytes, turning the
indirect memory accesses into direct load/store operations. :-)
Terje
--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching" |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in