ARM 與 MIPS 比較 (X86)

http://blog.163.com/tao198352__4232/blog/static/8502064520105984211236/?fromdm&fromSearch&isFromSearchEngine=yes

 

 

1.流水線結構 pipeline
    - MIPS 是最簡單的體繫結構之一，所以使大學喜歡選擇 MIPS 體繫結構來介紹計算體繫結構課程。
    - ARM has barrel shifter
        shifter是兩面性的，一方面它可以提高數學邏輯運算速度，另一方面它也增加了硬體的複雜性。所以和可以完成同樣功能的adder/shift register相比，效率更高，但是也     佔用更多的晶片面積。
       
    - MIPS have "branch delay slot" and "load delay slot"
        MIPS使用編譯器來解決上面的兩個問題。因為MIPS最初的設計思想就是使用簡單的RISC硬體，然後靠編譯器及其他軟體技術，來達成RISC的完整概念。

2.指令結構 instruction
    - MIPS have 32bit and 64bit architecture,but ARM only have 32bit architecture
       ARM11 局部64位
    - MIPS是開放式的架構,使用者可以在開發的核心中加入自己的指令，
    - ARM has 4-bit condition code in every instruction
      ARM 在這一點很像x86。MIPS在MIPS IV也加入"conditional move"指令，來提高pipeline的效率。
    - ARM has pre- and post-increment addressing modes
        auto-increment/decrement on load/store instructions
    - 在節省代碼空間方面，MIPS16 很類似ARM Thumb

3.寄存器 register
    -  由於MIPS核心中有32個註冊器（Register），而ARM只有16個，這種結構設計上的先天優勢，決定了在同等效能表現下，MIPS的晶片面積和功耗會更小。
    -  ARM 有一組特殊用途寄存器cp0-cp15,可以使用MCR,MRC等指令控制; 相對應的，MIPS也有cp0 0-30,使用mfc0,mtc0 指令控制。

    -  Register banking in ARM.  r8-r12 FIQ mode;r13:SP r14 R
       感覺不出banked register有什麼好處。

    -  MIPS has a hard-wired-to-zero register ,but ARM not
       MIPS use register $0 for Zero

4.地址空間 address space
    -  MIPS 起始地址是0xbfc00000,會有4Mbyte的大小限制，但一般MIPS晶片都會採取一些方法解決這個問題。
       ARM沒有這種問題。
       MIPS24K 起始地址改到了0xbf000000,現在有16Mbyte的空間了。

    -   MIPS don't have to turn paging on to enable the cache.
        MIPS have the address space for both cache and un-cache
        but ARM need enable/disable cache

5.功能 function
    -   Float point: MIPS64 has.
        ARM's support for FP is limited, and usually not included, and it is a 32 bit architecture
    -   ARM use JTAG,MIPS use EJTAG。Debug工具一般兩種都支援。使用起來感覺差不多。

6.效能 performance
    -  具體效能比較，因為差異性太大，所以很難分出誰好誰壞。從個人經驗來講 MIPS4k和ARM9基本上是同一個層級的,但ARM9效能似乎要比MIPS4K好。
       同樣是32bit的MIPS24K效能上比MIPS4K有很大提升，也應該比ARM9要好些。
       因為沒有用過ARM11和MIPS34K的晶片，沒法比較，但感覺這兩個似乎是一個層級的。

7.應用
    -  在1000MHz以上的應用,很難找到採用ARM架構的產品。
       MIPS架構用在200MHz或者是266MHz以下的應用比較少,而這恰恰是ARM的主攻市場。
    -  ARM 在手機等攜帶型領域,MIPS 在住宅網關、線纜數據機、線纜機頂盒等
    -  ARM 採用硬核授權;MIPS 採用軟核授權，使用者可以自己配置，做自己的產品。

8.未來發展
    -  ARM的下一代走向多核心結構，而MIPS公司的下一代核心則轉向硬體多線程功能(multithreading)
       MIPS 的multithreading 很類似Intel 的 HyperThreading技術。從現在的發展來看，多核心佔上風。

 

 

 

 

 

