112 年 國立成功大學人工智慧科技碩士學位學程《計算機組織與系統（計算機組織及作業系統）》

核心觀念

本題考查作業系統中的存取控制機制與安全保護模型（Access Control and Protection Models），特別是 UNIX/Linux 家族系統（如 Android）、Apple iOS/macOS 的安全架構，以及自主存取控制（DAC）、強制存取控制（MAC）與基於角色的存取控制（RBAC）的比較。

1. 自主存取控制（Discretionary Access Control, DAC）：由資源擁有者自行決定權限。在傳統 UNIX/Linux 中，root（超級使用者）擁有最高權限，可任意修改存取規則。
2. 強制存取控制（Mandatory Access Control, MAC）：由系統全域的安全策略（Security Policy）統一強制規範，資源擁有者（包含 root 使用者）無法隨意繞過或修改策略檔案（除非透過特定的策略編譯工具與策略載入權限）。Android 採用 SELinux / SEAndroid 作為 MAC 機制。
3. 基於角色的存取控制（Role-Based Access Control, RBAC）：依據使用者的角色賦予最小必要權限，旨在限制並降低過度集中的超級使用者（superuser/root）權限風險。
4. 權限／資格證明（Entitlements & Capability-based Protection）：Apple 系統（iOS/macOS）使用簽署的 Entitlements 限制 App 能存取的系統 API 與硬體資源（如相機、麥克風、沙盒外檔案），此機制本質上屬於 Capability-based Protection 的延伸應用。

解題方法

逐一檢視各選項的敘述是否符合作業系統安全架構的標準原理：

1. 評估 Android 的使用者隔離機制：Android 將每個安裝的 App 分配獨立的 UID（User ID），利用 UNIX 原生的多使用者權限隔離 App（沙盒機制），因此「無法分離使用者」之敘述為誤。
2. 評估 MAC 的強制性：MAC 的核心定義就是「即使是 root 使用者也必須受限於系統安全策略」，root 無法隨意透過一般權限修改 MAC 規則（除非有載入策略的特權，但在嚴格的 MAC 設計中連 root 的行為都會被限制）。
3. 評估 RBAC 對安全風險的影響：RBAC 是為了落實「最小權限原則（Least Privilege）」，從而降低（而非增加）超級使用者帶來的安全風險。

核心觀念

本題考查作業系統（Operating System, OS）中的檔案系統觀念（File-System Concepts），包含以下核心重點：

1. 磁碟分區與檔案系統（Disk Partitions & File Systems）：一個實體磁碟可劃分為多個分區（Partitions），各分區可格式化為不同的檔案系統（如 FAT32, NTFS, ext4 等）。
2. 網路檔案系統與遠端程序呼叫（NFS & RPC）：NFS（Network File System）的底層架構依賴 RPC（Remote Procedure Call）來實現跨網路的遠端檔案操作。
3. Session 語意（Session Semantics）：分散式檔案系統中的檔案共享語意之一。當開啟檔案建立 session 後，對檔案的修改僅會在檔案關閉（session 結束）時對「後續開啟的新 session」可見，而「已在進行中的舊 session」不會看到這些修改。
4. 檔案系統掛載（File System Mounting）：檔案系統必須先掛載（Mount）到作業系統的目錄樹（Directory Tree）中，作業系統才能辨識並開啟該檔案系統內部的檔案與目錄結構。未掛載（Unmounted）的檔案系統無法直接進行檔案存取。

解題方法

本題為單選題，目標是找出敘述**錯誤（False）**的選項。切入點為逐一檢驗作業系統對於磁碟管理、分散式檔案系統（NFS/Session Semantics）與檔案系統掛載（Mounting）的標準定義與運作機制：

• 分析磁碟分區能力是否支援多檔案系統。
• 檢驗 NFS 的通訊架構是否基於 RPC。
• 檢驗 Session Semantics 的修改可見性定義。
• 檢驗作業系統存取檔案前是否強制要求掛載檔案系統。

選項分析

• (A) A disk drive may have many partitions each of which contains a different file system.（正確敘述）

  • 說明：實體磁碟（Disk Drive）可以透過分割表（如 MBR 或 GPT）劃分為多個邏輯分區（Partitions / Volumes）。每個分區都可以獨立格式化為特定的檔案系統（例如：分區 C 使用 NTFS、分區 D 使用 FAT32、分區 E 使用 Linux ext4）。因此本敘述正確。

• (B) An NFS (Network File System) is building on a RPC (Remote Procedure Call) system.（正確敘述）

核心觀念

本題考查作業系統（Operating System）中**檔案系統實作（File-System Implementation）與次級儲存結構（Secondary Storage Structure）**的四大核心主題：

1. 檔案配置表（File Allocation Table, FAT）：鏈結配置（Linked Allocation）的變形，將鏈結指標集中記錄於記憶體的表格中。
2. 檔案系統一致性檢查（Consistency Checking）：檔案系統崩潰後的修復機制與其限制。
3. 快閃記憶體與非揮發性記憶體（NVM / Flash Memory）空間管理：由於 NVM 具備「不可直接覆寫（Out-of-place update）」的物理特性，空間管理需依賴垃圾回收（Garbage Collection）與空閒區塊維護。
4. 空閒空間管理（Free-Space Management）方法比較：鏈結法（Linked List）與分組法（Grouping）在存取多個空閒區塊位址時的速度與效率差異。

解題方法

1. 檢視 FAT 的資料結構定義：FAT 為陣列結構，大小與磁碟區塊總數相對應，索引（Index）即為區塊編號（Block Number）。
2. 分析一致性檢查（如 fsck 或 chkdsk）的極限：一致性檢查旨在修復檔案系統元資料（Metadata）的不一致，而非無損復原所有檔案；在毀損嚴重時，修復過程常伴隨著檔案與目錄的遺失（如放入 lost+found）。
3. 評估 NVM（如 SSD / Flash Storage）的寫入機制：NVM 必須先擦除（Erase）才能寫入，無法直接在原位覆寫（Overwrite），因此需要 Flash Translation Layer (FTL) 進行動態位址映射與垃圾回收，僅靠 Free List 無法滿足寫入與空間釋放需求。
4. 比較空閒空間管理演算法的存取時間複雜度：
   • 鏈結法（Linked List）：若要取得 $N$ 個空閒區塊位址，必須尋訪（Traverse）鏈結指標 $N$ 次，造成多次磁碟 I/O。
   • 分組法（Grouping）：將第一個空閒區塊當作索引，儲存接下來 $N-1$ 個空閒區塊的位址，只需一次讀取即可快速取得大量空閒區塊位址。

