Add second year
This commit is contained in:
@ -0,0 +1,401 @@
|
||||
- #[[CT213 - Computer Systems & Organisation]]
|
||||
- **Previous Topic:** [[Overview of Computer Systems]]
|
||||
- **Relevant Slides:** 
|
||||
-
|
||||
- What is a **Processor Programming Model**? #card
|
||||
card-last-interval:: -1
|
||||
card-repeats:: 1
|
||||
card-ease-factor:: 2.5
|
||||
card-next-schedule:: 2022-09-19T23:00:00.000Z
|
||||
card-last-reviewed:: 2022-09-19T18:30:08.809Z
|
||||
card-last-score:: 1
|
||||
- A **Processor Programming Model** defines ^^how instructions access their operands and how instructions are described in the processor's assembly language.^^
|
||||
- Processors with different programming models can offer similar sets of operations but may require very different approaches to programming.
|
||||
-
|
||||
- ## Instructions
|
||||
- What is the **Instruction Cycle**? #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T17:44:15.029Z
|
||||
card-last-reviewed:: 2022-09-19T17:44:15.030Z
|
||||
card-last-score:: 5
|
||||
- The **Instruction Cycle** is the ^^procedure of processing an instruction^^ by the microprocessor.
|
||||
- **Fetch:** read the instructions from memory
|
||||
- **Decode:** Determine what is to be done
|
||||
- **Execute:** Perform the operation
|
||||
- Each of the functions fetch -> decode -> execute consist of a sequence of one or more operations inside the CPU (and interaction with the subsystems).
|
||||
- ### Types of Instructions
|
||||
- #### Data Transfer Instructions
|
||||
- What are **Data Transfer Instructions**? #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-22T15:23:45.121Z
|
||||
card-last-reviewed:: 2022-09-18T15:23:45.122Z
|
||||
card-last-score:: 5
|
||||
- Operations that ^^move data^^ from one place to another.
|
||||
- These instructions ^^don't modify^^ the data, they just copy it to the destination.
|
||||
- What operations can data transfer instructions do? #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.36
|
||||
card-next-schedule:: 2022-09-18T20:04:00.341Z
|
||||
card-last-reviewed:: 2022-09-14T20:04:00.342Z
|
||||
card-last-score:: 3
|
||||
- card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.6
|
||||
card-next-schedule:: 2022-09-22T14:49:14.991Z
|
||||
card-last-reviewed:: 2022-09-18T14:49:14.991Z
|
||||
card-last-score:: 5
|
||||
1. **Load data** from memory into the microprocessor. #card
|
||||
- These instructions copy data from memory into microprocessor registers (i.e., LD).
|
||||
- card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.46
|
||||
card-next-schedule:: 2022-09-23T18:25:37.994Z
|
||||
card-last-reviewed:: 2022-09-19T18:25:37.995Z
|
||||
card-last-score:: 3
|
||||
2. **Store data** from the microprocessor into the memory. #card
|
||||
- Similar to load data, except that the data is copied in the opposite direction (i.e., ST).
|
||||
- Data is saved from internal microprocessor registers into the memory
|
||||
- card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T18:27:19.756Z
|
||||
card-last-reviewed:: 2022-09-19T18:27:19.757Z
|
||||
card-last-score:: 5
|
||||
3. **Move data** within the microprocessor. #card
|
||||
- These instructions move data from one microprocessor register to another (i.e., MOV)
|
||||
- card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T17:44:07.730Z
|
||||
card-last-reviewed:: 2022-09-19T17:44:07.731Z
|
||||
card-last-score:: 5
|
||||
4. **Input data** into the microprocessor.
|
||||
- A microprocessor may need to input data from the outside world.
|
||||
- These are the instructions that input data from the input device into the microprocessor.
|
||||
- card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T17:47:33.165Z
|
||||
card-last-reviewed:: 2022-09-19T17:47:33.165Z
|
||||
card-last-score:: 5
|
||||
5. **Output data** from the microprocessor.
|
||||
- The microprocessor copies data from one of its internal registers to an output device.
|
||||
- Example: the microprocessor may want to show the content of an internal register on a display (the key has been pressed) (i.e., IOWR).
|
||||
- #### Data Operation Instructions #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.46
|
||||
card-next-schedule:: 2022-09-23T18:22:56.393Z
|
||||
card-last-reviewed:: 2022-09-19T18:22:56.393Z
|
||||
card-last-score:: 5
|
||||
- Instructions ^^do^^ modify their data values.
|
||||
- They typically perform some operation (e.g., +, -, *) using one or two data values (operands) and store the result.
|
||||
- What operations can data operation instructions do? #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T18:24:32.521Z
|
||||
card-last-reviewed:: 2022-09-19T18:24:32.522Z
|
||||
card-last-score:: 5
|
||||
- **Arithmetic Instructions** #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T18:22:33.756Z
|
||||
card-last-reviewed:: 2022-09-19T18:22:33.756Z
|
||||
card-last-score:: 5
|
||||
- add, subtract, multiply, or divide
|
||||
- ADD, SUB, MUL, DIV
|
||||
- Instructions that increment or decrement one from a value
|
||||
- INC, DEC
|
||||
- Floating point instructions that operate on floating point values
|
||||
- FADD, FSUB, FMUL, FDIV
|
||||
- **Logic Instructions** #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T18:06:07.075Z
|
||||
card-last-reviewed:: 2022-09-19T18:06:07.076Z
|
||||
card-last-score:: 5
|
||||
- AND, OR, XOR, NOT, etc.
|
||||
- **Shift Instructions** #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.36
|
||||
card-next-schedule:: 2022-09-18T20:03:10.515Z
|
||||
card-last-reviewed:: 2022-09-14T20:03:10.515Z
|
||||
card-last-score:: 3
|
||||
- SR, SL, RR, RL, etc.
|
||||
- #### Program Control Instructions #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.6
|
||||
card-next-schedule:: 2022-09-21T20:52:13.309Z
|
||||
card-last-reviewed:: 2022-09-17T20:52:13.310Z
|
||||
card-last-score:: 5
|
||||
- **Jump** or **branch** instructions are used to ^^go to another part of the program^^; Jumps can be **absolute** or **conditional**.
|
||||
- e.g., if, then, else.
|
||||
- Instructions that can generate **interrupts**.
|
||||
- Software interrupts.
|
||||
- **Jump & branch instructions** (conditional or unconditional) #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T18:23:56.248Z
|
||||
card-last-reviewed:: 2022-09-19T18:23:56.248Z
|
||||
card-last-score:: 5
|
||||
- **JZ:** Jump if the zero flag is set.
|
||||
- **JNZ:** Jump if the zero flag is **not** set.
|
||||
- **JMP:** Unconditional jump - flags are ignored.
|
||||
- etc.
|
||||
- **Comparison Instructions** #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T17:49:38.450Z
|
||||
card-last-reviewed:: 2022-09-19T17:49:38.451Z
|
||||
card-last-score:: 5
|
||||
- TEST: logical BITWISE AND
|
||||
- **Calls & Returns** a / from a routine (conditional or unconditional) #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T18:26:43.360Z
|
||||
card-last-reviewed:: 2022-09-19T18:26:43.361Z
|
||||
card-last-score:: 5
|
||||
- **Call:** call a subroutine at a certain line.
|
||||
- **RET:** return from a subroutine.
|
||||
- **IRET:** interrupt & return.
|
||||
- **Software Interrupts** #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T18:26:39.506Z
|
||||
card-last-reviewed:: 2022-09-19T18:26:39.507Z
|
||||
card-last-score:: 5
|
||||
- Generated by devices outside of a microprocessor (not part of the instruction set).
|
||||
- INT
|
||||
- **Exceptions & Traps** #card
|
||||
card-last-interval:: -1
|
||||
card-repeats:: 1
|
||||
card-ease-factor:: 2.5
|
||||
card-next-schedule:: 2022-09-19T23:00:00.000Z
|
||||
card-last-reviewed:: 2022-09-19T17:43:10.837Z
|
||||
card-last-score:: 1
|
||||
- Triggered when valid instructions perform invalid operations.
|
||||
- e.g., dividing by zero.
|
||||
- **Halt Instructions** #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-22T15:21:28.059Z
|
||||
card-last-reviewed:: 2022-09-18T15:21:28.060Z
|
||||
card-last-score:: 5
|
||||
- Causes the processor to stop executions.
|
||||
- e.g., at the end of the program.
|
||||
- HALT
|
||||
-
|
||||
- ## Stack Architectures
|
||||
- ### The Stack
|
||||
- **Last In First Out (LIFO)** data structure.
|
||||
- Consists of **locations**, each of which can hold a **word of data**.
|
||||
- It can be used to explicitly **save / restore** data.
|
||||
- What operations does the stack support? #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T18:28:06.057Z
|
||||
card-last-reviewed:: 2022-09-19T18:28:06.058Z
|
||||
card-last-score:: 5
|
||||
- The stack supports ^^two operations.^^
|
||||
- **PUSH:** takes one argument and places the value of the argument at the top of the stack.
|
||||
- **POP:** removes one element from the stack, saving it into a predefined register of the processor.
|
||||
- The stack is ^^used implicitly by procedure call instructions.^^
|
||||
- (if available in the data set).
|
||||
- When new data is added to the stack, it is placed at the top of the stack, and all of the contents of the stack are pushed down one location.
|
||||
- ### Implementing Stacks
|
||||
- What are the two ways to implement a stack? #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.36
|
||||
card-next-schedule:: 2022-09-18T20:02:02.188Z
|
||||
card-last-reviewed:: 2022-09-14T20:02:02.189Z
|
||||
card-last-score:: 3
|
||||
- card-last-interval:: -1
|
||||
card-repeats:: 1
|
||||
card-ease-factor:: 2.36
|
||||
card-next-schedule:: 2022-09-19T23:00:00.000Z
|
||||
card-last-reviewed:: 2022-09-19T18:25:12.624Z
|
||||
card-last-score:: 1
|
||||
1. **Dedicated Hardware Stack** #card
|
||||
- Has a ^^hardware limitation^^ (limited number of locations).
|
||||
- Very fast.
|
||||
- card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T18:06:34.732Z
|
||||
card-last-reviewed:: 2022-09-19T18:06:34.733Z
|
||||
card-last-score:: 5
|
||||
2. **Memory Implemented Stack** #card
|
||||
- Limited by the ^^physical memory of the system.^^
|
||||
- Slow compared with hardware stacks, since extra memory addressing has to take place for each stack operation.
|
||||
- {:height 405, :width 638}
|
||||
- Every **push operation** will ^^increment the top of the **stack pointer**^^ with the word size of the machine.
|
||||
- Every **pop operation** will ^^decrement the top of the stack pointer^^ (with the word size of the machine).
|
||||
- **Stack overflows** can occur in both stack implementations
|
||||
- What is a **stack overflow**? #card
|
||||
card-last-interval:: 11.16
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-30T20:49:01.529Z
|
||||
card-last-reviewed:: 2022-09-19T17:49:01.530Z
|
||||
card-last-score:: 5
|
||||
- A **stack overflow** occurs when the amount of data in the stack exceeds the amount of space allocated to the stack (or the hardware limit of the stack).
|
||||
- ### Instructions in Stack-Based Architecture #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.22
|
||||
card-next-schedule:: 2022-09-23T18:28:26.926Z
|
||||
card-last-reviewed:: 2022-09-19T18:28:26.926Z
|
||||
card-last-score:: 3
|
||||
- Instructions in a stack-base architecture get their operands from the stack and write their results to the stack.
|
||||
- The advantage of this is that ^^program code takes little memory - there is no need to specify the address of the operands or registers.^^
|
||||
- PUSH is one exception, because it needs the operand to be specified (either as a constant or as an address).
|
||||
- ### Programs in a Stack-Based Architecture
|
||||
- Writing programs for stack-based architecture is not easy.
|
||||
- Stack-based architectures are better suited for **postfix** notation rather than **infix** notation.
|
||||
- What is **infix notation**? #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T17:49:06.464Z
|
||||
card-last-reviewed:: 2022-09-19T17:49:06.465Z
|
||||
card-last-score:: 5
|
||||
- **Infix notation** is the traditional way of representing mathematical expressions, with ^^operations placed **between** the operands.^^
|
||||
- e.g., a + b
|
||||
- What is **postfix notation**? #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-22T15:21:53.178Z
|
||||
card-last-reviewed:: 2022-09-18T15:21:53.178Z
|
||||
card-last-score:: 5
|
||||
- In **postfix notation**, ^^the operation is placed **after** the operands.^^
|
||||
- e.g., a b +
|
||||
- Stack-based architectures are better suited for **postfix notation**.
|
||||
- Once an expression has been converted into postfix notation, implementing it in programs is easy.
|
||||
- ### Using Stacks to Implement Procedure Calls
|
||||
- Programs need a way to **pass inputs to the procedures** that they call and to receive outputs back from them.
|
||||
- Procedures need to be able to **allocate space in memory for local variables** without overriding any data used by their calling program.
|
||||
- It is impossible to determine which registers may be used safely by the procedure (especially if the procedure is located in a library).
|
||||
- So, a mechanism to **save / restore registers** of the calling program has to be in place.
|
||||
- Procedures need a way to figure out where they were called from.
|
||||
- So, the execution can **return to the calling program** where the procedure completes (they need to restore the program counter).
|
||||
- How are procedure calls implemented in Stacks? #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.36
|
||||
card-next-schedule:: 2022-09-22T14:49:10.043Z
|
||||
card-last-reviewed:: 2022-09-18T14:49:10.044Z
|
||||
card-last-score:: 3
|
||||
- 
|
||||
- When a procedure is called, a **block of memory** in the stack called a **stack frame** is allocated.
|
||||
- The top of the stack pointer is incremented by the **number of locations** in the stack frame.
|
||||
- When a procedure finishes, it jumps to the **return address** of the stack and the execution of the calling program resumes.
|
||||
- How are nested procedure calls implemented in the stack? #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.22
|
||||
card-next-schedule:: 2022-09-23T18:28:18.819Z
|
||||
card-last-reviewed:: 2022-09-19T18:28:18.819Z
|
||||
card-last-score:: 3
|
||||
- 
|
||||
- main program calls function f(),
|
||||
- function f() calls function g(),
|
||||
- function g() calls function h()
|
||||
- ## General-Purpose Register Architectures
|
||||
- ### General-Purpose Register File
|
||||
- In GPR Architectures, instructions read their operands and write their results to a **random access register file**.
|
||||
- The general-purpose register file allows the ^^access of **any** register in **any** order^^ by specifying the number (register ID) of the register.
|
||||
- What is the main difference between a GPR & a stack? #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.46
|
||||
card-next-schedule:: 2022-09-23T18:05:31.335Z
|
||||
card-last-reviewed:: 2022-09-19T18:05:31.335Z
|
||||
card-last-score:: 3
|
||||
- The main difference between a GPR and a stack is that repeatedly reading a register will produce the same result and **will not** modify the state of the register file.
|
||||
- Popping an item from a LIFO structure (stack) **will** modify the contents of the stack,
|
||||
- Many GPR architectures assign special values to some registers in the register file to make programming easier.
|
||||
- e.g., sometimes, register 0 is hardwired with value 0 to generate this most common constant.
|
||||
- ### Instructions in GPR Architecture
|
||||
- What do GPR instructions need to specify? #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.36
|
||||
card-next-schedule:: 2022-09-21T20:52:42.181Z
|
||||
card-last-reviewed:: 2022-09-17T20:52:42.181Z
|
||||
card-last-score:: 3
|
||||
- GPR instructions need to specify:
|
||||
- **the register** that holds their **input operands**
|
||||
- the register that will hole the **result**
|
||||
- What is the most common GPR instruction format? #card
|
||||
card-last-interval:: 26.21
|
||||
card-repeats:: 4
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-15T22:48:52.100Z
|
||||
card-last-reviewed:: 2022-09-19T17:48:52.100Z
|
||||
card-last-score:: 5
|
||||
- The most common GPR instruction format is the **three operands instruction format**.
|
||||
- e.g., "ADD r1, r2, r3" instructs the processor to read the contents of r2 and r3, add them together, and write the results in r1.
|
||||
- Instructions that only have one or two inputs are also present in GPR architecture.
|
||||
- Which architecture allows **caching**? #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T18:23:37.492Z
|
||||
card-last-reviewed:: 2022-09-19T18:23:37.492Z
|
||||
card-last-score:: 5
|
||||
- In GPR Architecture, ^^programs can choose which values should be stored in the register file at any given time^^, allowing them to **cache** the most accessed data.
|
||||
- In stack-based architectures, once the data has been used, it's gone.
|
||||
- From this point of view, ^^GPR architectures have **better performance**^^, at the expense of needing **more storage space** for the program.
|
||||
- larger instructions are needed to encode the addresses of the operands.
|
||||
- #### Simple GPR Instruction Set
|
||||
- 
|
||||
-
|
||||
- ### Programs in a GPR Architecure #card
|
||||
card-last-interval:: -1
|
||||
card-repeats:: 1
|
||||
card-ease-factor:: 2.36
|
||||
card-next-schedule:: 2022-09-18T23:00:00.000Z
|
||||
card-last-reviewed:: 2022-09-18T15:22:40.946Z
|
||||
card-last-score:: 1
|
||||
- Programming a GPR architecture processor is **less structured** than programming a stack-based architecture processor.
|
||||
- There are **fewer restrictions on the order** in which operations can be executed.
|
||||
- In stack-based architectures, instructions must execute in the order that would leave the operands for the next instructions on the top of the stack.
|
||||
- In GPR, any order that places the operands for the next instruction in the register file before the instruction executes is valid.
|
||||
- Operations that access different registers can be **reordered** without making the program invalid.
|
||||
-
|
||||
- ## Stack-Bases vs GPR Architectures
|
||||
- Stack-based architectures are still attractive for certain embedded systems.
|
||||
- GPR architectures are used by modern computers.
|
||||
- ## Stack-Based Architectures #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.36
|
||||
card-next-schedule:: 2022-09-18T20:02:49.354Z
|
||||
card-last-reviewed:: 2022-09-14T20:02:49.354Z
|
||||
card-last-score:: 3
|
||||
- Instructions take **fewer bits** to encode.
|
||||
- **Reduced amount of memory** taken up by programs.
|
||||
- Manages the **use of registers automatically** (no need for programmer intervention).
|
||||
- The instruction set **does not change** if the size of the register file has changed.
|
||||
- ## GPR Architectures
|
||||
- With the evolution of technology, the amount of space taken up by a program is less important.
|
||||
- Compilers for GPR architecture achieve **better performance** with a given number of general-purpose registers than those on stack-based architectures with the same number of registers.
|
||||
- The compiler can choose which values to keep (**cache**) in the register file at any time.
|
||||
@ -0,0 +1,401 @@
|
||||
- #[[CT213 - Computer Systems & Organisation]]
|
||||
- **Previous Topic:** [[Overview of Computer Systems]]
|
||||
- **Relevant Slides:** 
|
||||
-
|
||||
- What is a **Processor Programming Model**? #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.36
|
||||
card-next-schedule:: 2022-10-04T08:27:22.997Z
|
||||
card-last-reviewed:: 2022-09-30T08:27:22.998Z
|
||||
card-last-score:: 3
|
||||
- A **Processor Programming Model** defines ^^how instructions access their operands and how instructions are described in the processor's assembly language.^^
|
||||
- Processors with different programming models can offer similar sets of operations but may require very different approaches to programming.
|
||||
-
|
||||
- ## Instructions
|
||||
- What is the **Instruction Cycle**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:42:30.873Z
|
||||
card-last-reviewed:: 2022-10-03T11:42:30.874Z
|
||||
card-last-score:: 5
|
||||
- The **Instruction Cycle** is the ^^procedure of processing an instruction^^ by the microprocessor.
|
||||
- **Fetch:** read the instructions from memory
|
||||
- **Decode:** Determine what is to be done
|
||||
- **Execute:** Perform the operation
|
||||
- Each of the functions fetch -> decode -> execute consist of a sequence of one or more operations inside the CPU (and interaction with the subsystems).
|
||||
- ### Types of Instructions
|
||||
- #### Data Transfer Instructions
|
||||
- What are **Data Transfer Instructions**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:40:48.321Z
|
||||
card-last-reviewed:: 2022-10-03T11:40:48.321Z
|
||||
card-last-score:: 5
|
||||
- Operations that ^^move data^^ from one place to another.
|
||||
- These instructions ^^don't modify^^ the data, they just copy it to the destination.
|
||||
- What operations can data transfer instructions do? #card
|
||||
card-last-interval:: 10.92
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.46
|
||||
card-next-schedule:: 2022-10-11T06:46:12.475Z
|
||||
card-last-reviewed:: 2022-09-30T08:46:12.475Z
|
||||
card-last-score:: 5
|
||||
- card-last-interval:: 11.56
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-10-11T21:26:36.529Z
|
||||
card-last-reviewed:: 2022-09-30T08:26:36.529Z
|
||||
card-last-score:: 5
|
||||
1. **Load data** from memory into the microprocessor. #card
|
||||
- These instructions copy data from memory into microprocessor registers (i.e., LD).
|
||||
- card-last-interval:: 10.24
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-13T19:28:41.508Z
|
||||
card-last-reviewed:: 2022-10-03T14:28:41.509Z
|
||||
card-last-score:: 5
|
||||
2. **Store data** from the microprocessor into the memory. #card
|
||||
- Similar to load data, except that the data is copied in the opposite direction (i.e., ST).
|
||||
- Data is saved from internal microprocessor registers into the memory
|
||||
- card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T18:29:32.655Z
|
||||
card-last-reviewed:: 2022-10-03T14:29:32.655Z
|
||||
card-last-score:: 5
|
||||
3. **Move data** within the microprocessor.
|
||||
- These instructions move data from one microprocessor register to another (i.e., MOV)
|
||||
- card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T17:44:07.730Z
|
||||
card-last-reviewed:: 2022-09-19T17:44:07.731Z
|
||||
card-last-score:: 5
|
||||
4. **Input data** into the microprocessor.
|
||||
- A microprocessor may need to input data from the outside world.
|
||||
- These are the instructions that input data from the input device into the microprocessor.
|
||||
- card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T17:47:33.165Z
|
||||
card-last-reviewed:: 2022-09-19T17:47:33.165Z
|
||||
card-last-score:: 5
|
||||
5. **Output data** from the microprocessor.
|
||||
- The microprocessor copies data from one of its internal registers to an output device.
|
||||
- Example: the microprocessor may want to show the content of an internal register on a display (the key has been pressed) (i.e., IOWR).
|
||||
- #### Data Operation Instructions #card
|
||||
card-last-interval:: 10.24
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-13T16:45:28.268Z
|
||||
card-last-reviewed:: 2022-10-03T11:45:28.268Z
|
||||
card-last-score:: 5
|
||||
- Instructions that *do* modify their data values.
|
||||
- They typically perform some operation (e.g., +, -, *) using one or two data values (operands) and store the result.
|
||||
- What operations can data operation instructions do? #card
|
||||
card-last-interval:: -1
|
||||
card-repeats:: 1
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-10-03T23:00:00.000Z
|
||||
card-last-reviewed:: 2022-10-03T14:27:42.566Z
|
||||
card-last-score:: 1
|
||||
- **Arithmetic Instructions** #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:44:56.702Z
|
||||
card-last-reviewed:: 2022-10-03T11:44:56.702Z
|
||||
card-last-score:: 5
|
||||
- add, subtract, multiply, or divide
|
||||
- ADD, SUB, MUL, DIV
|
||||
- Instructions that increment or decrement one from a value
|
||||
- INC, DEC
|
||||
- Floating point instructions that operate on floating point values
|
||||
- FADD, FSUB, FMUL, FDIV
|
||||
- **Logic Instructions**
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:43:49.421Z
|
||||
card-last-reviewed:: 2022-10-03T11:43:49.421Z
|
||||
card-last-score:: 5
|
||||
- AND, OR, XOR, NOT, etc.
|
||||
- **Shift Instructions**
|
||||
card-last-interval:: 10.92
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.46
|
||||
card-next-schedule:: 2022-10-11T06:45:44.876Z
|
||||
card-last-reviewed:: 2022-09-30T08:45:44.877Z
|
||||
card-last-score:: 5
|
||||
- SR, SL, RR, RL, etc.
|
||||
- #### Program Control Instructions #card
|
||||
card-last-interval:: 10.8
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-10-11T04:28:17.821Z
|
||||
card-last-reviewed:: 2022-09-30T09:28:17.821Z
|
||||
card-last-score:: 5
|
||||
- **Jump** or **branch** instructions are used to ^^go to another part of the program^^; Jumps can be **absolute** or **conditional**.
|
||||
- e.g., if, then, else.
|
||||
- Instructions that can generate **interrupts**.
|
||||
- Software interrupts.
|
||||
- **Jump & branch instructions** (conditional or unconditional)
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T18:27:30.317Z
|
||||
card-last-reviewed:: 2022-10-03T14:27:30.317Z
|
||||
card-last-score:: 5
|
||||
- **JZ:** Jump if the zero flag is set.
|
||||
- **JNZ:** Jump if the zero flag is **not** set.
|
||||
- **JMP:** Unconditional jump - flags are ignored.
|
||||
- etc.
|
||||
- **Comparison Instructions** #card
|
||||
card-last-interval:: 10.24
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-13T16:42:52.048Z
|
||||
card-last-reviewed:: 2022-10-03T11:42:52.049Z
|
||||
card-last-score:: 3
|
||||
- TEST: logical BITWISE AND
|
||||
- **Calls & Returns** a / from a routine (conditional or unconditional) #card
|
||||
card-last-interval:: 10.24
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-13T19:28:56.319Z
|
||||
card-last-reviewed:: 2022-10-03T14:28:56.319Z
|
||||
card-last-score:: 3
|
||||
- **Call:** call a subroutine at a certain line.
|
||||
- **RET:** return from a subroutine.
|
||||
- **IRET:** interrupt & return.
|
||||
- **Software Interrupts** #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T18:28:46.482Z
|
||||
card-last-reviewed:: 2022-10-03T14:28:46.483Z
|
||||
card-last-score:: 5
|
||||
- Generated by devices outside of a microprocessor (not part of the instruction set).
|
||||
- INT
|
||||
- **Exceptions & Traps** #card
|
||||
card-last-interval:: 4.14
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.6
|
||||
card-next-schedule:: 2022-10-04T12:23:07.638Z
|
||||
card-last-reviewed:: 2022-09-30T09:23:07.638Z
|
||||
card-last-score:: 5
|
||||
- Triggered when valid instructions perform invalid operations.
|
||||
- e.g., dividing by zero.
|
||||
- **Halt Instructions** #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:37:56.173Z
|
||||
card-last-reviewed:: 2022-10-03T11:37:56.174Z
|
||||
card-last-score:: 5
|
||||
- Causes the processor to stop executions.
|
||||
- e.g., at the end of the program.
|
||||
- HALT
|
||||
-
|
||||
- ## Stack Architectures
|
||||
- ### The Stack
|
||||
- **Last In First Out (LIFO)** data structure.
|
||||
- Consists of **locations**, each of which can hold a **word of data**.
|
||||
- It can be used to explicitly **save / restore** data.
|
||||
- What operations does the stack support? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T18:30:00.780Z
|
||||
card-last-reviewed:: 2022-10-03T14:30:00.780Z
|
||||
card-last-score:: 5
|
||||
- The stack supports ^^two operations.^^
|
||||
- **PUSH:** takes one argument and places the value of the argument at the top of the stack.
|
||||
- **POP:** removes one element from the stack, saving it into a predefined register of the processor.
|
||||
- The stack is ^^used implicitly by procedure call instructions.^^
|
||||
- (if available in the data set).
|
||||
- When new data is added to the stack, it is placed at the top of the stack, and all of the contents of the stack are pushed down one location.
|
||||
- ### Implementing Stacks
|
||||
- What are the two ways to implement a stack? #card
|
||||
card-last-interval:: 8.88
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.22
|
||||
card-next-schedule:: 2022-10-09T05:45:27.331Z
|
||||
card-last-reviewed:: 2022-09-30T08:45:27.331Z
|
||||
card-last-score:: 3
|
||||
- card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.22
|
||||
card-next-schedule:: 2022-10-04T09:27:02.226Z
|
||||
card-last-reviewed:: 2022-09-30T09:27:02.226Z
|
||||
card-last-score:: 3
|
||||
1. **Dedicated Hardware Stack** #card
|
||||
- Has a ^^hardware limitation^^ (limited number of locations).
|
||||
- Very fast.
|
||||
- card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:44:04.293Z
|
||||
card-last-reviewed:: 2022-10-03T11:44:04.294Z
|
||||
card-last-score:: 5
|
||||
2. **Memory Implemented Stack** #card
|
||||
- Limited by the ^^physical memory of the system.^^
|
||||
- Slow compared with hardware stacks, since extra memory addressing has to take place for each stack operation.
|
||||
- {:height 405, :width 638}
|
||||
- Every **push operation** will ^^increment the top of the **stack pointer**^^ with the word size of the machine.
|
||||
- Every **pop operation** will ^^decrement the top of the stack pointer^^ (with the word size of the machine).
|
||||
- **Stack overflows** can occur in both stack implementations
|
||||
- What is a **stack overflow**? #card
|
||||
card-last-interval:: 31.36
|
||||
card-repeats:: 4
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-11-04T20:25:37.658Z
|
||||
card-last-reviewed:: 2022-10-04T12:25:37.659Z
|
||||
card-last-score:: 5
|
||||
- A **stack overflow** occurs when the amount of data in the stack exceeds the amount of space allocated to the stack (or the hardware limit of the stack).
|
||||
- ### Instructions in Stack-Based Architecture #card
|
||||
card-last-interval:: 8.32
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.08
|
||||
card-next-schedule:: 2022-10-11T21:30:35.451Z
|
||||
card-last-reviewed:: 2022-10-03T14:30:35.452Z
|
||||
card-last-score:: 3
|
||||
- Instructions in a stack-base architecture get their operands from the stack and write their results to the stack.
|
||||
- The advantage of this is that ^^program code takes little memory - there is no need to specify the address of the operands or registers.^^
|
||||
- PUSH is one exception, because it needs the operand to be specified (either as a constant or as an address).
|
||||
- ### Programs in a Stack-Based Architecture
|
||||
- Writing programs for stack-based architecture is not easy.
|
||||
- Stack-based architectures are better suited for **postfix** notation rather than **infix** notation.
|
||||
- What is **infix notation**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:42:45.628Z
|
||||
card-last-reviewed:: 2022-10-03T11:42:45.628Z
|
||||
card-last-score:: 5
|
||||
- **Infix notation** is the traditional way of representing mathematical expressions, with ^^operations placed **between** the operands.^^
|
||||
- e.g., a + b
|
||||
- What is **postfix notation**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:39:50.328Z
|
||||
card-last-reviewed:: 2022-10-03T11:39:50.328Z
|
||||
card-last-score:: 5
|
||||
- In **postfix notation**, ^^the operation is placed **after** the operands.^^
|
||||
- e.g., a b +
|
||||
- Stack-based architectures are better suited for **postfix notation**.
|
||||
- Once an expression has been converted into postfix notation, implementing it in programs is easy.
|
||||
- ### Using Stacks to Implement Procedure Calls
|
||||
- Programs need a way to **pass inputs to the procedures** that they call and to receive outputs back from them.
|
||||
- Procedures need to be able to **allocate space in memory for local variables** without overriding any data used by their calling program.
|
||||
- It is impossible to determine which registers may be used safely by the procedure (especially if the procedure is located in a library).
|
||||
- So, a mechanism to **save / restore registers** of the calling program has to be in place.
|
||||
- Procedures need a way to figure out where they were called from.
|
||||
- So, the execution can **return to the calling program** where the procedure completes (they need to restore the program counter).
|
||||
- How are procedure calls implemented in Stacks? #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.22
|
||||
card-next-schedule:: 2022-10-08T12:27:13.347Z
|
||||
card-last-reviewed:: 2022-10-04T12:27:13.347Z
|
||||
card-last-score:: 3
|
||||
- 
|
||||
- When a procedure is called, a **block of memory** in the stack called a **stack frame** is allocated.
|
||||
- The top of the stack pointer is incremented by the **number of locations** in the stack frame.
|
||||
- When a procedure finishes, it jumps to the **return address** of the stack and the execution of the calling program resumes.
|
||||
- How are nested procedure calls implemented in the stack? #card
|
||||
card-last-interval:: 8.32
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.08
|
||||
card-next-schedule:: 2022-10-11T21:30:20.346Z
|
||||
card-last-reviewed:: 2022-10-03T14:30:20.347Z
|
||||
card-last-score:: 3
|
||||
- 
|
||||
- main program calls function f(),
|
||||
- function f() calls function g(),
|
||||
- function g() calls function h()
|
||||
- ## General-Purpose Register Architectures
|
||||
- ### General-Purpose Register File
|
||||
- In GPR Architectures, instructions read their operands and write their results to a **random access register file**.
|
||||
- The general-purpose register file allows the ^^access of **any** register in **any** order^^ by specifying the number (register ID) of the register.
|
||||
- What is the main difference between a GPR & a stack? #card
|
||||
card-last-interval:: 9.28
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.32
|
||||
card-next-schedule:: 2022-10-12T17:43:13.452Z
|
||||
card-last-reviewed:: 2022-10-03T11:43:13.452Z
|
||||
card-last-score:: 3
|
||||
- The main difference between a GPR and a stack is that repeatedly reading a register will produce the same result and **will not** modify the state of the register file.
|
||||
- Popping an item from a LIFO structure (stack) **will** modify the contents of the stack,
|
||||
- Many GPR architectures assign special values to some registers in the register file to make programming easier.
|
||||
- e.g., sometimes, register 0 is hardwired with value 0 to generate this most common constant.
|
||||
- ### Instructions in GPR Architecture
|
||||
- What do GPR instructions need to specify? #card
|
||||
card-last-interval:: 9.84
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.46
|
||||
card-next-schedule:: 2022-10-10T05:28:31.531Z
|
||||
card-last-reviewed:: 2022-09-30T09:28:31.531Z
|
||||
card-last-score:: 5
|
||||
- GPR instructions need to specify:
|
||||
- **the register** that holds their **input operands**
|
||||
- the register that will hole the **result**
|
||||
- What is the most common GPR instruction format? #card
|
||||
card-last-interval:: 26.21
|
||||
card-repeats:: 4
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-15T22:48:52.100Z
|
||||
card-last-reviewed:: 2022-09-19T17:48:52.100Z
|
||||
card-last-score:: 5
|
||||
- The most common GPR instruction format is the **three operands instruction format**.
|
||||
- e.g., "ADD r1, r2, r3" instructs the processor to read the contents of r2 and r3, add them together, and write the results in r1.
|
||||
- Instructions that only have one or two inputs are also present in GPR architecture.
|
||||
- Which architecture allows **caching**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-11T16:11:50.487Z
|
||||
card-last-reviewed:: 2022-09-30T12:11:50.488Z
|
||||
card-last-score:: 5
|
||||
- In GPR Architecture, ^^programs can choose which values should be stored in the register file at any given time^^, allowing them to **cache** the most accessed data.
|
||||
- In stack-based architectures, once the data has been used, it's gone.
|
||||
- From this point of view, ^^GPR architectures have **better performance**^^, at the expense of needing **more storage space** for the program.
|
||||
- larger instructions are needed to encode the addresses of the operands.
|
||||
- #### Simple GPR Instruction Set
|
||||
- 
|
||||
-
|
||||
- ### Programs in a GPR Architecure #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.46
|
||||
card-next-schedule:: 2022-10-08T12:29:33.188Z
|
||||
card-last-reviewed:: 2022-10-04T12:29:33.188Z
|
||||
card-last-score:: 5
|
||||
- Programming a GPR architecture processor is **less structured** than programming a stack-based architecture processor.
|
||||
- There are **fewer restrictions on the order** in which operations can be executed.
|
||||
- In stack-based architectures, instructions must execute in the order that would leave the operands for the next instructions on the top of the stack.
|
||||
- In GPR, any order that places the operands for the next instruction in the register file before the instruction executes is valid.
|
||||
- Operations that access different registers can be **reordered** without making the program invalid.
|
||||
-
|
||||
- ## Stack-Bases vs GPR Architectures
|
||||
- Stack-based architectures are still attractive for certain embedded systems.
|
||||
- GPR architectures are used by modern computers.
|
||||
- ## Stack-Based Architectures #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.46
|
||||
card-next-schedule:: 2022-10-08T12:29:47.226Z
|
||||
card-last-reviewed:: 2022-10-04T12:29:47.226Z
|
||||
card-last-score:: 5
|
||||
- Instructions take **fewer bits** to encode.
|
||||
- **Reduced amount of memory** taken up by programs.
|
||||
- Manages the **use of registers automatically** (no need for programmer intervention).
|
||||
- The instruction set **does not change** if the size of the register file has changed.
|
||||
- ## GPR Architectures
|
||||
- With the evolution of technology, the amount of space taken up by a program is less important.
|
||||
- Compilers for GPR architecture achieve **better performance** with a given number of general-purpose registers than those on stack-based architectures with the same number of registers.
|
||||
- The compiler can choose which values to keep (**cache**) in the register file at any time.
|
||||
@ -0,0 +1,401 @@
|
||||
- #[[CT213 - Computer Systems & Organisation]]
|
||||
- **Previous Topic:** [[Overview of Computer Systems]]
|
||||
- **Relevant Slides:** 
|
||||
-
|
||||
- What is a **Processor Programming Model**? #card
|
||||
card-last-interval:: -1
|
||||
card-repeats:: 1
|
||||
card-ease-factor:: 2.36
|
||||
card-next-schedule:: 2022-10-08T23:00:00.000Z
|
||||
card-last-reviewed:: 2022-10-08T22:41:26.528Z
|
||||
card-last-score:: 1
|
||||
- A **Processor Programming Model** defines ^^how instructions access their operands and how instructions are described in the processor's assembly language.^^
|
||||
- Processors with different programming models can offer similar sets of operations but may require very different approaches to programming.
|
||||
-
|
||||
- ## Instructions
|
||||
- What is the **Instruction Cycle**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:42:30.873Z
|
||||
card-last-reviewed:: 2022-10-03T11:42:30.874Z
|
||||
card-last-score:: 5
|
||||
- The **Instruction Cycle** is the ^^procedure of processing an instruction^^ by the microprocessor.
|
||||
- **Fetch:** read the instructions from memory
|
||||
- **Decode:** Determine what is to be done
|
||||
- **Execute:** Perform the operation
|
||||
- Each of the functions fetch -> decode -> execute consist of a sequence of one or more operations inside the CPU (and interaction with the subsystems).
|
||||
- ### Types of Instructions
|
||||
- #### Data Transfer Instructions
|
||||
- What are **Data Transfer Instructions**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:40:48.321Z
|
||||
card-last-reviewed:: 2022-10-03T11:40:48.321Z
|
||||
card-last-score:: 5
|
||||
- Operations that ^^move data^^ from one place to another.
|
||||
- These instructions ^^don't modify^^ the data, they just copy it to the destination.
|
||||
- What operations can data transfer instructions do? #card
|
||||
card-last-interval:: 10.92
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.46
|
||||
card-next-schedule:: 2022-10-11T06:46:12.475Z
|
||||
card-last-reviewed:: 2022-09-30T08:46:12.475Z
|
||||
card-last-score:: 5
|
||||
- card-last-interval:: 11.56
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-10-11T21:26:36.529Z
|
||||
card-last-reviewed:: 2022-09-30T08:26:36.529Z
|
||||
card-last-score:: 5
|
||||
1. **Load data** from memory into the microprocessor. #card
|
||||
- These instructions copy data from memory into microprocessor registers (i.e., LD).
|
||||
- card-last-interval:: 10.24
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-13T19:28:41.508Z
|
||||
card-last-reviewed:: 2022-10-03T14:28:41.509Z
|
||||
card-last-score:: 5
|
||||
2. **Store data** from the microprocessor into the memory. #card
|
||||
- Similar to load data, except that the data is copied in the opposite direction (i.e., ST).
|
||||
- Data is saved from internal microprocessor registers into the memory
|
||||
- card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T18:29:32.655Z
|
||||
card-last-reviewed:: 2022-10-03T14:29:32.655Z
|
||||
card-last-score:: 5
|
||||
3. **Move data** within the microprocessor.
|
||||
- These instructions move data from one microprocessor register to another (i.e., MOV)
|
||||
- card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T17:44:07.730Z
|
||||
card-last-reviewed:: 2022-09-19T17:44:07.731Z
|
||||
card-last-score:: 5
|
||||
4. **Input data** into the microprocessor.
|
||||
- A microprocessor may need to input data from the outside world.
|
||||
- These are the instructions that input data from the input device into the microprocessor.
|
||||
- card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T17:47:33.165Z
|
||||
card-last-reviewed:: 2022-09-19T17:47:33.165Z
|
||||
card-last-score:: 5
|
||||
5. **Output data** from the microprocessor.
|
||||
- The microprocessor copies data from one of its internal registers to an output device.
|
||||
- Example: the microprocessor may want to show the content of an internal register on a display (the key has been pressed) (i.e., IOWR).
|
||||
- #### Data Operation Instructions #card
|
||||
card-last-interval:: 10.24
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-13T16:45:28.268Z
|
||||
card-last-reviewed:: 2022-10-03T11:45:28.268Z
|
||||
card-last-score:: 5
|
||||
- Instructions that *do* modify their data values.
|
||||
- They typically perform some operation (e.g., +, -, *) using one or two data values (operands) and store the result.
|
||||
- What operations can data operation instructions do? #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-10T17:11:57.372Z
|
||||
card-last-reviewed:: 2022-10-06T17:11:57.372Z
|
||||
card-last-score:: 5
|
||||
- **Arithmetic Instructions** #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:44:56.702Z
|
||||
card-last-reviewed:: 2022-10-03T11:44:56.702Z
|
||||
card-last-score:: 5
|
||||
- add, subtract, multiply, or divide
|
||||
- ADD, SUB, MUL, DIV
|
||||
- Instructions that increment or decrement one from a value
|
||||
- INC, DEC
|
||||
- Floating point instructions that operate on floating point values
|
||||
- FADD, FSUB, FMUL, FDIV
|
||||
- **Logic Instructions**
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:43:49.421Z
|
||||
card-last-reviewed:: 2022-10-03T11:43:49.421Z
|
||||
card-last-score:: 5
|
||||
- AND, OR, XOR, NOT, etc.
|
||||
- **Shift Instructions**
|
||||
card-last-interval:: 10.92
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.46
|
||||
card-next-schedule:: 2022-10-11T06:45:44.876Z
|
||||
card-last-reviewed:: 2022-09-30T08:45:44.877Z
|
||||
card-last-score:: 5
|
||||
- SR, SL, RR, RL, etc.
|
||||
- #### Program Control Instructions #card
|
||||
card-last-interval:: 10.8
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-10-11T04:28:17.821Z
|
||||
card-last-reviewed:: 2022-09-30T09:28:17.821Z
|
||||
card-last-score:: 5
|
||||
- **Jump** or **branch** instructions are used to ^^go to another part of the program^^; Jumps can be **absolute** or **conditional**.
|
||||
- e.g., if, then, else.
|
||||
- Instructions that can generate **interrupts**.
|
||||
- Software interrupts.
|
||||
- **Jump & branch instructions** (conditional or unconditional)
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T18:27:30.317Z
|
||||
card-last-reviewed:: 2022-10-03T14:27:30.317Z
|
||||
card-last-score:: 5
|
||||
- **JZ:** Jump if the zero flag is set.
|
||||
- **JNZ:** Jump if the zero flag is **not** set.
|
||||
- **JMP:** Unconditional jump - flags are ignored.
|
||||
- etc.
|
||||
- **Comparison Instructions** #card
|
||||
card-last-interval:: 10.24
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-13T16:42:52.048Z
|
||||
card-last-reviewed:: 2022-10-03T11:42:52.049Z
|
||||
card-last-score:: 3
|
||||
- TEST: logical BITWISE AND
|
||||
- **Calls & Returns** a / from a routine (conditional or unconditional) #card
|
||||
card-last-interval:: 10.24
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-13T19:28:56.319Z
|
||||
card-last-reviewed:: 2022-10-03T14:28:56.319Z
|
||||
card-last-score:: 3
|
||||
- **Call:** call a subroutine at a certain line.
|
||||
- **RET:** return from a subroutine.
|
||||
- **IRET:** interrupt & return.
|
||||
- **Software Interrupts** #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T18:28:46.482Z
|
||||
card-last-reviewed:: 2022-10-03T14:28:46.483Z
|
||||
card-last-score:: 5
|
||||
- Generated by devices outside of a microprocessor (not part of the instruction set).
|
||||
- INT
|
||||
- **Exceptions & Traps** #card
|
||||
card-last-interval:: -1
|
||||
card-repeats:: 1
|
||||
card-ease-factor:: 2.6
|
||||
card-next-schedule:: 2022-10-08T23:00:00.000Z
|
||||
card-last-reviewed:: 2022-10-08T15:33:23.926Z
|
||||
card-last-score:: 1
|
||||
- Triggered when valid instructions perform invalid operations.
|
||||
- e.g., dividing by zero.
|
||||
- **Halt Instructions** #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:37:56.173Z
|
||||
card-last-reviewed:: 2022-10-03T11:37:56.174Z
|
||||
card-last-score:: 5
|
||||
- Causes the processor to stop executions.
|
||||
- e.g., at the end of the program.
|
||||
- HALT
|
||||
-
|
||||
- ## Stack Architectures
|
||||
- ### The Stack
|
||||
- **Last In First Out (LIFO)** data structure.
|
||||
- Consists of **locations**, each of which can hold a **word of data**.
|
||||
- It can be used to explicitly **save / restore** data.
|
||||
- What operations does the stack support? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T18:30:00.780Z
|
||||
card-last-reviewed:: 2022-10-03T14:30:00.780Z
|
||||
card-last-score:: 5
|
||||
- The stack supports ^^two operations.^^
|
||||
- **PUSH:** takes one argument and places the value of the argument at the top of the stack.
|
||||
- **POP:** removes one element from the stack, saving it into a predefined register of the processor.
|
||||
- The stack is ^^used implicitly by procedure call instructions.^^
|
||||
- (if available in the data set).
|
||||
- When new data is added to the stack, it is placed at the top of the stack, and all of the contents of the stack are pushed down one location.
|
||||
- ### Implementing Stacks
|
||||
- What are the two ways to implement a stack? #card
|
||||
card-last-interval:: 8.88
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.22
|
||||
card-next-schedule:: 2022-10-09T05:45:27.331Z
|
||||
card-last-reviewed:: 2022-09-30T08:45:27.331Z
|
||||
card-last-score:: 3
|
||||
- card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.08
|
||||
card-next-schedule:: 2022-10-12T15:29:51.594Z
|
||||
card-last-reviewed:: 2022-10-08T15:29:51.595Z
|
||||
card-last-score:: 3
|
||||
1. **Dedicated Hardware Stack** #card
|
||||
- Has a ^^hardware limitation^^ (limited number of locations).
|
||||
- Very fast.
|
||||
- card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:44:04.293Z
|
||||
card-last-reviewed:: 2022-10-03T11:44:04.294Z
|
||||
card-last-score:: 5
|
||||
2. **Memory Implemented Stack** #card
|
||||
- Limited by the ^^physical memory of the system.^^
|
||||
- Slow compared with hardware stacks, since extra memory addressing has to take place for each stack operation.
|
||||
- {:height 405, :width 638}
|
||||
- Every **push operation** will ^^increment the top of the **stack pointer**^^ with the word size of the machine.
|
||||
- Every **pop operation** will ^^decrement the top of the stack pointer^^ (with the word size of the machine).
|
||||
- **Stack overflows** can occur in both stack implementations
|
||||
- What is a **stack overflow**? #card
|
||||
card-last-interval:: 31.36
|
||||
card-repeats:: 4
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-11-04T20:25:37.658Z
|
||||
card-last-reviewed:: 2022-10-04T12:25:37.659Z
|
||||
card-last-score:: 5
|
||||
- A **stack overflow** occurs when the amount of data in the stack exceeds the amount of space allocated to the stack (or the hardware limit of the stack).
|
||||
- ### Instructions in Stack-Based Architecture #card
|
||||
card-last-interval:: 8.32
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.08
|
||||
card-next-schedule:: 2022-10-11T21:30:35.451Z
|
||||
card-last-reviewed:: 2022-10-03T14:30:35.452Z
|
||||
card-last-score:: 3
|
||||
- Instructions in a stack-base architecture get their operands from the stack and write their results to the stack.
|
||||
- The advantage of this is that ^^program code takes little memory - there is no need to specify the address of the operands or registers.^^
|
||||
- PUSH is one exception, because it needs the operand to be specified (either as a constant or as an address).
|
||||
- ### Programs in a Stack-Based Architecture
|
||||
- Writing programs for stack-based architecture is not easy.
|
||||
- Stack-based architectures are better suited for **postfix** notation rather than **infix** notation.
|
||||
- What is **infix notation**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:42:45.628Z
|
||||
card-last-reviewed:: 2022-10-03T11:42:45.628Z
|
||||
card-last-score:: 5
|
||||
- **Infix notation** is the traditional way of representing mathematical expressions, with ^^operations placed **between** the operands.^^
|
||||
- e.g., a + b
|
||||
- What is **postfix notation**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:39:50.328Z
|
||||
card-last-reviewed:: 2022-10-03T11:39:50.328Z
|
||||
card-last-score:: 5
|
||||
- In **postfix notation**, ^^the operation is placed **after** the operands.^^
|
||||
- e.g., a b +
|
||||
- Stack-based architectures are better suited for **postfix notation**.
|
||||
- Once an expression has been converted into postfix notation, implementing it in programs is easy.
|
||||
- ### Using Stacks to Implement Procedure Calls
|
||||
- Programs need a way to **pass inputs to the procedures** that they call and to receive outputs back from them.
|
||||
- Procedures need to be able to **allocate space in memory for local variables** without overriding any data used by their calling program.
|
||||
- It is impossible to determine which registers may be used safely by the procedure (especially if the procedure is located in a library).
|
||||
- So, a mechanism to **save / restore registers** of the calling program has to be in place.
|
||||
- Procedures need a way to figure out where they were called from.
|
||||
- So, the execution can **return to the calling program** where the procedure completes (they need to restore the program counter).
|
||||
- How are procedure calls implemented in Stacks? #card
|
||||
card-last-interval:: 9.28
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.32
|
||||
card-next-schedule:: 2022-10-18T04:57:53.451Z
|
||||
card-last-reviewed:: 2022-10-08T22:57:53.496Z
|
||||
card-last-score:: 5
|
||||
- 
|
||||
- When a procedure is called,^^a block of memory in the stack called a **stack frame** is allocated.^^
|
||||
- The top of the **stack pointer** is incremented by the number of locations in the stack frame.
|
||||
- When a procedure finishes, it jumps to the **return address** of the stack and the execution of the calling program resumes.
|
||||
- How are nested procedure calls implemented in the stack? #card
|
||||
card-last-interval:: 8.32
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.08
|
||||
card-next-schedule:: 2022-10-11T21:30:20.346Z
|
||||
card-last-reviewed:: 2022-10-03T14:30:20.347Z
|
||||
card-last-score:: 3
|
||||
- 
|
||||
- main program calls function f(),
|
||||
- function f() calls function g(),
|
||||
- function g() calls function h()
|
||||
- ## General-Purpose Register Architectures
|
||||
- ### General-Purpose Register File
|
||||
- In GPR Architectures, instructions read their operands and write their results to a **random access register file**.
|
||||
- The general-purpose register file allows the ^^access of **any** register in **any** order^^ by specifying the number (register ID) of the register.
|
||||
- What is the main difference between a GPR & a stack? #card
|
||||
card-last-interval:: 9.28
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.32
|
||||
card-next-schedule:: 2022-10-12T17:43:13.452Z
|
||||
card-last-reviewed:: 2022-10-03T11:43:13.452Z
|
||||
card-last-score:: 3
|
||||
- The main difference between a GPR and a stack is that repeatedly reading a register will produce the same result and **will not** modify the state of the register file.
|
||||
- Popping an item from a LIFO structure (stack) **will** modify the contents of the stack,
|
||||
- Many GPR architectures assign special values to some registers in the register file to make programming easier.
|
||||
- e.g., sometimes, register 0 is hardwired with value 0 to generate this most common constant.
|
||||
- ### Instructions in GPR Architecture
|
||||
- What do GPR instructions need to specify? #card
|
||||
card-last-interval:: 9.84
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.46
|
||||
card-next-schedule:: 2022-10-10T05:28:31.531Z
|
||||
card-last-reviewed:: 2022-09-30T09:28:31.531Z
|
||||
card-last-score:: 5
|
||||
- GPR instructions need to specify:
|
||||
- **the register** that holds their **input operands**
|
||||
- the register that will hole the **result**
|
||||
- What is the most common GPR instruction format? #card
|
||||
card-last-interval:: 26.21
|
||||
card-repeats:: 4
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-15T22:48:52.100Z
|
||||
card-last-reviewed:: 2022-09-19T17:48:52.100Z
|
||||
card-last-score:: 5
|
||||
- The most common GPR instruction format is the **three operands instruction format**.
|
||||
- e.g., "ADD r1, r2, r3" instructs the processor to read the contents of r2 and r3, add them together, and write the results in r1.
|
||||
- Instructions that only have one or two inputs are also present in GPR architecture.
|
||||
- Which architecture allows **caching**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-11T16:11:50.487Z
|
||||
card-last-reviewed:: 2022-09-30T12:11:50.488Z
|
||||
card-last-score:: 5
|
||||
- In GPR Architecture, ^^programs can choose which values should be stored in the register file at any given time^^, allowing them to **cache** the most accessed data.
|
||||
- In stack-based architectures, once the data has been used, it's gone.
|
||||
- From this point of view, ^^GPR architectures have **better performance**^^, at the expense of needing **more storage space** for the program.
|
||||
- larger instructions are needed to encode the addresses of the operands.
|
||||
- #### Simple GPR Instruction Set
|
||||
- 
|
||||
-
|
||||
- ### Programs in a GPR Architecure #card
|
||||
card-last-interval:: 10.6
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-19T12:58:16.278Z
|
||||
card-last-reviewed:: 2022-10-08T22:58:16.278Z
|
||||
card-last-score:: 5
|
||||
- Programming a GPR architecture processor is **less structured** than programming a stack-based architecture processor.
|
||||
- There are **fewer restrictions on the order** in which operations can be executed.
|
||||
- In stack-based architectures, instructions must execute in the order that would leave the operands for the next instructions on the top of the stack.
|
||||
- In GPR, any order that places the operands for the next instruction in the register file before the instruction executes is valid.
|
||||
- Operations that access different registers can be **reordered** without making the program invalid.
|
||||
-
|
||||
- ## Stack-Bases vs GPR Architectures
|
||||
- Stack-based architectures are still attractive for certain embedded systems.
|
||||
- GPR architectures are used by modern computers.
|
||||
- ## Stack-Based Architectures #card
|
||||
card-last-interval:: 10.6
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-19T12:59:04.549Z
|
||||
card-last-reviewed:: 2022-10-08T22:59:04.550Z
|
||||
card-last-score:: 5
|
||||
- Instructions take **fewer bits** to encode.
|
||||
- **Reduced amount of memory** taken up by programs.
|
||||
- Manages the **use of registers automatically** (no need for programmer intervention).
|
||||
- The instruction set **does not change** if the size of the register file has changed.
|
||||
- ## GPR Architectures
|
||||
- With the evolution of technology, the amount of space taken up by a program is less important.
|
||||
- Compilers for GPR architecture achieve **better performance** with a given number of general-purpose registers than those on stack-based architectures with the same number of registers.
|
||||
- The compiler can choose which values to keep (**cache**) in the register file at any time.
|
||||
@ -0,0 +1,401 @@
|
||||
- #[[CT213 - Computer Systems & Organisation]]
|
||||
- **Previous Topic:** [[Overview of Computer Systems]]
|
||||
- **Relevant Slides:** 
|
||||
-
|
||||
- What is a **Processor Programming Model**? #card
|
||||
card-last-interval:: 3.09
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.46
|
||||
card-next-schedule:: 2022-10-13T13:40:54.101Z
|
||||
card-last-reviewed:: 2022-10-10T11:40:54.101Z
|
||||
card-last-score:: 5
|
||||
- A **Processor Programming Model** defines ^^how instructions access their operands and how instructions are described in the processor's assembly language.^^
|
||||
- Processors with different programming models can offer similar sets of operations but may require very different approaches to programming.
|
||||
-
|
||||
- ## Instructions
|
||||
- What is the **Instruction Cycle**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:42:30.873Z
|
||||
card-last-reviewed:: 2022-10-03T11:42:30.874Z
|
||||
card-last-score:: 5
|
||||
- The **Instruction Cycle** is the ^^procedure of processing an instruction^^ by the microprocessor.
|
||||
- **Fetch:** read the instructions from memory
|
||||
- **Decode:** Determine what is to be done
|
||||
- **Execute:** Perform the operation
|
||||
- Each of the functions fetch -> decode -> execute consist of a sequence of one or more operations inside the CPU (and interaction with the subsystems).
|
||||
- ### Types of Instructions
|
||||
- #### Data Transfer Instructions
|
||||
- What are **Data Transfer Instructions**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:40:48.321Z
|
||||
card-last-reviewed:: 2022-10-03T11:40:48.321Z
|
||||
card-last-score:: 5
|
||||
- Operations that ^^move data^^ from one place to another.
|
||||
- These instructions ^^don't modify^^ the data, they just copy it to the destination.
|
||||
- What operations can data transfer instructions do? #card
|
||||
card-last-interval:: 10.92
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.46
|
||||
card-next-schedule:: 2022-10-11T06:46:12.475Z
|
||||
card-last-reviewed:: 2022-09-30T08:46:12.475Z
|
||||
card-last-score:: 5
|
||||
- card-last-interval:: 11.56
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-10-11T21:26:36.529Z
|
||||
card-last-reviewed:: 2022-09-30T08:26:36.529Z
|
||||
card-last-score:: 5
|
||||
1. **Load data** from memory into the microprocessor. #card
|
||||
- These instructions copy data from memory into microprocessor registers (i.e., LD).
|
||||
- card-last-interval:: 10.24
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-13T19:28:41.508Z
|
||||
card-last-reviewed:: 2022-10-03T14:28:41.509Z
|
||||
card-last-score:: 5
|
||||
2. **Store data** from the microprocessor into the memory. #card
|
||||
- Similar to load data, except that the data is copied in the opposite direction (i.e., ST).
|
||||
- Data is saved from internal microprocessor registers into the memory
|
||||
- card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T18:29:32.655Z
|
||||
card-last-reviewed:: 2022-10-03T14:29:32.655Z
|
||||
card-last-score:: 5
|
||||
3. **Move data** within the microprocessor.
|
||||
- These instructions move data from one microprocessor register to another (i.e., MOV)
|
||||
- card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T17:44:07.730Z
|
||||
card-last-reviewed:: 2022-09-19T17:44:07.731Z
|
||||
card-last-score:: 5
|
||||
4. **Input data** into the microprocessor.
|
||||
- A microprocessor may need to input data from the outside world.
|
||||
- These are the instructions that input data from the input device into the microprocessor.
|
||||
- card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T17:47:33.165Z
|
||||
card-last-reviewed:: 2022-09-19T17:47:33.165Z
|
||||
card-last-score:: 5
|
||||
5. **Output data** from the microprocessor.
|
||||
- The microprocessor copies data from one of its internal registers to an output device.
|
||||
- Example: the microprocessor may want to show the content of an internal register on a display (the key has been pressed) (i.e., IOWR).
|
||||
- #### Data Operation Instructions #card
|
||||
card-last-interval:: 10.24
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-13T16:45:28.268Z
|
||||
card-last-reviewed:: 2022-10-03T11:45:28.268Z
|
||||
card-last-score:: 5
|
||||
- Instructions that *do* modify their data values.
|
||||
- They typically perform some operation (e.g., +, -, *) using one or two data values (operands) and store the result.
|
||||
- What operations can data operation instructions do? #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-10T17:11:57.372Z
|
||||
card-last-reviewed:: 2022-10-06T17:11:57.372Z
|
||||
card-last-score:: 5
|
||||
- **Arithmetic Instructions** #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:44:56.702Z
|
||||
card-last-reviewed:: 2022-10-03T11:44:56.702Z
|
||||
card-last-score:: 5
|
||||
- add, subtract, multiply, or divide
|
||||
- ADD, SUB, MUL, DIV
|
||||
- Instructions that increment or decrement one from a value
|
||||
- INC, DEC
|
||||
- Floating point instructions that operate on floating point values
|
||||
- FADD, FSUB, FMUL, FDIV
|
||||
- **Logic Instructions**
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:43:49.421Z
|
||||
card-last-reviewed:: 2022-10-03T11:43:49.421Z
|
||||
card-last-score:: 5
|
||||
- AND, OR, XOR, NOT, etc.
|
||||
- **Shift Instructions**
|
||||
card-last-interval:: 10.92
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.46
|
||||
card-next-schedule:: 2022-10-11T06:45:44.876Z
|
||||
card-last-reviewed:: 2022-09-30T08:45:44.877Z
|
||||
card-last-score:: 5
|
||||
- SR, SL, RR, RL, etc.
|
||||
- #### Program Control Instructions #card
|
||||
card-last-interval:: 10.8
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-10-11T04:28:17.821Z
|
||||
card-last-reviewed:: 2022-09-30T09:28:17.821Z
|
||||
card-last-score:: 5
|
||||
- **Jump** or **branch** instructions are used to ^^go to another part of the program^^; Jumps can be **absolute** or **conditional**.
|
||||
- e.g., if, then, else.
|
||||
- Instructions that can generate **interrupts**.
|
||||
- Software interrupts.
|
||||
- **Jump & branch instructions** (conditional or unconditional)
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T18:27:30.317Z
|
||||
card-last-reviewed:: 2022-10-03T14:27:30.317Z
|
||||
card-last-score:: 5
|
||||
- **JZ:** Jump if the zero flag is set.
|
||||
- **JNZ:** Jump if the zero flag is **not** set.
|
||||
- **JMP:** Unconditional jump - flags are ignored.
|
||||
- etc.
|
||||
- **Comparison Instructions** #card
|
||||
card-last-interval:: 10.24
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-13T16:42:52.048Z
|
||||
card-last-reviewed:: 2022-10-03T11:42:52.049Z
|
||||
card-last-score:: 3
|
||||
- TEST: logical BITWISE AND
|
||||
- **Calls & Returns** a / from a routine (conditional or unconditional) #card
|
||||
card-last-interval:: 10.24
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-13T19:28:56.319Z
|
||||
card-last-reviewed:: 2022-10-03T14:28:56.319Z
|
||||
card-last-score:: 3
|
||||
- **Call:** call a subroutine at a certain line.
|
||||
- **RET:** return from a subroutine.
|
||||
- **IRET:** interrupt & return.
|
||||
- **Software Interrupts** #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T18:28:46.482Z
|
||||
card-last-reviewed:: 2022-10-03T14:28:46.483Z
|
||||
card-last-score:: 5
|
||||
- Generated by devices outside of a microprocessor (not part of the instruction set).
|
||||
- INT
|
||||
- **Exceptions & Traps** #card
|
||||
card-last-interval:: -1
|
||||
card-repeats:: 1
|
||||
card-ease-factor:: 2.6
|
||||
card-next-schedule:: 2022-10-10T23:00:00.000Z
|
||||
card-last-reviewed:: 2022-10-10T11:40:14.195Z
|
||||
card-last-score:: 1
|
||||
- Triggered when valid instructions perform invalid operations.
|
||||
- e.g., dividing by zero.
|
||||
- **Halt Instructions** #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:37:56.173Z
|
||||
card-last-reviewed:: 2022-10-03T11:37:56.174Z
|
||||
card-last-score:: 5
|
||||
- Causes the processor to stop executions.
|
||||
- e.g., at the end of the program.
|
||||
- HALT
|
||||
-
|
||||
- ## Stack Architectures
|
||||
- ### The Stack
|
||||
- **Last In First Out (LIFO)** data structure.
|
||||
- Consists of **locations**, each of which can hold a **word of data**.
|
||||
- It can be used to explicitly **save / restore** data.
|
||||
- What operations does the stack support? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T18:30:00.780Z
|
||||
card-last-reviewed:: 2022-10-03T14:30:00.780Z
|
||||
card-last-score:: 5
|
||||
- The stack supports ^^two operations.^^
|
||||
- **PUSH:** takes one argument and places the value of the argument at the top of the stack.
|
||||
- **POP:** removes one element from the stack, saving it into a predefined register of the processor.
|
||||
- The stack is ^^used implicitly by procedure call instructions.^^
|
||||
- (if available in the data set).
|
||||
- When new data is added to the stack, it is placed at the top of the stack, and all of the contents of the stack are pushed down one location.
|
||||
- ### Implementing Stacks
|
||||
- What are the two ways to implement a stack? #card
|
||||
card-last-interval:: 21.53
|
||||
card-repeats:: 4
|
||||
card-ease-factor:: 2.32
|
||||
card-next-schedule:: 2022-10-31T23:42:47.216Z
|
||||
card-last-reviewed:: 2022-10-10T11:42:47.216Z
|
||||
card-last-score:: 5
|
||||
- card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.08
|
||||
card-next-schedule:: 2022-10-12T15:29:51.594Z
|
||||
card-last-reviewed:: 2022-10-08T15:29:51.595Z
|
||||
card-last-score:: 3
|
||||
1. **Dedicated Hardware Stack** #card
|
||||
- Has a ^^hardware limitation^^ (limited number of locations).
|
||||
- Very fast.
|
||||
- card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:44:04.293Z
|
||||
card-last-reviewed:: 2022-10-03T11:44:04.294Z
|
||||
card-last-score:: 5
|
||||
2. **Memory Implemented Stack** #card
|
||||
- Limited by the ^^physical memory of the system.^^
|
||||
- Slow compared with hardware stacks, since extra memory addressing has to take place for each stack operation.
|
||||
- {:height 405, :width 638}
|
||||
- Every **push operation** will ^^increment the top of the **stack pointer**^^ with the word size of the machine.
|
||||
- Every **pop operation** will ^^decrement the top of the stack pointer^^ (with the word size of the machine).
|
||||
- **Stack overflows** can occur in both stack implementations
|
||||
- What is a **stack overflow**? #card
|
||||
card-last-interval:: 31.36
|
||||
card-repeats:: 4
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-11-04T20:25:37.658Z
|
||||
card-last-reviewed:: 2022-10-04T12:25:37.659Z
|
||||
card-last-score:: 5
|
||||
- A **stack overflow** occurs when the amount of data in the stack exceeds the amount of space allocated to the stack (or the hardware limit of the stack).
|
||||
- ### Instructions in Stack-Based Architecture #card
|
||||
card-last-interval:: 15.05
|
||||
card-repeats:: 4
|
||||
card-ease-factor:: 1.94
|
||||
card-next-schedule:: 2022-11-03T09:43:35.672Z
|
||||
card-last-reviewed:: 2022-10-19T08:43:35.673Z
|
||||
card-last-score:: 3
|
||||
- Instructions in a stack-base architecture get their operands from the stack and write their results to the stack.
|
||||
- The advantage of this is that ^^program code takes little memory - there is no need to specify the address of the operands or registers.^^
|
||||
- PUSH is one exception, because it needs the operand to be specified (either as a constant or as an address).
|
||||
- ### Programs in a Stack-Based Architecture
|
||||
- Writing programs for stack-based architecture is not easy.
|
||||
- Stack-based architectures are better suited for **postfix** notation rather than **infix** notation.
|
||||
- What is **infix notation**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:42:45.628Z
|
||||
card-last-reviewed:: 2022-10-03T11:42:45.628Z
|
||||
card-last-score:: 5
|
||||
- **Infix notation** is the traditional way of representing mathematical expressions, with ^^operations placed **between** the operands.^^
|
||||
- e.g., a + b
|
||||
- What is **postfix notation**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:39:50.328Z
|
||||
card-last-reviewed:: 2022-10-03T11:39:50.328Z
|
||||
card-last-score:: 5
|
||||
- In **postfix notation**, ^^the operation is placed **after** the operands.^^
|
||||
- e.g., a b +
|
||||
- Stack-based architectures are better suited for **postfix notation**.
|
||||
- Once an expression has been converted into postfix notation, implementing it in programs is easy.
|
||||
- ### Using Stacks to Implement Procedure Calls
|
||||
- Programs need a way to **pass inputs to the procedures** that they call and to receive outputs back from them.
|
||||
- Procedures need to be able to **allocate space in memory for local variables** without overriding any data used by their calling program.
|
||||
- It is impossible to determine which registers may be used safely by the procedure (especially if the procedure is located in a library).
|
||||
- So, a mechanism to **save / restore registers** of the calling program has to be in place.
|
||||
- Procedures need a way to figure out where they were called from.
|
||||
- So, the execution can **return to the calling program** where the procedure completes (they need to restore the program counter).
|
||||
- How are procedure calls implemented in Stacks? #card
|
||||
card-last-interval:: 9.28
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.32
|
||||
card-next-schedule:: 2022-10-18T04:57:53.451Z
|
||||
card-last-reviewed:: 2022-10-08T22:57:53.496Z
|
||||
card-last-score:: 5
|
||||
- 
|
||||
- When a procedure is called,^^a block of memory in the stack called a **stack frame** is allocated.^^
|
||||
- The top of the **stack pointer** is incremented by the number of locations in the stack frame.
|
||||
- When a procedure finishes, it jumps to the **return address** of the stack and the execution of the calling program resumes.
|
||||
- How are nested procedure calls implemented in the stack? #card
|
||||
card-last-interval:: 8.32
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.08
|
||||
card-next-schedule:: 2022-10-11T21:30:20.346Z
|
||||
card-last-reviewed:: 2022-10-03T14:30:20.347Z
|
||||
card-last-score:: 3
|
||||
- 
|
||||
- main program calls function f(),
|
||||
- function f() calls function g(),
|
||||
- function g() calls function h()
|
||||
- ## General-Purpose Register Architectures
|
||||
- ### General-Purpose Register File
|
||||
- In GPR Architectures, instructions read their operands and write their results to a **random access register file**.
|
||||
- The general-purpose register file allows the ^^access of **any** register in **any** order^^ by specifying the number (register ID) of the register.
|
||||
- What is the main difference between a GPR & a stack? #card
|
||||
card-last-interval:: 9.28
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.32
|
||||
card-next-schedule:: 2022-10-12T17:43:13.452Z
|
||||
card-last-reviewed:: 2022-10-03T11:43:13.452Z
|
||||
card-last-score:: 3
|
||||
- The main difference between a GPR and a stack is that repeatedly reading a register will produce the same result and **will not** modify the state of the register file.
|
||||
- Popping an item from a LIFO structure (stack) **will** modify the contents of the stack,
|
||||
- Many GPR architectures assign special values to some registers in the register file to make programming easier.
|
||||
- e.g., sometimes, register 0 is hardwired with value 0 to generate this most common constant.
|
||||
- ### Instructions in GPR Architecture
|
||||
- What do GPR instructions need to specify? #card
|
||||
card-last-interval:: 9.84
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.46
|
||||
card-next-schedule:: 2022-10-10T05:28:31.531Z
|
||||
card-last-reviewed:: 2022-09-30T09:28:31.531Z
|
||||
card-last-score:: 5
|
||||
- GPR instructions need to specify:
|
||||
- **the register** that holds their **input operands**
|
||||
- the register that will hole the **result**
|
||||
- What is the most common GPR instruction format? #card
|
||||
card-last-interval:: 26.21
|
||||
card-repeats:: 4
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-15T22:48:52.100Z
|
||||
card-last-reviewed:: 2022-09-19T17:48:52.100Z
|
||||
card-last-score:: 5
|
||||
- The most common GPR instruction format is the **three operands instruction format**.
|
||||
- e.g., "ADD r1, r2, r3" instructs the processor to read the contents of r2 and r3, add them together, and write the results in r1.
|
||||
- Instructions that only have one or two inputs are also present in GPR architecture.
|
||||
- Which architecture allows **caching**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-11T16:11:50.487Z
|
||||
card-last-reviewed:: 2022-09-30T12:11:50.488Z
|
||||
card-last-score:: 5
|
||||
- In GPR Architecture, ^^programs can choose which values should be stored in the register file at any given time^^, allowing them to **cache** the most accessed data.
|
||||
- In stack-based architectures, once the data has been used, it's gone.
|
||||
- From this point of view, ^^GPR architectures have **better performance**^^, at the expense of needing **more storage space** for the program.
|
||||
- larger instructions are needed to encode the addresses of the operands.
|
||||
- #### Simple GPR Instruction Set
|
||||
- 
|
||||
-
|
||||
- ### Programs in a GPR Architecure #card
|
||||
card-last-interval:: 10.6
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-19T12:58:16.278Z
|
||||
card-last-reviewed:: 2022-10-08T22:58:16.278Z
|
||||
card-last-score:: 5
|
||||
- Programming a GPR architecture processor is **less structured** than programming a stack-based architecture processor.
|
||||
- There are **fewer restrictions on the order** in which operations can be executed.
|
||||
- In stack-based architectures, instructions must execute in the order that would leave the operands for the next instructions on the top of the stack.
|
||||
- In GPR, any order that places the operands for the next instruction in the register file before the instruction executes is valid.
|
||||
- Operations that access different registers can be **reordered** without making the program invalid.
|
||||
-
|
||||
- ## Stack-Bases vs GPR Architectures
|
||||
- Stack-based architectures are still attractive for certain embedded systems.
|
||||
- GPR architectures are used by modern computers.
|
||||
- ## Stack-Based Architectures #card
|
||||
card-last-interval:: 10.6
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-19T12:59:04.549Z
|
||||
card-last-reviewed:: 2022-10-08T22:59:04.550Z
|
||||
card-last-score:: 5
|
||||
- Instructions take **fewer bits** to encode.
|
||||
- **Reduced amount of memory** taken up by programs.
|
||||
- Manages the **use of registers automatically** (no need for programmer intervention).
|
||||
- The instruction set **does not change** if the size of the register file has changed.
|
||||
- ## GPR Architectures
|
||||
- With the evolution of technology, the amount of space taken up by a program is less important.
|
||||
- Compilers for GPR architecture achieve **better performance** with a given number of general-purpose registers than those on stack-based architectures with the same number of registers.
|
||||
- The compiler can choose which values to keep (**cache**) in the register file at any time.
|
||||
@ -0,0 +1,401 @@
|
||||
- #[[CT213 - Computer Systems & Organisation]]
|
||||
- **Previous Topic:** [[Overview of Computer Systems]]
|
||||
- **Relevant Slides:** 
|
||||
-
|
||||
- What is a **Processor Programming Model**? #card
|
||||
card-last-interval:: 3.09
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.46
|
||||
card-next-schedule:: 2022-10-13T13:40:54.101Z
|
||||
card-last-reviewed:: 2022-10-10T11:40:54.101Z
|
||||
card-last-score:: 5
|
||||
- A **Processor Programming Model** defines ^^how instructions access their operands and how instructions are described in the processor's assembly language.^^
|
||||
- Processors with different programming models can offer similar sets of operations but may require very different approaches to programming.
|
||||
-
|
||||
- ## Instructions
|
||||
- What is the **Instruction Cycle**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:42:30.873Z
|
||||
card-last-reviewed:: 2022-10-03T11:42:30.874Z
|
||||
card-last-score:: 5
|
||||
- The **Instruction Cycle** is the ^^procedure of processing an instruction^^ by the microprocessor.
|
||||
- **Fetch:** read the instructions from memory
|
||||
- **Decode:** Determine what is to be done
|
||||
- **Execute:** Perform the operation
|
||||
- Each of the functions fetch -> decode -> execute consist of a sequence of one or more operations inside the CPU (and interaction with the subsystems).
|
||||
- ### Types of Instructions
|
||||
- #### Data Transfer Instructions
|
||||
- What are **Data Transfer Instructions**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:40:48.321Z
|
||||
card-last-reviewed:: 2022-10-03T11:40:48.321Z
|
||||
card-last-score:: 5
|
||||
- Operations that ^^move data^^ from one place to another.
|
||||
- These instructions ^^don't modify^^ the data, they just copy it to the destination.
|
||||
- What operations can data transfer instructions do? #card
|
||||
card-last-interval:: 10.92
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.46
|
||||
card-next-schedule:: 2022-10-11T06:46:12.475Z
|
||||
card-last-reviewed:: 2022-09-30T08:46:12.475Z
|
||||
card-last-score:: 5
|
||||
- card-last-interval:: 11.56
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-10-11T21:26:36.529Z
|
||||
card-last-reviewed:: 2022-09-30T08:26:36.529Z
|
||||
card-last-score:: 5
|
||||
1. **Load data** from memory into the microprocessor. #card
|
||||
- These instructions copy data from memory into microprocessor registers (i.e., LD).
|
||||
- card-last-interval:: 10.24
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-13T19:28:41.508Z
|
||||
card-last-reviewed:: 2022-10-03T14:28:41.509Z
|
||||
card-last-score:: 5
|
||||
2. **Store data** from the microprocessor into the memory. #card
|
||||
- Similar to load data, except that the data is copied in the opposite direction (i.e., ST).
|
||||
- Data is saved from internal microprocessor registers into the memory
|
||||
- card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T18:29:32.655Z
|
||||
card-last-reviewed:: 2022-10-03T14:29:32.655Z
|
||||
card-last-score:: 5
|
||||
3. **Move data** within the microprocessor.
|
||||
- These instructions move data from one microprocessor register to another (i.e., MOV)
|
||||
- card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T17:44:07.730Z
|
||||
card-last-reviewed:: 2022-09-19T17:44:07.731Z
|
||||
card-last-score:: 5
|
||||
4. **Input data** into the microprocessor.
|
||||
- A microprocessor may need to input data from the outside world.
|
||||
- These are the instructions that input data from the input device into the microprocessor.
|
||||
- card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T17:47:33.165Z
|
||||
card-last-reviewed:: 2022-09-19T17:47:33.165Z
|
||||
card-last-score:: 5
|
||||
5. **Output data** from the microprocessor.
|
||||
- The microprocessor copies data from one of its internal registers to an output device.
|
||||
- Example: the microprocessor may want to show the content of an internal register on a display (the key has been pressed) (i.e., IOWR).
|
||||
- #### Data Operation Instructions #card
|
||||
card-last-interval:: 10.24
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-13T16:45:28.268Z
|
||||
card-last-reviewed:: 2022-10-03T11:45:28.268Z
|
||||
card-last-score:: 5
|
||||
- Instructions that *do* modify their data values.
|
||||
- They typically perform some operation (e.g., +, -, *) using one or two data values (operands) and store the result.
|
||||
- What operations can data operation instructions do? #card
|
||||
card-last-interval:: 10.64
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.66
|
||||
card-next-schedule:: 2022-10-30T23:33:48.626Z
|
||||
card-last-reviewed:: 2022-10-20T08:33:48.627Z
|
||||
card-last-score:: 3
|
||||
- **Arithmetic Instructions** #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:44:56.702Z
|
||||
card-last-reviewed:: 2022-10-03T11:44:56.702Z
|
||||
card-last-score:: 5
|
||||
- add, subtract, multiply, or divide
|
||||
- ADD, SUB, MUL, DIV
|
||||
- Instructions that increment or decrement one from a value
|
||||
- INC, DEC
|
||||
- Floating point instructions that operate on floating point values
|
||||
- FADD, FSUB, FMUL, FDIV
|
||||
- **Logic Instructions**
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:43:49.421Z
|
||||
card-last-reviewed:: 2022-10-03T11:43:49.421Z
|
||||
card-last-score:: 5
|
||||
- AND, OR, XOR, NOT, etc.
|
||||
- **Shift Instructions**
|
||||
card-last-interval:: 10.92
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.46
|
||||
card-next-schedule:: 2022-10-11T06:45:44.876Z
|
||||
card-last-reviewed:: 2022-09-30T08:45:44.877Z
|
||||
card-last-score:: 5
|
||||
- SR, SL, RR, RL, etc.
|
||||
- #### Program Control Instructions #card
|
||||
card-last-interval:: 10.8
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-10-11T04:28:17.821Z
|
||||
card-last-reviewed:: 2022-09-30T09:28:17.821Z
|
||||
card-last-score:: 5
|
||||
- **Jump** or **branch** instructions are used to ^^go to another part of the program^^; Jumps can be **absolute** or **conditional**.
|
||||
- e.g., if, then, else.
|
||||
- Instructions that can generate **interrupts**.
|
||||
- Software interrupts.
|
||||
- **Jump & branch instructions** (conditional or unconditional)
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T18:27:30.317Z
|
||||
card-last-reviewed:: 2022-10-03T14:27:30.317Z
|
||||
card-last-score:: 5
|
||||
- **JZ:** Jump if the zero flag is set.
|
||||
- **JNZ:** Jump if the zero flag is **not** set.
|
||||
- **JMP:** Unconditional jump - flags are ignored.
|
||||
- etc.
|
||||
- **Comparison Instructions** #card
|
||||
card-last-interval:: 10.24
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-13T16:42:52.048Z
|
||||
card-last-reviewed:: 2022-10-03T11:42:52.049Z
|
||||
card-last-score:: 3
|
||||
- TEST: logical BITWISE AND
|
||||
- **Calls & Returns** a / from a routine (conditional or unconditional) #card
|
||||
card-last-interval:: 10.24
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-13T19:28:56.319Z
|
||||
card-last-reviewed:: 2022-10-03T14:28:56.319Z
|
||||
card-last-score:: 3
|
||||
- **Call:** call a subroutine at a certain line.
|
||||
- **RET:** return from a subroutine.
|
||||
- **IRET:** interrupt & return.
|
||||
- **Software Interrupts** #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T18:28:46.482Z
|
||||
card-last-reviewed:: 2022-10-03T14:28:46.483Z
|
||||
card-last-score:: 5
|
||||
- Generated by devices outside of a microprocessor (not part of the instruction set).
|
||||
- INT
|
||||
- **Exceptions & Traps** #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-10-24T08:41:17.975Z
|
||||
card-last-reviewed:: 2022-10-20T08:41:17.975Z
|
||||
card-last-score:: 5
|
||||
- Triggered when valid instructions perform invalid operations.
|
||||
- e.g., dividing by zero.
|
||||
- **Halt Instructions** #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:37:56.173Z
|
||||
card-last-reviewed:: 2022-10-03T11:37:56.174Z
|
||||
card-last-score:: 5
|
||||
- Causes the processor to stop executions.
|
||||
- e.g., at the end of the program.
|
||||
- HALT
|
||||
-
|
||||
- ## Stack Architectures
|
||||
- ### The Stack
|
||||
- **Last In First Out (LIFO)** data structure.
|
||||
- Consists of **locations**, each of which can hold a **word of data**.
|
||||
- It can be used to explicitly **save / restore** data.
|
||||
- What operations does the stack support? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T18:30:00.780Z
|
||||
card-last-reviewed:: 2022-10-03T14:30:00.780Z
|
||||
card-last-score:: 5
|
||||
- The stack supports ^^two operations.^^
|
||||
- **PUSH:** takes one argument and places the value of the argument at the top of the stack.
|
||||
- **POP:** removes one element from the stack, saving it into a predefined register of the processor.
|
||||
- The stack is ^^used implicitly by procedure call instructions.^^
|
||||
- (if available in the data set).
|
||||
- When new data is added to the stack, it is placed at the top of the stack, and all of the contents of the stack are pushed down one location.
|
||||
- ### Implementing Stacks
|
||||
- What are the two ways to implement a stack? #card
|
||||
card-last-interval:: 21.53
|
||||
card-repeats:: 4
|
||||
card-ease-factor:: 2.32
|
||||
card-next-schedule:: 2022-10-31T23:42:47.216Z
|
||||
card-last-reviewed:: 2022-10-10T11:42:47.216Z
|
||||
card-last-score:: 5
|
||||
- card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.08
|
||||
card-next-schedule:: 2022-10-12T15:29:51.594Z
|
||||
card-last-reviewed:: 2022-10-08T15:29:51.595Z
|
||||
card-last-score:: 3
|
||||
1. **Dedicated Hardware Stack** #card
|
||||
- Has a ^^hardware limitation^^ (limited number of locations).
|
||||
- Very fast.
|
||||
- card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:44:04.293Z
|
||||
card-last-reviewed:: 2022-10-03T11:44:04.294Z
|
||||
card-last-score:: 5
|
||||
2. **Memory Implemented Stack** #card
|
||||
- Limited by the ^^physical memory of the system.^^
|
||||
- Slow compared with hardware stacks, since extra memory addressing has to take place for each stack operation.
|
||||
- {:height 405, :width 638}
|
||||
- Every **push operation** will ^^increment the top of the **stack pointer**^^ with the word size of the machine.
|
||||
- Every **pop operation** will ^^decrement the top of the stack pointer^^ (with the word size of the machine).
|
||||
- **Stack overflows** can occur in both stack implementations
|
||||
- What is a **stack overflow**? #card
|
||||
card-last-interval:: 31.36
|
||||
card-repeats:: 4
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-11-04T20:25:37.658Z
|
||||
card-last-reviewed:: 2022-10-04T12:25:37.659Z
|
||||
card-last-score:: 5
|
||||
- A **stack overflow** occurs when the amount of data in the stack exceeds the amount of space allocated to the stack (or the hardware limit of the stack).
|
||||
- ### Instructions in Stack-Based Architecture #card
|
||||
card-last-interval:: 15.05
|
||||
card-repeats:: 4
|
||||
card-ease-factor:: 1.94
|
||||
card-next-schedule:: 2022-11-03T09:43:35.672Z
|
||||
card-last-reviewed:: 2022-10-19T08:43:35.673Z
|
||||
card-last-score:: 3
|
||||
- Instructions in a stack-base architecture get their operands from the stack and write their results to the stack.
|
||||
- The advantage of this is that ^^program code takes little memory - there is no need to specify the address of the operands or registers.^^
|
||||
- PUSH is one exception, because it needs the operand to be specified (either as a constant or as an address).
|
||||
- ### Programs in a Stack-Based Architecture
|
||||
- Writing programs for stack-based architecture is not easy.
|
||||
- Stack-based architectures are better suited for **postfix** notation rather than **infix** notation.
|
||||
- What is **infix notation**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:42:45.628Z
|
||||
card-last-reviewed:: 2022-10-03T11:42:45.628Z
|
||||
card-last-score:: 5
|
||||
- **Infix notation** is the traditional way of representing mathematical expressions, with ^^operations placed **between** the operands.^^
|
||||
- e.g., a + b
|
||||
- What is **postfix notation**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:39:50.328Z
|
||||
card-last-reviewed:: 2022-10-03T11:39:50.328Z
|
||||
card-last-score:: 5
|
||||
- In **postfix notation**, ^^the operation is placed **after** the operands.^^
|
||||
- e.g., a b +
|
||||
- Stack-based architectures are better suited for **postfix notation**.
|
||||
- Once an expression has been converted into postfix notation, implementing it in programs is easy.
|
||||
- ### Using Stacks to Implement Procedure Calls
|
||||
- Programs need a way to **pass inputs to the procedures** that they call and to receive outputs back from them.
|
||||
- Procedures need to be able to **allocate space in memory for local variables** without overriding any data used by their calling program.
|
||||
- It is impossible to determine which registers may be used safely by the procedure (especially if the procedure is located in a library).
|
||||
- So, a mechanism to **save / restore registers** of the calling program has to be in place.
|
||||
- Procedures need a way to figure out where they were called from.
|
||||
- So, the execution can **return to the calling program** where the procedure completes (they need to restore the program counter).
|
||||
- How are procedure calls implemented in Stacks? #card
|
||||
card-last-interval:: 9.28
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.32
|
||||
card-next-schedule:: 2022-10-18T04:57:53.451Z
|
||||
card-last-reviewed:: 2022-10-08T22:57:53.496Z
|
||||
card-last-score:: 5
|
||||
- 
|
||||
- When a procedure is called,^^a block of memory in the stack called a **stack frame** is allocated.^^
|
||||
- The top of the **stack pointer** is incremented by the number of locations in the stack frame.
|
||||
- When a procedure finishes, it jumps to the **return address** of the stack and the execution of the calling program resumes.
|
||||
- How are nested procedure calls implemented in the stack? #card
|
||||
card-last-interval:: 19.01
|
||||
card-repeats:: 4
|
||||
card-ease-factor:: 2.18
|
||||
card-next-schedule:: 2022-11-08T08:24:29.547Z
|
||||
card-last-reviewed:: 2022-10-20T08:24:29.548Z
|
||||
card-last-score:: 5
|
||||
- 
|
||||
- main program calls function f(),
|
||||
- function f() calls function g(),
|
||||
- function g() calls function h()
|
||||
- ## General-Purpose Register Architectures
|
||||
- ### General-Purpose Register File
|
||||
- In GPR Architectures, instructions read their operands and write their results to a **random access register file**.
|
||||
- The general-purpose register file allows the ^^access of **any** register in **any** order^^ by specifying the number (register ID) of the register.
|
||||
- What is the main difference between a GPR & a stack? #card
|
||||
card-last-interval:: 9.28
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.32
|
||||
card-next-schedule:: 2022-10-12T17:43:13.452Z
|
||||
card-last-reviewed:: 2022-10-03T11:43:13.452Z
|
||||
card-last-score:: 3
|
||||
- The main difference between a GPR and a stack is that repeatedly reading a register will produce the same result and **will not** modify the state of the register file.
|
||||
- Popping an item from a LIFO structure (stack) **will** modify the contents of the stack,
|
||||
- Many GPR architectures assign special values to some registers in the register file to make programming easier.
|
||||
- e.g., sometimes, register 0 is hardwired with value 0 to generate this most common constant.
|
||||
- ### Instructions in GPR Architecture
|
||||
- What do GPR instructions need to specify? #card
|
||||
card-last-interval:: 21.53
|
||||
card-repeats:: 4
|
||||
card-ease-factor:: 2.32
|
||||
card-next-schedule:: 2022-11-10T20:30:05.069Z
|
||||
card-last-reviewed:: 2022-10-20T08:30:05.069Z
|
||||
card-last-score:: 3
|
||||
- GPR instructions need to specify:
|
||||
- **the register** that holds their **input operands**
|
||||
- the register that will hole the **result**
|
||||
- What is the most common GPR instruction format? #card
|
||||
card-last-interval:: 26.21
|
||||
card-repeats:: 4
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-15T22:48:52.100Z
|
||||
card-last-reviewed:: 2022-09-19T17:48:52.100Z
|
||||
card-last-score:: 5
|
||||
- The most common GPR instruction format is the **three operands instruction format**.
|
||||
- e.g., "ADD r1, r2, r3" instructs the processor to read the contents of r2 and r3, add them together, and write the results in r1.
|
||||
- Instructions that only have one or two inputs are also present in GPR architecture.
|
||||
- Which architecture allows **caching**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-11T16:11:50.487Z
|
||||
card-last-reviewed:: 2022-09-30T12:11:50.488Z
|
||||
card-last-score:: 5
|
||||
- In GPR Architecture, ^^programs can choose which values should be stored in the register file at any given time^^, allowing them to **cache** the most accessed data.
|
||||
- In stack-based architectures, once the data has been used, it's gone.
|
||||
- From this point of view, ^^GPR architectures have **better performance**^^, at the expense of needing **more storage space** for the program.
|
||||
- larger instructions are needed to encode the addresses of the operands.
|
||||
- #### Simple GPR Instruction Set
|
||||
- 
|
||||
-
|
||||
- ### Programs in a GPR Architecure #card
|
||||
card-last-interval:: 10.6
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-19T12:58:16.278Z
|
||||
card-last-reviewed:: 2022-10-08T22:58:16.278Z
|
||||
card-last-score:: 5
|
||||
- Programming a GPR architecture processor is **less structured** than programming a stack-based architecture processor.
|
||||
- There are **fewer restrictions on the order** in which operations can be executed.
|
||||
- In stack-based architectures, instructions must execute in the order that would leave the operands for the next instructions on the top of the stack.
|
||||
- In GPR, any order that places the operands for the next instruction in the register file before the instruction executes is valid.
|
||||
- Operations that access different registers can be **reordered** without making the program invalid.
|
||||
-
|
||||
- ## Stack-Bases vs GPR Architectures
|
||||
- Stack-based architectures are still attractive for certain embedded systems.
|
||||
- GPR architectures are used by modern computers.
|
||||
- ## Stack-Based Architectures #card
|
||||
card-last-interval:: 10.6
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-19T12:59:04.549Z
|
||||
card-last-reviewed:: 2022-10-08T22:59:04.550Z
|
||||
card-last-score:: 5
|
||||
- Instructions take **fewer bits** to encode.
|
||||
- **Reduced amount of memory** taken up by programs.
|
||||
- Manages the **use of registers automatically** (no need for programmer intervention).
|
||||
- The instruction set **does not change** if the size of the register file has changed.
|
||||
- ## GPR Architectures
|
||||
- With the evolution of technology, the amount of space taken up by a program is less important.
|
||||
- Compilers for GPR architecture achieve **better performance** with a given number of general-purpose registers than those on stack-based architectures with the same number of registers.
|
||||
- The compiler can choose which values to keep (**cache**) in the register file at any time.
|
||||
@ -0,0 +1,401 @@
|
||||
- #[[CT213 - Computer Systems & Organisation]]
|
||||
- **Previous Topic:** [[Overview of Computer Systems]]
|
||||
- **Relevant Slides:** 
|
||||
-
|
||||
- What is a **Processor Programming Model**? #card
|
||||
card-last-interval:: 3.09
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.46
|
||||
card-next-schedule:: 2022-10-13T13:40:54.101Z
|
||||
card-last-reviewed:: 2022-10-10T11:40:54.101Z
|
||||
card-last-score:: 5
|
||||
- A **Processor Programming Model** defines ^^how instructions access their operands and how instructions are described in the processor's assembly language.^^
|
||||
- Processors with different programming models can offer similar sets of operations but may require very different approaches to programming.
|
||||
-
|
||||
- ## Instructions
|
||||
- What is the **Instruction Cycle**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:42:30.873Z
|
||||
card-last-reviewed:: 2022-10-03T11:42:30.874Z
|
||||
card-last-score:: 5
|
||||
- The **Instruction Cycle** is the ^^procedure of processing an instruction^^ by the microprocessor.
|
||||
- **Fetch:** read the instructions from memory
|
||||
- **Decode:** Determine what is to be done
|
||||
- **Execute:** Perform the operation
|
||||
- Each of the functions fetch -> decode -> execute consist of a sequence of one or more operations inside the CPU (and interaction with the subsystems).
|
||||
- ### Types of Instructions
|
||||
- #### Data Transfer Instructions
|
||||
- What are **Data Transfer Instructions**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:40:48.321Z
|
||||
card-last-reviewed:: 2022-10-03T11:40:48.321Z
|
||||
card-last-score:: 5
|
||||
- Operations that ^^move data^^ from one place to another.
|
||||
- These instructions ^^don't modify^^ the data, they just copy it to the destination.
|
||||
- What operations can data transfer instructions do? #card
|
||||
card-last-interval:: 10.92
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.46
|
||||
card-next-schedule:: 2022-10-11T06:46:12.475Z
|
||||
card-last-reviewed:: 2022-09-30T08:46:12.475Z
|
||||
card-last-score:: 5
|
||||
- card-last-interval:: 11.56
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-10-11T21:26:36.529Z
|
||||
card-last-reviewed:: 2022-09-30T08:26:36.529Z
|
||||
card-last-score:: 5
|
||||
1. **Load data** from memory into the microprocessor. #card
|
||||
- These instructions copy data from memory into microprocessor registers (i.e., LD).
|
||||
- card-last-interval:: 10.24
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-13T19:28:41.508Z
|
||||
card-last-reviewed:: 2022-10-03T14:28:41.509Z
|
||||
card-last-score:: 5
|
||||
2. **Store data** from the microprocessor into the memory. #card
|
||||
- Similar to load data, except that the data is copied in the opposite direction (i.e., ST).
|
||||
- Data is saved from internal microprocessor registers into the memory
|
||||
- card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T18:29:32.655Z
|
||||
card-last-reviewed:: 2022-10-03T14:29:32.655Z
|
||||
card-last-score:: 5
|
||||
3. **Move data** within the microprocessor.
|
||||
- These instructions move data from one microprocessor register to another (i.e., MOV)
|
||||
- card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T17:44:07.730Z
|
||||
card-last-reviewed:: 2022-09-19T17:44:07.731Z
|
||||
card-last-score:: 5
|
||||
4. **Input data** into the microprocessor.
|
||||
- A microprocessor may need to input data from the outside world.
|
||||
- These are the instructions that input data from the input device into the microprocessor.
|
||||
- card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-09-23T17:47:33.165Z
|
||||
card-last-reviewed:: 2022-09-19T17:47:33.165Z
|
||||
card-last-score:: 5
|
||||
5. **Output data** from the microprocessor.
|
||||
- The microprocessor copies data from one of its internal registers to an output device.
|
||||
- Example: the microprocessor may want to show the content of an internal register on a display (the key has been pressed) (i.e., IOWR).
|
||||
- #### Data Operation Instructions #card
|
||||
card-last-interval:: 10.24
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-13T16:45:28.268Z
|
||||
card-last-reviewed:: 2022-10-03T11:45:28.268Z
|
||||
card-last-score:: 5
|
||||
- Instructions that *do* modify their data values.
|
||||
- They typically perform some operation (e.g., +, -, *) using one or two data values (operands) and store the result.
|
||||
- What operations can data operation instructions do? #card
|
||||
card-last-interval:: 10.64
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.66
|
||||
card-next-schedule:: 2022-10-30T23:33:48.626Z
|
||||
card-last-reviewed:: 2022-10-20T08:33:48.627Z
|
||||
card-last-score:: 3
|
||||
- **Arithmetic Instructions** #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:44:56.702Z
|
||||
card-last-reviewed:: 2022-10-03T11:44:56.702Z
|
||||
card-last-score:: 5
|
||||
- add, subtract, multiply, or divide
|
||||
- ADD, SUB, MUL, DIV
|
||||
- Instructions that increment or decrement one from a value
|
||||
- INC, DEC
|
||||
- Floating point instructions that operate on floating point values
|
||||
- FADD, FSUB, FMUL, FDIV
|
||||
- **Logic Instructions**
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:43:49.421Z
|
||||
card-last-reviewed:: 2022-10-03T11:43:49.421Z
|
||||
card-last-score:: 5
|
||||
- AND, OR, XOR, NOT, etc.
|
||||
- **Shift Instructions**
|
||||
card-last-interval:: 10.92
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.46
|
||||
card-next-schedule:: 2022-10-11T06:45:44.876Z
|
||||
card-last-reviewed:: 2022-09-30T08:45:44.877Z
|
||||
card-last-score:: 5
|
||||
- SR, SL, RR, RL, etc.
|
||||
- #### Program Control Instructions #card
|
||||
card-last-interval:: 10.8
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-10-11T04:28:17.821Z
|
||||
card-last-reviewed:: 2022-09-30T09:28:17.821Z
|
||||
card-last-score:: 5
|
||||
- **Jump** or **branch** instructions are used to ^^go to another part of the program^^; Jumps can be **absolute** or **conditional**.
|
||||
- e.g., if, then, else.
|
||||
- Instructions that can generate **interrupts**.
|
||||
- Software interrupts.
|
||||
- **Jump & branch instructions** (conditional or unconditional)
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T18:27:30.317Z
|
||||
card-last-reviewed:: 2022-10-03T14:27:30.317Z
|
||||
card-last-score:: 5
|
||||
- **JZ:** Jump if the zero flag is set.
|
||||
- **JNZ:** Jump if the zero flag is **not** set.
|
||||
- **JMP:** Unconditional jump - flags are ignored.
|
||||
- etc.
|
||||
- **Comparison Instructions** #card
|
||||
card-last-interval:: 10.24
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-13T16:42:52.048Z
|
||||
card-last-reviewed:: 2022-10-03T11:42:52.049Z
|
||||
card-last-score:: 3
|
||||
- TEST: logical BITWISE AND
|
||||
- **Calls & Returns** a / from a routine (conditional or unconditional) #card
|
||||
card-last-interval:: -1
|
||||
card-repeats:: 1
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-11-10T00:00:00.000Z
|
||||
card-last-reviewed:: 2022-11-09T12:44:38.495Z
|
||||
card-last-score:: 1
|
||||
- **Call:** call a subroutine at a certain line.
|
||||
- **RET:** return from a subroutine.
|
||||
- **IRET:** interrupt & return.
|
||||
- **Software Interrupts** #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T18:28:46.482Z
|
||||
card-last-reviewed:: 2022-10-03T14:28:46.483Z
|
||||
card-last-score:: 5
|
||||
- Generated by devices outside of a microprocessor (not part of the instruction set).
|
||||
- INT
|
||||
- **Exceptions & Traps** #card
|
||||
card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.7
|
||||
card-next-schedule:: 2022-10-24T08:41:17.975Z
|
||||
card-last-reviewed:: 2022-10-20T08:41:17.975Z
|
||||
card-last-score:: 5
|
||||
- Triggered when valid instructions perform invalid operations.
|
||||
- e.g., dividing by zero.
|
||||
- **Halt Instructions** #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:37:56.173Z
|
||||
card-last-reviewed:: 2022-10-03T11:37:56.174Z
|
||||
card-last-score:: 5
|
||||
- Causes the processor to stop executions.
|
||||
- e.g., at the end of the program.
|
||||
- HALT
|
||||
-
|
||||
- ## Stack Architectures
|
||||
- ### The Stack
|
||||
- **Last In First Out (LIFO)** data structure.
|
||||
- Consists of **locations**, each of which can hold a **word of data**.
|
||||
- It can be used to explicitly **save / restore** data.
|
||||
- What operations does the stack support? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T18:30:00.780Z
|
||||
card-last-reviewed:: 2022-10-03T14:30:00.780Z
|
||||
card-last-score:: 5
|
||||
- The stack supports ^^two operations.^^
|
||||
- **PUSH:** takes one argument and places the value of the argument at the top of the stack.
|
||||
- **POP:** removes one element from the stack, saving it into a predefined register of the processor.
|
||||
- The stack is ^^used implicitly by procedure call instructions.^^
|
||||
- (if available in the data set).
|
||||
- When new data is added to the stack, it is placed at the top of the stack, and all of the contents of the stack are pushed down one location.
|
||||
- ### Implementing Stacks
|
||||
- What are the two ways to implement a stack? #card
|
||||
card-last-interval:: 41.44
|
||||
card-repeats:: 5
|
||||
card-ease-factor:: 2.18
|
||||
card-next-schedule:: 2022-12-20T22:45:42.001Z
|
||||
card-last-reviewed:: 2022-11-09T12:45:42.002Z
|
||||
card-last-score:: 3
|
||||
- card-last-interval:: 4
|
||||
card-repeats:: 2
|
||||
card-ease-factor:: 2.08
|
||||
card-next-schedule:: 2022-10-12T15:29:51.594Z
|
||||
card-last-reviewed:: 2022-10-08T15:29:51.595Z
|
||||
card-last-score:: 3
|
||||
1. **Dedicated Hardware Stack** #card
|
||||
- Has a ^^hardware limitation^^ (limited number of locations).
|
||||
- Very fast.
|
||||
- card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:44:04.293Z
|
||||
card-last-reviewed:: 2022-10-03T11:44:04.294Z
|
||||
card-last-score:: 5
|
||||
2. **Memory Implemented Stack** #card
|
||||
- Limited by the ^^physical memory of the system.^^
|
||||
- Slow compared with hardware stacks, since extra memory addressing has to take place for each stack operation.
|
||||
- {:height 405, :width 638}
|
||||
- Every **push operation** will ^^increment the top of the **stack pointer**^^ with the word size of the machine.
|
||||
- Every **pop operation** will ^^decrement the top of the stack pointer^^ (with the word size of the machine).
|
||||
- **Stack overflows** can occur in both stack implementations
|
||||
- What is a **stack overflow**? #card
|
||||
card-last-interval:: 31.36
|
||||
card-repeats:: 4
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-11-04T20:25:37.658Z
|
||||
card-last-reviewed:: 2022-10-04T12:25:37.659Z
|
||||
card-last-score:: 5
|
||||
- A **stack overflow** occurs when the amount of data in the stack exceeds the amount of space allocated to the stack (or the hardware limit of the stack).
|
||||
- ### Instructions in Stack-Based Architecture #card
|
||||
card-last-interval:: 15.05
|
||||
card-repeats:: 4
|
||||
card-ease-factor:: 1.94
|
||||
card-next-schedule:: 2022-11-03T09:43:35.672Z
|
||||
card-last-reviewed:: 2022-10-19T08:43:35.673Z
|
||||
card-last-score:: 3
|
||||
- Instructions in a stack-base architecture get their operands from the stack and write their results to the stack.
|
||||
- The advantage of this is that ^^program code takes little memory - there is no need to specify the address of the operands or registers.^^
|
||||
- PUSH is one exception, because it needs the operand to be specified (either as a constant or as an address).
|
||||
- ### Programs in a Stack-Based Architecture
|
||||
- Writing programs for stack-based architecture is not easy.
|
||||
- Stack-based architectures are better suited for **postfix** notation rather than **infix** notation.
|
||||
- What is **infix notation**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:42:45.628Z
|
||||
card-last-reviewed:: 2022-10-03T11:42:45.628Z
|
||||
card-last-score:: 5
|
||||
- **Infix notation** is the traditional way of representing mathematical expressions, with ^^operations placed **between** the operands.^^
|
||||
- e.g., a + b
|
||||
- What is **postfix notation**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-14T15:39:50.328Z
|
||||
card-last-reviewed:: 2022-10-03T11:39:50.328Z
|
||||
card-last-score:: 5
|
||||
- In **postfix notation**, ^^the operation is placed **after** the operands.^^
|
||||
- e.g., a b +
|
||||
- Stack-based architectures are better suited for **postfix notation**.
|
||||
- Once an expression has been converted into postfix notation, implementing it in programs is easy.
|
||||
- ### Using Stacks to Implement Procedure Calls
|
||||
- Programs need a way to **pass inputs to the procedures** that they call and to receive outputs back from them.
|
||||
- Procedures need to be able to **allocate space in memory for local variables** without overriding any data used by their calling program.
|
||||
- It is impossible to determine which registers may be used safely by the procedure (especially if the procedure is located in a library).
|
||||
- So, a mechanism to **save / restore registers** of the calling program has to be in place.
|
||||
- Procedures need a way to figure out where they were called from.
|
||||
- So, the execution can **return to the calling program** where the procedure completes (they need to restore the program counter).
|
||||
- How are procedure calls implemented in Stacks? #card
|
||||
card-last-interval:: 9.28
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.32
|
||||
card-next-schedule:: 2022-10-18T04:57:53.451Z
|
||||
card-last-reviewed:: 2022-10-08T22:57:53.496Z
|
||||
card-last-score:: 5
|
||||
- 
|
||||
- When a procedure is called,^^a block of memory in the stack called a **stack frame** is allocated.^^
|
||||
- The top of the **stack pointer** is incremented by the number of locations in the stack frame.
|
||||
- When a procedure finishes, it jumps to the **return address** of the stack and the execution of the calling program resumes.
|
||||
- How are nested procedure calls implemented in the stack? #card
|
||||
card-last-interval:: 19.01
|
||||
card-repeats:: 4
|
||||
card-ease-factor:: 2.18
|
||||
card-next-schedule:: 2022-11-08T08:24:29.547Z
|
||||
card-last-reviewed:: 2022-10-20T08:24:29.548Z
|
||||
card-last-score:: 5
|
||||
- 
|
||||
- main program calls function f(),
|
||||
- function f() calls function g(),
|
||||
- function g() calls function h()
|
||||
- ## General-Purpose Register Architectures
|
||||
- ### General-Purpose Register File
|
||||
- In GPR Architectures, instructions read their operands and write their results to a **random access register file**.
|
||||
- The general-purpose register file allows the ^^access of **any** register in **any** order^^ by specifying the number (register ID) of the register.
|
||||
- What is the main difference between a GPR & a stack? #card
|
||||
card-last-interval:: 9.28
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.32
|
||||
card-next-schedule:: 2022-10-12T17:43:13.452Z
|
||||
card-last-reviewed:: 2022-10-03T11:43:13.452Z
|
||||
card-last-score:: 3
|
||||
- The main difference between a GPR and a stack is that repeatedly reading a register will produce the same result and **will not** modify the state of the register file.
|
||||
- Popping an item from a LIFO structure (stack) **will** modify the contents of the stack,
|
||||
- Many GPR architectures assign special values to some registers in the register file to make programming easier.
|
||||
- e.g., sometimes, register 0 is hardwired with value 0 to generate this most common constant.
|
||||
- ### Instructions in GPR Architecture
|
||||
- What do GPR instructions need to specify? #card
|
||||
card-last-interval:: 21.53
|
||||
card-repeats:: 4
|
||||
card-ease-factor:: 2.32
|
||||
card-next-schedule:: 2022-11-10T20:30:05.069Z
|
||||
card-last-reviewed:: 2022-10-20T08:30:05.069Z
|
||||
card-last-score:: 3
|
||||
- GPR instructions need to specify:
|
||||
- **the register** that holds their **input operands**
|
||||
- the register that will hole the **result**
|
||||
- What is the most common GPR instruction format? #card
|
||||
card-last-interval:: 26.21
|
||||
card-repeats:: 4
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-15T22:48:52.100Z
|
||||
card-last-reviewed:: 2022-09-19T17:48:52.100Z
|
||||
card-last-score:: 5
|
||||
- The most common GPR instruction format is the **three operands instruction format**.
|
||||
- e.g., "ADD r1, r2, r3" instructs the processor to read the contents of r2 and r3, add them together, and write the results in r1.
|
||||
- Instructions that only have one or two inputs are also present in GPR architecture.
|
||||
- Which architecture allows **caching**? #card
|
||||
card-last-interval:: 11.2
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.8
|
||||
card-next-schedule:: 2022-10-11T16:11:50.487Z
|
||||
card-last-reviewed:: 2022-09-30T12:11:50.488Z
|
||||
card-last-score:: 5
|
||||
- In GPR Architecture, ^^programs can choose which values should be stored in the register file at any given time^^, allowing them to **cache** the most accessed data.
|
||||
- In stack-based architectures, once the data has been used, it's gone.
|
||||
- From this point of view, ^^GPR architectures have **better performance**^^, at the expense of needing **more storage space** for the program.
|
||||
- larger instructions are needed to encode the addresses of the operands.
|
||||
- #### Simple GPR Instruction Set
|
||||
- 
|
||||
-
|
||||
- ### Programs in a GPR Architecure #card
|
||||
card-last-interval:: 10.6
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-19T12:58:16.278Z
|
||||
card-last-reviewed:: 2022-10-08T22:58:16.278Z
|
||||
card-last-score:: 5
|
||||
- Programming a GPR architecture processor is **less structured** than programming a stack-based architecture processor.
|
||||
- There are **fewer restrictions on the order** in which operations can be executed.
|
||||
- In stack-based architectures, instructions must execute in the order that would leave the operands for the next instructions on the top of the stack.
|
||||
- In GPR, any order that places the operands for the next instruction in the register file before the instruction executes is valid.
|
||||
- Operations that access different registers can be **reordered** without making the program invalid.
|
||||
-
|
||||
- ## Stack-Bases vs GPR Architectures
|
||||
- Stack-based architectures are still attractive for certain embedded systems.
|
||||
- GPR architectures are used by modern computers.
|
||||
- ## Stack-Based Architectures #card
|
||||
card-last-interval:: 10.6
|
||||
card-repeats:: 3
|
||||
card-ease-factor:: 2.56
|
||||
card-next-schedule:: 2022-10-19T12:59:04.549Z
|
||||
card-last-reviewed:: 2022-10-08T22:59:04.550Z
|
||||
card-last-score:: 5
|
||||
- Instructions take **fewer bits** to encode.
|
||||
- **Reduced amount of memory** taken up by programs.
|
||||
- Manages the **use of registers automatically** (no need for programmer intervention).
|
||||
- The instruction set **does not change** if the size of the register file has changed.
|
||||
- ## GPR Architectures
|
||||
- With the evolution of technology, the amount of space taken up by a program is less important.
|
||||
- Compilers for GPR architecture achieve **better performance** with a given number of general-purpose registers than those on stack-based architectures with the same number of registers.
|
||||
- The compiler can choose which values to keep (**cache**) in the register file at any time.
|
||||
Reference in New Issue
Block a user