Byte Order Swapping Function

[Andrew Wiley]

On Thu, Jul 14, 2011 at 10:45 AM, Jonathan M Davis <jmdavisProg at gmx.com>wrote:

> On 2011-07-14 10:26, Andrew Wiley wrote:
> > On Thu, Jul 14, 2011 at 9:02 AM, Jonathan M Davis
> <jmdavisProg at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110714/b3facb04/attachment.html>