How can I change the byte orders of a struct?

Question

How can I change the order of a packed structure in C or C++?

struct myStruct {
  uint32_t A;
  uint16_t B1;
  uint16_t B2;
} __attribute__((packed));

The address 0x0 of the structure (or the LSB) is A.

My app communicates with hardware and the structure in hardware is defined like this:

struct packed {
  logic [31:0] A;
  logic [15:0] B1;
  logic [15:0] B2;
} myStruct;

But in SystemVerilog the "address 0x0" or more accurately the LSB of the structure is the LSB of B2 = B2[0].

The order is reversed.

To stay consistent and to avoid changing the hardware part, I'd like to inverse the "endianness" of the whole C/C++ structure.

I could just inverse all the fields:

struct myStruct {
  uint16_t B2;
  uint16_t B1;
  uint32_t A;
} __attribute__((packed));

but it's error-prone and not so convenient.

For datatype, both SystemVerilog and Intel CPUs are little-endian, that's not an issue.

• How can I do it?

Answer 1

How can I change the byte orders of a struct?

You cannot change the order of bytes within members. And you cannot change the memory order of the members in relation to other members to be different from the order of their declaration.

But, you can change the declaration order of members which is what determines their memory order. The first member is always in lowest memory position, second is after that and so on.

If correct order of members can be known based on the verilog source, then ideally the C struct definition should be generated with meta-programming to ensure matching order.

it's error-prone

Relying on particular memory order is error-prone indeed.

It is possible to rely only on the known memory order of the source data (presumably an array of bytes) without relying on the memory order of the members at all:

unsigned char* data = read_hardware();
myStruct s;
s.B2 = data[0] << 0u
     | data[1] << 8u;
s.B1 = data[2] << 0u
     | data[3] << 8u;
s.A  = data[4] << 0u
     | data[5] << 8u
     | data[6] << 16u
     | data[7] << 24u;

This relies neither memory layout of the members, nor on the endianness of CPU. It relies only on order of the source data (assumed to be little endian in this case).

If possible, this function should also ideally be generated based on the verilog source.