Re: Endian-specific types

[David Gwynne <david%gwynne.id.au@localhost>]

> On 12 Apr 2016, at 18:00, Martin Husemann <martin%duskware.de@localhost> wrote:
> 
> On Mon, Apr 11, 2016 at 10:04:27PM +0000, coypu%SDF.ORG@localhost wrote:
>> (As Paul said) this is for setting registers and such for the hardware.
> 
> For registers we normally don't see this at all (so just use uint16_t),
> as we access registers via bus_space_read/bus_space_write and the bus
> handling defines all needed endianess conversions.
> 
> However, we do see this in data that is DMA'd from or to the device,
> and proper use of le16toh and friends is important there.
> 
> So for DMA'd structs it may make sense to typedef it to uint16_t
> and use it in the struct definition - but on the other hand we don't
> do that anywhere else.

ive toyed with the idea of making types like this:

typedef struct {
  uint16_t word;
} __le16;

typedef struct {
  uint16_t word;
} __be16;

and an api like this:

uint16_t lemtoh16(__le16 *src);
uint16_t bemtoh16(__be16 *src);
void htolem16(__le16 *dst, uint16_t src);
void htobem16(__le16 *dst, uint16_t src);

you can assign structs to other structs of the same type by value, which is pretty natural for the above. however, it forces you to go via an api to do actual loads and stores.

internally the api can default to using htole16, letoh16, etc, but could also be implemented to take advantage of byte swapping loads and stores that are available on various architectures. eg, sparcv9 can do LE loads/stores via an ASI, and powerpc has byte swapping load and store opcodes. theyre probably already in use as the backend for the bus_space operations.

dlg