基于Linux的Gameboy模擬器移植和優(yōu)化研究

移植

　　Gnuboy在此平臺上的正確運行需要解決中斷、提供Framebuffer支持、數據存儲格式、字符串到64位整數轉換等問(wèn)題。

中斷問(wèn)題

　　Gnuboy需要依賴(lài)宿主操作系統(這里是L inux)來(lái)提供輸入/輸出等基本服務(wù),讓宿主操作系統作為它與硬件設備的中間人,這種游離于硬件通信細節之外的方法具有良好的可移植性,本文要解決的主要是提供對鍵盤(pán)輸入和游戲控制終端的中斷響應和處理。

　　在本文構建的平臺下,需要編寫(xiě)相應的鍵盤(pán)和游戲控制終端的Linux驅動(dòng)程序,以模塊方式加載后,在Gnuboy中打開(kāi)該設備。對應鍵盤(pán)處理,在Gnuboy中需要調整相應的鍵盤(pán)設置代碼使之與系統一致。

　　提供Framebuffer支持

　　Framebuffer技術(shù)提供了一個(gè)訪(fǎng)問(wèn)物理圖形設備的定義良好的接口,本文構建的平臺下采用的是Qt系統的嵌入式版本,它是基于Framebuffer的, Gnuboy要在該平臺下運行,必須提供對Framebuffer的支持。通過(guò)訪(fǎng)問(wèn)/dev/ fb0來(lái)取得系統framebuffer中用于顯示圖像的數據和進(jìn)行處理。在Gnuboy中調用游戲畫(huà)面的Framebuffer地址和掃描方法也需要作響應的修改。

　　修改Framebuffer地址,也就是獲得游戲畫(huà)面的開(kāi)始地址在內存中的位置。針對采用的LCD 的分辨率, 需要在Gnuboy中計算Framebuffer地址處做出相應修改。對于本平臺中采用的LCD, Gnuboy刷新處理方法是從第一行開(kāi)始,逐行刷新,同時(shí)由于一個(gè)像素采用兩個(gè)字節,因此在逐行刷新時(shí),每次寫(xiě)兩個(gè)字節。

　　數據存儲格式和字符串到64位整數轉換

　　在A(yíng)RM Linux下可配置成大數端或者小數端格式來(lái)保存和處理整數數值,在Gnuboy中與數值存儲字節順序有關(guān)的代碼需要與之對應。

　　Linux明顯缺乏用來(lái)把整數字符串轉換為64位整數的函數,如果字符串參數突破32位的極限,就有可能出問(wèn)題,因此在Gnuboy需要提供字符串到64位整數的的轉換函數。

　　設置啟動(dòng)模擬器路徑和編譯

　　在用戶(hù)已經(jīng)選擇好游戲Rom,點(diǎn)擊launch simulator按鈕觸發(fā)啟動(dòng)模擬器,進(jìn)入游戲功能,因此在Gnuboy代碼中需要獲得rom的絕對路徑,由于QT操作系統無(wú)法在代碼中直接運行qtop iagnuboy命令,因此需要給出該可執行文件的絕對路徑。

　　源代碼修改好以后,在Makefile中設定交叉編譯器: CC= arm - linux - gcc, CXX = arm - linux - g + +。編譯時(shí)要用到針對ARM的函數庫可以把函數庫放在一個(gè)自己建的一個(gè)目錄,為了讓gcc 在搜索函數庫時(shí)到指定的目錄中尋找,可在Makefile的通過(guò)- L參數添加存放針對ARM函數庫的目錄。例如QTOP IA L IBS = - L ＄(QPED IR) / lib。

　　經(jīng)過(guò)交叉編譯后把得到的可執行文件qtop iagnuboy和qtop iagnuboyl燒到嵌入式系統中可以運行,然后不足之處是畫(huà)面速度有些慢,這正是下面優(yōu)化要研究的問(wèn)題。

Gnuboy在A(yíng)RM Linux下的優(yōu)化

　　優(yōu)化概述

