Which CPUs had instructions leaving data registers in an unspecified state?

Question

When an ALU performs a floating point division operation using the non-restoring or the SRT algorithm, it maintains the current value of the "remainder" (in quotes, because it is not a true non-negative remainder) in a scratch register. After the operation, the quotient is presented in a user-visible location, and the contents of the scratch register are of no consequence.

However, if a user-visible register is used as the scratch, specifying its contents in all cases is too bothersome. For example, in the BESM-6, the instruction set manual leaves the contents of the accumulator extension register, normally holding the least significant bits of the mantissa after the FP additions or multiplications, unspecified after a division operation (another source explicitly says that it is undefined). I have not heard of attempts to reverse-engineer the value of that register after a division operation and to use it to speed up computation of the remainder.

A narrow-scope question: Is it possible to use the scratch register of a non-restoring or SRT division to figure out the remainder?

Update: As a matter of fact, it is the "positive" bits of the quotient which are left in a user-visible register. Unfortunately, there does not seem to be anything useful to be gleaned from comparing those bits with the final result.

My main question is, has there been another case of an unspecified data register contents after any arithmetic operation in another CPU architecture and were there any attempts to reverse-engineer them for a good use?

Answer 1

There are a lot of instructions on x86 that leave the flag(s) in an indeterminate state, which means the whole FLAGS register is also undefined. Most will have AF undefined, for example

• TEST

  The OF and CF flags are set to 0. The SF, ZF, and PF flags are set according to the result (see the “Operation” section above). The state of the AF flag is undefined.

but there are also other instructions that leave other undefined flags like

• AAA, AAS: OF, SF, ZF, PF
• DAA, DAS : OF
• SAL/SAR/SHL/SHR: OF, AF, CF
• IMUL: SF, ZF, AF, PF
• DIV, IDIV: CF, OF, SF, ZF, AF, PF

The x87 FPU also has its own flags which may also be left unspecified after many operations

• FSTSW/FNSTSW: C0, C1, C2, C3
• FADD/FADDP/FIADD: C0, C2, C3

You can open any of the lists in the X86 Opcode and Instruction Reference like this one and look at the undef_f column to have a summary of undefined flags after each instruction

---

Normal registers can also have an unspecified state, too. Early x86 CPUs will leave the high bit of a mov Reg, Sreg undefined

When executing MOV Reg, Sreg, the processor copies the content of Sreg to the 16 least significant bits of the general-purpose register. The upper bits of the destination register are zero for most IA-32 processors (Pentium Pro processors and later) and all Intel 64 processors, with the exception that bits 31:16 are undefined for Intel Quark X1000 processors, Pentium and earlier processors.

https://www.felixcloutier.com/x86/mov.html (emphasis mine)

And nowadays SHLD/SHRD still have undefined result

If the count operand is CL, the shift count is the logical AND of CL and a count mask. In non-64-bit modes and default 64-bit mode; only bits 0 through 4 of the count are used. This masks the count to a value between 0 and 31. If a count is greater than the operand size, the result is undefined.

https://www.felixcloutier.com/x86/shld

Some other examples on x86

• LAR: The following fields are returned only if the operand size is greater than 16 bits: Bits 19:16 are undefined
• SMSW: In non-64-bit modes, when the destination operand is a 32-bit register, the low-order 16 bits of register CR0 are copied into the low-order 16 bits of the register and the high-order 16 bits are undefined
• BSF, BSR, TZCNT: if source operand is zero, the content of destination operand are undefined
• SLDT: The high-order 16 bits of the register [...] are undefined for Pentium, Intel486, and Intel386 processors

Not sure whether their intermediate results can be utilize for other purposes or not though

---

Division and multiplication also often leave unspecified results

For example on PowerPC we have

• divw

  For the case of -2**31 / -1, and all other cases that cause overflow, the content of GPR RT is undefined.

• and divd

  If an attempt is made to perform the divisions 0x8000_0000_0000_0000 / -1 or / 0, the contents of RT are undefined

Similarly on MIPS

• for DIV/MOD/DIVU/MODU/DDIV/DDIVU,

  If the divisor in GPR rt is zero, the arithmetic result value is UNPREDICTABLE

• In older MIPS ISAs there are also restrictions regarding the HI and LO registers

  In MIPS 1 through MIPS III, if either of the two instructions preceding the divide is an MFHI or MFLO, the result of the MFHI or MFLO is UNPREDICTABLE

On MIPS many floating-point instructions also leave unpredictable result in the registers, like

• DIV.fmt

  The fields fs, ft, and fd must specify FPRs valid for operands of type fmt. If the fields are not valid, the result is UNPREDICABLE.

  The operands must be values in format fmt; if they are not, the result is UNPREDICTABLE and the value of the operand FPRs becomes UNPREDICTABLE.