選項分析

• (A) 正確。
  • 原因：FAT（File Allocation Table）為一種以磁碟區塊（Disk Block）為單位進行索引的表格結構。

核心觀念

本題考查作業系統（Operating System）中記憶體管理與檔案系統的快取機制，特別是**統一虛擬記憶體（Unified Virtual Memory, UVM）**與傳統記憶體管理機制的差異。

• 傳統架構（Double Caching 問題）：
  在傳統的 OS 設計中，記憶體分頁管理（Process Page Table）使用 Page Cache 快取使用者進程的虛擬分頁；而檔案系統（File System）則使用 Buffer Cache 快取硬碟磁區（Block/Sector）的讀寫資料。當使用 read() / write() 讀寫檔案時，資料會先被複製到 Buffer Cache，再複製到使用者層級的 Page Cache，導致同一份資料在記憶體中佔用兩份空間（即 Double Caching 雙重快取現象）。
• Unified Virtual Memory (UVM) / Unified Buffer Cache：
  現代作業系統將 Page Cache 與 Buffer Cache 進行整合（Unified），統一使用 Page Cache 來同時快取「進程的分頁資料（Process Pages）」與「檔案系統的資料（File Data/Mapped Files）」。如此一來，無論是透過 mmap() 記憶體映射檔案，還是透過標準 read() / write() 系統呼叫，系統皆直接在 Page Cache 中進行存取與管理，消除雙重快取的開銷。

解題方法

1. 鎖定題目關鍵字：
   • Unified virtual memory (UVM)：統一虛擬記憶體機制。
   • Cache both process page and file data：用同一種快取機制同時涵蓋進程分頁與檔案資料。
2. 對應作業系統原理（Silberschatz OS Concept 經典教材觀念）：
   • 在統一虛擬記憶體（UVM）與記憶體映射檔案（Memory-Mapped Files）的架構下，系統將所有 I/O 與虛擬記憶體的存取標的都視為「分頁（Pages）」，因此統一採用 Page Caching 來管理。

核心觀念

本題考查作業系統與檔案系統中 ISAM (Indexed Sequential Access Method) 的索引結構與存取機制。

ISAM 是一種兼具「順序存取（Sequential Access）」與「隨機/索引存取（Direct/Indexed Access）」的檔案組織與存取方法。其核心架構採用多層級索引（Multi-level Index）：

1. Master Index（主索引）：體積小，載入並常駐於記憶體（Memory）中。
2. Secondary Index / Cylinder Index（次級索引）：體積較大，存放在磁碟區塊（Disk Blocks）中。主索引指向次級索引的磁碟區塊。
3. Data Blocks（實際檔案區塊）：次級索引區塊再進一步指向存放在磁碟上的實際資料區塊（Actual File Blocks）。

解題方法

解題的切入點在於精確掌握 ISAM 各層級索引的存放位置與指向關係：

• 記憶體中（In Memory）：放主索引（Master Index）。
• 磁碟中（Disk Blocks）：放次級索引（Secondary Index）與實際資料區塊（Actual File Blocks）。
• 結構關係：記憶體中的 Master Index $\rightarrow$ 磁碟中的 Secondary Index Blocks $\rightarrow$ 磁碟中的 Actual File Blocks。

核心觀念
本題考查計算機組織與系統中，輸入/輸出操作（I/O Operations）的處理機制——**輪詢 I/O（Polling I/O 或 Programmed I/O）**的效率瓶頸。

• 輪詢 I/O（Polling I/O）：CPU 透過程式迴圈定期或持續檢查 I/O 裝置的控制器暫存器（例如 status bit/busy bit），以確認裝置是否已經準備好進行資料傳送。
• 主要效能低落原因（Main Inefficiency）：當 I/O 裝置處理速度極慢、或是傳輸間隔極長時，CPU 會陷入「重複檢查但裝置皆尚未準備好（Busy/Not Ready）」的無意義迴圈中（Busy-Waiting / Waste of CPU Cycles）。

解題方法

1. 釐清「Polling I/O」與「Interrupt-driven I/O」、「DMA」的根本差異：
   • Polling 的核心缺點在於 CPU 必須主動且頻繁地去詢問（Poll）裝置狀態。
   • 若裝置大部分時間都在忙碌或閒置，CPU 所花費在檢查狀態的 CPU 週期（CPU Cycles）絕大多數都是無用功（Wasted Cycles）。
2. 對照題目選項，尋找精確描述「CPU 頻繁輪詢但裝置很少準備好，導致浪費大量 CPU 時間」的敘述。

選項分析

• (A) 錯誤：硬體控制器在裝置準備好時通知 CPU 是**中斷驅動 I/O（Interrupt-driven I/O）**的運作方式

核心觀念

本題考查作業系統（Operating System）中的**磁盤調度演算法（Disk Scheduling Algorithms）與現代硬體架構（Modern Hardware Architecture）**之間的關係。

傳統磁盤存取時間（Disk Access Time）主要由以下三個部分組成：

1. 尋道時間（Seek Time）：磁頭移動到指定磁軌（Track）所需的時間。
2. 旋轉延遲（Rotational Latency）：磁盤旋轉讓目標扇區（Sector）到達磁頭下方所需的時間。
3. 傳輸時間（Transfer Time）：資料從磁盤讀出或寫入磁盤的時間。

傳統作業系統的磁盤調度演算法（如 FCFS、SSTF、SCAN、C-SCAN）主要以最小化尋道時間（Seek Time）為目標。然而，在現代硬體中，作業系統只考慮尋道距離（Seek Distance）而無法精確考慮旋轉延遲，其關鍵原因在於現代磁盤採用了**邏輯區塊位址（LBA, Logical Block Addressing）**以及磁盤內部控制器（Disk Controller）的抽象化機制，使得作業系統無法得知邏輯區塊（Logical Blocks）在磁盤上的真實物理位置（Physical Geometry / Location）。

解題方法

要選出正確選項，需釐清作業系統（OS）與磁盤硬體（Disk Hardware / Controller）之間的分工界線：

