基于gnuboy虛擬機的嵌入式實驗平臺的移植與優(yōu)化

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

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

　　數(shù)據(jù)存儲格式和字符串到64位整數(shù)轉(zhuǎn)換

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

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

　　設(shè)置啟動模擬器路徑和編譯

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

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

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

　　Gnuboy在ARM Linux下的優(yōu)化

　　優(yōu)化概述

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

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

　　簡化的圖著色技術(shù)應(yīng)用

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

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

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

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

　　測試評估

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

　　總結(jié)

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