Re: Endian-specific types

In article <[email protected]>,
David Gwynne  <[email protected]> wrote:
>
>> On 12 Apr 2016, at 18:00, Martin Husemann <[email protected]> wrote:
>> 
>> On Mon, Apr 11, 2016 at 10:04:27PM +0000, [email protected] 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.

There are struct padding ABI concerns so you can't just cast.

christos