Diamond assumes that the C6000 processors are used in little-endian mode, that is, increasing memory addresses indicate increasing significance of the bytes within a word.
There is no support for operating C6000 processors in big-endian mode.
Transferring data between processors supporting different byte order is difficult and cannot be managed automatically, either by hardware or software.
Consider the following C code:
struct {
int word;
char text[8];
} S;
S.word = 0x12345678;
strcpy(S.text, "1234567");
This appears in typical 32-bit memory words as follows:
little-endian processor |
0x12345678 0x34333231 0x00373635 |
big-endian processor |
0x12345678 0x31323334 0x35363700 |
If misguided hardware or software attempted to 'correct' the byte order of data being transferred a word at a time across links between these processors, there would be corruption in either the 'word' field (if it tried byte swopping) or the 'text' field (if it did nothing). Even transferring data a byte at a time leads to exactly the same problem.
Moving data between processors of different byte order requires knowledge of the structure of that data, and you have to put this into your code explicitly, introducing dependencies and inefficiencies. This is why, where possible, Diamond runs all processors in little-endian mode.