Reply to comment
The von Neumann Computer
Submitted by Arancaytar on Mon, 07/10/2006 - 23:30 – No commentsNote to Google users:
Thanks to Drupal's search-engine friendly set-up, this page is receiving fairly good rankings for any searches on the von-Neumann computer, and accordingly a lot of traffic. Please be aware that I am not an expert on this topic, and the text below is a haphazard summary of the syllabus I wrote here to revise for my examination.
If you actually want a good source, you'd be better off with Von Neumann architecture on Wikipedia.
We're getting close to the end. Note that I'm occasionally adding the German terms for some devices; this will help me remember them since the exam is, in fact, in German.
The von Neumann computer is divided into two distinct system parts: The CPU and the RAM memory. The rest (HD, input and output devices) are peripheral devices. CPU and memory are connected via two cables called "buses". The first is the address bus. It goes only in one direction; from the CPU to the memory. Here, the CPU sends requests for reading or writing certain memory cells.
The second is the data bus. It goes in two directions. Here, the memory sends read data back to the CPU, or the CPU sends data to write to the memory. The data bus is also connected to the peripheral devices.
CPU
The CPU is divided into the Control Unit (Steuerwerk), the Arithmetic Logic Unit (Rechenwerk) and the registers. Registers are high speed memory cells within the CPU that serve different functions. The Befehlszähler contains only the memory address of the next command. It is either incremented or - in case of a jump instruction like a loop or an if - is changed to a different value. The Befehlsregister contains the Word of Command itself (note that a "Word", in techspeak, is a code of a certain fixed bit length, in this case usually 16 bit long).
ALU
The ALU has two input registers which can be used to perform a certain arithmetic or boolean operation. The result is stored in the output register.
Commands
The CPU knows two types of command: Those involving only register operations, and those involving memory operations.
Three examples to illustrate:
Command Protocol
This is what the processor does with a command:
- Load the command addressed in the Befehlszähler from the memory into the Befehlsregister.
- Update the Befehlszähler (when exactly this is done with a conditional jump is another matter. Does it take another command cycle after the condition is tested to perform the jump?)
- Decode the command currently in the command register.
- If the command requires a memory cell (most do), find its address.
- Read the required cell into a register if necessary.
- Execute the command.
- Load the command addressed in... and so forth. This is done many millions of times each second. The life of a computer is a monotonous and stressful one.
Interpreter
The thing to note about these commands is that they are not hardwired into the computer. They are byte codes of data, which can be parsed and interpreted by any program. In effect, you can use Java to write a "virtual CPU" that interprets a certain program's code, looks up its memory accesses in a virtual sandbox memory (or allows it to access the physical memory) and acts in all ways like a hardware processor would, except not as fast due to the overhead.
Interpreters can be used at a much lower level too - at the operating system or even below it, extending the processor with "macros" that it interprets and passes on to the physical CPU. This allows for complex commands in the machine code that are executed by the interpreter without the user realizing the difference.
The advantage is the option of building a simpler (thus faster) CPU with fewer hardwired commands, while still allowing for a large and complex command set. The overhead is negligible - around 100%, which is very much balanced by the advantages.
RISKY KISS - er, RISC vs CISC
Can you tell it's 1 AM and I'm beginning to get tired?
There's a definite difference between
and
The latter is a so-called "high language", one that allows for very complex commands (for loops, arrays, even object-oriented programming). The first does only what you tell it to - step by tiny step, using only register cells and memory addresses. There is no reason why this should be any different - let the compilers worry about the machine code, let the humans write in a way that does not fry their brains.
This thought was not always prevalent.
In the late 70s, processors were made very complex. The mission was to close the gap between the high language and machine code, making it possible to write Assembly in the same way one would code Java.
Then, a new processor was developed. This implemented what was dubbed the RISC architecture, making use of only very few, simple commands as opposed to the CISC processors with their interpreters.
Naturally, the RISC processor required several times as many cycles to do what a CISC processor had a single command for. But the RISC processor needed no interpreter, which allowed it to decode commands up to ten times as fast.
- Arancaytar's blog
- 2221 reads



