Concatenate 2 numbers of a 1darray

[Kevin_Price]

Caution: the Typecast method doesn't always do what one might expect.  Here, getting the correct 16-bit values depends on the "endian-ness" used by your CPU (or maybe it's the OS that decides?  

Another method that can work would use the "Flatten to String" and Unflatten from String" pair of functions, where endian-ness can be *specified* for each operation.  Here's a post I remember making to illustrate.  The problem solved by that specific snippet is different, but should give you a good head start.

-Kevin P

[Ben]

---

@Kevin_Price wrote:

... the "endian-ness" used by your CPU (or maybe it's the OS that decides?  

...

---

It is the hardware that determines the endian-ness

Seat story time!

The NUXI problem

Spoiler

I was working for DEC when UNIX was first being developed to run on a PDP-11/40 (or was it a 11/70?). When they first tried to port it to an IBM machine there was a small problem when it first came up. Instead of the console "flying the banner" "UNIX" it printed out "NUXI". They had the code working but the text had not been adapted for the IBM hardware.

It was due to how the bytes inside an 16 bit word where addressed. DEC decided the first byte would be the low byte. IBM decided it would be the high byte.

Ben

[altenbach]

---

@Ben wrote:

---

@Kevin_Price wrote:

... the "endian-ness" used by your CPU (or maybe it's the OS that decides?  

---

It is the hardware that determines the endian-ness

---

Wikipedia has a very long article.

Deep down yes, but LabVIEW does some magic when casting and makes everything "look" big endian, no matter the platform. The original Macintosh was big endian, so when the first windows version of LabVIEW came out later, compatibility required that everything continued to look big endian, even when running on little endian windows. That was obviously a good decision even though there are probably minor performance implications.

Networking (Ethernet, IP, TCP/IP, etc.) is also always big endian (e.g. look at the multibyte numerical fields in the packet headers, etc.). Again a good thing to prevent a modern version of this. 😮