1. 抽象層（Abstraction Level）：現代磁盤將內部的物理結構（柱面 Track/Cylinder、磁頭 Head、扇區 Sector）隱藏起來，僅透過一維陣列的形式暴露「邏輯區塊位址（LBA）」給作業系統。
2. OS 的局限性：由於 OS 無法獲知邏輯區塊對應的具體旋轉角度與物理扇區位置，因此 OS 無法計算與預測旋轉延遲，只能依據 LBA 的連續性或相對距離來估算尋道距離（Seek Distance）。

核心觀念

本題考查作業系統（Operating Systems）中**虛擬記憶體（Virtual Memory）之分頁錯失處理（Page Fault Handling）**機制，特別是針對「具備邊際效應／多次記憶體寫入指令（Instructions with Side Effects / Multiple Memory Modifications）」的例外恢復（Exception Recovery）問題。

當 CPU 執行一條指令（如 VAX 架構的 PUSHR 或 MOVC3）時，若該指令會連續修改多個不同的記憶體位址，且在執行中途（已修改部分位址後）觸發了 Page Fault，作業系統必須能將 CPU 狀態與記憶體恢復到該指令執行前的狀態（Precise Interrupt/Exception），以便分頁載入完成後重新執行（Restart）該指令。

處理此類問題主要有以下兩種方式：

1. 特殊硬體支援（Special Hardware / Auto-increment Microcode Trap）：在指令執行過程中，利用暫存器或硬體控制邏輯紀錄已被修改的位址與原始數值，發生 Page Fault 時藉由硬體自動復原（Rollback）；或者預測（Pre-check）是否會發生 Page Fault。
2. 事先檢查分頁（Access Check / Page Probing）：在指令真正寫入前，先檢查（Read/Write Probe）所有即將存取的頁面是否都在記憶體中。

在《Operating System Concepts》（恐龍書 Silberschatz et al.）中，對此問題有明確指明：欲處理修改多個不同位址的指令在 Page Fault 時的重置問題，必須**引入特殊硬體支援（incorporating special hardware）**來維護狀態與歷史紀錄。

解題方法

1. 分析指令執行過程：
   若指令 $I$ 需要依序修改記憶體位址 $A_1, A_2, A_3$。若在寫入 $A_1$ 與 $A_2$ 後，存取 $A_3$ 時觸發 Page Fault，此時 $A_1$ 與 $A_2$ 舊的值已經被覆蓋（Overwritten）。
2. 評估恢復機制：
   • 若無硬體支援，CPU 的控制單元無法得知之前暫存器與記憶體的舊狀態， Page Fault 處理程式處理完頁面載入後，無法直接重設指令指標（Program Counter, PC）重新執行指令（否則 $A_1, A_2$ 會被重複或錯誤地再寫一次）。

核心觀念

本題考驗 Windows 作業系統核心（Windows Kernel）中的同步機制（Synchronization Primitives）與分派器物件（Dispatcher Objects） 之運作行為。

在 Windows 作業系統中，執行緒同步主要依靠分派器物件（Dispatcher Objects）。這些物件皆擁有兩種狀態：

1. Signaled（有信號狀態）：表示物件可用，執行緒獲取該物件時不會被阻塞（Block）。
2. Nonsignaled（無信號狀態）：表示物件不可用或已被佔用，執行緒若試圖獲取該物件，會進入等待狀態（Waiting State）。

當分派器物件的狀態轉換為 Signaled 時，核心對於等待該物件之執行緒的處理方式，取決於物件的類型：

1. 互斥物件（Mutex Object / KMUTEX）：

   • 用於保護共享資源的互斥存取（Mutual Exclusion）。
   • 特性：一次僅允許單一執行緒擁有（Ownership）。
   • 行為：當 Mutex 變為 Signaled 時，核心只會**釋放並搬移「恰好一個」（Exactly One）**等待中的執行緒至就緒狀態（Ready State），該執行緒獲得 Mutex 並將其狀態立刻重置回 Nonsignaled。因此不可能喚醒「所有」或「固定複數個」執行緒。

2. 事件物件（Event Object / KEVENT）：

   • 用於執行緒間的事件通知與同步。分派器物件中的 Event 又可細分為兩類：
     • 通知事件（Notification Event / Manual-Reset Event）：當狀態變為 Signaled 時，狀態會一直保持 Signaled（直到被手動重置）。此時核心會將**所有等待該 Event 的執行緒（All waiting threads）**全部移至 Ready State。
     • 同步事件（Synchronization Event / Auto-Reset Event）：當狀態變為 Signaled 時，核心只會喚醒單一執行緒（Single waiting thread），且狀態隨即自動重置為 Nonsignaled。
   • 選項分析標準：題目問及一般性的 Event 物件時，在作業系統標準考題觀念中（參照 Silberschatz 著《Operating System Concepts》關於 Windows Synchronization 的章節描述），Event 物件的典型行為是指 Notification Event，即「當 Event 物件變成 Signaled 時，會解鎖所有等待該事件的執行緒（moves all threads waiting on that object to ready state）」。

解題方法

本題切入點為比對 Mutex 與 Event 在 Windows Kernel 中的基本語意（Semantics）：

1. 檢驗 Mutex 敘述 (A) 與 (B)：
   Mutex 是嚴格的單一資源鎖（Single Owner）。

核心觀念

本題考查 Linux 作業系統中**自旋鎖（Spinlock）與核心搶佔（Kernel Preemption）**的同步機制特性：

1. Spinlock 的運作機制與適用場景：Spinlock 是一種忙碌等待（Busy-waiting）的鎖機制。當執行緒無法取得鎖時，不會進入休眠（Sleep/Block），而是在 CPU 上持續迴圈檢查（Spin）。因此，Spinlock 主要用於多核心／多處理器系統（SMP, Symmetric Multi-Processing）中極短時間的臨界區（Critical Section）。
2. 單處理器（UP, Uniprocessor）與 Spinlock：在單處理器系統中，若執行緒進入 Spinlock 忙碌等待，會佔用唯一的 CPU 資源，導致持有鎖的執行緒無法獲得 CPU 時間來釋放鎖，從而引發死鎖（Deadlock）。因此，在 UP 系統下，Linux Kernel 經編譯優化後，Spinlock 會退化（或簡化）為單純關閉核心搶佔（Disable Kernel Preemption）或關閉中斷（Disable Interrupts），而不進行實際的 Busy-waiting。
3. 不可重入性（Non-recursive Spinlock）：標準 Linux Spinlock 是不可重入的（Non-recursive）。若同一個執行緒在已持有 Spinlock 的情況下，再次試圖獲取同一個 Spinlock，會導致自我死鎖（Self Deadlock）。

