Has there been any effort to research the undocumented Thumb instructions of ARM7TDMI?

Question

Many CPUs have "holes" in the ISA, where the bit pattern is left undefined.

Considering the Z80 and the 6502, many people have mapped out what these undocumented instructions actually do.

Take for example this cheatsheet of the Thumb instruction set (PDF warning, 116K). Some bit patterns are marked as "undefined" or "unpredictable". What is known about these instructions? Are any of them stable/useful enough for use, have they seen use in existing software? So far my google-fu hasn't turned anything obvious up.

Answer 1

The Thumb instruction set is a compressed form of a subset of the full-size ARM instructions. As part of the fetch unit, there is a decoder which expands each 16-bit Thumb instruction into the equivalent 32-bit ARM instruction when the CPU is in Thumb mode, but passes the instruction words along unchanged when in ARM mode. This means the decoder's behaviour is the focus of the question.

In the given table, Thumb opcodes marked Undefined Instruction are expanded to ARM opcodes that are themselves Undefined Instruction, and will thus trigger a trap when the ARM instruction reaches the Decode stage of the pipeline.

However, those opcodes marked Unpredictable may be expanded to valid ARM opcodes, but are not part of the ARMv4T specification. This is the result of omitting gates that would have been needed to explicitly detect these opcodes and convert them to Undefined Instruction opcodes. Instead, they will be decoded similarly to nearby valid opcodes. There is no clear advantage to using the Unpredictable opcodes rather than the equivalent specified encodings.

Many of the Unpredictable and Undefined Instruction opcodes are re-specified explicitly in later versions of the Thumb instruction set, as used in the StrongARM, ARM9, ARM11, and subsequent Thumb-2 supporting cores. Thumb-2, in particular, has support for encoding 32-bit ARM instructions, less their conditional field, into a Thumb instruction stream without switching modes. This was necessary to enable the Cortex-M microcontrollers which always operate in Thumb mode, since they don't have an ARM mode. However, the specified decoding of these opcodes in later specifications is generally different from the "accidental" decode behaviour of the earlier ARM7 core.

Answer 2

Undefined instructions are those not understood by the main ARM CPU core. If there is also no coprocessor that understands them, then an undefined instruction trap is executed to allow for software to for example use them as system calls or to emulate missing hardware.

But there are some instructions opcodes that are not defined, and these do not cause undefined instruction trap either. Manual says these instructions must not be used, because they can be defined later, and manual also says the behaviour what these instructions might do is unpredictable.

The instructions are unpredictable, because the fastest way is to just not to expect undefined instructions to appear in code. Different implementations can work differently and they are free to do so.

So, these instructions are well-defined in that sense - do not use, if you do it might do anything, as they are reserved for future use.

Answer 3

After the 8 bit processors (6510, Z80 & so on), the decode units tend to do one of 2 things. They either map illegal op-codes to become NOP instructions (as the 65C816 did) or trigger an exception. The ARM processors actually have a CPU mode that is reserved for managing illegal instructions. The number of gates to do this became, in relative to the total number of gates on the processor, trivial.

The ARM solution is ACTUALLY very clever because it makes it possible to create your own instructions. They wouldn't be very fast but they would work.

As for Thumb specifically, well as others have noted, the ARM7 simply converts each 16-bit Thumb instruction into an ARM 32 bit instruction. On the other hand, the Cortex series of processors actually work using the raw 16 (and occasionally 32) bit instructions. I did perform a test and the M0 & M0+ processors indeed cause an exception.

What is MORE intriguing about Thumb is that there are a few instructions that can produce unpredictable results. The ones that spring to mind are:

RORS Rd,Rd - i.e. rotate Rd by the value in bits 0-7 of Rd. WHY it uses bits 0-7 I do not know since 32 is the maximum one would generally use. The other shift instructions also use bits 0-7.

I am a HUGE fan of Sophie Wilson and her decision to use bits 0-7 WILL have had a logical foundation but nobody else is aware of it.