http://ydragongfly.blog.sohu.com/116425075.htm

 

1. MIPS 與 X86 的 TLB 差別

其在於對 TLB 不命中時的處理上：

MIPS 會觸發TLB Refill 異常，核心的 tlb_refill_handler 會以 pgd_current 為當前進程的 PGD 基址，索引獲得轉換失敗的虛址對應的 PTE，並將其填入 TLB，完了CPU 把剛剛轉換失敗的虛地址再走一下 TLB 就OK了。

而 X86 在 TLB 不命中時，是由硬體 MMU 以 CR3 為當前進程的 PGD 基址，索引獲得 PFN 後，直接輸出 PA。同時 MMU 會填充 TLB 以加快下次轉換的速度。

另外轉換失敗的虛址，MIPS 使用 BadVAddr 寄存器存放，X86 使用 CR2 存放。

2. 關於 MIPS32 頁表的大小問題，系統每 fork 一個進程或者 clone 一個進程沒有CLONE_VM標誌，核心都會調用 __get_free_pages 為新進程分配一個頁給頁目錄表，前512項初始化都指向invalid_pte_table（空頁表，共有 PAGE_SIZE/sizeof(pte_t) 項），後面的都從 init 進程繼承。而後核心會根據新進程所需的儲存空間大小，為其分配頁表（大小為一個頁），分配記憶體頁，設定相應的頁表項，設定對應的頁目錄表項。

可以看到，只要進程數目固定式頁面目錄表所需的空間是固定的，每個進程頁目錄表為一個頁大小；而進程總頁表的大小要依賴於進程代碼、資料的大小。

一個典型的 MIPS32 系統，頁大小為4KB，單一使用者模式，僅有bash進程，其頁表大小為 48KB 左右（cat /proc/meminfo|grep PageTables）；頁目錄的大小可由下式計算：

PGD_SIZE = NR_PROCESS(exclude kernel thread) * PAGE_SIZE

3. MIPS TLB 的每項的主要資料有： ｜ G | ASID | VPN | PFN | ，其中 VPN 為 virtual page number， PFN 為 physical frame number。 項與項之間沒有次序，CPU 轉換時是直接匹配的。不能稱為 Page Table 。

而 Page Table 當年設計成 數組結構，以數組的下標作為虛頁號是經過考慮的，即使今天看來，我們依然能夠體會它的巧妙。

4. 核心在從組合語言跳到C語言中時，其棧的棧頂是在哪裡設定的？

核心在進入 start_kernel 前，將 esp 指向了 init_thread_union + THREAD_SIZE， init_thread_union 位於 .data.init_task 節，是個 union 結構，其大小為 THREAD_SIZE，定義的比較巧妙：

union thread_union {
struct thread_info thread_info;
unsigned long stack[THREAD_SIZE/sizeof(long)];
};

5. 核心態線程、核心線程以及進程的核心棧問題

linux 下線程庫的實現，以常用的 Linuxthread 或者 NPTL 為例，這些庫建立線程是使用這些標誌　CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND　調用 clone()　來實現的，就是一個輕量級進程。

在使用　fork, vfork, clone　這些函數建立進程或者輕量級進程時，核心都會調用　alloc_task_struct() 為其分配一個 task_struct；調用 alloc_thread_info() ，表面上看好像是分配 thread_info 結構，實際上：

#define alloc_thread_info(tsk) kmalloc(THREAD_SIZE, GFP_KERNEL)

分配了 THREAD_SIZE 的空間，底端為　thread_info ，指向它的指標儲存於 task_struct->thread_info 中。可以看到，task_struct->thread_info + THREAD_SIZE 即為進程或者輕量級進程的核心棧棧底。

無論是使用 clone 產生輕量級進程，還是使用 kernel_thread 建立核心線程，他們都會進入 do_fork，進而調用 alloc_thread_info()，因此他們都有核心棧，大小為 THREAD_SIZE，底端為 thread_info 。

因此linux 下，每個線程都會有一個核心棧，這個當線程數目很大時是個問題。