some edits to assembly - mainly formatting, some content additions

cs132/part3.md

@@ -1,15 +1,12 @@
 ---
 layout: CS132
-slides: true
 math: true
 title: Assembler
 part: true
 pre: part2
 nex: part4
 ---
-# Assembler
-
-## Microprocessor Fundamentals
+# Microprocessor Fundamentals
 
 Before diving into assembler, we need to be familiar with the **key components of all CPUs**. No matter how complex a CPU is, they always have the two following components.
 
@@ -21,18 +18,18 @@ Before diving into assembler, we need to be familiar with the **key components o
 > - Decode to form recognisable operations
 > - Execute to impact the current state
 
-### Learn the fetch-decode-execute cycle. Think of it every time you look at a CPU, or a series of instructions. Think about which of the components (the CU or the ALU) are operating and when.
+❕❗ **Learn the fetch-decode-execute cycle**. Think of it every time you look at a CPU, or a series of instructions. Think about which of the components (the CU or the ALU) are operating and when.
 
-The instruction cycle takes place over **several CPU clock cycles**- the same clock cycles we saw in **sequential logic circuits**. The FDE cycle relies on several CPU components interacting with one another.
+The instruction cycle takes place over **several CPU clock cycles** – the same clock cycles we saw in **sequential logic circuits**. The FDE cycle relies on several CPU components interacting with one another.
 
-### FDE Components
+## FDE Components
 There are several components that make up the FDE cycle:
 - ALU
 - CU
 - **Program Counter** (PC): this tracks the **memory address** of the **next instruction** for execution
 - **Instruction Register** (IR): contains the **most recent instruction** fetched
 - **Memory Address Register** (MAR): contains the address of the _region_ of memory for read/write purposes
-- **Memory Data Register** (MDR): contains **fetched data** from memory or **data ready to be written** to memory
+- **Memory Data Register** (MDR): contains **fetched data** from memory or **data ready to be written** to memory. The MDR is also sometimes referred to as the Memory Buffer Register (MBR).
 
 > Remember that the **Control Unit** is connected to all components
 
@@ -42,52 +39,50 @@ A typical instruction cycle may look something like this:
 | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
 | 1. Instruction Received from memory location in PC<br />2. Retrieved instruction stored in IR<br />3. PC incremented to point to next instruction in memory | 1. Opcode retrieved / instruction decoded<br />2. Read effective address to establish opcode type | 1. CU signals functional CPU components<br />2. Can result in changes to data registers, such as the PC etc.<br />3. PC incremented to point to next instruction in memory |
 
-
-
-## Registers
+# Registers
 
 Now that we have the FDE cycle established, we need **registers** to help store intermediate information- this can either be in the form of memory or system flags. The Motorola 68008 will be used to give context to each type of register:
 
 > You can think of a register as a parallel set of bits which can be toggled on or off.
 
-#### Data registers
+## Data registers
 - These are useful for storing **frequently used values** or **intermediate results** of calculations.
-- You typically **only need one** register **on chip**- however, the advantage of having many registers is that **fewer references to external memory are needed**.
+- You typically **only need one** data register **on chip** – however, the advantage of having many registers is that **fewer references to external memory are needed**.
 
 > The 68008 has 32 bit data registers. This is a _long_ register; 16 bits form a _word_, and 8 bits form a _byte_.
 
-#### Status registers
+## Status registers
 - These have various status bits that are set or reset by the **ALU**.
 - They are a _set of flags_:
   -  Half are for the **system** (CU)
   -  The **conditional control register** is a **subset of flags**
 
-| ⬅ System byte ➡ | ⬅ User byte ➡ |
-|-------------|-----------|
-| 8 bits | Several bits will make up the CCR |
+| ⬅ System byte ➡ |                 ⬅ User byte ➡                 |
+| :-------------: | :-------------------------------------------: |
+|     8 bits      | 8 bits, where a few bits will make up the CCR |
 
 > The CCR is made up of several bits representing statuses such as _extend, negative, zero, overflow, carry_. If you wanted to check the status of the computer in a program, you could use bitwise **AND** against a bitmask (the string of bits you want toggled) and seeing if the final result is the flag you wanted to see.
 
