Cool Code

Nearly 75 per cent of all embedded processors are based on the ARM Architecture (Advanced RISC Machine, or Acorn RISC Machine), because it meets such requirements beautifully-it’s half the size of an old 486 CPU, is almost as powerful (with the potential for more), doesn’t heat up even under load, and consumes but a smidgen of battery power. How does it do it, and why don’t we have such features in our desktop processors?

History Lesson, I: Less Is More
Today’s mobile processors owe their architecture to a division in processor design philosophy that started somewhere in the 1970s. Flashback (in black-and-white, if you like) to a dark age where no compilers existed, and processors were hand-coded in their own assembly language instructions. These instruction sets were quite simplistic, and something as simple as comparing two numbers could take ten instructions to execute. Imagine trying to write an operating system with that! But that was just half the problem.

When you gave an instruction to a processor, you do so as a hexadecimal op-code, which was stored in a register on the CPU itself before being executed. This register (a pipeline of many registers in today’s processors) is an expensive resource to waste, and the number of instructions required for the simplest operations made that painfully obvious-more so when processors were getting powerful enough to do so much more. The goal, then, was to create instructions that were the same length (in bits, that is), but led to the execution of many micro-operations. For example, the 8086’s JPE (Jump If Equal) instruction loads two numbers from the system’s memory, subtracts them, uses that result to determine whether they’re equal or not, and then jump to a new instruction if they are indeed equal. Contrast this with its predecessor, the 8085, with but the humble JMP instruction, which made the processor jump to the specified memory location.

This was the birth of Complex Instruction Set Computing (CISC)-simple instructions that performed complex tasks. It didn’t waste CPU resources as much, and gave programmers relief while they waited for the rise of higher-level languages and their compilers.

History Lesson, II-Enough Is Too Much
With the arrival of languages like C, programming trends started shifting away from the ungainly assembly languages to the more elegant (by those standards, anyway) higher-level languages-which used compilers that translated code to assembly language. As it turned out, these compilers weren’t exploiting the potential that CISC had to offer-mostly because compiler designers were at a loss to figure out which instruction to use when. The 8086 had 32 different “Jump If…” instructions to choose from, and more were added with every new processor. The time and effort that went into designing CISC processors started to seem… futile.

The processor design community split into two schools of thought-one concentrated on developing better compilers for CISC processors (notably the Intel x86, which is all-pervasive today), while the other believed that CISC processors were grossly overdesigned, and a simpler, more compiler-programmer-friendly instruction set was in order. The idea came to be known as Reduced Instruction Set Computing (RISC), and came with its own set of advantages and disadvantages.

Every RISC instruction takes one single clock cycle to execute, so the CPU never has to wait for complex instructions to finish executing; the time saved is even more prominent when instructions are sent alternately to multiple processors. Most operations would take the same time on both RISC and CISC processors regardless, but the hardware required to decode RISC instructions is less complex, which makes it easier and cheaper to implement. The most significant disadvantage of the RISC architecture, however, is that it relies quite heavily on software-a badly written compiler can have a devastating effect on performance, as could badly-written programs.

In a nutshell, the simplicity of implementing an RISC machine makes it perfect for mobile processors, so that’s precisely what Acorn decided to use when they came up with the ARM.

At The Drawing Board
The biggest thing to consider when designing a mobile processor is power consumption. Every single decision that follows-architecture, clock speed and so on-is driven by the need to use as little power as possible, and naturally so. How would you like it if you had to keep recharging your new PDA phone every three hours? Keeping power consumption low also ensures that less of it is dissipated as heat-which is good, because you don’t want to be saddled with a heat-sink in your pocket. Or worse.

It’s also important that these processors cost very little, which in turn means that they should be easy to design.

So in 1983, Acorn Computers designed the ARM (Acorn RISC Machine), a 32-bit RISC processor which had a third of the transistors as the Motorola 68000-which was six years older than the ARM-and could still actually do stuff.

while (i != j)
      if (i > j)
          i -= j;
      else
          j -= i;
   return i;


The most significant disadvantage of the RISC architecture is that it relies quite heavily on software

The premise is that if the lower of i and j is subtracted from the greater perpetually till they’re finally equal, the final number is the GCD.

When this code is compiled to x86 assembly, you’ll have instructions that:
1. Check the equality of i and j; the CPU will execute the following code if they’re equal, or will start executing code from another (specified) memory location if not. This is called branching-when there two possible outcomes of the same situation.

2. Once inside the loop, check which of i and j is greater and subtract the lower from it-resulting in another possible branch.

The x86 processor has an instruction pipeline, which loads instructions from the system’s memory and keeps them ready for the CPU to execute. In the above case, let’s say that while the CPU is performing the first comparison, the code for the rest of the loop is already in the pipeline. If i and j are equal, however, all that code is unnecessary, so the pipeline has to be cleared, and instructions need to be loaded from a new memory location all over again. This wastes the pipeline, CPU time; as we’ve mentioned before, these are expensive resources, so wastes are unacceptable. The x86 architecture compensates for this with a branch predictor, which does exactly what the name implies. Today’s predictors are accurate around 99 per cent of the time, and the overall gains offset the losses caused by the one percent.

loopCMPRi,Rj            ;set condition “NE (not equal)” if (i != j)
                ;            “GT (greater than)” if (i > j),
                ;        or  “LT (less than)” if (i < j)          
    SUBGT  Ri, Ri, Rj        ; if “GT”, i = i – j; 
    SUBLT  Rj, Rj, Ri        ; if “LT”, j = j – i;
    BNE loop        ; if “NE”, then loop

ARM, however, would have none of this. Branch predictors add complexity, so Acorn decided to use the last four bits of their instruction code as conditional code, which forgoes the branching issue altogether-for smaller loops, at least. The ARM assembly code for the same operation goes thus:

ARM doesn’t have to fight a Megahertz war-it can get more done for per clock cycle, so it can run on a lower clock frequency without too much loss

The result of the CMP (Compare) instruction is stored as a condition flag in the Current Processor State Register (CPSR) on the CPU for later reference.

Of the 32 bits that form the ARM’s instruction, 28 are used for the actual instruction, and the remaining four carry the condition flag-this is ARM’s own way of implementing RISC.

So when the SUBGT (Subtract if Greater Than) instruction is sent to the CPU, it isn’t going to waste CPU cycles loading the condition flag and then checking it-the flag is right there, and depending on its contents, the instruction executes.

The final instruction tells the ARM to branch back to the label “loop” if i and j aren’t equal. Notice that at no point here does the ARM have to jump to different memory locations-saving precious nanoseconds.

This clean, efficient way of going about things means that the ARM doesn’t have to fight a Megahertz war-it can get more done for per clock cycle, so it can run on a lower clock frequency without too much loss. Lower clock frequencies translate to less heat generated within the chip, so the only thing heating up your ARM is probably the sunlight that you’re basking in.

Assembly Language
When you give instructions to a microprocessor, you do so in Assembly Language. The instructions involve very granular operations in the processor-moving a byte of data from the main memory to the processor’s internal registers, for instance. You write assembly code in the form of mnemonics-MOV, ADD, DIV and so on, which are then converted to hexadecimal  operation codes or op-codes, which are finally given to the processor.

Microprograms
Microprograms (written in microcode) take op-codes and convert them into real processor actions. The ADD instruction, for instance, will bring numbers from the system’s memory to the processor’s registers before adding them-it’s the microcode that implements this part. Microcode is hard-wired into the processor when it’s designed, and optimising it for performance is right up there with the designers’ biggest headaches of all time.

Coffee With Jazelle