Computer Architecture and RISC-V

Unknown — Fri, 10 Apr 2026 00:00:00 +0000

Let's explore computer architecture and the structure of RISC-V CPUs.

The content of this post is based on POSTECH's CSED311 course,
supplemented with some additional topics not covered in class. </blockquote>

What is Architecture?</h1>

Computer architecture is the interface specification between hardware and software. Specifically, it defines the following aspects, centered around the Instruction Set Architecture (ISA) that the CPU understands:

Instructions: What operations (addition, branching, memory access, etc.) are supported and in what format they are expressed</li>
Registers: How many registers there are, how many bits each holds, and what each is used for</li>
Memory model: Address space size, byte order (endianness)</li>

Exception/Interrupt handling: How errors and external events are handled</li> </ul>

Architecture is an abstraction layer that remains the same regardless of the actual hardware implementation. As long as a compiler generates code conforming to this specification, the code will run on any chip that implements that architecture. Therefore, even if the manufacturers differ, users can run the same OS and applications as long as the architecture is the same. (Think of AMD and Intel x86-64 CPUs.)

On the other hand, microarchitecture is the internal design that implements the "contract" of an architecture in actual hardware. Optimizations and implementation details such as pipelines, out-of-order execution, and branch prediction fall under the microarchitecture.

Types of Architecture</h2>
The main types of computer architecture include von Neumann architecture, Harvard architecture, and dataflow architecture, among others.
Von Neumann Architecture</h3>
Von Neumann architecture is the fundamental computer structure proposed by John von Neumann, and it forms the foundation of nearly all general-purpose computers today. Computers before the von Neumann architecture (such as ENIAC) required physically rewiring to change programs.
At the time, Mauchly and Eckert, who developed ENIAC, conceived the idea of storing both programs and data in the same memory while designing the successor computer EDVAC. This approach had the advantage that simply loading a program into memory allowed different tasks to be performed with a single set of wiring. (Later, von Neumann distributed a report summarizing this idea as the sole author, which is how this structure came to be named the von Neumann architecture.)
The von Neumann architecture executes programs by having the CPU repeatedly fetch instructions from memory, decode them, and execute them. Since instructions and data share the same memory and the same data bus, no matter how fast the CPU is, performance is limited by memory bandwidth — this is known as the Von Neumann Bottleneck. For this reason, while modern CPUs are based on the von Neumann architecture, they do not use the traditional von Neumann structure as-is, but rather combine it appropriately with the Harvard architecture described below.
Harvard Architecture</h3>
Harvard architecture is an architecture that originated from Harvard University's Mark I computer around the same time as the von Neumann architecture. Since the Mark I read instructions from punched tape and data from mechanical counters separately, unlike the von Neumann architecture, it has a structure where instruction memory and data memory are physically completely separated.
The Harvard architecture separates the buses for instructions and data, allowing instructions and data to be read simultaneously, which provides higher throughput. However, the capacity between the two memories cannot be flexibly divided, and a separate mechanism is needed to transfer programs to instruction memory. In modern times, the Harvard architecture is used in some fields such as microcontrollers (like the AVR found in Arduino) and DSPs (Digital Signal Processors).
Modified Harvard Architecture</h3>
Modified Harvard architecture is a compromise between the von Neumann and Harvard architectures, adopted by most modern CPUs. At the L1 cache level, the I-cache and D-cache are separated to gain the benefit of high bandwidth from the Harvard architecture, while the memory below that level is unified to maintain the flexibility of the von Neumann architecture. From the CPU's perspective, since the L1 cache memory is separated into instruction and data portions, it operates like a Harvard architecture; but from the perspective of compilers and programmers, who do not directly manage the cache, the computer can be treated as having a single address space.
Dataflow Architecture</h3>
Dataflow architecture is a fundamentally different architectural paradigm from the Harvard or von Neumann architectures described above. In the von Neumann approach, a program counter sequentially specifies the "next instruction to execute." Dataflow architecture was designed to break free from the limitation of sequential instruction execution in the von Neumann approach, and it has no program counter. In a dataflow architecture, instructions execute immediately once all required data is ready, without a program counter sequentially specifying which instruction to perform. Rather than having the programmer or hardware determine the order of program execution, the data itself determines the flow of execution.
In a dataflow architecture, a program is represented not as a sequential list of instructions, but as a directed graph. When performing an operation like (a + b) * (c - d)</code>, the addition node and subtraction node have no dependency on each other, so they execute simultaneously. When the results of both operations arrive at the multiplication node, the multiplication operation fires. Even without the programmer explicitly specifying parallel operations, all operations are automatically executed in parallel.
The dataflow architecture, which first appeared in the 1970s, was actively researched as a next-generation computer in the 1980s-1990s, but failed to become commercially viable due to various limitations. The operations required for dataflow architecture were very expensive in hardware, there were difficulties in handling large-scale data structures, and all existing software infrastructure was written assuming a sequential execution model — these were compounding problems.
Pure dataflow computers have now disappeared, but the ideas continue to live on to the present day. The out-of-order execution (OoO) structure within the von Neumann model and circuit design in FPGAs carry on the design philosophy of dataflow architecture. Recently, AI accelerator processors have been reapplying dataflow principles to hardware, and although dataflow architecture was never commercialized as a general-purpose computing machine, research continues on using dataflow architecture in various special-purpose hardware.
ISA</h2> ISA stands for Instruction Set Architecture, and can be described as the interface between software and hardware. The ISA determines the following: What operations exist in the instruction set, and what the encoding format of each instruction is</li> What data types the hardware directly supports, and what the byte order is (little-endian, big-endian)</li> Register organization, including the number of registers, their bit widths, and their purposes</li> Addressing modes and how instructions specify the location of operands</li> The address space size of the memory model</li> Under what conditions (division by zero, page fault, illegal instruction) exceptions occur, and how interrupts are handled</li> Privilege levels, the distinction between protected mode/kernel mode, the range of registers and instructions accessible in each mode, and virtual memory-related aspects</li> </ul> On the other hand, the ISA does not specify matters related to the microarchitecture beneath it (clock speed, pipeline stages, cache structure, etc.) or software layer conventions (ABI, memory map, firmware interface). Programmer Visible State refers to all hardware state that a programmer (compiler) can directly read or write through instructions in the ISA. The semantics of a program are defined by changes to these states. Specifically, this includes general-purpose registers, the program counter, the stack pointer, flag registers, and the entire memory address space. Conversely, invisible state (microarchitectural state) includes cache contents, branch predictor history, reorder buffer, reservation station, physical register file, TLB entries, and so on. These only affect performance and do not change the logical results of a program. For any chip implementing the same ISA, as long as changes to the Programmer Visible State are identical, the implementation is correct, and all other internal state is free to differ. The instructions provided by an ISA can be classified by function as follows: Arithmetic/Logical: Performs operations on registers or immediate values. Results are typically stored in a register, and flags may be updated as a side effect.</li> Data Transfer/Memory: Moves data between registers and memory, or between registers.</li> Control Flow: Changes the program counter to alter the flow of execution. This includes unconditional jumps, conditional branches, function calls/returns, and so on.</li> System/Privileged: Instructions for OS or hardware control. This includes entering the kernel from user mode, interrupt control, and so on. In modern microprocessors, most such instructions can only be executed in kernel mode, and executing them in user mode causes an exception.</li> </ul> These instructions must be executed atomically. A single instruction may change multiple Programmer Visible States, but these intermediate changes must not be exposed to the programmer. In actual hardware, instructions may be processed in stages within a pipeline — writing to a register first and updating the PC later — but this is microarchitectural state, not Programmer Visible State. History of the ISA</h2> EDSAC</h3> EDSAC was one of the first stored-program computers and had a very simple ISA. An instruction consisted of a 5-bit opcode + a reserved bit + a 10-bit memory address (n), using a single accumulator structure. There was only one register, the Acc, and all operations revolved around this Acc register. Examples of instructions include: A n: Adds M[n]</code> to ACC</code></li> T n: Moves the contents of ACC</code> to M[n]</code> and clears ACC</li> E n: If ACC>=0</code>, jumps to M[n]</code></li> I n: Reads the next character from tape and stores it at the address pointed to by M[n]</code></li> Z : Halts the program and rings the bell</li> </ul> A notable characteristic is that all memory addresses are hardcoded in instructions. However, this leads to the following problems: When executing a function in code, the function must return to the call site. However, since EDSAC has return addresses hardcoded in instructions, it was difficult to specify the return address when calling the same function from multiple locations.</li> When accessing array elements, since array addresses are hardcoded in instructions, iterating through an array in a loop required modifying the instruction itself each time to change the address.</li> </ol> Evolution of the ISA</h3> To solve these problems, subsequent CPUs evolved in various ways. First, register architecture evolved from using only a single accumulator register to adding registers for program address specification, and in the modern era, multiple general-purpose registers (GPR, General Purpose Register) have been added so that any register can be used for any purpose. Second, instructions gained the ability to specify various operands. A structure like EDSAC where an instruction has an implicit operand (ACC) and only one explicit operand is called Monadic; a structure like OP inout, in2</code> where there are 2 operands and one of the inputs is overwritten with the result is called Dyadic; and a structure like OP out, in1, in2</code> that explicitly specifies both the output and two inputs is called Triadic. In CISC architectures described below, a single instruction like ADD [mem], reg</code> can perform both memory access and computation simultaneously, whereas RISC architectures restrict memory access to load/store instructions only. (load-store architecture) Third, instructions gained the ability to specify various memory addresses. Absolute - LD rt, 100</code>: The address is specified as a constant in the instruction, like EDSAC.</li> Register Indirect - LD rt, (r_base)</code>: Uses the value in a register as the address. Pointer dereferencing works this way.</li> Displaced - LD rt, offset(r_base)</code>: Creates an address by adding a constant offset to the register value. Useful for struct access.</li> Indexed - LD rt, (r_base, r_index)</code>: Creates an address by adding two register values.</li> Memory Indirect - LD rt, ((r_base))</code>: Reads a value from a memory address and uses that value as an address again. This corresponds to double pointer dereferencing.</li> Auto increment/decrement - LDR rt, (r_base)</code>: Uses the register value as an address, but automatically increments/decrements the register value before or after access. Useful for sequentially traversing arrays.</li> </ul> The Emergence of RISC</h3> Early CPU development progressed by making the initially simple ISA increasingly complex, adding various features to the instruction set. At the time, programming directly in assembly was common, and adding diverse instructions could simplify the programmer's coding work. Additionally, since memory size and performance were limited, it was useful to process frequently-used complex operations in a single step. However, as compiler technology advanced, cases where programmers directly used complex assembly instructions became rare. The complex instructions designed for human use were difficult for compilers to optimize, and since execution time and memory access counts varied wildly between instructions, it was also difficult to design efficient pipelines. Against this backdrop, RISC (Reduced Instruction Set Computer) emerged. RISC CPUs were built with the philosophy of keeping the instruction set simple — all instructions the same size, memory access only through designated instructions, simple individual instructions but with a generous number of registers. RISC shifted complexity from hardware to the compiler, making the hardware simple while delegating optimization burden to the now-advanced compilers. RISC made pipelines easier to build and was advantageous for increasing clock speeds. Since the hardware was simple, transistors could be invested in areas that help performance such as caches and branch predictors, and verification, debugging, and design cycles were shorter. In contrast to RISC, pre-RISC architectures (x86, M68K, Z80, etc.) are called CISC (Complex Instruction Set Computer). While many CISC architectures like M68K and Z80 disappeared, x86 survived due to its massive software ecosystem. Instead, it adopted a compromise of maintaining a CISC external ISA while internally being RISC, introducing a design where complex instructions are decomposed into RISC operations internally within the CPU. A leading representative of modern RISC architectures is ARM. ARM initially penetrated the emerging mobile market quickly, leveraging high performance-per-watt through simple design. Until the 2020s, RISC architectures were used in low-power designs such as mobile and embedded systems, while CISC architectures were used in workstation, desktop, and server environments that required high performance at the cost of higher power consumption. However, this situation was largely reversed after Apple Silicon released the M1 chip in the 2020s. Apple's M1 and other ARM CPUs, as RISC architecture-based CPUs, have been rapidly growing market share with high performance and improved performance-per-watt compared to CISC CPUs. Beyond Apple, ARM-based Windows/Linux laptops are now being sold, and RISC architectures are gradually expanding their share beyond the mobile market. RISC-V</h1> RISC-V is an open-source ISA that started at UC Berkeley in 2010. It was designed from scratch as a clean RISC ISA without legacy, incorporating lessons learned over the past 30 years since RISC-I and RISC-II, the first RISC processors designed in 1981. (The V stands for the fifth RISC design developed at Berkeley: RISC-I, RISC-II, SOAR, SPUR, RISC-V.) Unlike ARM and x86 which are tied to specific companies, anyone can freely build processors implementing the RISC-V ISA, and startups, universities, and large corporations can all freely design chips. Additionally, it was developed using a modular design — rather than a single monolithic ISA, it has a small ISA with a minimal set of instructions to which necessary extensions are attached. Programmer Visible State of RISC-V</h2> RISC-V has 32 integer general-purpose registers by default, from x0 to x31. x0 is always fixed at 0, because fixing x0 to 0 allows various operations to be expressed using existing instructions, thereby reducing the number of instruction types needed. (For example, NOP can be expressed as ADDI x0, x0, 0</code>, and loading an immediate value as ADDI x1, x0, 42</code>.) Additionally, there is a PC register that is not included in the general-purpose registers, as well as floating-point registers included in the F/D extensions that provide floating-point operations. Memory uses byte addressing, and is little-endian by default. Every byte of memory is Programmer Visible State, and little-endian alignment is used by default. RISC-V Extension System</h2> RISC-V has a structure where necessary extensions are combined with a small base ISA. The base ISAs are as follows: RV32I: 32-bit integer base. Contains only the minimal instructions for integer arithmetic/logic, load/store, etc.</li> RV64I: 64-bit integer base. Adds 64-bit operations and doubleword instructions to RV32I.</li> RV128I: 128-bit integer base. However, since it is still unclear when an address space larger than 64 bits would be needed, the specification has not been fully frozen yet.</li> RV32E, RV64E: Reduced ISA for embedded use, cutting registers from 32 to 16 to lower the cost of ultra-small microcontrollers.</li> </ul> The following standard extensions exist: M: Integer multiplication and division: Adds native integer multiplication instructions such as MUL</code>, MULH</code> using a hardware multiplier. On ultra-small embedded devices, multiplication and division can be replaced with other operations like bit manipulation without hardware multiplication, which is why multiplication and division are in a separate extension.</li> A: Atomic operations: Instructions for inter-core memory sharing in multi-core environments. Defines functionality for atomically performing reads and writes to memory, reserving memory, etc.</li> F: 32-bit floating-point operations: Adds hardware floating-point operations via the FPU. Adds 32 floating-point registers f0-f31 and the fcsr flag that records the results of floating-point operations.</li> D, Q: Add 64-bit double-precision floating-point and 128-bit quadruple-precision floating-point operation instructions, respectively.</li> C: Enables encoding of frequently used instructions in 16 bits. This can reduce code size, making it useful in embedded environments where flash memory size is severely constrained.</li> V: Vector extension. Supports various vector operations similar to SIMD.</li> H: Hypervisor extension. Supports the virtualization layer provided by hypervisors.</li> </ul> In addition to single-letter extensions, there are also more fine-grained extensions prefixed with Z: Zicsr: CSR access instructions</li> Zifencei: Instruction cache synchronization, ensures I-Cache and D-Cache coherence for self-modifying code and JIT compilation</li> Zba, Zbb, Zbc, Zbs: Address computation acceleration, basic bit manipulation, carry-less multiplication, and other detailed bit manipulation instructions</li> Zfinx: Performs floating-point operations in integer registers</li> Ztso: Guarantees Total Store Ordering memory model. Useful for x86 binary translation</li> Zicond: Conditional operations. Conditionally selects values without branching</li> </ul> Because there are so many extensions, RISC-V profiles exist that bundle frequently used extensions for software compatibility. For example, RVA20U64 is defined to mandatorily include the I, M, A, F, D, C, Zicsr, and Zifencei extensions. RISC-V Instruction Formats</h2> RISC-V defines 6 basic instruction formats. In RV32I, all are 32 bits of fixed length, and the positions of opcode, rd, rs1, and rs2 are arranged as consistently as possible across formats to simplify decoding. R-Type</h3> Used for register-to-register operations. [31:25] [24:20] [19:15] [14:12] [11:7] [6:0] funct7 rs2 rs1 funct3 rd opcode 7 bits 5 bits 5 bits 3 bits 5 bits 7 bits</code></pre> Operates on two source registers rs1 and rs2, and stores the result in rd. funct7</code> and funct3</code> distinguish the specific type of operation. Example: ADD x1, x2, x3</code>: x1 <- x2 + x3 I-Type</h3> Used for immediate value operations, loads, JALR, etc. [31:20] [19:15] [14:12] [11:7] [6:0] imm[11:0] rs1 funct3 rd opcode 12 bits 5 bits 3 bits 5 bits 7 bits</code></pre> The 12-bit immediate value is sign-extended before use. This is the R-type format with the funct7</code> and rs2</code> fields replaced by the immediate value. Example: ADDI x1, x2, 10</code>: x1 <- x2 + 10 Since funct7</code> is absent compared to R-type, there are some instruction differences. For example, ADD/SUB which are distinguished by funct7</code> in R-type — in I-type, SUB is unnecessary since negative immediate values can be used instead, and there are cases where the immediate field is split to distinguish sub-instructions. (In RV32I, shift instructions like SLLI, SRLI, and SRAI, which need at most 5 bits for the immediate value, use the upper 7 bits as an instruction specifier and the remaining 5 bits as the shift immediate value.) Load instructions that fetch values from memory are also I-Type, with 0000011</code> in the opcode</code> field to indicate a Load, rs1</code> as the base, and the 12-bit imm</code> as the offset. Depending on funct3</code>, these are distinguished into LW</code> which reads 32 bits, LH</code> which reads 16 bits with sign extension, LHU</code> which reads 16 bits with zero extension, LB</code> which reads 8 bits, LBU</code>, and so on. Also, immediate values are always limited to 12 bits. Immediate values used in programs are typically small values, and cases requiring large constants are usually rare, so this is an intentional design for optimization. When large constants are absolutely necessary, they can be constructed using U-type instructions or AUIPC, described below. This follows the RISC philosophy of not trying to do everything with a single instruction, but instead solving problems with combinations of simple instructions. S-Type</h3> Used for storing values to memory. [31:25] [24:20] [19:15] [14:12] [11:7] [6:0] imm[11:5] rs2 rs1 funct3 imm[4:0] opcode 7 bits 5 bits 5 bits 3 bits 5 bits 7 bits</code></pre> Since results are not written to a register, there is no rd</code>; instead, the lower bits of the immediate go in the rd</code> position, and the upper bits of the immediate go in the funct7</code> position. Example: SW x3, 12(x2)</code>: MEM[x2 + 12]</code> <- x3 B-Type (SB-Type)</h3> Used for conditional branches. [31] [30:25] [24:20] [19:15] [14:12] [11:8] [7] [6:0] imm[12] imm[10:5] rs2 rs1 funct3 imm[4:1] imm[11] opcode 1 bit 6 bits 5 bits 5 bits 3 bits 4 bits 1 bit 7 bits</code></pre> Similar to S-Type, but with a different immediate bit arrangement. The immediate is used as a branch offset, and since RISC-V instructions are aligned to at least 16-bit boundaries, the least significant bit of the branch offset is always 0 and is not encoded. Therefore, a branch range of 13 bits is possible. Example: BEQ x1, x2, offset</code>: If x1 == x2</code>, then PC <- PC + offset The reason the bit arrangement is peculiarly scrambled is to share as many bit positions as possible with S-type to simplify hardware. Due to this similarity with S-Type, B-Type is also sometimes called SB-Type. U-Type</h3> Instructions that use a 20-bit upper immediate value. [31:12] [11:7] [6:0] imm[31:12] rd opcode 20 bits 5 bits 7 bits</code></pre> The 20-bit immediate is placed in the upper 20 bits, and the lower 12 bits are filled with 0. Since I-Type instructions can use immediate values of up to 12 bits, this instruction was created to complement that limitation. LUI (Load Upper Immediate): rd <- imm << 12, used in combination with ADDI to create large constants. To create 0x12345678</code>, LUI x1, 0x12345</code> fills the upper 20 bits, and ADDI x1, x1, 0x678</code> fills the lower 12 bits.</li> AUIPC (Add Upper Immediate to PC): rd <- PC + (imm << 12), used for PC-relative address calculation, and can create addresses within a +/-2GB range from the current position when combined with JAL and load.</li> </ul> J-Type (UJ-Type)</h3> Used for unconditional jumps. [31] [30:21] [20] [19:12] [11:7] [6:0] imm[20] imm[10:1] imm[11] imm[19:12] rd opcode 1 bit 10 bits 1 bit 8 bits 5 bits 7 bits</code></pre> Uses a 20-bit immediate as a jump offset, and like B-Type, bit 0 is always 0 so it is not encoded. Therefore, a jump range of 21 bits (+/-1MB) is possible. Similar to B-Type, it is designed to share as many bit positions as possible with U-Type. Hence it is also sometimes called UJ-Type. RV32I Instruction Set</h2> Integer Arithmetic/Logic (R-type)</h3> Instruction</th> Operation</th> Description</th></tr></thead> ADD rd, rs1, rs2</code></td> rd <- rs1 + rs2</code></td> Addition</td></tr> SUB rd, rs1, rs2</code></td> rd <- rs1 - rs2</code></td> Subtraction</td></tr> AND rd, rs1, rs2</code></td> rd <- rs1 & rs2</code></td> Bitwise AND</td></tr> OR rd, rs1, rs2</code></td> rd <- rs1 | rs2</code></td> Bitwise OR</td></tr> XOR rd, rs1, rs2</code></td> rd <- rs1 ^ rs2</code></td> Bitwise XOR</td></tr> SLL rd, rs1, rs2</code></td> rd <- rs1 << rs2[4:0]</code></td> Logical left shift</td></tr> SRL rd, rs1, rs2</code></td> rd <- rs1 >> rs2[4:0]</code></td> Logical right shift (zero-fill)</td></tr> SRA rd, rs1, rs2</code></td> rd <- rs1 >>> rs2[4:0]</code></td> Arithmetic right shift (sign-preserving)</td></tr> SLT rd, rs1, rs2</code></td> rd <- (rs1 < rs2) ? 1 : 0</code></td> Signed comparison</td></tr> SLTU rd, rs1, rs2</code></td> rd <- (rs1 < rs2) ? 1 : 0</code></td> Unsigned comparison</td></tr> </tbody></table> Immediate Arithmetic/Logic (I-type)</h3> Instruction</th> Operation</th> Description</th></tr></thead> ADDI rd, rs1, imm</code></td> rd <- rs1 + sext(imm)</code></td> Immediate addition</td></tr> ANDI rd, rs1, imm</code></td> rd <- rs1 & sext(imm)</code></td> Immediate AND</td></tr> ORI rd, rs1, imm</code></td> rd <- rs1 | sext(imm)</code></td> Immediate OR</td></tr> XORI rd, rs1, imm</code></td> rd <- rs1 ^ sext(imm)</code></td> Immediate XOR</td></tr> SLLI rd, rs1, shamt</code></td> rd <- rs1 << shamt</code></td> Immediate logical left shift</td></tr> SRLI rd, rs1, shamt</code></td> rd <- rs1 >> shamt</code></td> Immediate logical right shift</td></tr> SRAI rd, rs1, shamt</code></td> rd <- rs1 >>> shamt</code></td> Immediate arithmetic right shift</td></tr> SLTI rd, rs1, imm</code></td> rd <- (rs1 < sext(imm)) ? 1 : 0</code></td> Immediate signed comparison</td></tr> SLTIU rd, rs1, imm</code></td> rd <- (rs1 < sext(imm)) ? 1 : 0</code></td> Immediate unsigned comparison</td></tr> </tbody></table> Upper Immediate (U-type)</h3> Instruction</th> Operation</th> Description</th></tr></thead> LUI rd, imm</code></td> rd <- imm << 12</code></td> Load upper 20 bits</td></tr> AUIPC rd, imm</code></td> rd <- PC + (imm << 12)</code></td> Add upper 20 bits relative to PC</td></tr> </tbody></table> Load (I-type)</h3> Instruction</th> funct3</th> Operation</th> Description</th></tr></thead> LB rd, imm(rs1)</code></td> 000</code></td> rd <- sext(MEM8[rs1 + sext(imm)])</code></td> Load byte (sign extension)</td></tr> LH rd, imm(rs1)</code></td> 001</code></td> rd <- sext(MEM16[rs1 + sext(imm)])</code></td> Load halfword (sign extension)</td></tr> LW rd, imm(rs1)</code></td> 010</code></td> rd <- MEM32[rs1 + sext(imm)]</code></td> Load word</td></tr> LBU rd, imm(rs1)</code></td> 100</code></td> rd <- zext(MEM8[rs1 + sext(imm)])</code></td> Load byte (zero extension)</td></tr> LHU rd, imm(rs1)</code></td> 101</code></td> rd <- zext(MEM16[rs1 + sext(imm)])</code></td> Load halfword (zero extension)</td></tr> </tbody></table> Store (S-type)</h3> Instruction</th> funct3</th> Operation</th> Description</th></tr></thead> SB rs2, imm(rs1)</code></td> 000</code></td> MEM8[rs1 + sext(imm)] <- rs2[7:0]</code></td> Store byte</td></tr> SH rs2, imm(rs1)</code></td> 001</code></td> MEM16[rs1 + sext(imm)] <- rs2[15:0]</code></td> Store halfword</td></tr> SW rs2, imm(rs1)</code></td> 010</code></td> MEM32[rs1 + sext(imm)] <- rs2</code></td> Store word</td></tr> </tbody></table> Conditional Branches (B-type)</h3> Instruction</th> funct3</th> Operation</th> Description</th></tr></thead> BEQ rs1, rs2, offset</code></td> 000</code></td> if (rs1 == rs2) PC <- PC + offset</code></td> Branch if equal</td></tr> BNE rs1, rs2, offset</code></td> 001</code></td> if (rs1 != rs2) PC <- PC + offset</code></td> Branch if not equal</td></tr> BLT rs1, rs2, offset</code></td> 100</code></td> if (rs1 < rs2) PC <- PC + offset</code></td> Signed less than</td></tr> BGE rs1, rs2, offset</code></td> 101</code></td> if (rs1 >= rs2) PC <- PC + offset</code></td> Signed greater than or equal</td></tr> BLTU rs1, rs2, offset</code></td> 110</code></td> if (rs1 < rs2) PC <- PC + offset</code></td> Unsigned less than</td></tr> BGEU rs1, rs2, offset</code></td> 111</code></td> if (rs1 >= rs2) PC <- PC + offset</code></td> Unsigned greater than or equal</td></tr> </tbody></table> Jumps</h3> Instruction</th> Type</th> Operation</th> Description</th></tr></thead> JAL rd, offset</code></td> J-type</td> rd <- PC+4, PC <- PC + offset</code></td> Direct jump (function call)</td></tr> JALR rd, rs1, imm</code></td> I-type</td> rd <- PC+4, PC <- (rs1 + sext(imm)) & ~1</code></td> Indirect jump (function return, etc.)</td></tr> </tbody></table> Memory Ordering</h3> Instruction</th> Description</th></tr></thead> FENCE pred, succ</code></td> Ensures memory access ordering (pred/succ: combinations of I, O, R, W)</td></tr> </tbody></table> System Instructions</h3> Instruction</th> Operation</th> Description</th></tr></thead> ECALL</code></td> Generates environment call trap</td> System call (OS entry)</td></tr> EBREAK</code></td> Generates debug trap</td> Breakpoint</td></tr> </tbody></table> Previously, the Zicsr</code> and Zifencei</code> extensions were included in RV32I, but they were separated into independent extensions in version 2.1, so currently a total of 40 instructions constitute RV32I. RISC-V ABI Conventions</h2> Register Conventions</h3> These are recommended register usage conventions for all systems, though they are not enforced at the ISA level. Only x0 = 0</code> is the sole constraint enforced by the ISA; all other registers are equivalent from a hardware perspective. In practice, adherence to these conventions is the role of the ABI and calling convention. However, since most compilers, operating systems, and debuggers follow these conventions, they should be adhered to except in very special cases such as bare-metal embedded environments that do not use any external libraries. Register</th> ABI Name</th> Purpose</th> Caller/Callee Saved</th></tr></thead> x0</code></td> zero</code></td> Always 0 (fixed at ISA level)</td> --</td></tr> x1</code></td> ra</code></td> Return Address</td> Caller</td></tr> x2</code></td> sp</code></td> Stack Pointer</td> Callee</td></tr> x3</code></td> gp</code></td> Global Pointer</td> --</td></tr> x4</code></td> tp</code></td> Thread Pointer</td> --</td></tr> x5</code></td> t0</code></td> Temporary register</td> Caller</td></tr> x6</code></td> t1</code></td> Temporary register</td> Caller</td></tr> x7</code></td> t2</code></td> Temporary register</td> Caller</td></tr> x8</code></td> s0</code> / fp</code></td> Saved register / Frame Pointer</td> Callee</td></tr> x9</code></td> s1</code></td> Saved register</td> Callee</td></tr> x10</code></td> a0</code></td> Function argument 1 / Return value 1</td> Caller</td></tr> x11</code></td> a1</code></td> Function argument 2 / Return value 2</td> Caller</td></tr> x12</code></td> a2</code></td> Function argument 3</td> Caller</td></tr> x13</code></td> a3</code></td> Function argument 4</td> Caller</td></tr> x14</code></td> a4</code></td> Function argument 5</td> Caller</td></tr> x15</code></td> a5</code></td> Function argument 6</td> Caller</td></tr> x16</code></td> a6</code></td> Function argument 7</td> Caller</td></tr> x17</code></td> a7</code></td> Function argument 8</td> Caller</td></tr> x18</code></td> s2</code></td> Saved register</td> Callee</td></tr> x19</code></td> s3</code></td> Saved register</td> Callee</td></tr> x20</code></td> s4</code></td> Saved register</td> Callee</td></tr> x21</code></td> s5</code></td> Saved register</td> Callee</td></tr> x22</code></td> s6</code></td> Saved register</td> Callee</td></tr> x23</code></td> s7</code></td> Saved register</td> Callee</td></tr> x24</code></td> s8</code></td> Saved register</td> Callee</td></tr> x25</code></td> s9</code></td> Saved register</td> Callee</td></tr> x26</code></td> s10</code></td> Saved register</td> Callee</td></tr> x27</code></td> s11</code></td> Saved register</td> Callee</td></tr> x28</code></td> t3</code></td> Temporary register</td> Caller</td></tr> x29</code></td> t4</code></td> Temporary register</td> Caller</td></tr> x30</code></td> t5</code></td> Temporary register</td> Caller</td></tr> x31</code></td> t6</code></td> Temporary register</td> Caller</td></tr> </tbody></table> Tree Rerooting (All-Direction Tree DP) Unknown — Fri, 12 Apr 2024 00:00:00 +0000 I looked into Tree DP — specifically All-Direction Tree (全方位木) DP — after seeing it used in AtCoder ABC #348</a>'s E - Minimize Sum of Distance</a>. This algorithm is called Rerooting outside of Japan, and is a useful technique for finding the optimal root in an unrooted tree. In Korea it's treated as a subcategory of dynamic programming on trees, but abroad it seems to appear frequently enough in competitive programming to have its own name. Concept</h2> Tree DFS</h3> First, let's think about how to find the total edge cost to all other nodes from a specific node. This can be implemented in $O(n)$ using DFS+DP. Rerooting</h3> So how can we find the node with the smallest total edge cost to all other nodes? We could use the tree DFS described above for each node, but that would take $O(n^2)$ and would time out once the number of vertices exceeds $10^5$. This is exactly when we use the rerooting technique. It exploits the fact that moving the root of a DFS+DP tree can be done in $O(1)$. In the figure above, let's calculate B's total distance sum using A's total distance sum of 30. The distances from A and the nodes beyond it — A(0), C(3), F(7) — increase by the cost of the A-B edge (5), becoming A(5), C(8), F(12). The distances from B and the nodes below it — B(5), D(8), E(7) — decrease by the A-B edge cost (5), becoming B(0), D(3), E(2). Since A's increase and B's decrease cancel out: (A's total distance) - {(nodes beyond A) - (nodes below B)} * (A-B edge cost)}</code> gives us B's total distance sum. Using this method, when we know A's total distance sum, we can compute B's total distance sum in $O(1)$. If you think of this as moving the root, it's the rerooting technique; if you think of it as running DFS searching in both directions, it's called all-direction tree DP. As with most algorithms, the name doesn't really matter. The number of nodes beyond A and below B can be obtained by storing the count of subnodes during the initial DFS that computes A's total distance sum. In the example above, A's subnode count</code> - B's subnode count</code> gives the number of nodes beyond A, and B's subnode count</code> directly gives the number of nodes below B. Examples</h2> BOJ 27730 : Gyeonwoo and Jiknyeo</a></h3> A problem where the above example can be applied directly. Run it on two trees and output the node with the smallest distance sum from both sides. BOJ 7812 : Central Tree</a></h3> Find the central node using rerooting, then run DFS again to output distances from all nodes. ABC#348 E</a></h3> This is the problem where I first learned about the rerooting technique. Instead of edge costs, vertex costs are given. That is, (number of edges needed to reach a vertex) * (vertex cost)</code> becomes the edge cost. This problem can be solved by keeping track of both the vertex cost sum c[x]</code> and the distance sum c[x]*d</code>. The solution code is below, and please refer to the editorial</a> for the explanation. #include <bits/stdc++.h> using namespace std; #define llint long long int int main() { int n; cin >> n; vector<int> a(n - 1), b(n - 1); vector<vector<int>> tree(n); for (int i = 0; i < n - 1; i++) { cin >> a[i] >> b[i]; a[i] -= 1; b[i] -= 1; tree[a[i]].push_back(b[i]); tree[b[i]].push_back(a[i]); } vector<llint> c(n); for (int i = 0; i < n; i++) cin >> c[i]; vector<llint> sub_sum_c(n), sub_sum_d(n); auto dfs =[&](auto &&self, int v, int par) -> pair<llint, llint> { for (int t: tree[v]) { if (t == par) continue; auto [child_sum_c, child_sum_d] = self(self, t, v); sub_sum_c[v] += child_sum_c; sub_sum_d[v] += child_sum_d; } sub_sum_d[v] += sub_sum_c[v]; sub_sum_c[v] += c[v]; return {sub_sum_c[v], sub_sum_d[v]}; }; dfs(dfs, 0, -1); vector<llint> f(n); auto reroot =[&](auto &&self, int v, int par, llint par_sum_c, llint par_sum_d) -> void { f[v] = sub_sum_d[v] + par_sum_d; for(int t : tree[v]) { if(t == par) continue; llint nc = par_sum_c + sub_sum_c[v] - sub_sum_c[t]; llint nd = par_sum_d + sub_sum_d[v] - sub_sum_d[t] - sub_sum_c[t] + nc; self(self, t, v, nc, nd); } }; reroot(reroot, 0, -1, 0, 0); cout << *min_element(f.begin(), f.end()) << endl; }</code></pre>See Also</h2> Codeforces - Rerooting Technique</a></li> nicotina04 - Rerooting Technique on Tree</a></li> Codeforces - Online Query Based Rerooting Technique</a></li> </ul> Building a Linux Lab Environment with Docker Unknown — Tue, 29 Aug 2023 00:00:00 +0000 I was tasked with giving a Linux seminar to junior members of our club. That means I need to set up a lab environment. Two years ago, the seniors told everyone to install VirtualBox. Last year, I ran the seminar myself and gave each junior an account on my Linux server. This year, my Linux and virtualization knowledge has grown a lot, and I've cleanly rebuilt my server</a>, so I decided to use virtualization to give everyone their own server. Googling</h3> Originally I was trying to open multiple containers and set up SSH reverse proxies or jump forwarding, but it was harder than expected. While struggling, I found this post: Replicate and Isolating user environments on the fly</a> This was exactly what I wanted, so I decided to modify it to fit my environment. Creating the Image</h3> The post above went through the process of modifying a container and turning it back into an image, but that's too tedious, so I decided to use a Dockerfile. # Dockerfile FROM ubuntu:latest RUN apt-get update RUN apt-get install -y vim sudo man-db gcc RUN yes | unminimize RUN useradd -ms /bin/bash guest RUN echo 'guest:password' | chpasswd RUN usermod -a -G sudo guest USER guest WORKDIR /home/guest</code></pre> Install the packages needed for the lab: vim</code>, sudo</code>, man-db</code>, gcc</code>, and run unminimize</code> to make man</code> work. Then create a user called guest so that when you connect to the container, you log in as a user rather than root. This gives a more similar feel to SSH-ing directly into a server. docker build --tag sandbox .</code></pre> Build the image with this command. Creating the User</h3> Now create a user so that when they connect via SSH, they enter a fake shell. mkdir /home/guest cat > /home/guest/sandbox <<EOF #!/bin/sh exec docker run -t -i --rm=true sandbox /bin/bash EOF chmod +x /home/guest/sandbox # useradd guest -g docker -s /home/guest/sandbox useradd guest -s /home/guest/sandbox chown guest /home/guest passwd guest</code></pre> Since I'm using Podman rather than Docker, I didn't need to give the user the docker</code> group to run Rootless Podman</a>. If you're using Docker, you'll need to add the docker</code> group. The --rm=true</code> argument on the docker</code> command ensures the container is deleted immediately when you exit, and the fake shell launches Docker when the user logs in. Complete</h3> With the above setup, when you SSH in as the guest</code> user, you get trapped in a temporarily created container. (The username differs from what's shown on the blog.) In this environment, you can install as many packages as you want or modify the system (as long as it's not kernel-related), and even running sudo rm -rf /</code> won't affect the host system running the container. When you log out and log back in, everything is reset and a new container is created — a great environment for practice. sudo rm -rf --no-preserve-root /</code></pre> Try running this and see that the system doesn't break. 2024.07.15 Update</h3> With the container setup above, there are issues where the container sometimes doesn't get properly deleted on logout, and a Refreshing Error occurs on login. ERRO[0001] Refreshing container 2e3d121a75ec00add6a35694cdc26e6442bb98a7e993b918569dd7584597bca6: acquiring lock 0 for container 2e3d121a75ec00add6a35694cdc26e6442bb98a7e993b918569dd7584597bca6: file exists</code></pre> For the container not being deleted on logout, I added docker stop sandbox</code> to the guest</code> account's .bash_logout</code> file — I'm not 100% sure but it seems to have fixed it. The error seems to be resolved by enabling lingering mode for the account with loginctl enable-linger guest</code>.

zlfn.space

Computer Architecture and RISC-V

RV32I Instruction Set</h2>

Tree Rerooting (All-Direction Tree DP)

Tree DFS</h3>
First, let's think about how to find the total edge cost to all other nodes</strong> from a specific node. This can be implemented in $O(n)$ using DFS+DP. </p>

See Also</h2>

Codeforces - Rerooting Technique</a></li>
nicotina04 - Rerooting Technique on Tree</a></li>
Codeforces - Online Query Based Rerooting Technique</a></li> </ul>

Building a Linux Lab Environment with Docker

zlfn.space

Computer Architecture and RISC-V

RV32I Instruction Set</h2>

Tree Rerooting (All-Direction Tree DP)

Tree DFS</h3> First, let's think about how to find the total edge cost to all other nodes</strong> from a specific node. This can be implemented in $O(n)$ using DFS+DP. </p>

Building a Linux Lab Environment with Docker

Tree DFS</h3>
First, let's think about how to find the total edge cost to all other nodes</strong> from a specific node. This can be implemented in $O(n)$ using DFS+DP. </p>