【正文】 在 Nachos 中，系統(tǒng)調(diào)用用其它異常陷入的入口處理函數(shù)都是ExceptionHandler 函數(shù)，只是陷入的類型為 SyscallException。 的與核心密切相關的部分，而將其它部分轉化成開發(fā)系統(tǒng)的一部分，作為開發(fā)系統(tǒng)的標準函數(shù)提供，運行在用戶態(tài)下。 的執(zhí)行效率和用途；因為不是每種應用都會用到所有的系統(tǒng)調(diào)用，系統(tǒng)調(diào)用數(shù)目太多，則會使得操作系統(tǒng)的NachOS課程設計 核心過于龐大而同樣影響系統(tǒng)的效率。系統(tǒng)調(diào)用作為操作系統(tǒng)的一部分，它們是長駐內(nèi)存 的。 一般的 UNIX操作系統(tǒng)提供幾十條甚至上百條系統(tǒng)調(diào)用，系統(tǒng)調(diào)用的多少取決于操作系統(tǒng)的復雜程度及其主要的適用范圍。所以系統(tǒng)調(diào)用也被看作軟件指令，它是在用戶態(tài)下運行的程序和操作系統(tǒng)的界面。但是在軟件開發(fā)過程中我們發(fā)現(xiàn)，有些指令序列需要重復使用，正如在結構化程序開發(fā)中，函數(shù)可以被重復調(diào)用一樣。 二、系統(tǒng)調(diào)用 （文件 , , ） 系統(tǒng)陷入有兩大原因：即系統(tǒng)調(diào)用和系統(tǒng)出錯陷入。 空間的轉換頁表覆蓋模擬機的轉換頁表 machine Run()。 // 恢復處理機用戶程序 錯誤 !未找到引用源。 空間初始化之后（設由 space 指針指向），真正的啟動運行過程如下： space InitRegisters()。 空間的實現(xiàn)非常簡單，這是因為系統(tǒng)一次只能運行一個用戶程序的局限和使用了線性頁面轉換表而決定NachOS課程設計 的。 實現(xiàn)： 賦值實現(xiàn)。 功能： 恢復處理機用戶程序 錯誤 !未找到引用源。 實現(xiàn)： 目前為空。 功能： 存儲用戶程序 錯誤 !未找到引用源。 實現(xiàn)： 設置 PC指針、棧指針的初值，并將其它寄存器的值設置為 0。 功能： 初始化寄存器，讓用戶程序 錯誤 !未找到引用源。 實現(xiàn)以后，這部分內(nèi)容也將做改動。 大小是有限制的，必須小于模擬的物理內(nèi)存空間大小，否則出錯。當讀者需要加強這部分內(nèi)容時，需要增加內(nèi)存分配算法。 時，有如下的限制： ? 系統(tǒng)一次只能有運行一個用戶程序 錯誤 !未找到引用源。 的正文段和數(shù)據(jù)段依次調(diào)入內(nèi)存，棧段記錄的是用戶程序的運行狀態(tài)，它的位置緊接于數(shù)據(jù)段之后。 線性頁表。如果大于整個模擬的物理內(nèi)存空間，出錯返回。 實現(xiàn)： 1. 判斷打開文件是否符合可執(zhí)行代碼的格式，如果不符合，出錯返回 2. 將用戶程序 錯誤 !未找到引用源。 生成方法 語法： AddrSpace (OpenFile *executable) 參數(shù)： Executable: 需要執(zhí)行代碼 的打開文件結構 功能： 初始化用戶程序 錯誤 !未找到引用源。 在 Linux系統(tǒng)中，使用 gcc交叉編譯技術將 C程序編譯成 R2/3000錯誤 !未找到引用源。 // 用戶程序 錯誤 !未找到引用源。 // 用戶程序 錯誤 !未找到引用源。 // 保存當前機器頁表狀態(tài) void RestoreState()。 //析構方法 void InitRegisters()。 //根據(jù)可執(zhí)行文件構成用戶程序 錯誤 !未找到引用源 。 其中，用戶程序 錯誤 !未找到引用源。 // 線程切換時恢復虛擬機寄存器組 NachOS課程設計 AddrSpace *space。 // 虛擬機 的寄存器組 void SaveUserState()。核心部分同一般的系統(tǒng)線程沒有區(qū)別，它共用了 Nachos 的正文段和數(shù)據(jù)段，運行在宿主機上；而用戶程序部分則有自己的正文段、數(shù)據(jù)段和棧段，它存儲在 Nachos 的模擬內(nèi)存中，運行在 Nachos 的模擬機上。 空間 （文件 , ） Nachos 的用戶進程由兩部分組成：核心部分和用戶程序 錯誤 !未找到引用源。 在實際的系統(tǒng)中，線性頁面地址轉換和 TLB頁面地址轉換只能二者取一，目前為簡便起見， Nachos 選擇了前者，讀者可以自行完成 TLB頁面地址轉換的實現(xiàn)。由于 TLB 轉換頁表是硬件實現(xiàn)的，所以指向TLB 轉換頁表的指針應該是只讀的，所以 Machine 類 錯誤 !未找到引用源。如果 TLB表已滿，就需要對 TLB 表項做 LRU替換。這樣就可能出現(xiàn)邏輯地址轉換失敗的現(xiàn)象，會發(fā)生 PageFaultException 異常。 TLB頁面轉換則不同， TLB轉換頁表是硬件來實現(xiàn)的，表的大小一般較實際的用戶程序 錯誤 !未找到引用源。當其被切換上模擬處理機上運行時，需要將進程的線性頁面轉換表覆蓋模擬處理機的線性頁面轉換表。在作轉換時，給出邏輯地址，計算出其所在的邏輯頁號和頁中偏移量，通過查詢轉換表（實際上在使用線性頁面地址轉換時， TranslationEntry結構中的 virtualPage 是多余的，線性頁面轉換表的下標就是邏輯頁號），即可以得到實際物理頁號和其頁中偏移量。 線性頁面地址轉換是一種較為簡單的方式，即用戶程序 錯誤 !未找到引用源。 的目的是為了執(zhí)行用戶程序 錯誤 !未找到引用源。 Nachos 處理的陷入有： 需要注意的是，雖然這里的很多方法和屬性規(guī)定為 public的，但是它們只能在系統(tǒng)核心內(nèi)被調(diào)用。系統(tǒng)調(diào)用可以看作是軟件指令，它們有效地彌補了機器硬件指令不足；系統(tǒng)出錯陷入在系統(tǒng)發(fā)生錯誤時發(fā)生，比如用戶程序使用了非法指令以及用戶程序邏輯地址同實際的物理地址映射出錯等情況。系統(tǒng)陷入有兩大類原因：進行系統(tǒng)調(diào)用陷入和系統(tǒng)出錯陷入。 在用戶程序 錯誤 !未找到引用源。所以 Nachos 的一些重要的數(shù)據(jù)結構如線程控制結構等的數(shù)目可以是無限的，不受 Nachos 模擬內(nèi)存大小的限制。事實上， Nachos 的內(nèi)存只有當需要執(zhí)行用戶程序 錯誤 !未找到引用源。為了簡便起見，每個內(nèi)存頁的大小同磁盤扇區(qū)的大小相同，而 整個內(nèi)存的大小遠遠小于模擬磁盤的大小。 的堆棧指針 RetAddrReg 31 存放過程調(diào)用的返回地址 HiReg 32 存放乘法結果的高 32位 LoReg 33 存放乘法結果的低 32位 PCReg 34 當前 PC指針 NextPCReg 35 下一條執(zhí)行語句的 PC指針 PrevPCReg 36 上一條執(zhí)行語句的 PC指針（調(diào)試用） LoadReg 37 需要延遲載入的寄存器編號 LoadValueReg 38 需要延遲載入的寄存器值 BadAddReg 39 當出錯陷入（ Exception）時用戶程序 錯誤 !未找到引用源。 機（ R2/3000錯誤 !未找到引用源。 三、 理解 Nachos中支持用戶進程的機制 Nachos 對內(nèi)存、寄存器以及 CPU的模 擬 Nachos 機器模擬很重要的部分是內(nèi)存和寄存器的模擬。 在現(xiàn)有的 Nachos 中，沒有給出條件變量的實現(xiàn)，條件變量的基本結構也只給出了部分內(nèi)容，其它內(nèi)容可以視實現(xiàn)決定。 // 喚醒 等待該條件變量的線程 private: char* name。 // 線程進入等待 void Signal(Lock *conditionLock)。 // 析構方法 char* getName() { return (name)。條件變量總是和鎖機制一同使用，它的基本結構如下： class Condition { public: Condition(char* debugName)。 條件變量 條件變量和信號量與鎖機制不一樣，它是沒有值的。 在現(xiàn)有的 Nachos 中，沒有給出鎖機制的實現(xiàn)，鎖的基本結構也只給 出了部分內(nèi)容，其它內(nèi)容可以視實現(xiàn)決定。 // 判斷鎖是否為現(xiàn)運行線程擁有 private: char* name。 // 獲得鎖方法 void Release()。 // 析構方法 char* getName() { return name。 鎖的基本結構如下所示： class Lock { public: Lock(char* debugName)。一個鎖有兩種狀態(tài)， BUSY 和 FREE。 2. value++。 2. 當 value大于 0時， value。 P操作 1. 當 value等于 0時， . 將當前運行線程放入線程等待隊列。線程等待隊列中存放所有等待該信號量的線程。 // 線程等待隊列 }。 // 信號量的 V操作 private: int value。 信號量 ( Semaphore ) Nachos已經(jīng)實現(xiàn)了 Semaphore，它的基本結構如下所示： class Semaphore { public: void P()。 在同步互斥機制的實現(xiàn)中，很多操作都是原子操作。 c: 測試終端輸入輸出 和文件系統(tǒng)有關的選項： f: 格式化模擬磁盤 cp: 將一個文件從宿主機拷貝到 Nachos模擬磁盤上 p: 將 Nachos磁盤上的文件顯示出來 r: 將一個文件從 Nachos模擬磁盤上刪除 l: 列出 Nachos模擬磁盤上的文件 D: 打印出 Nachos文件系統(tǒng)的內(nèi)容 t: 測試 Nachos文件系統(tǒng)的效率 和網(wǎng)絡有關的選項： n: 設置網(wǎng)絡的可靠度（在 01之間的一個小數(shù)） NachOS課程設計 m: 設置自己的 HostID o: 執(zhí)行網(wǎng)絡測試程序 6. 同步機制模塊分析（文件 ） 線程的同步和互斥是多個線程協(xié)同工作的基礎。（由于不是每時 每刻都檢查棧段是否溢出，所以這時候線程的運行可能已經(jīng)出錯） 3. 將 nextThread的狀態(tài)設置成運行態(tài)，并作為 currentThread現(xiàn)運行線程（在調(diào)用 Run方法之前，當前運行線程已經(jīng)放入就緒隊列中，變成就緒態(tài)） （以上是運行在現(xiàn)有的線程?？臻g上，以下是運行在 nextThread的?？臻g上） 4. 切換到 nextThread線程運行 5. 釋放 threadToBeDestroyed線程需要?？臻g（如果有的話） NachOS課程設計 6. 如果是用戶線程，恢復當前虛擬機的狀態(tài) 返回： 空 5. Nachos主控模塊分析（文件 ） 該模塊是整個 Nachos 系統(tǒng)的入口，它分析了 Nachos 的命令行參數(shù)，根據(jù)不同的選項進行不同功能的初始化設置。讀者可以在這一點上進行加強，實現(xiàn)有優(yōu)先級的線程調(diào)度。調(diào)度算法非常簡單，就是取出第一個放在處理機運行即可。 } 返回： 空 4. 線程調(diào)度算法模塊分析（文件 ） 該模塊的作用是進行線程的調(diào)度。 machineState[WhenDonePCState] = (int) ThreadFinish。 machineState[InitialPCState] = (int) func。 // 設置棧溢出標志 machineState[PCState] = (int) ThreadRoot。 ThreadRoot函 數(shù) // 將會開中斷，并調(diào)用 func(arg)成為一個獨立的調(diào)度單位。 // 設置棧首指針 *(stackTop) = (int)ThreadRoot。 NachOS課程設計 實現(xiàn)： void Thread::StackAllocate (VoidFunctionPtr func, int arg) { stack = (int *) AllocBoundedArray(StackSize * sizeof(int))。 實現(xiàn)： 1. 申請線程?？臻g 2. 初始化該?？臻g，使其滿足 SWITCH函數(shù)進行線程切換的條件 3. 將該線程放到就緒隊列中。 UserRegisters[]數(shù)組變量和 SaveUserState(), RestoreUserState()方法就是為了用戶進程的切換設計的。 // 線程運行的用戶程序 錯誤 !未找到引用源。 // 線程切換時保存虛擬機寄存器 void RestoreUserState()。