基于ARM Linux的Gameboy模拟器移植和优化研究

引言

　　面向A R M微处理器构架的嵌入式操作系统的使用量这些年持续增长,在各种嵌入式操作系统中, L inux是获得支持最多的第三大力量。

　　目前,ARM L inux支持包括ARM610、A RM710、ARM720T cores、ARM920T cores、StrongARM 110、StrongARM1100、XScale等系列的ARM处理器。

　　Gameboy是目前比较流行的8位掌上游戏机,通常被简称为GB,它的最终态Game Boy Color (GBC)是完全向后兼容的。Gnuboy是GB /GBC的软件模拟器,是一种自由软件,它是基于Qt系统的,能够运行几乎所有的黑白和彩色的GB /GBC游戏ROM,但运行复杂一些的游戏需要在速度上得到加强,同时它的声音还没有得到测试。

　　Gnuboy已经实现了i386汇编代码的一些优化工作,能够在奔腾机器上运行良好,除此之外,到目前为止,它能够运行的平台还很有限。随着嵌入式系统设计技术的发展,PDA、Smartphone等嵌入式产品的功能不断地得到扩展,适应用户的需要, Gnuboy在嵌入式产品中的移植应用非常具有前景。目前Gnuboy在ARM Linux下还没有得到很好的应用,本文就是在构建的基于ARM920T Linux的嵌入式平台上对gnuboy运用进行的尝试性工作,同时, Gnuboy作为一种虚拟机技术,本文的工作对研究虚拟机技术在ARM L inux中的应用也具有一定的价值。

　　硬件环境

　　本实验测试板采用Motorola公司的MX1 Lite,系统的主要模块有处理器内核模块、用户接口模块、连接设备模块等,如图1所示,下面分别进行介绍。

1)处理器内核模块采用v4T体系结构的ARM920T 内核拥有16K的指令缓存和16K的数据缓存; 外部接口模块提供了最多6 个片选信号来访问外部设备,其中连接的12Kx16bits的NOR Flash 经过配置用于系统启动; SDRAM 控制器提供了对使用32Mx32bits的SDRAM的访问控制。

　　2)用户接口模块由于MX1 L ite没有模拟信号处理模块,无法直接接收触摸屏的输入,所以本系统采用了TI的TSC2301芯片来支持触摸屏的输入功能,它与主芯片通过连续外设接口协议连接,它不仅可以接收触摸屏的输入,而且它还支持声音数模转换和输入输出等功能; LCD 控制器用于给外部液晶显示屏提供显示数据,LCD采用了Sharp 的20x240 HR - TFT LCD,它支持触摸屏输入,分辨率为320x240。

　　3)连接设备模块包含有多媒体卡/数字安全主机控制模块、内存棒控制器和智能卡接口,以此来连接用于外部存储的多媒体卡。

　　Gnuboy软件结构和一些工具软件

　　Gnuboy是基于Qt系统的,可从图2中看出它和整个系统的关系。本文构建的基于ARM920T的嵌入式L inux平台下采用的是嵌入式系统的QT 版本: QT/Embedded 和Qtop ia(QPE) ,这有助于模拟器的移植。

QT/Embedded和Qtopia

　　QT/Embedded和Qtopia是著名的QT库开发商TrollTech开发的基于Framebuffer、面向嵌入式系统的QT版本。它的特点是界面美观、色彩配比好,使用与QT/Windows和QT/X11 完全一致的AP I接口,许多基于QT的程序可以非常方便地移植到嵌入式系统。Qtopia 包括了全套的个人信息管理PIM,如地址本、日程安排、游戏、配置工具等。QT/Embedded实现了对下层输入设备的驱动和底层图形接口以及各基类和AP I,它在编译后生成函数库被应用程序调用。Qtopia也是以客户/服务器的方式,通过消息机制来管理各种应用程序。图3描述了QT应用程序的执行方式及系统结构,其中X Server是核心。

一些工具软件

　　移植前需要在宿主机上建立ARM 的交叉编译环境,主要用到的开发工具包括三个部分: binutils、gcc、glibc。

