異質雙核心 Java 處理器

RISC Core

Java Core

External memory controller Mailbox

system bus

I/O controller interrupt

Bytecode Execution Engine

DDR-SDRAM (Class images pool)

Dynamic Resolution

Controller

CF card (application classes)

Method Area Manager Method Image CircularBuffer ClassSymbolTabler

Circular Buffer Java

Stack Exception

Handler Interrupt

Service Routines

Object Heap Space

Cross 處理器來執行我們所提供的系統軟體，這部分包括類別解析器（Class Parser）、對 Java 部分指令支援所提供的程序以及實作系統類別所提供的原生方法（Native method）實 作，並且在系統軟體上的實作上，我們是採用 Sun Microsystems 所提出的 JavaOS model[32]僅需仰賴平台提供的精簡系統函式庫，做為底層硬體的 Hardware Abstraction Layer (HAL)無需仰賴全功能作業系統的支援，這樣的特性也讓我們可以整合至任何現

6

有的作業系統或處理器中。在這個架構下，對於 Inter-process communication(IPC)採用較 簡單的介面完成單方向呼叫的機制，即讓 JAIP 可以透過這個機制呼叫到 RISC 處理器所 提供的服務。並在 JAIP 上利用 8 個暫存器做為 MailBox 的傳遞機制，以透過中斷處理 的方式，將 Java 加速處理器所要傳遞的參數，傳遞給 RISC 處理器。因此在執行 Java 應用程式時，絕大部分的 Java 位元組碼可在高效能的 Java 處理器上運作。只有少部分 的位元組碼牽涉到 I/O 控制或 Java 類別檔案載入及解析，會透過中斷交由 RISC 處理 器的中斷處理機制(Interrupt Service Routine)來實作。

Translate Stage

48-bits Instruction

Buffer

Fetch Stage Decode Stage Execute Stage

Dynamic Resolution Circuitry

Bytecode Class Sifier

Lookup Rom

Fetch Controller Hazard Detector j_code Sequence ROM

j_code Decoder IPC Request

Controller

Double-issue Datapath

Two-level Java Stack J_code

Info. j_codes

Ctrl.

branch flag IPC request

operands

bytecodes / operands

enable branch flag

圖 3. Four-stage pipelines of bytecode execution engine

JAIP 的設計是可以同時間執行雙指令，Java 位元組碼運作於執行引擎(如圖 3 所 示)。此位元組碼執行引擎採用 four-stage pipeline 架構，包含 Translate Stage、Fetch Stage、

Decode Stage 和 Execute Stage。由於 JAIP 是一個獨立的 IP 並不需依賴任何處理器的架 構，因此可以較容易的將 JAIP 整合到任何有支援利用中斷去執行 Inter-process

communication 的處理器上。

在 JAIP 的實作上定義了自己的一套 Instruction Set Architecture(ISA)稱之為 j_code 用以執行 Java 位元組碼，並將 Java 位元組碼型態分類成 simple、complex 以及 operand 三種。大部分指令都是一對一的轉換，稱之為 simple。少部分的指令(例如 invoke 指令 等)則是轉換成 code sequence，稱之為 complex。附帶在指令後面的參數則稱之為 operand。當 Translate Stage 從 Instruction Buffer 中取得位元組碼後。如果取得的是 simple

7

指令，則單純地轉換成單一 j_code 並送到 Fetch Stage。如果取得的是 complex 指令，即 會轉成對應於 Fetch Stage 的 j_code sequence 起始位址。若取得的是 operand，則此 operand 的值將會在 Decode Stage 直接由 Instruction Buffer 中提取。Fetch Stage 每個週期 負責傳送一對 j_code 指令到 Decode Stage。如果從 Translate Stage 傳送過來的是 complex 指令的 j_code sequence 起始位址，則會從 j_code sequence ROM 中提取一對 j_code 指令 送到 Decode Stage。然而在 j_code sequence ROM 中指令皆是成對的，有些成對的指令 可能會使用到 NOP。當 Fetch Stage 把真正要執行的 j_code 傳到 Decode Stage 之後，

Decode Stage 便會同時解析傳過來的一對指令並產生相應的控制訊號以及拉起某些特 定訊號。最後 Execute Stage 即根據 Decode stage 所生成的控制訊號來執行相關運作。

Java 虛擬機器是為 stack-based 的設計，因此在 JAIP 的實作中堆疊架構與堆疊的運 作也是設計的重點。為了實現雙指令執行的運作，JAIP 設計了一組特別的 Two-level Java stack memory(如圖 4 所示)，第一層是由三個暫存器所組成，負責去存放 Java stack 最上 方的三筆資料。第二層的 Java stack 則是由兩塊 Dual-port On-chip BRAM 來實作交錯式

（Interleaving）的記憶體架構，並針對每一塊 BRAM 將 Dual-Port 分成 Read 以及 Write 的兩個 Port。並使用四個暫存器作為存取較為頻繁的前四個區域變數的快取，用來支援 對前四個區域變數的存取指令，

Customized 4-port memory

LV 0 LV 1 LV 2 LV 3

Java Stack dual-port

圖 4. Two-level Java stack memory

8

Normal

Get Xrt Ref

Offset Access

Method List Searching Class

Parsing Field

Store

Field Load

Native [multicycle]

MA&

CST Loading Stack

Initialization [6 cycles]

GetObjClsID [3 cycles]

圖 5. Dynamic resolutionru 機制有限狀態機

當 JAIP 在執行 Java 程式時，是將 JAR 檔內所有的檔案先全部載入到記憶體中，

但卻並不是一開始就將所有類別全部解析。而是當所要呼叫方法(Method)的類別尚未被 解析時，才交由於 RISC 處理器上由系統軟體所實作的類別解析器（Class Parser）來做 解析並產生適用於 JAIP 的執行映像檔（Run Time Image），並將解析完畢的映像檔會保 留在記憶體中。此外會由類別解析器維護一張 Class Parsing Table[31]，此張表格主要用 於紀錄各類別的詳細資訊，例如類別編號、名稱、記憶體位址、繼承與介面資訊、Field Data 與 Method 的參照資料等。由於當 Java 程式於 JAIP 上執行時，Field Data 存取及呼 叫方法時都需要經常查找這個資訊，所以類別解析器會將這兩項資料整理並存放於由 On-chip BRAM 所組成的 Cross Reference Table 之中。因此當 JAIP 在執行 Field Data 存 取及呼叫方法時，會先啟動 dynamic resolution 機制(如圖五所示)，會去查找 Cross Reference Table 內所需的資訊(如圖 6 所示)。若是存取 field data 會取得 offset 值去計算

9

存放於 Heap space 的 object data 位址。若是執行呼叫方法，則會取得所要呼叫方法的 Class ID 跟 Method ID。

Cross Reference Table

Field data[0] Class ID & Object offset

Method[0]

Descriptor & Class ID Class ID & Method ID Link-List Pointer

… … … …

圖 6. Cross Reference Table 類別存放資訊