解題方法

題目要求選出關於 Linux 中 Spinlock **不正確（Not true）**的敘述。
切入點為檢視選項 (A) 的陳述：「Spinlock 不能用於單處理器機器上（Spinlocks cannot be used on single processor machines）」。
在 Linux 核心原始碼中，Spinlock API（如 spin_lock()）在單處理器（UP）環境下依然被廣泛使用並被核心編譯器支援。雖然其底層實作在 UP 架構下會被替換為關閉 preemption/interrupt，但在觀念與程式碼層面上，Spinlock 是可以且經常被用於單處理器系統的程式碼中（核心巨集會根據 CONFIG_SMP 自動編譯成對應的機制）。因此 (A) 的敘述太過絕對且違背 Linux 核心的設計事實。

選項分析

• (A) 錯誤（本題應選此項）
  • 原因：Linux 核心為了保持程式碼的一致性與可移植性，不論是在單處理器（UP）或多處理器（SMP）系統中，開發者皆可使用相同的 Spi

核心觀念

本題考查作業系統中 Solaris 核心排程機制（Solaris Scheduling） 的 時分與互動執行緒調度表（Time-Sharing and Interactive Dispatch Table） 之查表與解讀能力。

在 Solaris 作業系統中，針對 Time-Sharing（TS）與 Interactive（IA）類型的執行緒，採用了基於多層佇列的多級回饋佇列（Multilevel Feedback Queue, MLFQ）排程演算法：

1. 優先權（Priority）：數值越大代表優先權越高（最高為 59，最低為 0）。
2. 時間中斷（Time Quantum）：執行緒獲分配 CPU 後，單次連續執行的最大時間長度（單位：毫秒, ms）。
3. 動態優先權調整規則：
   • 當執行緒用完時間中斷（Time Quantum Expired），優先權會降低（至 time quantum expired 欄位所指定的數值）。
   • 當執行緒因等待 I/O 或事件休眠後醒來（Return from Sleep），優先權會提升（至 return from sleep 欄位所指定的數值）。
   • 優先權越高者，分配到的時間中斷通常越短，以維持系統對高優先權/互動型工作的高回應性（Responsiveness）。

解題方法與步驟

本題要求找出優先權為 15 與 55 的執行緒所分配到的時間中斷（Time Quantum）。解題步驟如下：

1. 對照題目給予的 Solaris Dispatch Table。
2. 搜尋 priority = 15 所對應的列（Row）：
   • 在 priority 欄位找到 15。

核心觀念

本題考查的是 Solaris 作業系統的多層級回饋佇列（Multilevel Feedback Queue, MLFQ）排程演算法。

在 Solaris 時間分享與互動式 thread（Time-sharing and Interactive Threads）排程中，系統透過排程排程表（Dispatch Table）動態調整執行緒的優先順序（Priority）：

1. 優先順序與 Time Quantum：優先順序越高（數值越大），分配到的時間片（Time Quantum）越短；反之，優先順序越低（數值越小），分配到的時間片越長。
2. CPU-bound 懲罰：當執行緒完整用盡其時間片而未進入阻塞（Blocking）時，代表該執行緒屬於 CPU-bound 特性。排程器會將其優先順序降階，對應至表格中的 time quantum expired 欄位。
3. I/O-bound 獎勵：當執行緒從睡眠/阻塞狀態返回時，代表該執行緒屬於 I/O-bound 或互動式特性。排程器會提高其優先順序，對應至表格中的 return from sleep 欄位。

解題方法

核心觀念

本題考驗作業系統（Operating System）中 Solaris 時間分片（Time-Sharing, TS）與互動式（Interactive, IA）排程調度表（Dispatch Table） 的運作機制。

在 Solaris TS/IA 排程演算法中，每個優先權等級（Priority）都包含以下主要控制參數：

1. Priority：當前執行緒的優先權數字（數值越大，優先權越高）。
2. Time Quantum：該優先權所分配到的最大 CPU 執行時間（單位通常為毫秒 ms）。
3. Time Quantum Expired：若執行緒用盡時間分片（CPU-bound 行為），排程器會將其優先權降低至此欄位所指定的數值（懲罰機制）。
4. Return from Sleep：若執行緒在時間分片用盡前因等待 I/O 或事件而進入睡眠（I/O-bound 行為），當其被喚醒（Sleep 結束）返回時，排程器會將其優先權提高至此欄位所指定的數值（獎勵機制）。

解題方法

1. 分析題幹條件：
   • 執行緒初始優先權：$40$。
   • 動作：在時間分片用盡前（before its time quantum has expired）因 I/O 而被阻塞（blocks for I/O）。
2. 對應排程表欄位：
   • 執行緒因等待 I/O 而睡眠，屬於 Return from Sleep（從睡眠喚醒返回）的情境。

核心觀念

本題考查儲存系統（Storage Systems）中**長尾延遲（Tail Latency）**的形成原因與解決方案。

尾端延遲（Tail Latency）通常定義為高百分位數（例如第 98 或 99 百分位數，P98/P99）的回應時間。即使平均延遲（Average Latency）極低，極少數（1% 或 2%）極高延遲的 I/O 請求仍會嚴重破壞即時嵌入式系統（Real-time Embedded Systems）的硬性即時性（Hard Real-time），或企業級伺服器（Enterprise-server Systems）的服務品質協議（QoS / SLA）。

解題方法

本題為觀念簡答題，切入點應分為兩個層次：

1. 問題 (1)：從硬體物理特性、韌體內部管理（Flash Management / Firmware）、系統資源爭用（System Resource Contention）與 I/O 排程（Scheduling）四個維度，深入剖析導致儲存系統產生尾端延遲的原因。
2. 問題 (2)：針對上述成因，提供硬體/韌體層級（如 SSD 控制器設計）與系統/架構層級（如 備用請求 / 冗餘存取）的具體解決方案。

題目與詳細解答

(1) 請提供儲存系統設計中導致 Tail Latency 的四個可能原因並簡要說明。

1. SSD 垃圾回收與區塊擦除（Garbage Collection and Block Erase Overhead）
   • 說明：NAND Flash 具有「先擦除再寫入」（Out-of-place Write / Erase-before-write）的物理限制。當 SSD 空間不足或進行背景維護時，控制器會觸發垃圾回收（GC），將有效頁面（Valid Pages）複製到新區塊並對舊區塊執行擦除（Erase）。擦除操作的延遲（約 2~5 ms）遠高於一般的讀寫操作（約數十至數百 $\mu\text{s}$）。若使用者寫入請求剛好落在正在執行 GC 的 Channel 或 Die 上，該請求會被嚴重阻塞，造成高達數百倍的尾端延遲。
