Swap Long

[wiebe@CARYA]

(hope this hasn't been posted before, couldn't find it)

Since we now have 64 bit numbers, can we please have a Swap Long function?

This is a real hassle to do yourself (convert to byte array, rotate array, convert back? or flatten to string, flatten back with different byte order?). If you have large arrays of "quads", it is a real performance hit without the function.

Regards,

Wiebe.

[Darin.K]

I would do (x<<32)^(x>>32).  No reason not to have this. 

Edit:  should have a general endian swap function, I think it has been suggested already. 

[RavensFan]

Swapping long is not the same thing as rotate the array.  Swapping long is like taking 12345678 and it becoming 56781234.  Reversing byte order or rotating the array is like going to 87654321.  Not the same thing.

It makes sense to have the swap long function to go along with the other two swaps.  But have you actually ever needed it in real life?

[Darin.K]

The real life application is swapping endianness, like I commented above it would be nice to have a function for doing that explicitly.  I know I have seen it discussed a long time ago. 

[elset191]

It seems like a swap/join would be a more straight forward workaround.

Perhaps I'm missing something

[wiebe@CARYA]

> I would do (x<<32)^(x>>32).

True, that would work. You actually only need to "rotate" once by 32 bits, and it works on arrays.

 

>Edit:  should have a general endian swap function, I think it has been suggested already. 

You might want to swap just the longs, not the bytes and words. (Motorola modbus floats have reversed longs, but normal endianess).

>It makes sense to have the swap long function to go along with the other two swaps.  >

If only for consistancy...

>But have you actually ever needed it in real life?

Quite often actually. Well, like 4X a year or something... When flattening a byte array to an array of U64's and the order is wrong, it's nice to have the function. But if there was a "swap endianness" function I could use that instead. There are always alternatives, but when performance counts, a swap long can be nice.

[wiebe@CARYA]

> I would do (x<<32)^(x>>32).

True, that would work. You actually only need to "rotate" once by 32 bits, and it works on arrays.

 

>Edit:  should have a general endian swap function, I think it has been suggested already. 

You might want to swap just the longs, not the bytes and words. (Motorola modbus floats have reversed longs, but normal endianess).

>It makes sense to have the swap long function to go along with the other two swaps.  >

If only for consistancy...

>But have you actually ever needed it in real life?

Quite often actually. Well, like 4X a year or something... When flattening a byte array to an array of U64's and the order is wrong, it's nice to have the function. But if there was a "swap endianness" function I could use that instead. There are always alternatives, but when performance counts, a swap long can be nice.

[altenbach]

---

Darin.K wrote: The real life application is swapping endianness, like I commented above it would be nice to have a function for doing that explicitly.  I know I have seen it discussed a long time ago. 

---

I brought this suggestion up in a private forum discussion. I think I should write it up as an idea.

(I thought I did already, but it does not look like it)

[DavidBoyd]

I'm amazed I hadn't noticed this "hole" in the data manipulation palette till now, and then find this IE entry is from 2014! (Also that 64-bit integers were introduced so long ago, my how time flies...)

And yes, I wanted this while working on a VIM for CRC computation.  The lovely semantics of the existing swap primitives (that would be carried over to a Swap Longwords, should it be added) are that they're essentially no-ops on smaller integers.  So a string of swap bytes - swap words - swap longwords would be a size-agnostic way to reorder any integer on a VIM.

Not holding my breath here for NI Emerson to add this since this hasn't seen more discussion, but it gets an upvote from me, and I'm just going to code a slightly less elegant solution with a Type Specialization Structure I didn't need till I wanted to support CRC-64.

Dave