PDA

View Full Version : A very complicated question, I think.


Brian
14th December 2003, 08:25 PM
I'm going to go slow because I don't know what I'm talking about.
My understanding is this:
A CPU is a crap load of little on/off switches. If this one is on and that one is off*1,000,000, the top left pixel on my monitor turns blue. ect.
Am I on the right track?
How do they get the whole shebang going?
The operating system is looking for on's and off's from the CPU. The CPU is looking for on/off instructions from? the operating system?
Seems like a chicken/egg kind of thing.
How did they ever build an operating system to work with a bunch of on/off switches that had no instructions? Just a capability to be in one of two states.

roger
14th December 2003, 08:48 PM
You are leaving out a couple of levels of abstraction.

CPUs implement assembly language, which is a very low level way to program computers. For example,

ADD R1, R2

adds the value in register R2 (memory in the CPU) to R1 and stores it in R1.


JE R1, R2, 2ABF

compares the values in R1 and R2, and jumps to address 2ABF if they are equal (JE = Jump if Equal).

So the operating system is written as a series of instructions like the above - the programmer does not think of 1s and 0s at the transister level.

Now, how are the assembly instructions implemented as 1s and 0s? Usually, they are not. Instead, there is another level of abstraction, called microcode. Microcode is a way to program the CPU at a very, very low level.

Think of the CPU as built of a bunch of building blocks. Over here are the registers (storage memory) R1 throught R16. Over there is the ALU - the arithemetic unit. There are several pipelines connecting all of the registers to the ALU, and more pipelines leading from the ALU back to the registers. Think of them like water storage tanks connected with pipes and valves. So, the microcode to implement the add instruction above might read something like:

open pipe from R1 to ALU
open pipe from R2 to ALU
Send command to ALU to perform addition
open pipe from ALU back to R1

Now, how are _those_ implemented in 1s and 0s. Well, of course there are many schemes. But a typical way is to implement a very wide word. Say we decide that every microcode instruction has 256 bits. We can then allocate those bits so they control the different values.

So, we can let the first 5 bits indicate which of the registers we are referring to. We can let 0000 mean R1, 0001 mean R2, etc, and 11111 mean no register being used. Say there are 10 destination blocks that we can send the register to. That takes 4 more bits to represent, so let bits 6-9 in our long word tell us where the data goes so. Maybe the ALU is 1010. So far, the first microcode instruction looks like 00001010..... I won't go through the rest of the specification for the imaginary machine I am designing, but you get the idea, I hope.

Now, how does an assembly instruction get executed. Well, each assembly instruction is, you guessed it, a series of bits. In my imaginary machine, each instruction is 16 bits long. Maybe our add instruction looks like:

1001110100110001

The CPU will use a look up table to find where in the CPUs memory the microcode for this instruction resides. It 'jumps' to that location in memory, and starts executing the microcode.

That's all very oversimplified, there are very complicated schemes used to encode assembly instructions, microcode, etc, that go beyond the naive schemes that I used here, but what I described would work fine for a small CPU from 20 years ago.

How does the OS get loaded and run? Well, you have some code stored in nonvolatile memory, a very small program that is just smart enough to load more code. When the CPU is powered up, it is hardwired to always execute that code in nonvolatile memory. This 'boots' the CPU, and enables it to load more code. Basically the BIOS loads code that allows the CPU to communicate with the peripherals needed to get to the OS - the hard drive, CD-ROM, etc. Once that is loaded, it goes to the disk, loads the OS, and runs the OS. Tada!

Beanbag
14th December 2003, 08:57 PM
It's actually quite simple -- when the memory in a computer first powers up, it's in a random state (we're talking about the kind of memory that can be altered by the computer while it's running, not the stuff that has information permanently written into it can only be read, not changed). There's a set of circuitry in the computer known as the reset circuit. Once power has been applied to the computer for a suitable period of time, the reset circuit "thumps" the CPU and also causes a small section of the read-write memory to be replaced by the read-only memory I mentioned before. This read-only memory contains a set of instructions called a boot-loader. When "thumped", or reset, the CPU goes to the same meory location now filled by the boot-loader read-only memory and starts executing the instructions it finds there. The boot-load read-only memory provides enough low-level instructions to cause the CPU to check for proper functioning and to start reading the "real" operating system from the hard drive. Once that's been done, the CPU pulls the plug on the boot-load read-only memory, and goes on doing what the newly loaded operating system says to do.

