Did any processor have opposite endianness for instructions and data?

Question

The question "Which endian was the Intel 4004?" generated some discussion about the distinction between the endianness of instructions versus data. In the case of the 4004, the code space had 12 bit addresses, and addresses which were encoded inside instructions were packed in big endian format. However, the data size was only 4 bits, making the question of data endianness supported by the hardware moot (although software was free to use whichever representation they desired).

Recognizing that instructions and data can theoretically have opposite endianness, did any processor have big endian instructions and little endian data, or vice versa? By "instructions" I mean opcodes and operands, and "data" means all other memory accesses.

Note that many processors are now "bi-endian", meaning that they are capable of loading and storing data in both big and little endian. That's not what is being discussed here, so please do not include that as an answer.

Answer 1

First that comes to mind would be Nationals NS16xxx/32xxx series. For data in memory it's little-endian, but displacements and immediate values within instructions are big-endian.

[Official End Of Answer]

---

[Later AddOn I Couldn't Stop Myself From Doing]

I know, the question does explicit exclude for bi-endian CPUs, but spending some time about the issue, I think there is more to it to be able to simply put it away as a single issue. So please pardon me for going there.

---

In reality, what often is called bi-endianess isn't a single feature, but a spectrum.

• At one end there are CPUs (*1) like MIPS, which offers separate load and store for either endianess. Here byte order is really arbitrary and most definitely nothing to be considered in context of this question.

• On the other end we have ARM. The CPU was originally designed as little-endian but a bi-endian mode was added regarding data. Being a RISC CPU it matters only for load and store (*2, *3), but unlike MIPS, it's not done per-instruction but switched via a global flag. Control register 1 holds a bit for endianness. When cleared (like after reset) access is little-endian, otherwise big-endian. Writing that register (CPRT) is a privileged instruction, making switching anything but casual.

  As a result, an ARM CPU with the big-endian bit set fits the question for all operations. Data read from memory are big-endian, while values in instructions (*4) are little-endian. A user-mode programmer has no chance to change this.

  So in hindsight, I would place ARM on the list of 'dual endianness ' CPUs. (*5)

• To add more confusion, SUN gave us not only SPARC, but increased pressure with UltraSPARC (64 bit), which introduced per (load/store) instruction endianness, much like MIPS. In addition, the MMU got a memory attribute defining endianness for a memory region. Here programs do not have a say about endianness, instead it's done automatically depending on the address which is accessed.

  So again, as with ARM, the decision is not in hands of ordinary programmers but defined by the OS. I guess SPARC V9 should also go on the 'dual endianness' list.

---

P.S.: Interesting question :))

---

*1 - I use a generic plural here to avoid any discussion how many are there.

*2 - Plus SWP (Swap).

*3 - Always doing aligned word access; using a non-word address also reorders bytes/words, but that's a different issue.

*4 - Another unusual case for ARM, as by default it knows only an 8-bit immediate value, which can be shifted after loading. In addition there are 12-bit offsets for relative addressing and 24-bit offsets for branching.

*5 - An attempt to use a different word than "bi-endian" to describe a CPU with different code and data endianness.

Answer 2

The PDP-11 used little endian for most data, and for its instructions. So a normal 16-bit integer, or an instruction like 0xABCD in hex would be stored in two bytes in memory, in ascending address order: CD, AB.

The in-memory representation for the 32-bit double-width integers, and for the floating point numbers, was different. Two 16-bit little endian numbers, combined in big endian format themselves. So a 32-bit number represented by hex 1234ABCD would be stored as: 34, 12, CD, AB.

Various other mixed forms are of course possible. And some have been used. This particular arrangement got the name PDP-endian, and that term, and software support for it in the UNIX world at least, persisted long past the PDP-11 platform itself.

Answer 3

In considering whether to design a processor to be big-endian, little-endian, or some form of mixed-endian, the question one should ask is whether the processor will benefit from processing things in any particular order. Consider the 6502 and its (zp),y addressing mode. Given an instruction "lda ($12),y", if locations $12 and $34 hold $AB and $CD, the processor will perform the following sequence of steps:

1. Read the opcode
2. Read the operand $12
3. Fetch a byte ($AB) from an address formed by outputting 0 on the upper address bus and forwarding the received value to the lower address bus, while computing ($12 + 1).
4. Fetch a byte ($CD) from an address formed by outputting 0 on the upper address bus and the newly-computed value on the lower address bus, while computing ($AB + Y).
5. Fetch a byte from an address formed by outputting the newly computed value on the lower address bus and the newly fetched value on the upper address, bus while computing ($BC + 1).
6. If ($AB + Y) had generated a carry, fetch a byte from the address formed by keeping the value on the lower address bus and outputting the newly computed value on the upper address bus.

If computation of ($AB + Y) generates a carry, the instruction will take six cycles. If it does not, however, step 5 will have been able to start outputting the correct address as soon as the upper byte was received, without having to perform any computation on it. If the lower byte had been accessed second, the processor would have to add Y to it before being able to use it as an address, thus requiring six cycles in every case.

In cases where all operand bits are fetched separately from from instruction bits, there's seldom if ever any advantage to using big-endian format, and there are sometimes advantages to little-endian. In cases where operand and instruction bits are combined, however, a processor might need to know what the instruction bits are before it can do anything useful with the operand. In those cases, it may be advantageous (if not downright essential) to fetch the instruction bits before the operand bits. If some operand bits are included with those instruction bits, putting upper bits there may be more convenient than putting lower bits there.