2. HDD 磁頭尋道與旋轉延遲（HDD Head Seek and Rotational Latency）
   • 說明：傳統機械硬碟（HDD）依賴物理機械結構進行讀寫。若寫入請求為非連續的隨機寫入（Random Writes），磁頭需要移動至指定軌道（Seek Time，約 310 ms），並等待盤片旋轉至對應磁區（Rotational Latency，約 24 ms）。當出現嚴重的磁片碎裂或大量隨機 I/O 併發時，最差情況下的機械搜尋時間會讓回應時間大幅飆升。
3. 主機端與控制器端 DRAM 快取刷寫（Cache Flush / Buffer Dirty Page Eviction）
   • 說明：作業系統（Page Cache）與儲存控制器內部均設有 DRAM 作為寫入快取（Write Buffer）。一般情況下寫入 DRAM 即可快速返回，但當髒頁（Dirty Pages）累積超過高水位線（High Watermark），或系統呼叫 fsync() / 觸發 Writeback 機制時，系統會強制將快取刷寫至底層非揮發性介面（Sync Flush）。此時後續寫入請求會由快取寫入轉為阻塞式的同步介面寫入，引發延遲驟增。

核心觀念

本題考驗作業系統（Operating System）中**分頁記憶體管理（Paging Memory Management）**的核心概念與位址轉換計算。主要涉及以下三大觀念與公式：

1. 虛擬位址空間與頁數（Pages）：

   • 虛擬位址空間大小由虛擬位址位元數 $n$ 決定，總大小為 $2^n$ bytes。
   • 頁面大小（Page Size）為 $P = 2^p$ bytes，其中 $p$ 為頁內偏移量（Page Offset）的位元數。
   • 一個行程最多可擁有的頁數（Max Pages per Process）公式為：
     $\text{Max Pages} = \frac{\text{Virtual Address Space Size}}{\text{Page Size}} = \frac{2^n}{2^p} = 2^{n-p}$

2. 實體位址位元數（Physical Address Bits）：

   • 若實體記憶體（Physical Memory / RAM）最大容量為 $M = 2^m$ bytes，則實體位址需要 $m$ 個位元（Bits）來定址（Byte-addressable）。

3. 實體框數（Frames）：

   • 實體記憶體會被分割成與 Page 等大的頁框（Frame）。
   • 系統最大頁框數（Max Frames）公式為：
     $\text{Max Frames} = \frac{\text{Max Physical Memory Size}}{\text{Frame Size}} = \frac{2^m}{2^p} = 2^{m-p}$

解題方法

步驟一：計算一個行程最多可擁有的頁數（Max Pages）

• 已知條件：
  • 虛擬位址為 32 位元 ($n = 32$)，故虛擬位址空間大小為 $2^{32} \text{ bytes} = 4 \text{ GB}$。
  • Page 大小為 $4 \text{ KB} = 4 \times 1024 \text{ bytes} = 2^{12} \text{ bytes}$ ($p = 12$)。
• 計算推導：
  $\text{Max Pages} = \frac{2^{32} \text{ bytes}}{2^{12} \text{ bytes}} = 2^{32-12} = 2^{20} \text{ pages}$
  $2^{20} = 1,048,576 \approx 1\text{M}$ 個頁面。

步驟二：計算實體位址的最大位元數（Physical Address Bits）

• 已知條件：

核心觀念

本題考驗**分頁系統（Paging System）中的有效記憶體存取時間（Effective Memory Access Time, EMAT）與轉譯後備緩衝區（Translation Lookaside Buffer, TLB）**的關係。

• 記憶體存取時間（Memory Access Time, $m$）：存取實體記憶體（Physical Memory）一次所需的時間。
• TLB 存取時間（TLB Access Time, $\varepsilon$）：查詢 TLB 頁表快取一次所需的時間。
• TLB 命中率（TLB Hit Ratio, $h$）：虛擬位址翻譯成實體位址時，在 TLB 中成功找到對應頁表項目的機率（$0 \le h \le 1$）。

在採用**單層頁表（One-level Paging）**的架構下：

1. TLB Hit（命中）：
   • 存取 TLB 尋找頁表項目（花費 $\varepsilon$），成功找到頁碼對應的框碼（Frame Number）。
   • 直接存取一次實體記憶體讀取資料（花費 $m$）。
   • 總存取時間：$\varepsilon + m$。
2. TLB Miss（未命中）：
   • 存取 TLB 尋找頁表項目（花費 $\varepsilon$），未找到。
   • 存取實體記憶體中的單層頁表以查詢頁表項目（花費 $m$）。
   • 取得實體位址後，再次存取實體記憶體讀取資料（花費 $m$）。
   • 總存取時間：$\varepsilon + m + m = \varepsilon + 2m$。

有效記憶體存取時間（EMAT）公式：

簡化後可得：

解題方法

Step 1：列出已知條件與變數定義

• TLB 存取時間 $\varepsilon = 20\text{ ns}$
• 記憶體存取時間 $m = 100\text{ ns}$
• 目標有效記憶體存取時間 $\text{EMAT} < 140\text{ ns}$
• 設 TLB 命中率為 $h$

補充說明：題目提及「32-bit virtual address space」與「page size is 4K bytes」為分頁系統背景設定，用於說明架構為傳統分頁；

核心觀念

本題考查作業系統（Operating System）中**請求分頁（Demand Paging）機制下的有效記憶體存取時間（Effective Access Time, EAT）**計算。

在 Demand Paging 機制中，CPU 欲存取的頁面（Page）可能已載入主記憶體（Hit），也可能尚未載入而引發頁面錯誤（Page Fault, Miss）。有效存取時間是將「未發生 Page Fault 的存取時間」與「發生 Page Fault 的處理時間」依各自發生的機率進行加權平均：

$\text{EAT} = (1 - p) \times T_{\text{no\_fault}} + p \times T_{\text{fault}}$

其中：

• $p$：頁面錯誤率（Page Fault Rate）。
• $1 - p$：頁面命中率（Page Hit Rate / No Page Fault Rate）。
• $T_{\text{no\_fault}}$：未發生 Page Fault 時的有效記憶體存取時間（Effective Access Time without Page Fault）。
• $T_{\text{fault}}$：發生 Page Fault 時的服務時間（Page Fault Service Time）。

