Curious how does ALU addressing work like in Assembly code?

Question

When writing assembly code, say R1 = R2 + R3, it is pretty easy to understand the addressing procedure because all registers are close to the ALU. But I find it hard to see how does the ALU go to the memory in R2 in instructions like R1 = R1 + M[R2]. It could be very far away, and I don't see it going checking and matching the addresses. How does it even translate the hexadecimal number in R2 into a memory location?

Answer 1

The hex number is a convenience based on the hardware of the processor and memory. A 4 digit hex number like FA3B represents 16 digits in binary (1111 1010 0011 1011), which are the 16 address lines of the system memory. There is a physical 1 to 1 relationship between the binary numbers and the hardware "wires". They are 1 or 0 which is on or off. There are a little over 65,000 possible combinations of those 16 digits ( 2 to the 16th power which everyone calls 64K).

Decoding this to get to a single set of memory bits is done in parallel. In your idea of distance (or some norm that measures how hard it is to reach a memory location) from the ALU, they are all the same distance and take the same amount of time to find. The address lines go to decoding circuits and the outputs are all 0 except the one combination that matches the address bits. Split this into a matrix of 256 rows and 256 columns for each bit of data. If you are fetching a byte, like in an AVR, there are 8 sets. This fits on the flat plane of a silicon slice. The decoders do simple things. They can have 4 inputs and 16 outputs like the 7400 series logic chips. They can be kept that simple and use a bunch of them or on modern chips, more likely one big decoder circuit. You can see how they branch out like a tree along the side of a memory block in some microscopic pictures of memory chips.

Check some wiki type info on how RAM works or easier to picture, ROM - because you don't have to write to it. Looking at a simple example, like a 16 byte ROM should make it clear. -- A quick search did not turn up any good diagrams! Check a data sheet for the 74HC138 to see a simple decoder stage circuit.

For a mental picture that is logically valid, view each memory bit as having sixteen comparators that compare the values on the address bus with its particular address out of the 64K possible values. They all do the comparison simultaneously and only one answers.

If that sounds like it would use a lot of power, it would. In reality it is a divide and conquer strategy. Take the highest digit. In the case or FA3B the most significant binary bit is 1. That means the location is in the upper 32K of memory, so the lower 32K does not even need to be turned on. The next bit is a 1 so it is in the upper 16K of the upper 32 K. Then the upper 8K and the upper 4K and the upper 2K. Finally a 0! So it is in the lower 1K of that last 2K then the upper 512 of that and the lower 256 of that and the lower 128 of that and lower 64 then upper 32 upper 16 upper 8 lower 4 upper 2 and finally it is the upper one of the final two possibilities. I think I counted right.

As you can see, if you arrange the memory in small blocks you don't even have to turn on most if it for any particular access. You can use the address logic to also power up the part of the chip that is needed on the fly, so to speak.

All this to emulate the linear address model of the ALU (or the tape of a Turing Machine).

Answer 2

In my opinion: R1 = R1 + M[R2] is not one of the most basic instructions that CPU can execute in only one clock cycle.

If the CPU does not support this instruction, the compiler should translate this into 2 simpler ones: the first loads data into a temporary register, the second adds that values to R1. Notice that, the temporary register may or may not available from programmer's perspective.

Otherwise, it takes at least 2 clock cycles for the CPU to do 2 separated actions.

You can verify my opinion by looking for required clock cycles of that instruction in the CPU data sheet.

Answer 3

There are two main types of computer ISAs (Instruction set architectures) - RISC and CISC. RISC means Reduced Instruction Set Computer. It does not mean there are fewer instructions, it means that each instruction is less capable. In such an ISA if you want to do this:

ADD R1 R1 M[R2]

You will have to code it like this:

LOAD TEMP M[R2]
ADD R1 R1 TEMP

Now, we have architectures like the ubiquitous x86 ISA. These are CISC ISAs, which means each instruction is very powerful. In fact, you can copy an entire string in x86 assembly like this:

REP MOVSB

And you can have memory-register instructions like the one you described:

MOV EAX [EBX]

Which means take EAX = EAX + M(EBX).

The original x86 chip was microcoded, which means that the preceding instruction would become two simpler RISC-style instructions, which would then be executed sequentially. Then they got pipelined processors, where they had memory stages to access memory. Now as you described, it was complicated and slow.

Nowadays, the x86 instruction decoder decodes these instructions into a internal RISC-like ISA, which is then executed. You can search for the Haswell microarchitecture to see how their latest microarchitecture works!