[fpc-pascal] Byte order modification in fpc on ARM?

[Karoly Balogh (Charlie/SGR)]

Hi,

On Mon, 19 Oct 2015, Bo Berglund wrote:

> I am making a control program for a data collection system using FPC +
> Lazarus on a Raspberry Pi2 platform. I will use a number of Delphi
> units, which implement the communications and data handling needs in a
> way that works fine on a Windows platform.
>
> While looking over existing code I see that there are instructions to
> modify received data from the instrument by reversing the byte order.
> The reason for that was that the instrument is based on a Motorola
> controller and it uses the opposite byte order as in the Intel CPU:s
> on the PC. Since download is of binary data areas in the instrument
> the byte order change was necessary for all multi-byte data like word
> and integers as well as real (floating point 32 bit values).
>
> Now I wonder if it will be necessary also on an ARM platform like the
> RPi2?

Yes.

> Is there a function or such to interrogate the byte order of the
> platform FPC runs on? So that I could add a test at the start of
> download to check if swapping is needed?

There are compile time defines. ENDIAN_LITTLE and ENDIAN_BIG.
As documented here:
http://www.freepascal.org/docs-html/prog/progap7.html

But the Raspberry Pi2's ARM is little endian, just like the x86 processors
in a PC. It's also pretty easy to write a test function, which determines
it runtime:

function islittleendian: boolean;
var
  x: longint;
begin
  x:=1;
  islittleendian:=pbyte(@x)^ = 1;
end;

This will return true on little endian processors, and false on big
endians. Should return true on RPi2 and x86 PCs.

> Or is the ARM used on RPi2 working with the same byte order as the
> Motorola MC68HC11 MCU is?

No, the MC68HC11 is big endian (according to the Internet, I have no
direct experience with that platform).

BTW, big endian is also known as "network byte order" so you could look at
sockets unit, which has network-to-host and host-to-network byte order
which will just "always work" so compile to a no-op on big endian
platforms, while doing the right conversion on little endian ones.

Charlie