• or FLOOR.L.fmt

  The fields fs and fd must specify valid FPRs: fs for type fmt and fd for long fixed point. If the fields are not valid, the result is UNPREDICTABLE.

  The operand must be a value in format fmt; if it is not, the result is UNPREDICTABLE and the value of the operand FPR becomes UNPREDICTABLE.

  The result of this instruction is UNPREDICTABLE if the processor is executing in the FR=0 32-bit FPU register model; it is predictable if executing on a 64-bit FPU in the FR=1 mode, but not with FR=0, and not on a 32-bit FPU.

http://hades.mech.northwestern.edu/images/1/16/MIPS32_Architecture_Volume_II-A_Instruction_Set.pdf

Answer 2

Some arithmetic operations in the Xerox Alto would leave registers in unpredictable states, as the cycle time was shorter than the total propagation time of the ALU:

With a 137ns clock cycle time, the CP pushes the underlying hardware to its limits. As a result, some combinations of input sources requested by a microinstruction will not produce valid results because the data simply cannot all make it to its destination on time. Some combinations will produce garbage in all bits, but some will be correct only in the lower nibble or byte of the result, with the upper bits being undefined. (This is due to the ALU in the CP being comprised of four 4-bit ALUs chained together.)

-- https://engblg.livingcomputers.org/index.php/2019/01/19/introducing-darkstar-a-xerox-star-emulator/

Answer 3

This is a little bit outside the scope of the question. It's not really arithmetic instructions (though they are common instructions, and some of them do involve arithmetic), and the architecture in question isn't very "retro". But anyway, maybe it will be of interest to someone.

In the ARMv8 architecture, circa 2011, most instructions write to only a single register (or none). But there are a few exceptions:

• Load (and store) instructions can use a writeback addressing mode, where the address register is post- or pre-incremented by a specified amount. So ldr x0, [x1], #8 loads a 64-bit doubleword from the address in register x1, puts the result in register x0, and adds 8 to x1. Much like x0 = *x1++. Likewise ldr x0, [x1, #8]! is the equivalent of x0 = *++x1.

• There are load pair instructions (also store pair), which load two registers from adjacent memory addresses. For instance ldp x0, x1, [x2] loads x0 from the address in x2, and loads x1 from the same address plus 8.

With these instructions, it is possible to specify that a register should be written in two different ways. For instance ldr x0, [x0], #8: does x0 get left with the value loaded from memory, or the address plus 8, or the value loaded plus 8, or what? And with ldp x0, x0, [x2], does x0 end up with the first loaded dword, or the second one, or what?

The architecture resolves this ambiguity by defining the effect of such instructions to be "CONSTRAINED UNPREDICTABLE", meaning the machine can behave in any of several specified ways. One of those options is that the register in question may take an "UNKNOWN" value, defined in the glossary as "does not contain valid data, and can vary from implementation to implementation." (However, they are careful to say that it must not return privileged data that the code could not otherwise access.)

On the Cortex A-72 where I tested this, the results are unfortunately boring. The writeback loads just do the load and ignore the writeback; so ldr x0, [x0], #8 executes like ldr x0, [x0], and ldr x0, [x0, #8]! executes like ldr x0, [x0, #8]. (Yes, the syntax is obnoxious.) And ldp x0, x0, [x2] traps as an illegal instruction, which is another of the options allowed under CONSTRAINED UNPREDICTABLE. I don't know whether there are any actual machines where the results are interesting in any way, let alone useful.

---

Edit: Looking a little at the 32-bit ARM instruction set, which I'm not as familiar with, it looks like there are some more examples, including some that are truly arithmetic instructions. For instance, the widening Multiply Long instructions write a 64-bit result to a pair of 32-bit register. If they are the same register, as in umull r0, r0, r1, r2, the result is CONSTRAINED UNPREDICTABLE as able, with the possibility of an UNKNOWN value being written to r0.

Answer 4

One example are the two undocumented 8085 flags that can be found by reverse-engineering the silicon (well, it's part of a register, not a complete register). They have uses for signed overflow in arithmetic operations and signed comparison. There are actually a few undocumented opcodes that make use of at least the K flag.

They were put in deliberately (so it's not a chance effect like in the undocumented opcodes for the 6502 - one could argue that the contents of the BESM-6 scratch register would also be a "chance effect", though a deliberate one that depends on the internal algorithm), but not documented for "political" reasons.

Answer 5

And then there are data registers of various FPUs leaving one or more entries in unspecified state after an operation. Well known for example the AMD 9511 series where next to all higher FP functions like SIN or LOG working on a single argument leave at least two entries in undefined states (*1).

---

*1 - Two operand functions always leave one entry undefined due to their nature. Or as njuffa summarized from the manual:

The Am9511 uses a stack-oriented architecture. So when executing a two-operand operation like FADD which operates on the two registers A and B at the current top of stack, the result R goes into the register that formerly held B, which is the new top of stack, and the contents of the register formerly holding A is undefined. Operations like EXP require registers A, B, C, and D, with A closest to top of stack. Afterwards, the result R replaces A, B is unchanged, and the contents of C and D are now undefined (used for scratchpad storage)