<div class="gmail_quote">On Thu, Jul 14, 2011 at 10:45 AM, Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisProg@gmx.com">jmdavisProg@gmx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><div></div><div class="h5">On 2011-07-14 10:26, Andrew Wiley wrote:<br>
> On Thu, Jul 14, 2011 at 9:02 AM, Jonathan M Davis<br>
<<a href="mailto:jmdavisProg@gmx.com">jmdavisProg@gmx.com</a>>wrote:<br>
> > On Thursday 14 July 2011 06:27:47 Andrei Alexandrescu wrote:<br>
> > > On 7/14/11 5:51 AM, Regan Heath wrote:<br>
> > > > That's my point. I need 8/16/32/64/128 bit versions and it really<br>
> > > > would be better if there were general variants. My version are less<br>
> > > > than optimal, but do use intrinsics where possible. Someone else can<br>
> > > > do a<br>
> ><br>
> > far<br>
> ><br>
> > > > better job than I, and it really should be done once, by that person.<br>
> > > > Surely we have the infrastructure for someone to add this to phobos?<br>
> > > > If something this simple can't or won't be done, what hope do we<br>
> > > > have!?<br>
> > ><br>
> > > I think we should have these functions in std.bitmanip:<br>
> > ><br>
> > > T toBigEndian(T)(T val) if (isArithmetic!T || isSomeChar!T);<br>
> > > T toLittleEndian(T)(T val) if (isArithmetic!T || isSomeChar!T);<br>
> > > T bigEndianToNative(T)(T val) if (isArithmetic!T || isSomeChar!T);<br>
> > > T littleEndianToNative(T)(T val) if (isArithmetic!T || isSomeChar!T);<br>
> > ><br>
> > > That means all characters, all integers, and all floating point<br>
> > > numbers. The implementations would opportunistically use intrinsics<br>
> > > and other specialized means.<br>
> ><br>
> > Well, it's questionable as to whether there's any point in having such<br>
> > functions for 8-bit values, since it would just return the original<br>
> > value. And<br>
> > I don't think that it should deal with floating point numbers, since<br>
> > they're<br>
> > not affected by endian-ness.<br>
><br>
> I looked this up at one point, and found that (according to Wikipedia,<br>
> which may not be perfect) floating point numbers are generally stored<br>
> according to the same endianness rules as integers, in which case they<br>
> would be affected. I'm not an expert, but why do you think they aren't?<br>
<br>
</div></div>1. I was pretty darn sure of it from what I recalled about looking into it in<br>
the past.<br>
<br>
2. I misread wikipedia when I went to verify it prior to posting (I just went<br>
and reread it after reading your post):<br>
<a href="http://en.wikipedia.org/wiki/Endian#Floating-point_and_endianness" target="_blank">http://en.wikipedia.org/wiki/Endian#Floating-point_and_endianness</a>. It<br>
discusses the possibility of a little endian machine having big endian<br>
floating point values and how that pretty much doesn't happen now and how all<br>
x86 machines use little endian floating point. I skimmed it too quickly and<br>
thought that it said that all machines today use little endian rather than it<br>
saying that all x86 machines use little endian for floating point.<br>
<br>
So, yes. Unfortunately, floating point values _are_ affected by endianness -<br>
though apparently unlike integers, there is no standard way to transmit them<br>
over the network. So, I guess that we do need to worry about converting<br>
floating point values. Bleh. Why couldn't all computers have been smart and<br>
just have used big endian from the beginning and be done with it...<br>
<font color="#888888"><br>
- Jonathan M Davis<br></font></blockquote><div><br></div><div>From reading about it, it seems like there's no *standard* way to transmit them across the network, but if you swap them like integers and don't store them back into a floating point type (!), it'll pretty much work. If you store them back into a floating point value and the compiler ever puts that value into a floating point register, the FPU might try to "fix" an invalid value to a NaN value, thus breaking everything.</div>

<div><br>The irony of endianness is that my bi-endian ARM system runs in little-endian by default so as to be closer to x86, but this forces me to reorder everything I send over the network. Sigh.</div></div><br>