　　● Binutils — 用于操作二进制文件的实用程序集合,包括诸如汇编器as、二进制转换工具( objdump、objcopy) 等这样的实用程序;

　　● Gcc — GNUC编译器(C编译器gcc和C + +编译器g + + ) ;

　　● Glibc —所有应用程序将链接到的C库。

　　可以直接从Internet上下载已经编译的二进制文件安装到PC机上,并相应设置比如路径等这样一些比较简单的参数即可使用,但必须保证编译时所用的函数库版本与目标板上运行时所使用的函数库版本的一致。ARM Developer Suite它是全套的实时开发软件工具包,编译器生成的代码密度和执行速度优异,可快速低价地创建ARM结构应用。

　　移植和优化

　　Gnuboy是一种虚拟机机制,它对具体硬件的操作是通过操作系统(这里是L inux)来进行的,图4 为它对基于ARMlinux平台硬件操作的抽象层次。

这个抽象层次也适用于在ARM Linux平台下用C语言编写的一般虚拟技术应用。越是顶层越是抽象,代码可移植性就越好;越是底层,越是硬件相关,代码可移植性就越差,但代码执行速度越快。这也是一般虚拟机移植和优化思想的体现,提高移植性,多运用抽象的接口,提高速度,多一些直接操作硬件的代码。

　　移植

　　Gnuboy在此平台上的正确运行需要解决中断、提供Framebuffer支持、数据存储格式、字符串到64位整数转换等问题。[!--empirenews.page--]

　　中断问题

　　Gnuboy需要依赖宿主操作系统(这里是L inux)来提供输入/输出等基本服务,让宿主操作系统作为它与硬件设备的中间人,这种游离于硬件通信细节之外的方法具有良好的可移植性,本文要解决的主要是提供对键盘输入和游戏控制终端的中断响应和处理。

　　在本文构建的平台下,需要编写相应的键盘和游戏控制终端的Linux驱动程序,以模块方式加载后,在Gnuboy中打开该设备。对应键盘处理,在Gnuboy中需要调整相应的键盘设置代码使之与系统一致。

　　提供Framebuffer支持

　　Framebuffer技术提供了一个访问物理图形设备的定义良好的接口,本文构建的平台下采用的是Qt系统的嵌入式版本,它是基于Framebuffer的, Gnuboy要在该平台下运行,必须提供对Framebuffer的支持。通过访问/dev/ fb0来取得系统framebuffer中用于显示图像的数据和进行处理。在Gnuboy中调用游戏画面的Framebuffer地址和扫描方法也需要作响应的修改。

　　修改Framebuffer地址,也就是获得游戏画面的开始地址在内存中的位置。针对采用的LCD 的分辨率, 需要在Gnuboy中计算Framebuffer地址处做出相应修改。对于本平台中采用的LCD, Gnuboy刷新处理方法是从第一行开始,逐行刷新,同时由于一个像素采用两个字节,因此在逐行刷新时,每次写两个字节。

　　数据存储格式和字符串到64位整数转换

　　在ARM Linux下可配置成大数端或者小数端格式来保存和处理整数数值,在Gnuboy中与数值存储字节顺序有关的代码需要与之对应。

　　Linux明显缺乏用来把整数字符串转换为64位整数的函数,如果字符串参数突破32位的极限,就有可能出问题,因此在Gnuboy需要提供字符串到64位整数的的转换函数。

　　设置启动模拟器路径和编译

　　在用户已经选择好游戏Rom,点击launch simulator按钮触发启动模拟器,进入游戏功能,因此在Gnuboy代码中需要获得rom的绝对路径,由于QT操作系统无法在代码中直接运行qtop iagnuboy命令,因此需要给出该可执行文件的绝对路径。

　　源代码修改好以后,在Makefile中设定交叉编译器: CC= arm - linux - gcc, CXX = arm - linux - g + +。编译时要用到针对ARM的函数库可以把函数库放在一个自己建的一个目录,为了让gcc 在搜索函数库时到指定的目录中寻找,可在Makefile的通过- L参数添加存放针对ARM函数库的目录。例如QTOP IA L IBS = - L ＄(QPED IR) / lib。

