A basic model for how a CPU works
-
In my student days - this was in 1979 - one of the lab exercises were with an AMD 2901 Evaluation Kit. The 2901 was a 4-bit "bit slice" ALU, with carry in and out, so you could hook two of them together for an 8-bit machine, four for a 16-bit or 8 for a 32-bit. We had only a single one. With the ALU came a memory for 64 words of 16 bit microcode: Flip 16 switches, press Deposit, flip again, press Deposit ... 64 times to fill the entire microcode memory. We hooked up each of the 16 bits to the control lines for the ALU: Load accumulator from bus, dump accumulator to bus ... actually, today I have only a vague memory of what the control signals were. The 'sequencer' was a separate chip that selected one word from microcode RAM, transferring it to the ALU control inputs. It had a microcode address counter; one of the control signals incremented this counter. We did succeed in microcoding an instruction for reading four switches (the "bus") as data, adding another 4 bit value, and display the result on 4 LEDs (plus one for the carry line). This was an exceptionally valuable lab exercize to learn what (an extremely simpified) CPU is like in its very basic mechanisms. If 2901 Evaluation Kits were still on the market, I would recommend it to anyone who wants a true hands on experience with a CPU. (If you happen to find one on eBay: Be prepared to do some thorough studying of the ALU before trying to microcode it; microcoding is not to be don on intuition!) Of course: Anything like the 2901 kit can teach you only the basic techniques of simple, unsophisticated computers, the way they were built in the old days. I see other people refer to 'modern' CPUs as if they have little to do with what an evaluation kit can teach you - but you can immediately forget jumping directly onto a 'modern' CPU. It is so complex, contains so many fancy tricks for speeding it up, that you will be be completely blown down. Better start with something that you have a chance to really understand, and then add the fancy techniques one by one. If you get as far as to thoroughly understand even a third of them, you will be qualified as Chief Engineer at AMD or Intel :-) Or, to phrase it differently: Don't expect to understand the fancy techniques. You may get as far as to understand what they want to achieve, but don't expect to understand how.
I remember bit slicing processing and the 2901 set. We also do some similar exercises. I agree, modern CPU's are much more complex, but the AMD 2901 exercises really help one to understand the basics that almost all CPU's have in common. I also agree, micro-coding is not intuitive and that was why we were getting a lesson in it. WOW blast from past. Thanx for sharing that.
"A little time, a little trouble, your better day" Badfinger
-
Circa 87-88 we used a software package to do the same. We used it to build classics like Mark I, Eniac, etc Then you had to write a small assembly program to run on it. Hats off to some of the people that made real programs on the real hardware with a handful of op codes. I think it took about 30-40 op codes of self modifying code to sum an array.
Reminds me of a simulator I was in touch with (as the councellor for a student project using it - the students did all the work :-)), for the 8051. So it was not a general simulator but specific for this one controller. This had the great advantage that the simulator knew all the internal working of the chip and could provide a graphical display of how a pulse flowed from one internal unit to the other on, as we single stepped through the clock cycles. The simulator was so well made that even when you single stepped by clock pulses, it managed to generate 'real' output on the PC's COM port, where another PC was hooked up for displaying it (and also provide character input). 8051 is a simple processor, but an actual, industrial level one that I believe is still in use (at least it was five years ago). It is not a toy, not historical (well, that may be argued), not experimental - that gives the experience some real value. I am surprised that you were able to obtain the schematics for Mark I and Eniac, though! Mark I wasn't an electronic computer, but built from relays. So I guess you had to re-interpret the relay signals and mechanical equipment controlled by the relays as if they were logic gates ... Must have been fun! For being curious: With the Eniac, did you model it valve-by-valve (there were 18000+ of them!), or did you see them as groups performing a function (such as a flip-flop) to model that function as such, independent of the original valve realization of the same? (Since both Mark I and Eniac were decimal machines, not binary ones, I guess you couldn't condsider adders etc. as logical units, simulating them by binary addition!) Do you happen to have any links to this software package (I suspect that would be to a technical museum!), and to the Mark I and Eniac descriptions you based your implementation on?
-
Reminds me of a simulator I was in touch with (as the councellor for a student project using it - the students did all the work :-)), for the 8051. So it was not a general simulator but specific for this one controller. This had the great advantage that the simulator knew all the internal working of the chip and could provide a graphical display of how a pulse flowed from one internal unit to the other on, as we single stepped through the clock cycles. The simulator was so well made that even when you single stepped by clock pulses, it managed to generate 'real' output on the PC's COM port, where another PC was hooked up for displaying it (and also provide character input). 8051 is a simple processor, but an actual, industrial level one that I believe is still in use (at least it was five years ago). It is not a toy, not historical (well, that may be argued), not experimental - that gives the experience some real value. I am surprised that you were able to obtain the schematics for Mark I and Eniac, though! Mark I wasn't an electronic computer, but built from relays. So I guess you had to re-interpret the relay signals and mechanical equipment controlled by the relays as if they were logic gates ... Must have been fun! For being curious: With the Eniac, did you model it valve-by-valve (there were 18000+ of them!), or did you see them as groups performing a function (such as a flip-flop) to model that function as such, independent of the original valve realization of the same? (Since both Mark I and Eniac were decimal machines, not binary ones, I guess you couldn't condsider adders etc. as logical units, simulating them by binary addition!) Do you happen to have any links to this software package (I suspect that would be to a technical museum!), and to the Mark I and Eniac descriptions you based your implementation on?
I tried googling it but could not find it. It was fairly simple. I remember that you declared registers with bit width, something like: ACC<1:12> PC<1:10> RAM<1:12>[0:1024] And then you would define the op codes somehow. And how they affected the declared registers and memory. I think the Mark I or II had a few op codes: 1. Load from memory address into ACC 2. Store inverse/negative from ACC to memory 3. Add from memory into ACC 4. Skip next address if ACC is zero 5. JMP / set PC 6. HALT I do remember our final project was to create a single instruction multiple data grid computer.
-
I guess that obermd is essentially referring to various effects of pipelining. Each individual instruction may spend 5-6 (or more) clock cycles total in various stages of processing: Instruction fetch, instruction decoding, operand fetch, *instruction execution*, storing results, ... The *instruction execution* (e.g. adding) is done in a single clock cycle, but that is only a part of the processing. In parallell with this instruction doing its add (say), the previous instruction is stuffing away its results, the next instruction is having operands fetched, the one two steps behind is being decoded and the one three steps behind is being fetched. So the CPU may be doing one add (say) per cycle, and in the same cycle one of each of the other operations, on different instructions. For one given instruction, it takes a number of cycles to have all the different processing steps done, though.
Hi nice to meet you. > I guess that obermd is essentially referring to You are not too sure huh? >clock cycles total What I understand is that sometimes it takes one cycle to pass an instruction through an individual processing stage. There are several processing stages so it takes more than one cycle to land the operation result in the destination register.