　　如果說(shuō)CISC的指導思想之一是為了減輕編譯的負擔,R ISC則向編譯提出了更高的要求,ARM作為一種R ISC體系結構,優(yōu)化問(wèn)題顯得非常重要。從圖4 的抽象層次可以知道,對Gnuboy的優(yōu)化問(wèn)題,概括來(lái)說(shuō)是對它一些抽象代碼進(jìn)行硬件相關(guān)代碼替代的過(guò)程,并且越是底層的代碼,速度越快,這里直接用ARM匯編語(yǔ)言來(lái)改寫(xiě)一些原來(lái)的C函數。前面的移植運行結果已經(jīng)顯示, Gnuboy的圖像顯示較慢。它的函數void lcd refreshline ( )的主要功能是使用已經(jīng)解碼好的圖像數據來(lái)完成游戲畫(huà)面的顯示。對它的優(yōu)化主要是對它里面調用的兩個(gè)用C語(yǔ)言所寫(xiě)函數updatepatp ix ( )和bg scan color ( )函數的優(yōu)化。

　　本文采用了與機器相關(guān)優(yōu)化的優(yōu)化技術(shù),與機器相關(guān)的優(yōu)化這里主要是寄存器分配問(wèn)題,一般寄存器分配算法是基于一種稱(chēng)為圖著(zhù)色技術(shù)的。給定一個(gè)無(wú)向圖G= (V , E ) ,V 是有限節點(diǎn)的集合,V = { v 1, v 2, ., v n} , E是邊的集合, E = { ( i, j ) | v i∈V , v j∈V , v i和v j相連} , 圖著(zhù)色問(wèn)題要求找到一個(gè)k盡量小的所有節點(diǎn)的賦值(也稱(chēng)“完全賦值”) C: V — > {1.k } , 要求在該完全賦值中, 若( i,j ) ∈E , 則C ( v i) ≠C ( vj) 。

　　簡(jiǎn)化的圖著(zhù)色技術(shù)應用

　　針對本文的優(yōu)化,第一階段是把C函數用偽ARM匯編指令(即用符號寄存器Ui替代真正ARM寄存器的ARM指令)改寫(xiě)。

　　第二階段對符號寄存器U1～Un ( n > 15)畫(huà)出相干圖并進(jìn)行著(zhù)色,所謂對圖進(jìn)行著(zhù)色是指給圖中的每個(gè)結點(diǎn)賦予一種顏色,而且所有相鄰的兩個(gè)結點(diǎn)都具有不同的顏色。這樣,每種顏色就對應于處理器中的一個(gè)實(shí)際的物理寄存器,如此著(zhù)色保證了所有可能發(fā)生沖突的符號寄存器都被賦予不同的物理寄存器。

　　假設n + 1個(gè)符號寄存器的相干圖如圖5 ( a)所示,其中結點(diǎn)是符號寄存器,而結點(diǎn)之間的弧線(xiàn)表示變量的生命周期有重疊,最少需要16種顏色才能避免相連結點(diǎn)顏色有重疊。由于A(yíng)RM920T只有r0～r14等15個(gè)寄存器可用于存儲程序變量,小于16,也就是存在寄存器沖突問(wèn)題,這個(gè)時(shí)候就可以通過(guò)選擇刪除一個(gè)結點(diǎn)(如圖中Un + 1) ,也就是把U6對應的數據存儲到存儲器中,以后再重裝入寄存器來(lái)達到對各寄存器進(jìn)行釋放的目的,見(jiàn)圖5 ( b)所示,虛線(xiàn)圓圈表示符號寄存器U16對應的數據轉存到存儲器中。

用上面介紹的方法對updatepatp ix和bg scan color函數進(jìn)行處理,得到的ARM匯編函數,用它們替換掉gnuboy源代碼中原先的C函數并進(jìn)行編譯生成可執行文件,可執行文件在構建的測試板上運行良好。下面對上面提到的優(yōu)化來(lái)進(jìn)行一些測試。

測試評估

　　用CodeWarrior forARM Developer Suite和AXD Debugger軟件測試優(yōu)化前后函數的運行時(shí)間,結果如表1所示。圖著(zhù)色技術(shù)強調實(shí)現活躍變量的100%分配,并且代碼需要寄存器數量越多,優(yōu)化效果越明顯,這從updatapatp ix和bg scan color函數的優(yōu)化中可以看出(前者代碼較后者復雜,需要存放的臨時(shí)變量也多) 。進(jìn)一步優(yōu)化gnuboy,可用類(lèi)似的方法替換源代碼的另外一些影響速度較大的函數。

總結

　　本文構建了一個(gè)基于A(yíng)RM920T嵌入式Linux的實(shí)驗平臺環(huán)境, gnuboy作為一種虛擬機,應用到這樣的嵌入式環(huán)境中遇到的問(wèn)題具有一定的代表性,最需要解決的問(wèn)題是速度問(wèn)題,針對于此,本文實(shí)現了它在所構建的平臺上的移植和一些優(yōu)化研究。