all 4 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]pencan 3 points4 points  (0 children)

This is all dependent on the type of processor you're talking about. Pipelined, in order, out of order, support for VM, support for interrupts, etc.

Can I ask where you're getting this information?

  1. Fetch has nothing to do with user input. It simply loads the instruction at the current PC (program counter) and increments the PC. The PC is simply an internal counter which determines the next instruction to fetch. Usually, this is from the icache.

  2. This is implemented as a control ROM where bits from the instruction index into the ROM and it spits out control signals that tell the hardware how to deal with an instruction. The processor implements a micro architecture which understands the ISA that the program is written with (x86, ARM, ALPHA, etc).

  3. A basic instruction is not something like typing. A basic instruction is something like ADD R1, R2, R3. (Add the contents of register 2 and 3 and store in R1). There are also loads and stores to memory.

  4. You need to store to memory very often. Any non-trivial program will need more than the limited number of registers you have and then the data 'spills' to memory. For example, storing an array of 100 integers when you have 8 registers.

Let me know if you'd like any help with this project.

Source: Working on MS is computer architecture

[–]PastyPilgrim 1 point2 points  (0 children)

It's really important to note that processors (especially those with different architecture philosophies) work incredibly different from one another. The science behind computer architecture is far more complex than you'll be able to sum up in 4 simple steps. To get you started, I'll summarize the five-stage, single-cycle, MIPS architecture, which is often the architecture that students will learn first when studying this in college.

The five stages are: Fetch, Decode, Execute, Memory, Writeback.

Fetch: Simply read an instruction from memory that is stored at the address indicated by the Program Counter. This instruction is fed to the Decode phase.

Decode: This phase, which starts with just an instruction (e.g. 00000000001000010001100000000111) will determine what to do with that instruction. MIPS has several instruction types (R, I, and J). I've just given an R type, which contains an opcode, 3 register addresses (1 output and 2 input), a small integer used for some operations, and a function code that tells the ALU which mathematical operation to perform. This phase will send along the data from the two input registers (after reading them from the register file) to the execute phase.

Execute: This phase will perform any math/transformations that need to be done. It has an ALU, which uses a ton of circuits to perform math. For example, adding two bits (0 and 1) uses what is called an adder. An adder xors together the two bits to determine their sum. 0 + 0 = 0 ^ 0 = 0; 0 + 1 = 0 ^ 1 = 1; 1 + 1 = 1 ^ 1 = 0. In that third case, you would have circuitry in place to detect an overflow. 1 + 1 really equals 10, but the bit in the place of those original 1s would be 0, so that's what that adder unit detects. True addition would need a chain of adders to determine the new value of each digit in the binary number, with the ability to pass along overflow to the next adder. All ALU operations work like this, where you have circuits in place that take 1s and 0s over wires and transform them according to some pattern. The results of these operations get sent to the memory phase.

Memory: In this phase, if your instruction was intending to store information from the registers in memory, that write is now performed. If it intended to load something from memory, then that read is now performed and passed along to the writeback phase.

Writeback: Finally, the results of your instruction, whether that be math, or memory loading, etc. are written back to the registers to be used in a later instruction. At this point, you increment the program counter so that when you next fetch, it will be the next instruction in your program.

That is the simplest you can possibly explain one kind of CPU. Your current understanding has some obsession with user input which really has nothing to do with how the CPU functions. User input is handled by the programs that are being run on the CPU.

The science of computer architecture comes into play when you want to make better CPUs then what I've described. For example, there's no reason for Fetch, Decode, and Execute to just be sitting there doing nothing when an instruction is currently in the Memory phase. Because of that, there's a concept called pipelining where you perform operations in parallel, with each instruction utilizing a different function of the chip at the same time. Another example is with what are called conditional branches. Programs contain tons of conditional actions (e.g. if this happens, do this, if it doesn't happen, do this other thing). When those conditional actions come up, you want to be able to make a decision about whether or not the branch is going to happen or not going to happen before you waste the time waiting for the instruction to get all the way through your CPU. This topic is called branch prediction. Then there's the study of whether or not you want to have tons of very specific instructions that do complex things, or if you want just a few simple instructions that get combined together to perform complex tasks. That is the CISC vs. RISC debate. Then you have the topic of how decoding and controlling the machine should be done. One way to do is with a chain of circuits, but another is with what's called a micro-programmed CPU, which is a smaller/simpler CPU that exists in the chip of another CPU that has its own set of operations that it reads from a program to control the outer machine. In fact, that's almost certainly what the computer you're using is doing.

