c++ - C++11 on exotic hardware

Question

There was a question like this before, in 2011: Exotic architectures the standards committees care about

Now, I'd like to ask a very similar question, but this time, I'm asking it from the programmer's view of perspective, and in the perspective of C++11.

Which hardwares exist currently, which has a C++11 compiler for it, and can be considered exotic?

What do I consider exotic?

• where a char is not 8 bit
• where IEEE 754 float number format not available
• where the integer numbers aren't encoded in two complement
• where there is no 8, 16 or 32 bit types supported by the compiler
• where the memory model is not linear (so, you cannot compare/subtract any pointers)

So anything, which is not the standard, which we see on x86/ARM world, where we have:

• have 8/16/32-bit two complement integers
• IEEE754 floats, some fully compliant, some don't, but use the IEEE754 format
• linear memory model

Note: I'd like to have answers, where a C++11 conformant compiler exists for the hardware, not where a C++ compiler exists, but isn't fully conformant.

I'm asking this, because a lot of times, I get answers like "you cannot depend on that, it is implementation defined", and I'd like to know, that actually, in the real world, how much I can depend on the standard. Just an example: whenever I write std::uint16_t, I may worry (as this feature is optional), that on a platform, this type is non-existent. But, is there an actual platform, where this type doesn't exist?

Answer 1

Go looking for DSP cores, that's your best bet for "exotic" architectures.

For example, the Motorola/Freescale/NXP 56720 has a C++ compiler available from Tasking, but has 24-bit memory on three or more buses. I think the stack model on the device (at least the older 56K devices) was a hardware stack and didn't really fit the C/C++ model.

edit: more details...

The register model on this beast is odd:

1. Accumulators (56 bits, broken up in to 8bit, 24 bit, 24 bit sub registers)
2. data registers (24 or 48 bits)
3. address registers (R0..7, M0..7, and N0..7) For the address, modulo, and step size

The modulo and step size registers don't map to anything intrinsically modeled in C/C++, so there's always some oddball constructs and #pragma to help the compiler along to support circular buffers.

There's no stack pointer (no push or pop instruction). There's a hardware stack for function return addresses, but that's only 16 calls deep. The software has to manage overflows and local variables don't live in on the stack.

Because there's no stack, the compiler does weird things like static call tree analysis and puts local variables in overlayed memory pools. This means no re-entrant functions and necessarily only one context without much weirdness or severe performance penalties.

sizeof(int) = sizeof(char) = sizeof(short) = 1 = 24 bits

This means no byte access (at least on the old 56002, not sure about the 56300). I think it takes about 24 cycles to read/write a specific byte from an array of 24-bit integers. This core is not good and barrel shifting, masking, and or-ing

Not ALL DSP cores are like this of course, but they're usually varying degrees of 'weird' from the standard of 32/64 bit unified memory and sizeof(char)=1 expectations of GCC because of the intrinsic modulo pointers and multiple memory buses.