2
\$\begingroup\$

The AT91SAM7X microcontroller has several instruction modes:

  • TDMI32bit
  • TUMB16bit
  • Jazelle8bit

Each of these modes has its own instruction code.

Why did Atmel make a 32 bit micocontroller (TDMI32bit) but make 16 bit (TUMB16bit) instructions the default?

\$\endgroup\$
2
  • \$\begingroup\$ See en.wikipedia.org/wiki/ARM_architecture#Jazelle \$\endgroup\$ Commented Sep 19, 2013 at 21:51
  • 1
    \$\begingroup\$ the three instruction modes that you are talking about are common to all ARM processors and micro-controllers.Why they do support 16-bit instructions is because they need to exploit code density. Why jazelle support is to support java. \$\endgroup\$ Commented Sep 20, 2013 at 0:45

3 Answers 3

2
\$\begingroup\$

The reality in microcontrollers is that code space is at a premium. Being able to reduce the size of the instructions reduces the size of code and enables packing more code into the same flash. The Thumb instruction set enables the programmer to get a lot more out of the ARM, but it has its caveats and so must be used carefully. This is because there are tradeoffs to having fewer bits and so the instruction capability is reduced. Still, a good compiler can help you utilize this feature.

Thumb2 tried to improve upon this and bridge the gap between the limits of instructions in Thumb and the ones for the 32-bit instructions.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ Itb is not just the code (flash) size that is at a premium, it is (also, maybe even mainly) the bandwidth between the flash and the CPU. \$\endgroup\$ Commented Sep 20, 2013 at 6:36
  • \$\begingroup\$ Indeed, even much less constrained devices than flash-based micros (Android phones for example) typically have compilers configured to generate code for a thumb mode in the bodies of most functions, even if inter-library linkage is arm. \$\endgroup\$ Commented Sep 20, 2013 at 15:22
  • \$\begingroup\$ I think the issue with Thumb was not that it "had to be used carefully", but rather that it wasn't designed to all the instructions that an application would need, but instead to have enough instructions that programs could be written mostly using the Thumb instruction set, but have a few routines which needed ARM mode use that one. \$\endgroup\$
    – supercat
    Commented Oct 2, 2013 at 15:43
1
\$\begingroup\$

Atmel is just the chip vendor. The processor is from ARM. The normal arm instruction set is the 32 bit flavor. thumb is a reduced instruction set, 16 bit instructions to reduce code size and bandwidth at a tolerable overhead in number of instructions and performance, say 10-20% more instructions to implement the same program compared to ARM mode. Jazelle is its own deal meant to support java, from what I can tell it is smoke and mirrors, a Jazelle enabled arm doesnt appear to have a java instruction set, what it appears to be is that if you pay more money arm will sell you some software that you run on your java enabled processor that lets you execute java. Another two instruction sets you didnt mention perhaps because your processor doesnt have them is thumb2 which are just thumb extensions, and the other is an fpu, which are basically renamed coprocessor instructions.

having all of these is for the moment rare, most arm processors with thumb either dont have arm or dont have thumb2 (yes arm makes a processor that is thumb only, no full sized arm instructions. the Cortex-M series). some of the newer big arm processors do have all of the above.

The sam7 is based on the ARM7TDMI core. Which is an ARMv4T. So it has arm and thumb but not thumb2 and not jazelle. All the exceptions are ARM mode, including reset. After that software has to switch to thumb mode using the bx instruction. You may be using software from atmel or elsewhere that is primarily thumb based and give the illusion that thumb mode is the default, except for the cortex-M (armv6m and armv7m) there is no arm processor that defaults to thumb mode.

\$\endgroup\$
0
\$\begingroup\$

The ARM instruction set is very powerful, and a single ARM instruction can do some combinations of things that would require multiple instructions when using many other instruction sets. This power comes at a cost, however: every ARM instruction takes four bytes to store; while ARM instructions may on average do somewhat more useful "work" than would be possible with a two-byte instruction, they don't do twice as much. Further, in a typical application there will be sections of the code which need the more powerful instructions, but there will also be large sections of the code which receive relatively little benefit from them.

The original purpose of the Thumb instruction set wasn't to serve as a complete alternative to ARM, but rather to allow the parts of the application that need the more powerful instructions to use them, while allowing the parts that don't need those instructions can be stored more compactly. Even if 90% of a program is written in Thumb mode, that portion can easily call a subroutine written in ARM mode if it needs to do something which ARM mode. Consequently, the designers were free to omit from the Thumb mode instructions set certain operations which most applications wouldn't need to perform very often even if the applications would need to do them at some times.

In its later cores, ARM has shifted away from the two-mode design, going in two different directions. Some cores like the Cortex-M3 use only a 16-bit instruction mode, but use some otherwise-unused 16-bit instruction patterns to represent the first half of a two-word instruction. This makes most ARM instructions available even within 16-bit mode. Other cores like the Cortex-M0 are mostly limited to the original Thumb instruction set, but augment it with just enough additional instructions to make it possible to do the things which would otherwise have required switching to ARM mode.

Personally, I'm somewhat sad to see ARM mode dropped. While the Cortex-M3 approach works almost as well, ARM mode could do a few things Cortex-M3 can't do as nicely. For example, in the ARM mode every instruction had a "condition" field which would cause it to execute only if certain flags were set. This made it possible to to do certain kinds of bit-permutation code using three instructions for every two bits.

; Capture bits 2 and 3 of R0 in sign and carry flags, respectively
    movs  r0,r0,rol #29
    orrmi r4,r4,#128 ; Set bit 7 of R4 if bit 2 of R0 was set
    orrcs r5,r5,#128 ; Set bit 7 of R5 if bit 3 of R0 was set

The Cortex-M3 has a rather powerful "if-then-else" instruction which can be used to make the execution of the following instructions conditional based upon flags, and it has modes to e.g. "execute the next instruction only if carry is set, and the one after that only if it's clear" but all instructions controlled by a particular "if-then-else" instruction must use the same condition flag. Consequently, the above three-instruction sequence would become five.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.