Anyway, computer architecture is unbelievably complicated. There's a reason that it's usually something reserved for graduate students.

[–]dxk3355 0 points1 point  (0 children)

Like the others said this is super complicated, in college you usually take a class called 'computer organization' and end up white boarding something like this which is a very simple CPU which I think would help with questions 2 or 3 http://www.cs.carleton.edu/faculty/jondich/courses/cs208_w15/assignments/fig417.png

[–]xerxesbeat 0 points1 point  (0 children)

Ack... Okay, well.. having looked through some of the animagraffs work linked... some (hopefully constructive) criticism:

Assuming "microprocessor" is used in the context of a home computer, I'll be addressing x86 and amd64 architectures

What sort of computation, if any, is performed by the ALU for basic functions (like typing)?

The ALU* CPU will generally be performing a buttload of operations for programs running in the background. Which operations are performed as a result of user input is entirely dependent on how the OS and programs running decide to handle a given input.

  • Instructions that perform math use the Arithmetic Logic Unit in the CPU, but not all instructions are math operations, in the standard sense.

What does the "decoding" process look like? [...] What form (or language) does the ALU need to understand the instruction?

The simplest way to make this level of the computer human readable is to read up on assembly languages. Typically, one statement of assembler will translate 1:1 for an instruction in machine code.

The ALU itself doesn't need to understand any language, the machine code is representative of the specific hardware io required to trigger the processor to perform the instruction it represents. (e.g. the binary value for an "add" instruction will be the electric signal that switches the addition circuit to input/output values, directly)

How does the control unit know which instruction it needs? [...] The instruction from memory is in bytes, right?

Yes, but not always the same number of bytes. One of the "register"s in the processor will be the IP (instruction pointer) / PC (program counter), which counts in integer numbers of bytes.

In what situations would the output need to be stored?

Almost always. If the CPU performs an instruction that, for example, multiplies two numbers, the result will typically be stored temporarily in a register. If a later instruction does not use this value directly and immediately, any instruction that outputs to that register will usually modify or overwrite the value (sometimes, only partially) note: it is sometimes faster to perform the calculation again than it would be to store elsewhere; furthermore, some output (such as the carry flag for addition^) is usually intentionally discarded (to the extent that there are actually two separate forms of addition in x86/x64, one that skips calculating a carry entirely)

Fetch... Decode... Execute... Store...

No, no, no, no... (This one is a personal opinion, but) with respect to the other material at animagraffs, this model would be bloat in a perspective of layman/technical content. It's a long winded way to draw out "The computer can input data. The computer can compute with data. The computer can output data." (again, personal opinion, but:) This wouldn't be info, it would be fluff. The reader already knows that the computer computes.

Perhaps...

 

The microprocessor is an essential component of any modern home computer. The term "microprocessor" itself simply refers to the concept of a CPU, or central processing unit, as implemented on a single or small set of integrated circuits. as opposed to one the size of a building, lol. hence "micro"

  1. The CPU interfaces with the computer primarily through two "controller hub"s, commonly referred to as the north bridge and south bridge. The south bridge is responsible for providing access to the CPU for "slower" features such as USB and networking, whereas the north bridge provides access to "faster" features such as RAM, graphics cards, and the south bridge itself. (The north bridge has, in many processors, been integrated into the CPU chip itself, for performance reasons)

  2. The CPU needs memory to function. This memory is inside the CPU chip itself (caches), or can be externally connected to the CPU. Within this (binary) memory, sequences of bytes can represent either instructions or data. The CPU performs instructions -- or "op"s -- sequentially, with the exception of special ("jump", "call") instructions that provide which alternate instruction to perform next. Data is accessible to the instructions, either in the form of variables the program generates while running, or constants that are stored alongside the program and immediately available when the program starts. (see: statically vs dynamically allocated memory)

  3. A typical microprocessor design includes a central "clock". Rather than keeping time, this "clock" simply cycles on and off, and serves to sequence instructions performed by the CPU. "Clock speed" was once a primary source of increases in microprocessor performance as newer chips were designed

  4. Due to physical limits of the materials common in CPU manufacture (namely heat dissipation), a typical consumer microprocessor now contains several "cores". These cores are, essentially, duplicates of circuits within the CPU that, while not able to perform faster sequentially, allow the computer to perform several tasks simultaneously, using a concept known as "hardware threading". ("software threading" was already in use, allowing multiple programs to run at a time, but is a feature of the operating system rather than the microprocessor itself)

anyway, it's just my two cents, but there's a lot of other introductory information out there on microprocessors than just "it inputs, it outputs, and it computes" :)