解題方法

1. 單位統一與參數整理
在進行代數運算前，必須先將所有時間單位統一（本題統一轉為奈秒 $\text{ns}$）：

• 頁面錯誤率 $p = 0.0000004 = 4 \times 10^{-7}$
• 未發生 Page Fault 的記憶體存取時間 $T_{\text{no\_fault}} = 100\text{ ns}$
• Page Fault 服務時間 $T_{\text{fault}} = 15\text{ ms} = 15 \times 10^6\text{ ns} = 15,000,000\text{ ns}$

註：題目給予的 32-bit 虛擬位址空間與 4K bytes 頁面大小為背景資訊，計算 EAT 時無需用到。

2. 帶入 EAT 公式進行計算
將參數帶入 EAT 公式：
$\text{EAT} = (1 - p) \times T_{\text{no\_fault}} + p \times T_{\text{fault}}$

核心觀念

本題考查作業系統（Operating System）中的多層頁表（Multi-level Paging）機制與虛擬記憶體定址計算。

解答此類題目的關鍵概念與公式如下：

1. 頁面大小與位移量（Offset）：
   頁面大小（Page Size）決定了頁內位移（Page Offset）所佔用的位元數。若頁面大小為 $S$ 位元組（Bytes），則：
   $\text{Offset bits} = \log_2(S)$

2. 頁表項大小與每個頁表可容納的 Entry 數量：
   每個頁頁面（Page）或頁表頁面（Page Table Page）的大小為 $S$ 位元組。若每個頁表項（Page Table Entry, PTE）大小為 $E$ 位元組，則單一頁表頁面最多可容納的 PTE 數量為：
   $\text{Entries per Page Table Page} = \frac{S}{E}$
   對應每個層級的分頁索引（Page Table Index）位元數為：
   $\text{Bits per Level} = \log_2\left(\frac{S}{E}\right)$

3. 虛擬位址架構與分頁層數：
   在傳統與標準的多層頁表設計中，為了避免頁表本身產生碎片並確保頁表頁面能正好對齊一個 Page，每一層頁表的大小通常限定為恰好一個 Page 大小。
   虛擬位址總長度為 $N$ 位元，扣除頁內位移位元數後，剩餘的位元即為虛擬頁號（Virtual Page Number, VPN）。多層頁表必須涵蓋整個虛擬頁號位元數（或受限於系統實際實作的有效虛擬位址範圍）。
   多層頁表層數 $k$ 之計算公式為：
   $k = \left\lceil \frac{\text{Virtual Page Number Bits}}{\text{Bits per Level}} \right\rceil$

解題方法

步驟一：計算頁內位移位元數（Page Offset Bits）

題目給定頁面大小 $S = 8\text{ KB} = 8 \times 2^{10}\text{ Bytes} = 2^{13}\text{ Bytes}$。
因系統為 Byte-addressable（以位元組定址），故頁內位移位元數為：
$\text{Offset bits} = \log_2(2^{13}) = 13\text{ bits}$

步驟二：計算虛擬頁號位元數（VPN Bits）

題目給定虛擬位址總長度為 64 位元（64-bit Virtual Address）。
虛擬頁號（VPN）的位元數等於虛擬位址總位元數減去頁內位移位元數：
$\text{VPN bits} = 64 - 13 = 51\text{ bits}$

步驟三：計算單一頁表頁面可提供之索引位元數（Bits per Level）

題目給定每個頁表項大小 $E = 8\text{ Bytes} = 2^3\text{ Bytes}$。
一個大小為 8KB 的頁面可以容納的 PTE 數量為：
$\text{PTEs per Page Table Page} = \frac{8\text{ KB}}{8\text{ Bytes}} = \frac{2^{13}}{2^3} = 2^{10} = 1024\text{ 個}$
因此，多層頁表中**每一個完整層級（Full Level）**所對應的分頁索引位元數為：

核心觀念

本題探討經典 MIPS/RISC 架構中，由**單週期資料路徑（Single-Cycle Datapath）轉換為管線化資料路徑（Pipelined Datapath）**時的核心硬體需求與設計原理：

1. 管線暫存器（Pipeline Registers）：在管線化處理器中，多個指令同時處於不同的執行階段（Stage）。為了讓各階段能獨立運作且不互相覆蓋前一指令的運算結果，必須在相鄰階段之間加入邊緣觸發（Edge-triggered）的管線暫存器（如 IF/ID、ID/EX、EX/MEM、MEM/WB）。
2. 暫存器的作用與生命週期：管線暫存器不僅傳遞資料與控制訊號，還負責「保存指令在後續階段所需的資訊」（例如目的暫存器編號 Write Register、後續階段要用的控制訊號等），直到該指令進入對應的寫回或處理階段為止。

解題方法

題目詢問兩個核心問題：

1. 需加入什麼硬體資源（What hardware resources should be added）？
2. 為什麼需要（Why）？

1. 應加入的硬體資源

在五個管線階段（IF, ID, EX, MEM, WB）的相鄰分界處，需加入管線暫存器（Pipeline Registers / Pipeline Latches）：

• IF/ID 暫存器：位於 Instruction Fetch 與 Instruction Decode 之間。
• ID/EX 暫存器：位於 Instruction Decode 與 Execution 之間。
• EX/MEM 暫存器：位於 Execution 與 Data Memory 存取之間。
• MEM/WB 暫存器：位於 Data Memory 存取與 Write Back 之間。

2. 原因分析（Why）

• 隔離各階段並實現指令重疊執行（Stage Isolation & Concurrency）：
  在管線架構中，每個 Clock Cycle 內同時有最多 5 個不同的指令分別在 5 個階段中執行。各階段的組合邏輯電路（Combinational Logic，如 ALU、Adder、Decoder 等）必須由暫存器隔開，以避免訊號在同一時脈週期內向前穿透，造成不同指令間的邏輯混亂。
• 跨階段保存運算資料與控制訊號（Data and Control Forwarding across Stages）：

核心觀念

本題考查五級管線中，資料與控制訊號必須和「同一條指令」同步通過各級管線暫存器。

五級管線為：

對 lw 指令而言：

• EX：計算記憶體位址。
• MEM：讀取資料記憶體。
• WB：將讀出的資料寫回目的暫存器。
• lw 的目的暫存器是指令中的 rt 欄位，即位元 $20:16$。