In the "old days", personal computers had banks of toggle switches on the front panel. You had to manually write the boot-loader program into memory in binary, using the switches to set the address and data, while the CPU was disabled by flipping another switch that caused it to halt. Once you had the boot-loader written into the starting memory, you reset the CPU, and it took over. Life got better when read-only memory became cheap enough to where you only had to load the boot-loader once, and after that it was written permanently into the chip. The boot-loader usually provided just enough smarts to let you load a more complex program from a punched paper tape reader.

Of course, back then if you had a computer with 4K (that's Kilo, not mega or gigabyte) of memory, you had a BIG system. Hard drives were unheard of, floppies were a luxury no one could afford, so you stored everything either on cassette tape or paper tape.

Sigh. The good old days. Makes me want to wire-wrap up another Z80-based machine.

Regards;
Beanbag

Brian
14th December 2003, 09:06 PM
Gah! Thanks, but, simple as that may be, it's far, far beyond my education. Does the CPU have instructions in it?
I mean, you have a bunch of on/off switches, what makes them do anything. To grasp this I need a "for dummies" answer.

epepke
14th December 2003, 09:46 PM
Originally posted by Brian
I'm going to go slow because I don't know what I'm talking about.
My understanding is this:
A CPU is a crap load of little on/off switches. If this one is on and that one is off*1,000,000, the top left pixel on my monitor turns blue. ect.
Am I on the right track?
How do they get the whole shebang going?
The operating system is looking for on's and off's from the CPU. The CPU is looking for on/off instructions from? the operating system?
Seems like a chicken/egg kind of thing.
How did they ever build an operating system to work with a bunch of on/off switches that had no instructions? Just a capability to be in one of two states.

Modern computers work approximately like this. When switched on, the CPU jumps to execute some instructions in read-only memory that are responsible for loading the operating system.

In the early days, this was actually kind of a big problem. Taking only early microprocessors, most of them had 32 bytes of ROM. Some didn't, and every time you started the machine, you had to enter the 32 bytes using toggle switches. These 32 bytes of ROM were just enough to load the first sector of 128 bytes from the disk (usually a floppy at that time). That, then, loaded the rest of the OS. This is the origin of the term "boot"; the computer pulled itself up by its own bootstraps.

The guy who describes machine code may be answering another aspect of your question. All processors have a way of interpreting memory and doing something according to the bits; this is called the instruction set of the processor. Most modern instruction sets are pretty complex.

It's kind of a fun game, however, to see how little you can get away with and still have a computer. The Turing machine is one way. It consists of a read/write head, a tape with a bunch of squares that can have a 1 or 0, and a set of internal states. Based on the internal state and whether the square under the head is a 1 or a 0, it can write a 1 or a 0 to the tape and move one square to the right or left. (There are many variants on the Turing machine; this is the simplest.) Hard as it may seem, a Turing machine can compute anything that can be computed by any reasonable meaning of the term, although it's much slower than most architectures.

It's also possible, with only a dozen or so states, to build a Universal Turing Maching that can read and simulate any possible Turing Machine encoded on a tape. This is essentially what modern processors do. The states are the internal machinery of the processor, and the memory is the tape.

You can also do anything in a Random Access Machine using indirect fetch and store, subtraction, jump on zero, and the constant 1.

Beanbag
14th December 2003, 09:52 PM
Originally posted by Brian
Gah! Thanks, but, simple as that may be, it's far, far beyond my education. Does the CPU have instructions in it?
I mean, you have a bunch of on/off switches, what makes them do anything. To grasp this I need a "for dummies" answer.

The CPU does have a set of simple instructions hardwired into it, sometimes called microcode. The CPU basically looks at a list of things to do stored in memory. When it sees a particular instruction, say, to add two numbers together, it executes the microcode for that instruction that adds the numbers together and stores the result somewhere according to the type of instruction (there's more than one add instruction, depending on where the numbers are stored and where you want the answer to go).

Regards;
Beanbag

epepke
14th December 2003, 10:16 PM
Originally posted by Beanbag
The CPU does have a set of simple instructions hardwired into it, sometimes called microcode. The CPU basically looks at a list of things to do stored in memory. When it sees a particular instruction, say, to add two numbers together, it executes the microcode for that instruction that adds the numbers together and stores the result somewhere according to the type of instruction (there's more than one add instruction, depending on where the numbers are stored and where you want the answer to go).

Microcode, on processors that have it (not all do) is like a computer within a computer. Ultimately, it all relies on a bunch of primitive instructions that are hard-wired into the CPU. Microcode may decide, for example, which two registers to add, but typically as a simplification there's one Arithmetic Logic Unit that just sees the bits of the registers and a bit that means "add" and uses a bunch of half-adders to add the registers.

At the lowest level, there are gates, consisting of one or a couple of transistors each, that do the primitive operations. These are usually taught as AND, OR, and NOT, but of course there are other possible sets, depending on what's cheaper to make in the die. AND takes two inputs and produces a 1 if both inputs are 1; OR produces a 1 if either input is 1, and NOT produces a 1 if the input is 0 and vice-versa. Using just these and wires, you can build anything you need.

It's also a fun game here to find out what little you can get away with, and you can do everything with NAND, which is AND with a NOT on the output. Or NOR.

In reversible computing, which may become important for quantum computing, the gates are slightly different: NOT, Controlled-NOT, and Controlled-Controlled-NOT. Again, there's a way of doing everything with just one type of gate. Again, you can get by with just one kind of gate.

Janus
15th December 2003, 05:34 AM
Originally posted by Brian
Gah! Thanks, but, simple as that may be, it's far, far beyond my education. Does the CPU have instructions in it?
I mean, you have a bunch of on/off switches, what makes them do anything. To grasp this I need a "for dummies" answer.

Its not realy posible to go from a bunch of switches to pixels on screen in a for dummies answer. I'll try a fill in some of the gaps.

Now firstly, by switches I assume that your refering to transitors. Transistors arn't like a wall switch, but more like a regulator, there is a input current which is used to vary a larger current. A single transitor does little on its own, its only in groups that they do anything remotely use full.

Imagine that you have two switches, "A" and "B". Let say that we can switch on A at any time we like. Also A is wired up to B's input, so that when A is on, B will switch on; When A switches off, then B will switch off. Now lets wire the output of B, into the input of B. So now, when we turn A on, B will switch on, as before, but when we turn A off, B will still be feeding its self, so B stays on.

Now by connecting more and more together, you can obtain more and more complex functions. To make a cpu, you will need lots and lots of diffrent functions, which requires a whole crap load of transitors. You'll need groups of transitors to remember numbers. You'll need more groups of transitors to load and unload numbers, to perform opertaions the numbers, move the numbers in and out of main memory, and so on, and so on.

None of this has anything to do with getting pictures on screen. For that the cpu has to talk to some video hardware, and It will do that the same way as it talk to main memory. It all works a bit like the telephone system. Most numbers connect you to another telephone, but one particular number connects you to the talking clock. Most memory address are just memory addresses, but some are map on to bits of hardware, such as the video adaptor. Getting dots on the screen is accomplished by writing the correct value to the section of memory that is owned by the video hardware. The video hardware will do the rest.

epepke
18th December 2003, 10:20 AM
Brian, has any of this helped?

Brian
19th December 2003, 10:04 PM
Originally posted by epepke
Brian, has any of this helped?

A little. Thanks. Anything I'm missing is due to my lack of knowledge.
The instructions the chip has on it, when you go all the way to the bottom, are they analog? Simple machines (that would be pretty wild)? I just can't figure how electricity shoots into the chip, and all the little gates and switches know what to do. Like, ZAP!, "I better start talking to the hard drive!".

roger
19th December 2003, 10:23 PM
Brian,

Reductionism, while a powerful way to analyze the world, is not necessarily the easiest way to learn something. In other words, thinking of some complex computer operation at the user level, and then trying to imagine how the 6million transistors make that happen by shuffling electrons around, is enough to boggle any brain.

It's probably easier to learn this stuff from the bottom up. Learn what a logic gate is, and how they work (basically they take one or two inputs, transform them in a very well defined way to make an output). Then learn how to combine a couple of logic gates together to do some simple things - make a half adder (something that adds two bits), memory for a single bit, etc. Then learn how to connect a bunch of half adders together so it can add to 32 bit words. Then learn how to connect the bits of memory to the adder. etc. Don't worry too much about the next step - "but, but, the CPU can do multiplication, how do you multiply" type things. Trust that the next step in complexity will be handled fine.

But basically everything is built up in a very modular fashion. transistors are linked together to make logic gates - AND, OR, NAND, NOR, NOT. Period. There are many other ways to link transistors together, but they are not used (for the most part). Because modular is easy to understand.

Gates are plugged together to make adders, flip flops (storage), etc. Adders, flip flops,etc, plug together to make arithmetic units, etc.

Like legos.

Back when I learned this, in the 80's, there was a helpful book that I bought at radio shack that basically did it in that order. After reading the book 2-3 times, I had it cold. I can't point you to any equivalent book today, but no doubt they are out there.

a_unique_person
20th December 2003, 05:48 AM
They are all transistors, which can and often are used in analog applications. However, in the case of a computer, they are only used in 'digital' mode, that is, binary switches that are either on or off.

Think of it in this way.

The computer is run according to a clock, that tells everyone when they can do something. The main actor is the CPU. It can read stuff in, it can write stuff out, to memory or other devices, such as disk.

The stuff it reads in can be sheer data, that it merely manipulates, or instructions, that tell it what to do.

The instructions that tell it what to do are all binary combinations of 10101010101 etc.

These instructions are decoded, and tell it what to do with the data it has. It may add things, compare things, read things, write things, or change it's program flow according to the results of tests.

Everything it does, takes code. Starting up, writing to a disk, displaying something on the screen, reading the mouse, it's just churning through code. Naturally, if you are moving the mouse while reading a web page and playing an MP3, it is doing a lot of things at once. It cannot literally do this, as a CPU can only ever do one thing at a time, (well, it gets a little more complicated than that internally, but to a person outside the black box, it only appears to do one thing at a time), so there are mechanisms that allow it do these things, a bit at a time, but so fast, that it appears to be doing them at the same time. A bit like superman when he is busy at two places at once.

But here is the good bit. This mechanism that allows it to run two programs at the same time is, itself, another program. Isn't that wonderful?

epepke
20th December 2003, 06:07 AM
Originally posted by Brian


A little. Thanks. Anything I'm missing is due to my lack of knowledge.
The instructions the chip has on it, when you go all the way to the bottom, are they analog? Simple machines (that would be pretty wild)? I just can't figure how electricity shoots into the chip, and all the little gates and switches know what to do. Like, ZAP!, "I better start talking to the hard drive!".

They're made out of transistors, which are normally analog devices, but they are biased so heavily that effectively they're either on or off.

To take one classification, everything can be made of AND, OR, and NOT gates. I think it's simpler to understand if you talk about relays. I don't know to what extent people are familiar with these in this day and age, so I'll explain. They have a little electromagnet in them, a coil wrapped around a piece of iron. When the coil is energized, it becomes magnetic and attract a bar which flips a switch. In the double-throw relay, the switch is a little arm that is connected to one of two contacts, one if the relay is energized, and the other if not.

Using relays, calling current flowing, through a contact or a coil, a 1 and calling the absence of current a 0, you can construct all three gates. The OR gate is the simplest: just connect a couple of wires together. For the AND gate, use one signal to energize a relay, and run the other signal through the "on" contact, so that current flows only if both are on. For the NOT gate, just use the "off" contact and connect the arm to the power supply.

Doing this, it's possible to build any computer. Of course, relays are slow and clunky, and they get dirty, so we use transistors instead. But they effectively work the same way. Everything else is wiring and software.

The Central Scrutinizer
20th December 2003, 01:38 PM
Originally posted by Brian
I'm going to go slow because I don't know what I'm talking about.
My understanding is this:
A CPU is a crap load of little on/off switches. If this one is on and that one is off*1,000,000, the top left pixel on my monitor turns blue. ect.
Am I on the right track?
How do they get the whole shebang going?
The operating system is looking for on's and off's from the CPU. The CPU is looking for on/off instructions from? the operating system?
Seems like a chicken/egg kind of thing.
How did they ever build an operating system to work with a bunch of on/off switches that had no instructions? Just a capability to be in one of two states.

It's magic.

The Central Scrutinizer
20th December 2003, 01:40 PM
Originally posted by roger
You are leaving out a couple of levels of abstraction.

CPUs implement assembly language, which is a very low level way to program computers. For example,

ADD R1, R2

adds the value in register R2 (memory in the CPU) to R1 and stores it in R1.


JE R1, R2, 2ABF

compares the values in R1 and R2, and jumps to address 2ABF if they are equal (JE = Jump if Equal).


Technically, the machine implements machine code. Assembler is a higher level language that still has to get converted to machine code. So call me a nitpicker!

Wudang
20th December 2003, 02:03 PM
Try this (http://www.research.ibm.com/journal/rd/464/schwarz.html)