Another Thumb instruction that intrigues me is the MULS which multiplies together two registers i.e. 32-bit x 32-bit & returns the bottom 32 bits. Now, on earlier versions, the Z & N flags were set based on the result but the C & V flags were corrupted. I can only guess WHY the flags were corrupted but more importantly, I could never figure out any use for the flags that were returned. So many people mistakenly thought that C flagged the result being >32 bits.... but it doesn't.

Finally, I think that the SVC (formally SWI i.e. software interrupt) instruction baers some investigation. It allows an immediate 8-bit value to be moved to and from the processor status. I strongly suspect that the control(s) that this instruction support are chosen by the maker of each specific ARM Cortex based design. I don't know if you have come across any M0 implementations that have a cache. The one I saw was only 32 bytes & was direct mapped but it meant that a CPU performing a copy wouldn't tie up the bus if DMA or such also needed RAM access.

I don't know how familiar you are with ARMs TCM but I for one would have much preferred a 64-byte scratch pad to a 32-byte cache. MY personal reason is that it would be big enough to store a 32-bit x 32-bit ---> 64-bit signed multiply. I'm writing an MP2/MP2.5/MP3/MP4/MELP/ACELP audio decode suite and the KEY presumption in their designs is that the host CPU has a fast multiply. As it is, I've managed to get the code into 17 instructions & 17 cycles. If my MULSHIFT32 (it actually returns the top 32 bits of the 64 bit result) left the bus free, it would quickly be used by the DMA....

Answer 4

Preface:

It is important to keep in mind that ARM instruction sets, as defined by ARM, are just that, definitions, not implementations. While ARM does provide templates, manufactures do their implementation independent of each other and ARM. So anything not defined by ARM is implementation and chip specific and may change even within the same manufacturer and type in follow up versions.

---

First it might be useful to remember that this is neither an official ARM table or naming, nor a default ARM core, but a third party compilation for the GBA's custom ARM7TDMI implementation (*1)

Beside that the distinction is rather obvious encodings marked with

• unpredictable are redundant encodings, while
• undefined mark simply what it says, instructions that have (at that time) no function assigned.

The unpredictable are all encodings of the ADD/CMP/MOV group meant to access the 'higher' registers (R8..15) with both high bits zeroed, making them work between lower registers (R0..R7) only. These are simply redundant to regular ADD/CMP/MOV (*2).

Within ARM manuals, they are all Undefined. (*3)

For these instructions it's up to the implementation if they get translated into their counter parts, like early Thumb implementations did, or not.

Since they were defined by ARM as unused, they could and did redefine them - like with ARMv5 for MOV. The redundant MOV was made not only made a real opcode, but changed in function as well. The high register versions of MOV are now copy (CPY) instead of move - meaning no flags are touched.

Maybe that's why the authors of that table marked them as 'unpredictable'

The undefined in contrast are simply the remaining encodings that have no assigned function. As well Undefined in genuine ARM documentation.

Like with all undefined behaviour, they may or may not have some working depending on silicon and their workings may not only change between manufacturers, but as well between chip versions - not to mention assigning functions in later designs. For example the undefined version of BX (*4) was turned into BLX with ARMv5.

Beside these clearly marked as undefined, there are some other instruction set holes: Wherever a field is marked as (SB)Z - all encodings other than zeroes can (and will) be used for future extensions.

---

P.S.: Have you already tried to ask that on SO, which might be a more appropriate audience?

---

*1 - An easy visible oddity is that this table includes all 16 conditions for 8 bit relative branches, whereas Thumb excludes always and never (14/15) - with never later (v5) be redefined as software interrupt.

*2 - Check the line right above each.

*3 - With a capital 'U' :)

*4 - Interestingly called unpredictable in the ARMv5E Architecture Reference Manual.

Answer 5

Ever tried putting an undefined instruction into any ARM (from 2 onwards)? It actually goes into a processor state specifically for dealing with such instructions.

Unpredictable is what it says - generally it's flag conditions after certain instructions.

I do love the fact that ROR Rx,Rx IS valid although AFAIK it's never been used although it would allow a few 32 bit numbers to be set up using an 8 bit immediate & a ROR i.e. 32 bits to set up a 32-bit value.

I did ask ARM about the above i.e. should they put it into their C compilers.... they thought I was mad.