　　经过交叉编译后把得到的可执行文件qtop iagnuboy和qtop iagnuboyl烧到嵌入式系统中可以运行,然后不足之处是画面速度有些慢,这正是下面优化要研究的问题。

　　Gnuboy在ARM L inux下的优化

　　优化概述

　　如果说CISC的指导思想之一是为了减轻编译的负担,R ISC则向编译提出了更高的要求,ARM作为一种R ISC体系结构,优化问题显得非常重要。从图4 的抽象层次可以知道,对Gnuboy的优化问题,概括来说是对它一些抽象代码进行硬件相关代码替代的过程,并且越是底层的代码,速度越快,这里直接用ARM汇编语言来改写一些原来的C函数。前面的移植运行结果已经显示, Gnuboy的图像显示较慢。它的函数void lcd refreshline ( )的主要功能是使用已经解码好的图像数据来完成游戏画面的显示。对它的优化主要是对它里面调用的两个用C语言所写函数updatepatp ix ( )和bg scan color ( )函数的优化。

　　本文采用了与机器相关优化的优化技术,与机器相关的优化这里主要是寄存器分配问题,一般寄存器分配算法是基于一种称为图着色技术的。给定一个无向图G= (V , E ) ,V 是有限节点的集合,V = { v 1, v 2, ., v n} , E是边的集合, E = { ( i, j ) | v i∈V , v j∈V , v i和v j相连} , 图着色问题要求找到一个k尽量小的所有节点的赋值(也称“完全赋值”) C: V — > {1.k } , 要求在该完全赋值中, 若( i,j ) ∈E , 则C ( v i) ≠C ( vj) 。

　　简化的图着色技术应用

　　针对本文的优化,第一阶段是把C函数用伪ARM汇编指令(即用符号寄存器Ui替代真正ARM寄存器的ARM指令)改写。

　　第二阶段对符号寄存器U1～Un ( n > 15)画出相干图并进行着色,所谓对图进行着色是指给图中的每个结点赋予一种颜色,而且所有相邻的两个结点都具有不同的颜色。这样,每种颜色就对应于处理器中的一个实际的物理寄存器,如此着色保证了所有可能发生冲突的符号寄存器都被赋予不同的物理寄存器。

　　假设n + 1个符号寄存器的相干图如图5 ( a)所示,其中结点是符号寄存器,而结点之间的弧线表示变量的生命周期有重叠,最少需要16种颜色才能避免相连结点颜色有重叠。由于ARM920T只有r0～r14等15个寄存器可用于存储程序变量,小于16,也就是存在寄存器冲突问题,这个时候就可以通过选择删除一个结点(如图中Un + 1) ,也就是把U6对应的数据存储到存储器中,以后再重装入寄存器来达到对各寄存器进行释放的目的,见图5 ( b)所示,虚线圆圈表示符号寄存器U16对应的数据转存到存储器中。

用上面介绍的方法对updatepatp ix和bg scan color函数进行处理,得到的ARM汇编函数,用它们替换掉gnuboy源代码中原先的C函数并进行编译生成可执行文件,可执行文件在构建的测试板上运行良好。下面对上面提到的优化来进行一些测试。

　　测试评估

　　用CodeWarrior forARM Developer Suite和AXD Debugger软件测试优化前后函数的运行时间,结果如表1所示。图着色技术强调实现活跃变量的100%分配,并且代码需要寄存器数量越多,优化效果越明显,这从updatapatp ix和bg scan color函数的优化中可以看出(前者代码较后者复杂,需要存放的临时变量也多) 。进一步优化gnuboy,可用类似的方法替换源代码的另外一些影响速度较大的函数。

总结

　　本文构建了一个基于ARM920T嵌入式Linux的实验平台环境, gnuboy作为一种虚拟机,应用到这样的嵌入式环境中遇到的问题具有一定的代表性,最需要解决的问题是速度问题,针对于此,本文实现了它在所构建的平台上的移植和一些优化研究。