big endian vs. little endian, why 1960

When I said "alien" it was my way of referring to an integer format which is not native to the CPU you're running. (The second half of that sentence was intended to my meaning clear.)

So, I now understand that you ARE talking about the whole different issue of importing integers from non-native data formats.

In your original posting, I thought the question was "why were some computers designed using little-endian format for internal of integers." Since that note made reference to Intel and DEC vs. Motorola et. al, this was a reasonable interpretation. Your later clarifications show that you're actually concerned with compatibility with an external data format standard originated in 1989.

Anyway, I somehow doubt the hardware architects at DEC or Intel (or Motorola) took CCSDS into account. One might better ask why the CCSDS was designed to be incompatible with efficient little-endian hardware.

Just to play Devil's Advocate, I could suggest that the CCSDS standard should have specified little-endian integers to allow this kind of hardware optimization. I could easily imagine designing byte-serial arithmetic into spacecraft flight hardware, to reduce gate-count and power consumption in an FPGA or small ASIC. (I'm not seriously trying to make this case -- this optimization likely doesn't make sense given the protocol complexity I see in that spec. -- but since you have described the overhead of swapping the byte order as "nightmares" then perhaps little inefficiencies are important. Your own words can and will be used against you, if I can give myself a talking point.)

(OK, I'm done jerking your chain now.)

By the way, this isn't all academic. I have personally designed hardware byte-serial data processing, and it was recently by AFC standards (mid-1990s). It wasn't in a CPU, it was a dedicated path for decoding a fast compressed data stream in real-time. Naturally, the integer format was little-endian! -- Jonathan Griffitts AnyWare Engineering Boulder, CO, USA