![\"\"](\"https:\/\/gtechbooster.com\/media\/2023\/01\/26001.jpeg\")
<\/a><\/div><\/div>So far we have looked at the overall workings of a computer and\nspecifically the memory principle. Memories are devices that when given\none input automatically produce an associated output – reading or will\nautomatically store the output if it is also presented. The memory\nprinciple and memory mechanisms are fascinating but we need more we need\n something that can execute instructions making use of the memory – we\nneed a processor.<\/p>\n\n\n\n
Principles Of Execution<\/h2>\n\n\n\n
The processor is quite another level of difficulty.<\/p>\n\n\n\n
The processor is the computer<\/h3>\n\n\n\n
There really is no question of the validity of this assertion.<\/p>\n\n\n\n
If you don\u2019t believe me try running a program written for a PC on a Mac.<\/p>\n\n\n\n
The point is that computers with different processors are different \u2013\n computers with the same processor are just faster or slower.<\/p>\n\n\n\n
The details of memory management and caching my be impressive but the\n real complexity of any computer system resides in the processor and it\nis time to look more closely at how it does what it does.<\/p>\n\n\n\n
Even if you think you already know you still might find the explanation interesting. The reason is that many books and courses don\u2019t really tell you the whole story. They stop short and leave you with a sense that the processor is somehow magic even though you know the rough outline of how it all should work.<\/p>\n\n\n\n
Elsewhere we have discovered that what makes a computer is the intimate connection between processor and memory. When the processor places an address on the address bus a particular memory location is selected and either stores the data on the data bus or places the data stored in the location on the data bus. <\/p>\n\n\n\n
Notice that this isn’t magic. There isn’t a little humanoid that goes and finds a particular memory location by address and then retrieves the contents for the CPU. The action is as automatic as a key in a lock. The CPU puts the address on the address bus and this selects and activates a particular memory location. The read\/write line sets the memory location’s behavior and it either places its content on the data bus or it “latches” or stores the contents of the data bus. All automatic.<\/p>\n\n\n\n
Program Counter<\/h3>\n\n\n\n
This might well be the major operating principle of a computer but it\n leaves out what the processor actually \u201cdoes\u201d with the data.<\/p>\n\n\n\n
After all it is called a \u201cprocessor\u201d so presumably it doesn\u2019t just\nstore and retrieve bit patterns. We already know how binary patterns can\n be used to represent numbers and we know how Boolean logic can be used\nto manipulate them \u2013 with addition and subtraction.<\/p>\n\n\n\n
But this is only part of what goes on. When you first start to\nconsider the workings of the processor it is usually arithmetic that the\n focus falls on. The reason is that we often, mistakenly, think of\ncomputers as \u201ccomputers\u201d but for the vast majority of the time a\ncomputer is actually doing something other than arithmetic.<\/p>\n\n\n\n
Once you start looking a little more closely the magic seems to be\nmore to do with how this lump of silicon, or whatever it is made from,\ncan obey the commands in a program. How on earth does it look at the\nnext instruction in a program, work out what it means and then arrange\nthe immutable hardware to do it? Software may be soft but hardware is\nhard and it doesn’t change depending on what the instruction wants it to\n do.<\/p>\n\n\n\n
Once again there is a tendency to think of a little humanoid sitting\nwhere the processor is waiting for the next instruction to appear and\nthen doing whatever it commands. This is, of course not how it happens\nand it is all just as automatic as the memory storage and retrieval.<\/p>\n\n\n\n
The \u201ctrick\u201d that the processor performs seems very complex but it is\nall based on building the complex from the simple and the very regular \u2013\n but isn\u2019t this always the principle when it comes to computers?<\/p>\n\n\n\n
The first thing a processor needs is some way of keeping track of where it has reached in the program. This is using a single internal memory location, usually called the \u201cProgram Counter\u201d or PC \u2013 and it doesn’t count programs! All internal memory locations within the processor are called \u201cregisters\u201d for historical reasons and to indicate that they are generally just a little more than simple memory locations. For example, the PC register has two operations that it can perform. It can be initialized to a set value and it can be incremented, i.e. it can add one to the value stored in it.<\/p>\n\n\n\n\n\n\n\n
The Fetch cycle<\/h2>\n\n\n\n
As well as the PC register, a processor also has an instruction register which is used to store the current program instruction. A system clock generator provides pulses that synchronize what happens in the entire machine \u2013 it doesn\u2019t have to be this way but non-clock synchronized machines are much more difficult to build and, by for the same reason, to describe!<\/p>\n\n\n\n
What happens is that the PC register contains the address of the next instruction and on the first clock pulse this address is placed on the address bus and a read cycle transfers the instruction into the instruction register. Notice that we are already using \u201clittle human\u201d descriptions of what happens. The address isn\u2019t \u201cplaced on the bus\u201d by some intelligent intervention. Instead there is a logic gate that responds to the clock pulse by enabling other logic gates to allow the contents of the PC register to set the address bus.<\/p>\n\n\n\n
This is called the Fetch cycle.<\/p>\n\n\n\n\n\n
If you want a more detailed description of the fetch cycle you also have to include delays that are necessary for everything to settle down. So the complete fetch cycle might be something like:
<\/p>\n\n\n\n
- On the rising edge of the clock pulse the PC register drives the address bus and the instruction register is set to read whatever appears on the data bus \u2013 i.e the next instruction. However this doesn\u2019t appear on the data bus immediately as it takes time for the memory to respond to the new address.
<\/li> - During the clock pulse the address decoder selects the RAM location that is addressed. The fact that the read\/write line is set to read means that the memory location automatically places its contents on the data bus
<\/li> - On the falling edge of the clock pulse the instruction register latches whatever is on the data bus and the PC register adds one to its contents.<\/li><\/ol>\n\n\n\n
Notice that the fetch cycle is always the same and nothing ever varies, i.e. it is easy to implement this using nothing but logic gates. Let the PC drive the address bus, wait a while for everything to settle and let the instruction register latch what is on the data bas \u2013 easy! <\/p>\n\n\n\n
Once the instruction has been loaded into the instruction register the PC register is automatically incremented by one. This makes sure that at the start of the next fetch cycle the very next instruction is \u201cfetched\u201d and the program progresses from beginning to end.<\/p>\n\n\n\n
So far so good, but what happens to the instruction that is in the instruction register?<\/p>\n\n\n\n
Execute cycle<\/h3>\n\n\n\n
At the moment, with only a fetch cycle, running a program amounts to transferring each program word into the instruction register in turn but nothing actually gets done!<\/p>\n\n\n\n
The solution is to add the \u201cexecute cycle\u201d.<\/p>\n\n\n\n
After each fetch cycle the next clock pulse initiates an execution phase.<\/p>\n\n\n\n
The usual way of explaining the execute cycle is to say that the instruction is \u201cdecoded\u201d and then acted upon.<\/p>\n\n\n\n
The trouble with this explanation is that it is once again almost mystical and it brings to mind the image of someone living in the machine that looks at the instruction and then does what it says. This is of course still nonsense! What really happens is as automatic, regular and non-intelligent as every other aspect of the working computer.
Every instruction is composed of a number of parts or fields. Exactly how many and what type depends on the architecture of the processor and can be decided by the hardware designer, but there are usually at least two.<\/p>\n\n\n\nThe first part is called the \u201cop code\u201d. This is a simple binary value that specifies what the instruction will do.<\/p>\n\n\n\n
Most processors have other registers as well as the program counter and the instruction register and these are generally the subjects of instructions. For historical reasons the first general-purpose register is usually called the A register \u2013 the \u201cA\u201d standing for Accumulator \u2013 and a typical instruction is to load the A register from some specified memory location. Any additional general-purpose registers are usually called B, C, D and so on.
Each instruction has a unique operation code and this not only serves to identify it but it actually causes the computer to carry out the operation. The way that this happens is that the instruction register has a section corresponding to the fixed location of the op code in the instruction.<\/p>\n\n\n\nIn our example, shown in the diagram, the op-code corresponds to the top four bits. Each of the bits in the op-code is connected to some combinatorial logic called the instruction decoder which causes the processor to do whatever the op-code corresponds to.<\/p>\n\n\n\n\n\n\n\n
Op-code<\/h2>\n\n\n\n
The op-code isn\u2019t just any old number; it has a structure.<\/p>\n\n\n\n
In our example the first two bits of the op-code act as a mini address that selects which register the operation is going to use \u2013<\/p>\n\n\n\n
11 A register,
10 B register,
01 C register and
00 D register.<\/p>