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