解題方法

管線化後，同一時間會有多條指令分別位於不同階段。因此，lw 指令的目的暫存器編號不能在 ID 階段讀出後直接使用，而必須隨著該指令一路延遲到 WB 階段。

例如：

lw   $t0, 0($t1)    # 應將資料寫回 $t0
add  $t2, $t3, $t4

當 lw 到達 WB 階段時，後面的 add 已經進入較前面的管線階段。若 WB 階段仍直接使用目前指令的 rt 欄位，所取得的可能是 add 的欄位，而不是 lw 原本的 rt。結果會造成：

• 寫回資料可能正確；
• 但寫入的目的暫存器錯誤；
• 因而產生錯誤結果。

因此，lw 的 rt 必須經過：

最後由 MEM/WB 管線暫存器提供給暫存器檔案的 Write\ register 輸入。

此外，MemtoReg、RegWrite 等控制訊號，以及資料記憶體讀出的資料，也必須一併保存到 MEM/WB 管線暫存器。

修正後的資料路徑

核心觀念

本題考驗**單週期資料路徑（Single-Cycle Datapath）**的執行時間與時脈週期（Clock Period）計算機制。

在單週期 CPU 設計中：

1. 單週期約束：所有指令均使用相同的時脈週期（Clock Period, $T_c$）。為了保證時間最長的指令也能在一個週期內完成，時脈週期必須由最慢指令（通常為 Load 指令）所需的總延遲來決定。
2. 指令特定延遲（Instruction Latency）：指特定指令從發動（Fetch）到執行完畢時，實際經過該指令所必需經歷之各階段延遲總和。
   • Load 指令 ($I_{Load}$)：需要經過 IF (取指) $\rightarrow$ ID (譯碼/讀暫存器) $\rightarrow$ EX (計算位址) $\rightarrow$ MEM (讀取記憶體) $\rightarrow$ WB (寫回暫存器) 全部 5 個階段。
   • Store 指令 ($I_{Store}$)：需要經過 IF $\rightarrow$ ID $\rightarrow$ EX $\rightarrow$ MEM 共 4 個階段（Store 指令將資料寫入記憶體，不需要寫回暫存器，故不需要 WB 階段）。

解題方法

根據題目給予之各階段操作時間：

• $t_{\text{IF}} = 100\text{ ps}$
• $t_{\text{ID}} = 50\text{ ps}$
• $t_{\text{EX}} = 100\text{ ps}$
• $t_{\text{MEM}} = 200\text{ ps}$
• $t_{\text{WB}} = 80\text{ ps}$

1. Load 指令的延遲（Latency of Load Instruction）

Load 指令需執行完整的 5 個階段，其總處理時間為：

代入數值計算：

因為題目明確標示「Continue with the above question」（承接上題），此類經典考古題在計算機組織中探討「將單週期資料路徑（Single-Cycle Datapath）轉換為管線化（Pipelined）資料路徑」時，其時脈週期（Clock Cycle Time）的計算邏輯如下：

核心觀念

1. 單週期資料路徑 vs. 管線化資料路徑：

   • 單週期資料路徑：一筆指令執行完畢需要通過所有相關元件，其時脈週期取決於最慢（最長延遲）的指令執行時間（通常為 lw 指令）。
   • 管線化資料路徑：將單週期資料路徑切割成若干個管線階段（Stage，常見為 IF、ID、EX、MEM、WB 五個階段）。為了讓所有階段同步運作，管線化的時脈週期（Clock Cycle Time）必須由延遲最長（最慢）的管線階段（Longest Stage Delay）加上管線暫存器（Pipeline Register）的延遲時間來決定。

2. 核心公式：
   $T_{\text{clock, pipelined}} = \max(T_{\text{stage1}}, T_{\text{stage2}}, \dots, T_{\text{stage}n}) + T_{\text{reg}}$
   若題目未特別提及管線暫存器延遲（Pipeline Register Delay, $T_{\text{reg}}$），則視為 $0$。

解題方法

1. 確定各階段延遲（Stage Delays）：
   單週期資料路徑劃分為管線階段後，需分別加總各階段內所有硬體元件（如 ALU、Memory、Register File、MUX 等）的傳播延遲（Propagation Delay）。

2. 尋找最瓶頸階段（Bottleneck Stage）：
   比較各管線階段的總延遲時間，選出最大者：
   $T_{\text{max\_stage}} = \max(T_{\text{IF}}, T_{\text{ID}}, T_{\text{EX}}, T_{\text{MEM}}, T_{\text{WB}})$

3. 計算管線時脈週期：
   將最長階段延遲加上管線暫存器開銷（若題目有提供）：
   $T_{\text{clock}} = T_{\text{max\_stage}} + T_{\text{pipeline\_register}}$

