How easy is it to develop with Renesas RX micros?

[ajb]

The Renesas headers we're using have duplicate definitions of all registers, for big and little endian.

Really? That's ridiculous.  One of the first rules of pragmatic programming is "Don't Repeat Yourself", and the worst possible way to violate that rule is repeating yourself in a slightly but critically different way.

Not that it matters, because no-one should ever use bit fields for hardware registers.

So true. Unfortunately, nobody seems to care anymore.

Yes, it's one of those things that's sort of nice syntactically for single bits, but really not worth the trouble and potential issues.  Also annoying when they'r'e declared in such a way that you have to tack ".reg" onto the end of every single register access if you're not using the bitfields.

[andersm]

The Renesas headers we're using have duplicate definitions of all registers, for big and little endian.

Really? That's ridiculous.  One of the first rules of pragmatic programming is "Don't Repeat Yourself", and the worst possible way to violate that rule is repeating yourself in a slightly but critically different way.

From the CPU's POV, the layout of the registers changes depending on endianness, so there's no much choice. To be clear, each bitfield definition contains an "#ifdef __RX_ENDIAN__BIG__ #else #endif" pattern, they don't duplicate the outer "struct" part.

[ajb]

The Renesas headers we're using have duplicate definitions of all registers, for big and little endian.

Really? That's ridiculous.  One of the first rules of pragmatic programming is "Don't Repeat Yourself", and the worst possible way to violate that rule is repeating yourself in a slightly but critically different way.

From the CPU's POV, the layout of the registers changes depending on endianness, so there's no much choice. To be clear, each bitfield definition contains an "#ifdef __RX_ENDIAN__BIG__ #else #endif" pattern, they don't duplicate the outer "struct" part.

OOOOoooh, the CPU can be switched, got it.  From the context I was under the impression that it was to support toolchains with different (or switchable) conventions for bitfields.

Switchable endianness seems like a rather expensive feature for limited benefit--maybe a couple of hardware instructions for swapping bytes would have been better and more flexible? 

[andersm]

Switchable endianness seems like a rather expensive feature for limited benefit--maybe a couple of hardware instructions for swapping bytes would have been better and more flexible?

I suspect it's a backwards compatibility feature, the H8 series and older SuperH were big-endian. It's a bit quirky in that code is always little-endian, but data endianness is configurable via an option bit.

[0xdeadbeef]

I wouldn't trust switchable endianess. The earlier Motorola/Freescale/NXP eSys controllers with PowerPC core had this features but it was so bug ridden that it was finally removed.
On a somewhat related note, Motorola also counted the bits the other way round, so the least significant bit in a 32bit register was 31. Even worse, some cores also existed as 64bit versions with some peripherals and buses being also 64bit wide, but only the "lower" 32bit were implemented on a 32bit core. So some 32bit registers were counted from 63 (LSB) to 32 (MSB). Now if that isn't confusing.

[andersm]

I wouldn't trust switchable endianess. The earlier Motorola/Freescale/NXP eSys controllers with PowerPC core had this features but it was so bug ridden that it was finally removed.

PowerPC implemented little-endian by XORing the LSBs of the address, which doesn't work as expected with unaligned data. That's not an issue with the RX implementation.