-#### Address register
+## Address register
 - These are used as **pointer registers** in the calculation of operand addresses.
 - Operations on these addresses **do not alter the CCR**.
-- The **ALU** has the capacity to incur changes in status (through operations on non-addresses).
+- Only the **ALU** has the capacity to incur changes in status (through operations on non-addresses).
 
-#### Stack pointer
+### Stack pointer
 - This is an **address register** that points to the **next free location**; it can hold **subroutine return addresses**.
 
 > The 68008 has pointer registers `A0-A6` whilst `A7` is used as a system stack pointer.
 
-#### Program counter
-We are already familiar with what the PC does- it is a **32 bit** register on the 68008 that keeps track of the address at which the next instruction will be found. 
+## Program counter
+We are already familiar with what the PC does – it is a **32 bit** register on the 68008 that keeps track of the address at which the next instruction will be found. 
 
 > If you were writing a software emulator, think of the memory as an array of strings (each string is an opcode). The PC would be an integer; your code would access `memory[PC]` to find out which opcode to pull from the memory and decode. Therefore, by incrementing the PC (an 8-bit, 16-bit, or 32-bit integer in your code) you can increment through the memory array. You can sometimes increment the PC by multiple amounts.
 > Generally speaking, if you were to be writing an emulator for any CPU, you _could_ represent each register as an n-bit unsigned integer as you can toggle bits and perform bitwise operations, including bitshifts, on each integer variable. You would typically want to implement memory as a simple array of m-bit integers, where m is the word length of your CPU.
 
-## Register Transfer Language
+# Register Transfer Language
 
 > RTL is used to describe the operations of the microprocessor as it is executing program instructions.
-> It is also a way of making sure we access the correct parts of the microprocessor- **do not confuse it with assembler instructions**.
+> It is also a way of making sure we access the correct parts of the microprocessor – **do not confuse it with assembler instructions**.
 
 | Example RTL | Meaning |
 |-------------|---------|
@@ -114,17 +109,25 @@ ALU ⬅ [MBR] + D0
 ```
 As you can see, RTL describes how we can specifically set values in registers and interact with components in a standardised language.
 
-## Assembly Language
+# Assembly Language
+
+You should be able to explain the motivations, applications, and characteristics of high-level and low-level programming languages.
+
+|                     High-level Language                      |                           Assembly                           |                Machine Code                |
+| :----------------------------------------------------------: | :----------------------------------------------------------: | :----------------------------------------: |
+| Human readable. Difficult to translate into performant machine code whilst retaining original intention. | Middle-ground. More readable than machine code but more precise than high-level languages. | Very precise and performant. Not readable. |
+
+![image-20210509115201462](part3.assets/image-20210509115201462.png)
 
 > Assembly language saves us from machine code by using **mnemonics**.
 > We can provide **memory locations** and **constants**, as well as **symbolic names**.
 > These features are not afforded to us by RTL!
 
 Assembly language typically takes the following form:
 
-| Label | Opcode | Operand | Comment |
-|-------|--------|---------|---------|
-| `START:` | `move.b` | `#5, D0` | load `D0` with `5` |
+|  | Label | Opcode | Operand | Comment |
+|:-----:|:------:|:-------:|:-------:|:-------:|
+| **Example** | `START:` | `move.b` | `#5, D0` | `|load D0 with 5` |
 
 ### Assembly Language Conventions
 
@@ -156,7 +159,7 @@ Previously, we saw how the `DS` directive requires a data type and then an amoun
 
 > You can typically omit the data type and `.` if you are working with a **word**.
 
-## Instruction set aspects
+# Instruction set aspects
 
 Generally speaking, there are two aspects to a CPU instruction set:
 - **Instructions** which tell the processor which operations to perform
@@ -181,7 +184,7 @@ These are crucial for **control flow statements**; we typically branch based on
 #### Subroutines
 Subroutines (`JSR`; jump, `RTS`; return)  let you use the **same code repeatedly**. You will **push and pop the stack** to return to the PC.
 
-## Addressing modes
+# Addressing modes
 As mentioned earlier, there are several ways for the CPU to access memory; you should be familiar with the following, and they are found on many CPUs (not just the 68008):
 
 | Address type | Definition | Example |