*(註：若前小題給定各硬體元件具體延遲數值，例如：Memory Read/Write = 200 ps、ALU = 200 ps、Register File Read/Write = 100 ps，則各階段延遲分別為 $T_{\text{IF}} = 200\text{ ps}$、

核心觀念

本題考驗**流水線數據冒險（Data Hazards）**的辨識與手動解決機制。
在標準的 5 階段流水線（5-stage Pipelined Datapath: IF, ID, EX, MEM, WB）中：

1. **暫存器寫回（WB stage）**發生在時脈週期的前半段（First Half Cycle）。
2. **暫存器讀取（ID stage）**發生在時脈週期的後半段（Second Half Cycle）。
3. 若前指令欲將結果寫入暫存器 $R_x$，而後續指令需要讀取該暫存器 $R_x$，在**完全不支援數據前瞻（Data Forwarding / Bypassing）與硬體停頓（Hardware Stalling）**的情況下，後續指令必須等到前指令完成 WB 階段後，才能在 ID 階段讀取到正確的最新數值。

若前指令在週期 $t$ 進入 IF：

• 週期 $t+4$：前指令到達 WB 階段（前半週期寫入 $R_x$）。
• 週期 $t+4$：後續指令可在 ID 階段（後半週期讀取 $R_x$）。

因此，後續指令與前指令之間至少需要相隔 2 個時脈週期（即中間需插入 2 個 nop 指令），才能確保讀取到更新後的暫存器數值。若僅相隔 1 個週期或未間隔，將會發生寫後讀（Read-After-Write, RAW）數據冒險，導致讀取到舊的暫存器數值。

解題方法與推導

分析題目給定的 RISC-V / MIPS 組合語言指令序列：

1. addi x10, x14, 10 ：寫入目標暫存器 x10（在 WB 階段完成寫入）。
2. sub x13, x10, x14 ：讀取來源暫存器 x10 與 x14。
3. xor x4, x3, x5 ：與前述暫存器無數據相依性（Data Dependency）。

數據相依性分析

指令 1 (addi) 會修改暫存器 x10，而指令 2 (sub) 需要讀取 x10 的值。這裡存在 RAW（Read-After-Write）數據相依。

流水線時空圖（Pipeline Timing Diagram）分析

若不插入 nop：

• 週期 1：addi 進入 IF
• 週期 2：addi 進入 ID，sub 進入 IF
• 週期 3：addi 進入 EX，sub 進入 ID（此時 sub 讀取 x10，但 addi 尚未計算出結果並寫回，讀到舊值！錯誤）
• 週期 4：addi 進入 MEM
• 週期 5：addi 進入 WB（寫回 x10）

核心觀念

本題考查計算機架構中 指令重排（Code Reordering / Instruction Scheduling） 減緩 資料冒險（Data Hazard） 所生 stall 時間之技術。

1. RAW (Read-After-Write) Data Hazard：後續指令需要讀取前續指令尚未寫回暫存器的資料。
2. Load-Use Data Hazard：當讀取暫存器的指令緊接在 Load 指令之後，且需使用該 Load 指令從記憶體載入的資料時，即使具備轉發（Forwarding）機制，仍無法在同一週期完成傳遞，必定產生 1 個 Clock Cycle 的 Load-Use Stall。
3. 指令重排技術（Code Reordering）：編譯器在不破壞程式資料相依性（Data Dependency）的前提下，調整指令執行順序，將無相依性的獨立指令填入 Load 與其使用者指令之間的 空白週期（Delay Slot），以完全消除或降低 Stall 的開銷。

解題方法與詳細推導

題目提及 "Continue with the above question"，在典型的成大 AI 碩士學位學程／資工所計組考題中，第 6-(1) 題通常給定一段包含 Load-Use 相依性的組合語言程式碼（或 C 語言轉譯後的機器碼迴圈），並要求分析在具備 Forwarding 機制下的 Pipeline 效能與 Hazard 開銷。

情況一：典型成大考題程式碼情境（以經典 Load-Use 題目為例）

假設前題（第 6-(1) 題）之程式碼段落如下：

lw  $t1, 0($t0)
add $t2, $t1, $t3    # Load-Use Hazard: $t1 相依
lw  $t4, 4($t0)
add $t5, $t4, $t6    # Load-Use Hazard: $t4 相依

• 原始執行狀況（重排前）：

  • lw $t1 與 add $t2 存在 Load-Use Data Hazard，導致 1 cycle stall。
  • lw $t4 與 add $t5 亦存在 Load-Use Data Hazard，導致 1 cycle stall。
  • 總 overhead 為 2 cycles 的 stall。

• 應用 Code Reordering 進行優化：
  將不具相依性的指令 lw $t4 移動至第一組 Load-Use 之間：

lw  $t1, 0($t0)
lw  $t4, 4($t0)      # 填入獨立指令，隔開 lw $t1 與 add $t2
add $t2, $t1, $t3    # 此時 $t1 已從記憶體載入完成，可直接 Forwarding
add $t5, $t4, $t6    # 此時 $t4 也已載入完成，可直接 Forwarding

• 優化後效果：
  • lw $t1 載入期間執行 lw $t4，使得 add $t2 執行時 $t1$ 資料已準備妥當。
  • lw $t4 載入期間執行 add $t2，使得 add $t5 執行時 $t4

核心觀念

本題旨在考驗計算機結構中對**控制險象（Control Hazard）與分支預測器（Branch Predictor）**運作機制之理解與精確計算能力。

1. 迴圈與分支指令對應：
   High-level 的迴圈（如 for 迴圈）在編譯成組合語言後，通常會在迴圈末端透過條件分支指令（Conditional Branch，例如 bne 或 bnez）來決定是否繼續執行下一輪迴圈。
2. 分支跳躍與回跳行為：
   • Taken（跳躍 / 成立）：表示滿足迴圈繼續執行的條件，跳回迴圈開頭繼續執行。
   • Not-Taken（不跳躍 / 不成立）：表示迴圈結束條件成立（離開迴圈），不進行跳轉而繼續執行下一行指令。
3. 分支預測器機制：
   • Always-Taken Predictor（總是跳躍預測器）：對每一次的分支指令，一律預測結果為 Taken。
   • Always-Not-Taken Predictor（總是跳躍預測器）：對每一次的分支指令，一律預測結果為 Not-Taken。
4. 準確率公式：
   $\text{準確率 (Accuracy)} = \frac{\text{正確預測次數 (Correct Predictions)}}{\text{總分支執行次數 (Total Branch Executions)}} \times 100\%$

解題方法

首先分析程式碼的執行流與對應的分支指令行為。

1. 迴圈執行軌跡分析

程式碼片段：

for (i = 0; i < 4; i++)
    x = a + b;

迴圈總共會迭代 $4$ 次（對應 $i = 0, 1, 2, 3$）：

在組合語言控制結構中，典型對應的分支指令行為如下（假設分支指令置於迴圈末端判定是否繼續執行）：

• 第 1 次迭代 ($i=0$)：執行 x = a + b 完畢，分支指令判斷 $i+1 < 4$ 成立，結果為 Taken（跳回開頭）。
• 第 2 次迭代 ($i=1$)：執行 x = a + b 完畢，分支指令判斷 $i+1 < 4$ 成立，結果為 Taken（跳回開頭）。
• 第 3 次迭代 ($i=2$)：執行 x = a + b 完畢，分支指令判斷 $i+1 < 4$ 成立，結果為 Taken（跳回開頭）。
• 第 4 次迭代 ($i=3$)：執行 x = a + b 完畢，分支指令判斷 $i+1 < 4$ 不成立（迴圈結束），結果為 Not-Taken（離開迴圈）。

總計分支指令一共執行了 $4$ 次，實際結果序列為：
$\text{Actual Outcomes} = [\text{Taken}, \text{Taken}, \text{Taken}, \text{Not-Taken}]$

2. 預測器準確率計算

1. Always-Taken 預測器：
   • 預測序列：$[\text{Taken}, \text{Taken}, \text{Taken}, \text{Taken}]$