`
RednaxelaFX
  • 浏览: 3052073 次
  • 性别: Icon_minigender_1
  • 来自: 海外
社区版块
存档分类
最新评论

虚拟机随谈(一):解释器,树遍历解释器,基于栈与基于寄存器,大杂烩

阅读更多
(Disclaimer:如果需要转载请先与我联系;文中图片请不要直接链接
作者:@RednaxelaFX -> http://rednaxelafx.iteye.com

大前天收到一条PM:
引用
你好,很冒昧的向你发短消息,我现在在看JS引擎,能过看博客发现你对js engine很了解,我想请教一下你 基于栈的解析器与基于寄存器的解析器有什么同,javascriptcore是基于寄存器的,V8是基于栈的,能不能说一下这两者有什么一样吗?能推荐一点资料吗?谢谢。

我刚收到的时候很兴奋,就开始写回复。写啊写发觉已经比我平时发的帖还要长了,想着干脆把回复直接发出来好了。于是下面就是回复:

你好 ^ ^ 很抱歉拖了这么久才回复。码字和画图太耗时间了。
别说冒昧了,我只是个普通的刚毕业的学生而已,担当不起啊 =_=||||
而且我也不敢说“很”了解,只是有所接触而已。很高兴有人来一起讨论JavaScript引擎的设计与实现,总觉得身边对这个有兴趣的人不多,或者是很少冒出来讨论。如果你发个帖或者blog来讨论这方面的内容我也会很感兴趣的~

想拿出几点来讨论一下。上面提出的问题我希望能够一一给予回答,不过首先得做些铺垫。
另外先提一点:JavaScriptCore从SquirrelFish版开始是“基于寄存器”的,V8则不适合用“基于栈”或者“基于寄存器”的说法来描述。

1、解析器与解释器

解析器是parser,而解释器是interpreter。两者不是同一样东西,不应该混用。

前者是编译器/解释器的重要组成部分,也可以用在IDE之类的地方;其主要作用是进行语法分析,提取出句子的结构。广义来说输入一般是程序的源码,输出一般是语法树(syntax tree,也叫parse tree等)抽象语法树(abstract syntax tree,AST)。进一步剥开来,广义的解析器里一般会有扫描器(scanner,也叫tokenizer或者lexical analyzer,词法分析器),以及狭义的解析器(parser,也叫syntax analyzer,语法分析器)。扫描器的输入一般是文本,经过词法分析,输出是将文本切割为单词的流。狭义的解析器输入是单词的流,经过语法分析,输出是语法树或者精简过的AST。
(在一些编译器/解释器中,解析也可能与后续的语义分析、代码生成或解释执行等步骤融合在一起,不一定真的会构造出完整的语法树。但概念上说解析器就是用来抽取句子结构用的,而语法树就是表示句子结构的方式。关于边解析边解释执行的例子,可以看看这帖的计算器。)
举例:将i = a + b * c作为源代码输入到解析器里,则广义上的解析器的工作流程如下图:

其中词法分析由扫描器完成,语法分析由狭义的解析器完成。
(嗯,说来其实“解析器”这词还是按狭义用法比较准确。把扫描器和解析器合起来叫解析器总觉得怪怪的,但不少人这么用,这里就将就下吧 =_=
不过近来“scannerless parsing”也挺流行的:不区分词法分析与语法分析,没有单独的扫描器,直接用解析器从源码生成语法树。这倒整个就是解析器了,没狭不狭义的问题)

后者则是实现程序执行的一种实现方式,与编译器相对。它直接实现程序源码的语义,输入是程序源码,输出则是执行源码得到的计算结果;编译器的输入与解释器相同,而输出是用别的语言实现了输入源码的语义的程序。通常编译器的输入语言比输出语言高级,但不一定;也有输入输出是同种语言的情况,此时编译器很可能主要用于优化代码。
举例:把同样的源码分别输入到编译器与解释器中,得到的输出不同:

值得留意的是,编译器生成出来的代码执行后的结果应该跟解释器输出的结果一样——它们都应该实现源码所指定的语义。

在很多地方都看到解析器与解释器两个不同的东西被混为一谈,感到十分无奈。
最近某本引起很多关注的书便在开篇给读者们当头一棒,介绍了“JavaScript解析机制”。“编译”和“预处理”也顺带混为一谈了,还有“预编译” 0_0
我一直以为“预编译”应该是ahead-of-time compilation的翻译,是与“即时编译”(just-in-time compilation,JIT)相对的概念。另外就是PCH(precompile header)这种用法,把以前的编译结果缓存下来称为“预编译”。把AOT、PCH跟“预处理”(preprocess)混为一谈真是诡异。算了,我还是不要淌这浑水的好……打住。


2、“解释器”到底是什么?“解释型语言”呢?

很多资料会说,Python、Ruby、JavaScript都是“解释型语言”,是通过解释器来实现的。这么说其实很容易引起误解:语言一般只会定义其抽象语义,而不会强制性要求采用某种实现方式。
例如说C一般被认为是“编译型语言”,但C的解释器也是存在的,例如Ch。同样,C++也有解释器版本的实现,例如Cint
一般被称为“解释型语言”的是主流实现为解释器的语言,但并不是说它就无法编译。例如说经常被认为是“解释型语言”的Scheme就有好几种编译器实现,其中率先支持R6RS规范的大部分内容的是Ikarus,支持在x86上编译Scheme;它最终不是生成某种虚拟机的字节码,而是直接生成x86机器码。

解释器就是个黑箱,输入是源码,输出就是输入程序的执行结果,对用户来说中间没有独立的“编译”步骤。这非常抽象,内部是怎么实现的都没关系,只要能实现语义就行。你可以写一个C语言的解释器,里面只是先用普通的C编译器把源码编译为in-memory image,然后直接调用那个image去得到运行结果;用户拿过去,发现直接输入源码可以得到源程序对应的运行结果就满足需求了,无需在意解释器这个“黑箱子”里到底是什么。
实际上很多解释器内部是以“编译器+虚拟机”的方式来实现的,先通过编译器将源码转换为AST或者字节码,然后由虚拟机去完成实际的执行。所谓“解释型语言”并不是不用编译,而只是不需要用户显式去使用编译器得到可执行代码而已。

那么虚拟机(virtual machine,VM)又是什么?在许多不同的场合,VM有着不同的意义。如果上下文是Java、Python这类语言,那么一般指的是高级语言虚拟机(high-level language virtual machine,HLL VM),其意义是实现高级语言的语义。VM既然被称为“机器”,一般认为输入是满足某种指令集架构(instruction set architecture,ISA)的指令序列,中间转换为目标ISA的指令序列并加以执行,输出为程序的执行结果的,就是VM。源与目标ISA可以是同一种,这是所谓same-ISA VM。
前面提到解释器中的编译器的输出可能是AST,也可能是字节码之类的指令序列;一般会把执行后者的程序称为VM,而执行前者的还是笼统称为解释器或者树遍历式解释器(tree-walking interpreter)。这只是种习惯而已,并没有多少确凿的依据。只不过线性(相对于树形)的指令序列看起来更像一般真正机器会执行的指令序列而已。
其实我觉得把执行AST的也叫VM也没啥大问题。如果认同这个观点,那么把DLR看作一种VM也就可以接受了——它的“指令集”就是树形的Expression Tree。

VM并不是神奇的就能执行代码了,它也得采用某种方式去实现输入程序的语义,并且同样有几种选择:“编译”,例如微软的.NET中的CLR;“解释”,例如CPython、CRuby 1.9,许多老的JavaScript引擎等;也有介于两者之间的混合式,例如Sun的JVM,HotSpot。如果采用编译方式,VM会把输入的指令先转换为某种能被底下的系统直接执行的形式(一般就是native code),然后再执行之;如果采用解释方式,则VM会把输入的指令逐条直接执行。
换个角度说,我觉得采用编译和解释方式实现虚拟机最大的区别就在于是否存下目标代码:编译的话会把输入的源程序以某种单位(例如基本块/函数/方法/trace等)翻译生成为目标代码,并存下来(无论是存在内存中还是磁盘上,无所谓),后续执行可以复用之;解释的话则是把源程序中的指令逐条解释,不生成也不存下目标代码,后续执行没有多少可复用的信息。有些稍微先进一点的解释器可能会优化输入的源程序,把满足某些模式的指令序列合并为“超级指令”;这么做就是朝着编译的方向推进。后面讲到解释器的演化时再讨论超级指令吧。

如果一种语言的主流实现是解释器,其内部是编译器+虚拟机,而虚拟机又是采用解释方式实现的,或者内部实现是编译器+树遍历解释器,那它就是名副其实的“解释型语言”。如果内部用的虚拟机是用编译方式实现的,其实跟普遍印象中的“解释器”还是挺不同的……

可以举这样一个例子:ActionScript 3,一般都被认为是“解释型语言”对吧?但这种观点到底是把FlashPlayer整体看成一个解释器,因而AS3是“解释型语言”呢?还是认为FlashPlayer中的虚拟机采用解释执行方案,因而AS3是“解释型语言”呢?
其实Flash或Flex等从AS3生成出来的SWF文件里就包含有AS字节码(ActionScript Byte Code,ABC)。等到FlashPlayer去执行SWF文件,或者说等到AVM2(ActionScript Virtual Machine 2)去执行ABC时,又有解释器和JIT编译器两种实现。这种需要让用户显式进行编译步骤的语言,到底是不是“解释型语言”呢?呵呵。所以我一直觉得“编译型语言”跟“解释型语言”的说法太模糊,不太好。
有兴趣想体验一下从命令行编译“裸”的AS3文件得到ABC文件,再从命令行调用AVM2去执行ABC文件的同学,可以从这帖下载我之前从源码编译出来的AVM2,自己玩玩看。例如说要编译一个名为test.as的文件,用下列命令:
java -jar asc.jar -import builtin.abc -import toplevel.abc test.as

就是用ASC将test.as编译,得到test.abc。接着用:
avmplus test.abc

就是用AVM2去执行程序了。很生动的体现出“编译器+虚拟机”的实现方式。
这个“裸”的AVM2没有带Flash或Flex的类库,能用的函数和类都有限。不过AS3语言实现是完整的。可以用print()函数来向标准输出流写东西。
Well……其实写Java程序不也是这样么?现在也确实还有很多人把Java称为“解释型语言”,完全无视Java代码通常是经过显式编译步骤才得到.class文件,而有些JVM是采用纯JIT编译方式实现的,内部没解释器,例如JRockitMaxine VMJikes RVM。我愈发感到“解释型语言”是个应该避开的用语 =_=

关于虚拟机,有本很好的书绝对值得一读,《虚拟机——系统与进程的通用平台》(Virtual Machines: Versatile Platforms for Systems and Processes)。国内有影印版也有中文版,我是读了影印版,不太清楚中文版的翻译质量如何。据说翻译得还行,我无法印证。


3、基于栈与基于寄存器的指令集架构

用C的语法来写这么一个语句:
a = b + c;

如果把它变成这种形式:
add a, b, c
那看起来就更像机器指令了,对吧?这种就是所谓“三地址指令”(3-address instruction),一般形式为:
op dest, src1, src2
许多操作都是二元运算+赋值。三地址指令正好可以指定两个源和一个目标,能非常灵活的支持二元操作与赋值的组合。ARM处理器的主要指令集就是三地址形式的。

C里要是这样写的话:
a += b;

变成:
add a, b
这就是所谓“二地址指令”,一般形式为:
op dest, src
它要支持二元操作,就只能把其中一个源同时也作为目标。上面的add a, b在执行过后,就会破坏a原有的值,而b的值保持不变。x86系列的处理器就是二地址形式的。

上面提到的三地址与二地址形式的指令集,一般就是通过“基于寄存器的架构”来实现的。例如典型的RISC架构会要求除load和store以外,其它用于运算的指令的源与目标都要是寄存器。

显然,指令集可以是任意“n地址”的,n属于自然数。那么一地址形式的指令集是怎样的呢?
想像一下这样一组指令序列:
add 5
sub 3
这只指定了操作的源,那目标是什么?一般来说,这种运算的目标是被称为“累加器”(accumulator)的专用寄存器,所有运算都靠更新累加器的状态来完成。那么上面两条指令用C来写就类似:
acc += 5;
acc -= 3;

只不过acc是“隐藏”的目标。基于累加器的架构近来比较少见了,在很老的机器上繁荣过一段时间。

那“n地址”的n如果是0的话呢?
看这样一段Java字节码:
iconst_1
iconst_2
iadd
istore_0

注意那个iadd(表示整型加法)指令并没有任何参数。连源都无法指定了,零地址指令有什么用??
零地址意味着源与目标都是隐含参数,其实现依赖于一种常见的数据结构——没错,就是栈。上面的iconst_1、iconst_2两条指令,分别向一个叫做“求值栈”(evaluation stack,也叫做operand stack“操作数栈”或者expression stack“表达式栈”)的地方压入整型常量1、2。iadd指令则从求值栈顶弹出2个值,将值相加,然后把结果压回到栈顶。istore_0指令从求值栈顶弹出一个值,并将值保存到局部变量区的第一个位置(slot 0)。
零地址形式的指令集一般就是通过“基于栈的架构”来实现的。请一定要注意,这个栈是指“求值栈”,而不是与系统调用栈(system call stack,或者就叫system stack)。千万别弄混了。有些虚拟机把求值栈实现在系统调用栈上,但两者概念上不是一个东西。

由于指令的源与目标都是隐含的,零地址指令的“密度”可以非常高——可以用更少空间放下更多条指令。因此在空间紧缺的环境中,零地址指令是种可取的设计。但零地址指令要完成一件事情,一般会比二地址或者三地址指令许多更多条指令。上面Java字节码做的加法,如果用x86指令两条就能完成了:
mov  eax, 1
add  eax, 2

(好吧我犯规了,istore_0对应的保存我没写。但假如局部变量比较少的话也不必把EAX的值保存(“溢出”,register spilling)到调用栈上,就这样吧 =_=
其实就算把结果保存到栈上也就是多一条指令而已……)

一些比较老的解释器,例如CRuby在1.9引入YARV作为新的VM之前的解释器,还有SquirrleFish之前的老JavaScriptCore以及它的前身KJS,它们内部是树遍历式解释器;解释器递归遍历树,树的每个节点的操作依赖于解释其各个子节点返回的值。这种解释器里没有所谓的求值栈,也没有所谓的虚拟寄存器,所以不适合以“基于栈”或“基于寄存器”去描述。

而像V8那样直接编译JavaScript生成机器码,而不通过中间的字节码的中间表示的JavaScript引擎,它内部有虚拟寄存器的概念,但那只是普通native编译器的正常组成部分。我觉得也不应该用“基于栈”或“基于寄存器”去描述它。
V8在内部也用了“求值栈”(在V8里具体叫“表达式栈”)的概念来简化生成代码的过程,在编译过程中进行“抽象解释”,使用所谓“虚拟栈帧”来记录局部变量与求值栈的状态;但在真正生成代码的时候会做窥孔优化,消除冗余的push/pop,将许多对求值栈的操作转变为对寄存器的操作,以此提高代码质量。于是最终生成出来的代码看起来就不像是基于栈的代码了。

关于JavaScript引擎的实现方式,下文会再提到。


4、基于栈与基于寄存器架构的VM,用哪个好?

如果是要模拟现有的处理器,那没什么可选的,原本处理器采用了什么架构就只能以它为源。但HLL VM的架构通常可以自由构造,有很大的选择余地。为什么许多主流HLL VM,诸如JVM、CLI、CPython、CRuby 1.9等,都采用了基于栈的架构呢?我觉得这有三个主要原因:

·实现简单
由于指令中不必显式指定源与目标,VM可以设计得很简单,不必考虑为临时变量分配空间的问题,求值过程中的临时数据存储都让求值栈包办就行。
更新:回帖中cscript指出了这句不太准确,应该是针对基于栈架构的指令集生成代码的编译器更容易实现,而不是VM更容易实现。

·该VM是为某类资源非常匮乏的硬件而设计的
这类硬件的存储器可能很小,每一字节的资源都要节省。零地址指令比其它形式的指令更紧凑,所以是个自然的选择。

·考虑到可移植性
处理器的特性各个不同:典型的CISC处理器的通用寄存器数量很少,例如32位的x86就只有8个32位通用寄存器(如果不算EBP和ESP那就是6个,现在一般都算上);典型的RISC处理器的各种寄存器数量多一些,例如ARM有16个32位通用寄存器,Sun的SPARC在一个寄存器窗口里则有24个通用寄存器(8 in,8 local,8 out)。
假如一个VM采用基于寄存器的架构(它接受的指令集大概就是二地址或者三地址形式的),为了高效执行,一般会希望能把源架构中的寄存器映射到实际机器上寄存器上。但是VM里有些很重要的辅助数据会经常被访问,例如一些VM会保存源指令序列的程序计数器(program counter,PC),为了效率,这些数据也得放在实际机器的寄存器里。如果源架构中寄存器的数量跟实际机器的一样,或者前者比后者更多,那源架构的寄存器就没办法都映射到实际机器的寄存器上;这样VM实现起来比较麻烦,与能够全部映射相比效率也会大打折扣。像Dalvik VM的解释器实现,就是把虚拟寄存器全部映射到栈帧(内存)里的,这跟把局部变量区与操作数栈都映射到内存里的JVM解释器实现相比实际区别不太大。

如果一个VM采用基于栈的架构,则无论在怎样的实际机器上,都很好实现——它的源架构里没有任何通用寄存器,所以实现VM时可以比较自由的分配实际机器的寄存器。于是这样的VM可移植性就比较高。作为优化,基于栈的VM可以用编译方式实现,“求值栈”实际上也可以由编译器映射到寄存器上,减轻数据移动的开销。

回到主题,基于栈与基于寄存器的架构,谁更快?看看现在的实际处理器,大多都是基于寄存器的架构,从侧面反映出它比基于栈的架构更优秀。
而对于VM来说,源架构的求值栈或者寄存器都可能是用实际机器的内存来模拟的,所以性能特性与实际硬件又有点不同。一般认为基于寄存器的架构对VM来说也是更快的,原因是:虽然零地址指令更紧凑,但完成操作需要更多的load/store指令,也意味着更多的指令分派(instruction dispatch)次数与内存访问次数;访问内存是执行速度的一个重要瓶颈,二地址或三地址指令虽然每条指令占的空间较多,但总体来说可以用更少的指令完成操作,指令分派与内存访问次数都较少。
这方面有篇被引用得很多的论文讲得比较清楚,Virtual Machine Showdown: Stack Versus Registers,是在VEE 2005发表的。VEE是Virtual Execution Environment的缩写,是ACM下SIGPLAN组织的一个会议,专门研讨虚拟机的设计与实现的。可以去找找这个会议往年的论文,很多都值得读。


5、树遍历解释器图解

在演示基于栈与基于寄存器的VM的例子前,先回头看看更原始的解释器形式。
前面提到解析器的时候用了i = a + b * c的例子,现在让我们来看看由解析器生成的AST要是交给一个树遍历解释器,会如何被解释执行呢?

用文字说不够形象,还是看图吧:

这是对AST的后序遍历:假设有一个eval(Node n)函数,用于解释AST上的每个节点;在解释一个节点时如果依赖于子树的操作,则对子节点递归调用eval(Node n),从这些递归调用的返回值获取需要的值(或副作用)——也就是说子节点都eval好了之后,父节点才能进行自己的eval——典型的后序遍历。
(话说,上图中节点左下角有蓝色标记的说明那是节点的“内在属性”。从属性语法的角度看,如果一个节点的某个属性的值只依赖于自身或子节点,则该属性被称为“综合属性”(synthesized attribute);如果一个节点的某个属性只依赖于自身、父节点和兄弟节点,则该属性被称为“继承属性”(inherited attribute)。上图中节点右下角的红色标记都只依赖子节点来计算,显然是综合属性。)

SquirrelFish之前的JavaScriptCore、CRuby 1.9之前的CRuby就都是采用这种方式来解释执行的。

可能需要说明的:
·左值与右值
在源代码i = a + b * c中,赋值符号左侧的i是一个标识符,表示一个变量,取的是变量的“左值”(也就是与变量i绑定的存储单元);右侧的a、b、c虽然也是变量,但取的是它们的右值(也就是与变量绑定的存储单元内的值)。在许多编程语言中,左值与右值在语法上没有区别,它们实质的差异容易被忽视。一般来说左值可以作为右值使用,反之则不一定。例如数字1,它自身有值就是1,可以作为右值使用;但它没有与可赋值的存储单元相绑定,所以无法作为左值使用。
左值不一定只是简单的变量,还可以是数组元素或者结构体的域之类,可能由复杂的表达式所描述。因此左值也是需要计算的。

·优先级、结合性与求值顺序
这三个是不同的概念,却经常被混淆。通过AST来看就很容易理解:(假设源码是从左到右输入的)
所谓优先级,就是不同操作相邻出现时,AST节点与根的距离的关系。优先级高的操作会更远离根,优先级低的操作会更接近根。为什么?因为整棵AST是以后序遍历求值的,显然节点离根越远就越早被求值。
所谓结合性,就是当同类操作相邻出现时,操作的先后顺序同AST节点与根的距离的关系。如果是左结合,则先出现的操作对应的AST节点比后出现的操作的节点离根更远;换句话说,先出现的节点会是后出现节点的子节点。
所谓求值顺序,就是在遍历子节点时的顺序。对二元运算对应的节点来说,先遍历左子节点再遍历右子节点就是从左到右的求值顺序,反之则是从右到左的求值顺序。
这三个概念与运算的联系都很紧密,但实际描述的是不同的关系。前两者是解析器根据语法生成AST时就已经决定好的,后者则是解释执行或者生成代码而去遍历AST时决定的。
在没有副作用的环境中,给定优先级与结合性,则无论求值顺序是怎样的都能得到同样的结果;而在有副作用的环境中,求值顺序会影响结果。

赋值运算虽然是右结合的,但仍然可以用从左到右的求值顺序;事实上Java、C#等许多语言都在规范里写明表达式的求值顺序是从左到右的。上面的例子中就先遍历的=的左侧,求得i的左值;再遍历=的右侧,得到表达式的值23;最后执行=自身,完成对i的赋值。
所以如果你要问:赋值在类似C的语言里明明是右结合的运算,为什么你先遍历左子树再遍历右子树?上面的说明应该能让你发现你把结合性与求值顺序混为一谈了。

看看Java从左到右求值顺序的例子:
public class EvalOrderDemo {
    public static void main(String[] args) {
        int[] arr = new int[1];
        int a = 1;
        int b = 2;
        arr[0] = a + b;
    }
}

由javac编译,得到arr[0] = a + b对应的字节码是:
// 左子树:数组下标
// a[0]
aload_1
iconst_0

// 右子树:加法
// a
iload_2
// b
iload_3
// +
iadd

// 根节点:赋值
iastore



6、从树遍历解释器进化为基于栈的字节码解释器的前端

如果你看到树形结构与后序遍历,并且知道后缀记法(或者逆波兰记法,reverse Polish notation)的话,那敏锐的你或许已经察觉了:要解释执行AST,可以先通过后序遍历AST生成对应的后缀记法的操作序列,然后再解释执行该操作序列。这样就把树形结构压扁,成为了线性结构。
树遍历解释器对AST的求值其实隐式依赖于调用栈:eval(Node n)的递归调用关系是靠调用栈来维护的。后缀表达式的求值则通常显式依赖于一个栈,在遇到操作数时将其压入栈中,遇到运算时将合适数量的值从栈顶弹出进行运算,再将结果压回到栈上。这种描述看起来眼熟么?没错,后缀记法的求值中的核心数据结构就是前文提到过的“求值栈”(或者叫操作数栈,现在应该更好理解了)。后缀记法也就与基于栈的架构联系了起来:后者可以很方便的执行前者。同理,零地址指令也与树形结构联系了起来:可以通过一个栈方便的把零地址指令序列再转换回到树的形式。

Java字节码与Java源码联系紧密,前者可以看成后者的后缀记法。如果想在JVM上开发一种语义能直接映射到Java上的语言,那么编译器很好写:秘诀就是后序遍历AST。
那么让我们再来看看,同样是i = a + b * c这段源码对应的AST,生成Java字节码的例子:

(假设a、b、c、i分别被分配到局部变量区的slot 0到slot 3)
能看出Java字节码与源码间的对应关系了么?
一个Java编译器的输入是Java源代码,输出是含有Java字节码的.class文件。它里面主要包含扫描器与解析器,语义分析器(包括类型检查器/类型推导器等),代码生成器等几大部分。上图所展示的就是代码生成器的工作。对Java编译器来说,代码生成就到字节码的层次就结束了;而对native编译器来说,这里刚到生成中间表示的部分,接下去是优化与最终的代码生成。

如果你对PythonCRuby 1.9之类有所了解,会发现它们的字节码跟Java字节码在“基于栈”的这一特征上非常相似。其实它们都是由“编译器+VM”构成的,概念上就像是Java编译器与JVM融为一体一般。
从这点看,Java与Python和Ruby可以说是一条船上的。虽说内部具体实现的显著差异使得先进的JVM比简单的JVM快很多,而JVM又普遍比Python和Ruby快很多。

当解释器中用于解释执行的中间代码是树形时,其中能被称为“编译器”的部分基本上就是解析器;中间代码是线性形式(如字节码)时,其中能被称为编译器的部分就包括上述的代码生成器部分,更接近于所谓“完整的编译器”;如果虚拟机是基于寄存器架构的,那么编译器里至少还得有虚拟寄存器分配器,又更接近“完整的编译器”了。


7、基于栈与基于寄存器架构的VM的一组图解

要是拿两个分别实现了基于栈与基于寄存器架构、但没有直接联系的VM来对比,效果或许不会太好。现在恰巧有两者有紧密联系的例子——JVM与Dalvik VM。JVM的字节码主要是零地址形式的,概念上说JVM是基于栈的架构。Google Android平台上的应用程序的主要开发语言是Java,通过其中的Dalvik VM来运行Java程序。为了能正确实现语义,Dalvik VM的许多设计都考虑到与JVM的兼容性;但它却采用了基于寄存器的架构,其字节码主要是二地址/三地址混合形式的,乍一看可能让人纳闷。考虑到Android有明确的目标:面向移动设备,特别是最初要对ARM提供良好的支持。ARM9有16个32位通用寄存器,Dalvik VM的架构也常用16个虚拟寄存器(一样多……没办法把虚拟寄存器全部直接映射到硬件寄存器上了);这样Dalvik VM就不用太顾虑可移植性的问题,优先考虑在ARM9上以高效的方式实现,发挥基于寄存器架构的优势。
Dalvik VM的主要设计者Dan Bornstein在Google I/O 2008上做过一个关于Dalvik内部实现的演讲;同一演讲也在Google Developer Day 2008 China和Japan等会议上重复过。这个演讲中Dan特别提到了Dalvik VM与JVM在字节码设计上的区别,指出Dalvik VM的字节码可以用更少指令条数、更少内存访问次数来完成操作。(看不到YouTube的请自行想办法)

眼见为实。要自己动手感受一下该例子,请先确保已经正确安装JDK 6,并从官网获取Android SDK 1.6R1。连不上官网的也请自己想办法。

创建Demo.java文件,内容为:
public class Demo {
    public static void foo() {
        int a = 1;
        int b = 2;
        int c = (a + b) * 5;
    }
}

通过javac编译,得到Demo.class。通过javap可以看到foo()方法的字节码是:
0:  iconst_1
1:  istore_0
2:  iconst_2
3:  istore_1
4:  iload_0
5:  iload_1
6:  iadd
7:  iconst_5
8:  imul
9:  istore_2
10: return


接着用Android SDK里platforms\android-1.6\tools目录中的dx工具将Demo.class转换为dex格式。转换时可以直接以文本形式dump出dex文件的内容。使用下面的命令:
dx --dex --verbose --dump-to=Demo.dex.txt --dump-method=Demo.foo --verbose-dump Demo.class

可以看到foo()方法的字节码是:
0000: const/4       v0, #int 1 // #1
0001: const/4       v1, #int 2 // #2
0002: add-int/2addr v0, v1
0003: mul-int/lit8  v0, v0, #int 5 // #05
0005: return-void

(原本的输出里还有些code-address、local-snapshot等,那些不是字节码的部分,可以忽略。)

让我们看看两个版本在概念上是如何工作的。
JVM:

(图中数字均以十六进制表示。其中字节码的一列表示的是字节码指令的实际数值,后面跟着的助记符则是其对应的文字形式。标记为红色的值是相对上一条指令的执行状态有所更新的值。下同)
说明:Java字节码以1字节为单元。上面代码中有11条指令,每条都只占1单元,共11单元==11字节。
程序计数器是用于记录程序当前执行的位置用的。对Java程序来说,每个线程都有自己的PC。PC以字节为单位记录当前运行位置里方法开头的偏移量。
每个线程都有一个Java栈,用于记录Java方法调用的“活动记录”(activation record)。Java栈以帧(frame)为单位线程的运行状态,每调用一个方法就会分配一个新的栈帧压入Java栈上,每从一个方法返回则弹出并撤销相应的栈帧。
每个栈帧包括局部变量区、求值栈(JVM规范中将其称为“操作数栈”)和其它一些信息。局部变量区用于存储方法的参数与局部变量,其中参数按源码中从左到右顺序保存在局部变量区开头的几个slot。求值栈用于保存求值的中间结果和调用别的方法的参数等。两者都以字长(32位的字)为单位,每个slot可以保存byte、short、char、int、float、reference和returnAddress等长度小于或等于32位的类型的数据;相邻两项可用于保存long和double类型的数据。每个方法所需要的局部变量区与求值栈大小都能够在编译时确定,并且记录在.class文件里。
在上面的例子中,Demo.foo()方法所需要的局部变量区大小为3个slot,需要的求值栈大小为2个slot。Java源码的a、b、c分别被分配到局部变量区的slot 0、slot 1和slot 2。可以观察到Java字节码是如何指示JVM将数据压入或弹出栈,以及数据是如何在栈与局部变量区之前流动的;可以看到数据移动的次数特别多。动画里可能不太明显,iadd和imul指令都是要从求值栈弹出两个值运算,再把结果压回到栈上的;光这样一条指令就有3次概念上的数据移动了。

对了,想提醒一下:Java的局部变量区并不需要把某个局部变量固定分配在某个slot里;不仅如此,在一个方法内某个slot甚至可能保存不同类型的数据。如何分配slot是编译器的自由。从类型安全的角度看,只要对某个slot的一次load的类型与最近一次对它的store的类型匹配,JVM的字节码校验器就不会抱怨。以后再找时间写写这方面。

Dalvik VM:

说明:Dalvik字节码以16位为单元(或许叫“双字节码”更准确 =_=|||)。上面代码中有5条指令,其中mul-int/lit8指令占2单元,其余每条都只占1单元,共6单元==12字节。
与JVM相似,在Dalvik VM中每个线程都有自己的PC和调用栈,方法调用的活动记录以帧为单位保存在调用栈上。PC记录的是以16位为单位的偏移量而不是以字节为单位的。
与JVM不同的是,Dalvik VM的栈帧中没有局部变量区与求值栈,取而代之的是一组虚拟寄存器。每个方法被调用时都会得到自己的一组虚拟寄存器。常用v0-v15这16个,也有少数指令可以访问v0-v255范围内的256个虚拟寄存器。与JVM相同的是,每个方法所需要的虚拟寄存器个数都能够在编译时确定,并且记录在.dex文件里;每个寄存器都是字长(32位),相邻的一对寄存器可用于保存64位数据。方法的参数按源码中从左到右的顺序保存在末尾的几个虚拟寄存器里。
与JVM版相比,可以发现Dalvik版程序的指令数明显减少了,数据移动次数也明显减少了,用于保存临时结果的存储单元也减少了。

你可能会抱怨:上面两个版本的代码明明不对应:JVM版到return前完好持有a、b、c三个变量的值;而Dalvik版到return-void前只持有b与c的值(分别位于v0与v1),a的值被刷掉了。
但注意到a与b的特征:它们都只在声明时接受过一次赋值,赋值的源是常量。这样就可以对它们应用常量传播,将
int c = (a + b) * 5;

替换为
int c = (1 + 2) * 5;

然后可以再对c的初始化表达式应用常量折叠,进一步替换为:
int c = 15;

把变量的每次状态更新(包括初始赋值在内)称为变量的一次“定义”(definition),把每次访问变量(从变量读取值)称为变量的一次“使用”(use),则可以把代码整理为“使用-定义链”(简称UD链,use-define chain)。显然,一个变量的某次定义要被使用过才有意义。上面的例子经过常量传播与折叠后,我们可以分析得知变量a、b、c都只被定义而没有被使用。于是它们的定义就成为了无用代码(dead code),可以安全的被消除。
上面一段的分析用一句话描述就是:由于foo()里没有产生外部可见的副作用,所以foo()的整个方法体都可以被优化为空。经过dx工具处理后,Dalvik版程序相对JVM版确实是稍微优化了一些,不过没有影响程序的语义,程序的正确性是没问题的。这是其一。

其二是Dalvik版代码只要多分配一个虚拟寄存器就能在return-void前同时持有a、b、c三个变量的值,指令几乎没有变化:
0000: const/4      v0, #int 1 // #1
0001: const/4      v1, #int 2 // #2
0002: add-int      v2, v0, v1
0004: mul-int/lit8 v2, v2, #int 5 // #05
0006: return-void

这样比原先的版本多使用了一个虚拟寄存器,指令方面也多用了一个单元(add-int指令占2单元);但指令的条数没变,仍然是5条,数据移动的次数也没变。

题外话1:Dalvik VM是基于寄存器的,x86也是基于寄存器的,但两者的“寄存器”却相当不同:前者的寄存器是每个方法被调用时都有自己一组私有的,后者的寄存器则是全局的。也就是说,概念上Dalvik VM字节码中不用担心保护寄存器的问题,某个方法在调用了别的方法返回过来后自己的寄存器的值肯定跟调用前一样。而x86程序在调用函数时要考虑清楚calling convention,调用方在调用前要不要保护某些寄存器的当前状态,还是说被调用方会处理好这些问题,麻烦事不少。Dalvik VM这种虚拟寄存器让人想起一些实际处理器的“寄存器窗口”,例如SPARC的Register Windows也是保证每个函数都觉得自己有“私有的一组寄存器”,减轻了在代码里处理寄存器保护的麻烦——扔给硬件和操作系统解决了。IA-64也有寄存器窗口的概念。
(当然,Dalvik VM与x86的“寄存器”一个是虚拟寄存器一个是真实硬件的ISA提供的寄存器,本来也不在一个级别上…上面这段只是讨论寄存器的语义。)

题外话2:Dalvik的.dex文件在未压缩状态下的体积通常比同等内容的.jar文件在deflate压缩后还要小。但光从字节码看,Java字节码几乎总是比Dalvik的小,那.dex文件的体积是从哪里来减出来的呢?这主要得益与.dex文件对常量池的压缩,一个.dex文件中所有类都共享常量池,使得相同的字符串、相同的数字常量等都只出现一次,自然能大大减小体积。相比之下,.jar文件中每个类都持有自己的常量池,诸如"Ljava/lang/Object;"这种常见的字符串会被重复多次。Sun自己也有进一步压缩JAR的工具,Pack200,对应的标准是JSR 200。它的主要应用场景是作为JAR的网络传输格式,以更高的压缩比来减少文件传输时间。在官方文档提到了Pack200所用到的压缩技巧,
JDK 5.0 Documentation 写道
Pack200 works most efficiently on Java class files. It uses several techniques to efficiently reduce the size of JAR files:
  • It merges and sorts the constant-pool data in the class files and co-locates them in the archive.
  • It removes redundant class attributes.
  • It stores internal data structures.
  • It use delta and variable length encoding.
  • It chooses optimum coding types for secondary compression.
可见.dex文件与Pack200采用了一些相似的减小体积的方法。很可惜目前还没有正式发布的JVM支持直接加载Pack200格式的归档,毕竟网络传输才是Pack200最初构想的应用场景。

再次提醒注意,上面的描述是针对概念上的JVM与Dalvik VM,而不是针对它们的具体实现。实现VM时可以采用许多优化技巧去减少性能损失,使得实际的运行方式与概念中的不完全相符,只要最终的运行结果满足原本概念上的VM所实现的语义就行。

===========================================================================

上面“简单”的提了些讨论点,不过还没具体到JavaScript引擎,抱歉。弄得太长了,只好在这里先拆分一次……有些东西想写的,洗个澡又忘记了。等想起来再补充 orz
“简单”是相对于实际应该掌握的信息量而言。上面写的都还没挠上痒痒,心虚。
Anyway。根据拆分的现状,下一篇应该是讨论动态语言与编译的问题,然后再下一篇会看看解释器的演化方法,再接着会看看JavaScript引擎的状况(主要针对V8和Nitro,也会谈谈Tamarin。就不讨论JScript了)。

关于推荐资料,在“我的收藏”的virtual machine标签里就有不少值得一读的资料。如果只是对JavaScript引擎相关感兴趣的话也可以选着读些。我的收藏里还有v8和tamarin等标签的,资料有的是 ^ ^

能有耐心读到结尾的同学们,欢迎提出意见和建议,以及指出文中的错漏 ^_^
不像抓到虫就给美分的大师,我没那种信心……错漏难免,我也需要进一步学习。拜托大家了~

P.S. 画图真的很辛苦,加上JavaEye的带宽也不是无限的……所以拜托不要直接链接这帖里的图 <(_ _)>
有需要原始图片的可以跟我联系。我是画成多帧PNG然后转换为GIF发出来的。上面的PNG图片都还保留有原始的图层信息,要拿去再编辑也很方便 ^ ^

更新1:
原本在树遍历解释器图解的小节中,我用的是这幅图:

其实上图画得不准确,a、b、c的右值不应该画在节点上的;节点应该只保存了它们的左值才对,要获取对应的右值就要查询变量表。我修改了图更新到正文了。原本的图里对i的赋值看起来很奇怪,就像是遍历过程经过了两次i节点一般,而事实不是那样的。
  • 大小: 208.6 KB
  • 大小: 103.3 KB
  • 描述: old
  • 大小: 42.5 KB
  • 大小: 46.9 KB
  • 大小: 48.7 KB
  • 大小: 29.7 KB
  • 大小: 56.5 KB
分享到:
评论
17 楼 dalviker 2009-10-19  
厉害。
题外话 ,dalvik这么做,体积小了,
但由于需要对每个class都转为dex,多了一个计算步骤。
对于整个jar包的转换,需要对所有变量进行缓存和比较,计算量挺大。这就要求使用前就把dex包做好。
如果在热部署时使用jar包转换为dex包,经常出现内存溢出。
从使用上看,dex并不省内存。
经常的,我们设计过分强调某些方面,另一些方面就成为瓶颈。希望google加油改进。
16 楼 RednaxelaFX 2009-10-19  
cscript 写道
楼主向我们展现了什么叫做追求完美、做事认真,尤其是精心制作的插图让读者感动,别的不说,首先赞这一点。

引用

为什么许多主流HLL VM,诸如JVM、CLI、CPython、CRuby 1.9等,都采用了基于栈的架构呢?我觉得这有三个主要原因:
·实现简单
由于指令中不必显式指定源与目标,VM可以设计得很简单,不必考虑为临时变量分配空间的问题,求值过程中的临时数据存储都让求值栈包办就行。

应该是Compiler可以得以简化,我写过基于3地址指令和基于0地址指令的程序,翻译表达式时,产生3地址指令比产生0地址指令要麻烦一点,需要考虑消除临时变量的问题

赞一下cscript的回复。你说得对,我应该编辑一下原帖,0地址代码的设计主要简化的是编译器的代码生成,而不是VM自身。
不过在“消除临时变量”之前,“为临时变量显式指定空间”的问题在3地址指令中就已经比0地址的麻烦。在我见过的编译器实现中,有些是为表达式的中间结果生成临时变量后,不再区分临时变量与程序中显式写明的变量,而有些则对临时变量做更激进的优化而对显式的变量更保守些。无论是哪种情况,临时变量都变成了编译器需要显式管理的对象,因而实现难度就已经提升了。
在生成初步的中间代码后,0地址指令仍然可以(且会面临)被优化。不过优化过程中变量不是显式的处理起来就很麻烦,所以多数native编译器都不采用这种形式的中间代码。变量的各种关系越明显就越方便处理,像SSA形式中UD链就是显式的,看名字就行,就很方便。
15 楼 cscript 2009-10-19  
下面就是生成3地址代码,注意在comileAddExpression中,总是分配一个临时变量并返回,但这样做产生的是非优化代码。
生成3地址代码

class Expression {
    virtual void compile();
}

class AddExpression: Expression {
    Expression left, right;
}

class AssignmentExpression: Expression {
    Expression left, right;
}

class IdExpression: Expresson {
    String name;
}

Address compileAddExpression(AddExpression ast)
{
    Address left = compile(ast.left);
    Address right = compile(ast.right); 
    Address temporary = allocateTemporary();
    emit("add", tempoaray, left, right);
    return temporaray;
}

Address compileAssignmentExpression(AssignmentExpression ast)
{
    Address left = compile(ast.left);
    Address right = compile(ast.right); 
    emit("mov", left, right);
    return left;
}

Address compileIdExpression(IdExpression ast)
{
    return ID的地址;
}

Address compile(Expression ast)
{
    if (ast is AddExpression)
        return compileAddExpression(ast);
    else if (ast is AssignmentExpression)
        return compileAssignmentExpression(ast);
    else if (ast is IdExpression) 
        return compileIDExpression(ast);
}


14 楼 cscript 2009-10-19  
楼主向我们展现了什么叫做追求完美、做事认真,尤其是精心制作的插图让读者感动,别的不说,首先赞这一点。

引用

为什么许多主流HLL VM,诸如JVM、CLI、CPython、CRuby 1.9等,都采用了基于栈的架构呢?我觉得这有三个主要原因:
·实现简单
由于指令中不必显式指定源与目标,VM可以设计得很简单,不必考虑为临时变量分配空间的问题,求值过程中的临时数据存储都让求值栈包办就行。

应该是Compiler可以得以简化,我写过基于3地址指令和基于0地址指令的程序,翻译表达式时,产生3地址指令比产生0地址指令要麻烦一点,需要考虑消除临时变量的问题,比如说:
引用

a = b + c + d;

对于上面的表达式有两种翻译方案:

方案1:
add t0  b  c
add t1  t0 d
mov a  t1

方案2:
add t0 b  c
add a  t0 d


虽然方案2比方案1减少了一条指令,但就实现来说方案1要比方案2简单,考虑翻译"加法表达式":在方案1中,总是分配临时变量,把表达式结果保存到临时变量中;在方案2中,在有些Context中是需要分配临时变量,可以把表达式结果直接保存到目标变量中。在方案1中,翻译AST是Context-Free,翻译"赋值表达式"与"加法表达式"两者是没有关联的。

生成0地址指令就和方案1类似,每一步都把求和结果压栈,是Context-Free的,比较简单;而产生3地址指令需要区分在不同的Context中把计算结果是保存在临时变量还是最终目标变量中。

我解决消除临时变量的问题的方法是把编译分成两个步骤:第一步把AST翻译成方案1;第二步再把方案1的代码转换为方案2的代码。第二步还有些麻烦的问题要处理,比如说把"add t1  t0 d"、"mov a  t1"合并成"add a t0 d"的过程中,变量t1被消除了,但如果t1被下面的代码引用怎么办?还要再进行额外的处理,这里就不叙述了。


13 楼 RednaxelaFX 2009-10-19  
febird 写道
javavm 也不是严格的堆栈机,更像是一个堆栈机与寄存器机的混合

要是把“严格的基于栈的架构”定义为“只有一个核心的栈,没有任何寄存器”的话,那JVM似乎不是严格的:spec定义里有提到PC寄存器,每个线程都有自己的PC。
不过JVM指令集里并没有能够显式操纵PC的指令,所有跳转都必须用控制流指令来完成,包括条件跳转的if-*、无条件跳转的goto-*,还有两个switch指令,等;另外方法调用的invoke-*在调用native方法时对PC的状态未定义。显然在JVM字节码里无法通过load/store操作去改变PC。

不过另外一点使得JVM的指令集跟更典型的基于栈的架构不同的是,JVM指令集中有许多指令有显式参数,而不是从求值栈获取所有参数。包括*-load/*-store与控制流等的指令,都在后面直接跟有参数。
以iload为例:该指令的基本形式是iload index,其中index是局部变量区的索引。iload_<n>形式的指令只是把常用的几个n融合到指令里而已,没有改变其包含参数的本质。
假设右侧是栈顶,则该指令执行前后求值栈的变化是:... => ..., value
如果是更典型的基于栈的架构,则index应该是从求值栈弹出,然后求值(加载局部变量),再把结果压到栈上。
那么指令执行前后求值栈的变化应该是:..., index => ..., value
为什么JVM要在这些地方用显式参数呢?主要是为了可校验性(verifiability)。在JVM加载一个类时,其中一个步骤就是对字节码做静态校验,以保证类型安全、求值栈状态一致、局部跳转目标都在方法内部,等。上面的iload例子如果从求值栈上获取index,则静态校验就难以进行了:index变成了运行时可计算的值,而不是可静态确定的值。可以看看之前我写过的一个例子,演示了JVM的校验。
如果从这点说概念上的JVM不是严格的基于栈架构,那倒也有道理。不过概念上的JVM中用于求值的核心结构仍然是求值栈,一般把它归类为基于栈的架构还是没问题的。
12 楼 febird 2009-10-19  
javavm 也不是严格的堆栈机,更像是一个堆栈机与寄存器机的混合
11 楼 febird 2009-10-19  
一般地讲,寄存器机器的机器码要比堆栈机的机器码大很多,这也是为什么大多数hvm使用堆栈机的一个重要原因
10 楼 RednaxelaFX 2009-10-18  
liujinmarshall 写道
我的感觉主要是,生成代码体积的大小主要和指令集的大小比较有关系,和寄存器的数目关系并不大

我觉得是在指令里需要显式指定的“地址”越少,指令密度就可以做得越高。也就是顶楼里所说的“n地址指令”的n的问题,而跟寄存器的数目没特别紧密的关系。VEE 2005的那篇论文也提到了这点,
不过如果寄存器不够用而需要spill的话,代码就膨胀起来了,总体来说生成代码的体积就会更大。

如果提供的操作种类相似,那么无论采用哪种架构,指令集的大小(指令集里指令的条数)都应该差不多。
JVM的iadd跟Dalvik的add-int提供的运算是一样的,其它许多指令也是如此。如果你观察Dalvik的字节码指令集,会发现它的opcode个数其实还不到256:3E..43、73、79、7A、E3..FF都是unused。事实上Dalvik字节码单从opcode看就是“真正”的字节码,之所以采用了16位为单元是因为opcode后面还得跟上参数。

const/4指令为例,它用于将一个4位带符号立即数加载到v0..v15的其中一个寄存器。将目标固定为v0、立即数取0..5的话,有:
指令             助记符
1200  const/4 v0, #int 0
1210  const/4 v0, #int 1
1220  const/4 v0, #int 2
1230  const/4 v0, #int 3
1240  const/4 v0, #int 4
1250  const/4 v0, #int 5

如果这些指令总是以v0为目标,那就可以省下4位,可以腾出来给后面的立即数用。这样出来的代码就跟Java字节码中的bipush一样了:bipush的opcode本身占1字节,后面的8位带符号立即数又占1字节。
如果Dalvik其它所有指令也都可以省下指令目标占用的空间,那么一些常用常量还可以进一步融合到opcode里。这样就跟Java字节码中的iconst_m1、iconst_0..iconst_5这样的指令一样了,opcode占1字节,没有参数。

不知道上述讨论是否充分展示了“地址”的多少跟指令大小的关系呢?

当然不能包括这种情况:之前我看一个游戏引擎里的脚本虚拟机,它的中间代码虽然指令集中包含的指令不超过256条,却为了实现方便而让每个opcode占用了一个DWORD。虽然那个虚拟机是基于寄存器的架构,生成的代码本来就应该比同等的基于栈架构的代码要大;但它生成的代码体积特别大主要还是因为它浪费空间了。要比较两种架构的代码得注意不能有一边的设计本身就特别占空间 =_=||||
9 楼 liujinmarshall 2009-10-18  
我的感觉主要是,生成代码体积的大小主要和指令集的大小比较有关系,和寄存器的数目关系并不大
8 楼 mryufeng 2009-10-18  
写的非常好
7 楼 lwwin 2009-10-17  
这就是要么不做,要做就要做好的典型=v=+

不愧是FX大~
6 楼 alanwu 2009-10-17  
牛!  要说什么好呢。。。深入浅出浅显易懂形象生动得解释了解释器这个比较抽象的概念
5 楼 RednaxelaFX 2009-10-17  
night_stalker 写道
photoshop 画的……?

Fireworks画的

simohayha 写道
就算你是基于寄存器的虚拟机,寄存器也是在内存中虚拟的,何谈与硬件的寄存器映射?现在有直接映射到硬件寄存器的方案或者实现?

没错。如果有兴趣了解可以阅读上面提到的《虚拟机——系统与进程的通用平台》,里面介绍了不少例子。例如在Alpha上模拟x86的FX!32就把被模拟的x86的寄存器映射到Alpha上的硬件寄存器上。即便是纯解释器,其核心部分(instruction handler)也可能是用汇编写的;如果host上的寄存器数量足够多,就可以用一一对应的方式把guest上的寄存器直接映射过去。

嗯……放点代码好了。Dalvik里,解释器中针对ARMv5TE的代码,
header.s:
/*
Mterp and ARM notes:

The following registers have fixed assignments:

  reg nick      purpose
  r4  rPC       interpreted program counter, used for fetching instructions
  r5  rFP       interpreted frame pointer, used for accessing locals and args
  r6  rGLUE     MterpGlue pointer
  r7  rIBASE    interpreted instruction base pointer, used for computed goto
  r8  rINST     first 16-bit code unit of current instruction

Macros are provided for common operations.  Each macro MUST emit only
one instruction to make instruction-counting easier.  They MUST NOT alter
unspecified registers or condition codes.
*/

/* single-purpose registers, given names for clarity */
#define rPC     r4
#define rFP     r5
#define rGLUE   r6
#define rIBASE  r7
#define rINST   r8


binop.s:
%default {"preinstr":"", "result":"r0", "chkzero":"0"}
    /*
     * Generic 32-bit binary operation.  Provide an "instr" line that
     * specifies an instruction that performs "result = r0 op r1".
     * This could be an ARM instruction or a function call.  (If the result
     * comes back in a register other than r0, you can override "result".)
     *
     * If "chkzero" is set to 1, we perform a divide-by-zero check on
     * vCC (r1).  Useful for integer division and modulus.  Note that we
     * *don't* check for (INT_MIN / -1) here, because the ARM math lib
     * handles it correctly.
     *
     * For: add-int, sub-int, mul-int, div-int, rem-int, and-int, or-int,
     *      xor-int, shl-int, shr-int, ushr-int, add-float, sub-float,
     *      mul-float, div-float, rem-float
     */
    /* binop vAA, vBB, vCC */
    FETCH(r0, 1)                        @ r0<- CCBB
    mov     r9, rINST, lsr #8           @ r9<- AA
    mov     r3, r0, lsr #8              @ r3<- CC
    and     r2, r0, #255                @ r2<- BB
    GET_VREG(r1, r3)                    @ r1<- vCC
    GET_VREG(r0, r2)                    @ r0<- vBB
    .if $chkzero
    cmp     r1, #0                      @ is second operand zero?
    beq     common_errDivideByZero
    .endif

    FETCH_ADVANCE_INST(2)               @ advance rPC, load rINST
    $preinstr                           @ optional op; may set condition codes
    $instr                              @ $result<- op, r0-r3 changed
    GET_INST_OPCODE(ip)                 @ extract opcode from rINST
    SET_VREG($result, r9)               @ vAA<- $result
    GOTO_OPCODE(ip)                     @ jump to next instruction
    /* 11-14 instructions */

可以看到其中的一些固定映射关系,例如Dalvik PC -> R4;而Dalvik的通用虚拟寄存器则是在栈帧上分配空间的。Hmm...于是Dalvik的ARMv5TE版算不上是直接映射的好例子,但至少演示了部分辅助数据被直接映射的情况。
4 楼 simohayha 2009-10-17  
就算你是基于寄存器的虚拟机,寄存器也是在内存中虚拟的,何谈与硬件的寄存器映射?现在有直接映射到硬件寄存器的方案或者实现?
3 楼 night_stalker 2009-10-17  
photoshop 画的……?
2 楼 cnlinkin 2009-10-17  
华丽阿
1 楼 dennis_zane 2009-10-17  
佩服,写的这么用心,也非常详细。

相关推荐

    tiny-vm:一个基于寄存器的微型虚拟机

    TinyVM 是一个简单的基于寄存器的虚拟机,用 C ( tinyvm.c ) 实现。 字节码汇编器是用 Python ( tas.py ) 编写的。 TinyVM 在 32 位地址空间 ( 0x00000000 - 0x0000FFFF ) 中有 4 个寄存器 ( $0 - $3 ) 和 64k 内存...

    graal,格拉尔:高性能多点虚拟机:火箭::奖杯:.zip

    graalvm是一个通用的虚拟机,用于运行用javascript、python、ruby、r、基于jvm的语言(如java、scala、clojure、kotlin)和基于llvm的语言(如c和c++)编写的应用程序。

    自制的一个编译器, 用于学习,完整实现了词法分析,语法分析,中间代码(SSA)生成,机器码生成,和基于寄存器的虚拟机.zip

    5. **基于寄存器的虚拟机**:不同于传统的栈式虚拟机,基于寄存器的虚拟机使用一组预先定义的寄存器来存储数据,执行效率通常更高。这种虚拟机可以模拟真实硬件的执行环境,使得编译器生成的机器码可以在虚拟机上...

    UNDER-C.rar_C解释器_C语言解释器_under c 解释器_虚拟机 解释器

    《深入理解C语言解释器与虚拟机》 在编程领域,C语言因其高效、灵活和广泛的应用而备受赞誉。然而,通常我们所熟知的C语言是通过编译器进行编译,然后生成机器码执行的。然而,"Under C"项目提供了一种不同寻常的...

    使用C语言编写的脚本语言Tiderip解释器.zip

    虚拟机可以是基于栈的,其中指令和数据都在一个共享栈上操作,或者基于寄存器的,每个操作都有自己的寄存器。 4. **内存管理**:解释器需要处理内存分配和释放,确保程序不会因内存泄漏或访问未初始化的内存而崩溃...

    java遍历文件目录生成树结构txt文件

    在Java编程中,遍历文件目录并生成树结构的文本文件是一个常见的任务,尤其是在处理大量文件数据时。这个任务可以通过使用Java的`java.io.File`类及其相关API来实现。`Dir.class`和`Dir.java`是这次操作的核心文件,...

    Java卡Java卡虚拟机解释器Java栈异常处理[定义].pdf

    设计JCVM解释器需要考虑如何实现指令集、寄存器、Java栈、堆空间以及异常处理机制。寄存器用于临时存储数据,Java栈的结构和运行机制关乎程序执行效率,堆空间则用于动态分配对象。异常处理机制的实现需要建立异常类...

    自己做的小解释器 cmm解释器

    在CMM解释器中,"CMM"代表了一种自定义的中间语言,它可能是基于经典的“字节码”概念设计的,类似于Java的字节码或Python的PVM(Python虚拟机)的指令集。这种中间语言可以简化编译器的设计,因为它不需要直接面对...

    虚拟机的设计与实现——C_C++

    解释器负责解析并执行虚拟机指令,内存管理系统则处理虚拟内存的分配和回收,而输入/输出系统则允许虚拟机与外界交互。 2. **虚拟机指令集**:虚拟机有自己的指令集,这些指令通常比真实硬件的指令更简单,更易于...

    深入JAVA虚拟机 随书源码 JVM规范

    Java虚拟机(JVM)是Java程序运行的核心,它负责解释和执行字节码,为开发者提供了跨平台的运行环境。深入理解JVM对于优化代码性能、排查问题以及提升编程能力至关重要。本篇文章将详细探讨JVM的工作原理、内存管理...

    clox:C89中Lox编程语言的虚拟机和Tree-walk解释器

    《clox:C89中的Lox编程语言虚拟机与Tree-walk解释器解析》 在编程领域,理解和实现一种编程语言的虚拟机和解释器是深入学习编译原理和技术的重要途径。clox项目,源自C89语言,提供了一个用于Lox编程语言的虚拟机...

    Go-go.vm一个简单的虚拟机-编译器和解释器-用golang编写

    《Go-go.vm:一个简单的虚拟机 - 编译器与解释器的实现》 Go-go.vm项目是一个基于Golang语言实现的简单虚拟机,它旨在为开发者提供一个学习和理解虚拟机、编译器和解释器工作原理的平台。本文将深入探讨该项目中的...

    虚拟机设计(模拟CPU 寄存器等)

    在本篇文章中,我们将深入探讨虚拟机的工作原理,特别是如何模拟CPU和寄存器,以及这一过程对于理解VMware等虚拟化技术的重要性。 首先,我们要明白虚拟机的基本概念。虚拟机是一种软件实现的计算机系统,它可以...

    基于栈式虚拟机的类c语言编译器源码.zip

    基于栈式虚拟机的类c 语言编译器源码.zip基于栈式虚拟机的类c 语言编译器源码.zip基于栈式虚拟机的类c 语言编译器源码.zip基于栈式虚拟机的类c 语言编译器源码.zip基于栈式虚拟机的类c 语言编译器源码.zip基于栈式...

    虚拟机的设计和实现(PDF+源码)c/c++

    《虚拟机的设计和实现》是一本深入探讨虚拟机原理与实现的专业书籍,主要针对C/C++编程语言。这本书详尽地介绍了如何构建一个虚拟机,包括其内部结构、指令集设计、内存管理、垃圾回收机制以及编译器的实现等方面。...

    解释器构造

    桂浩的解释器可能生成一种栈式或寄存器式的中间代码,这种代码便于解释器理解和执行。中间代码的生成有助于提高解释器的效率,因为它可以进行一些全局优化,如常量折叠、死代码消除等。 4. **解释执行**: 最后,...

    深入java虚拟机 随书源码

    6. **字节码与解释器**:Java程序编译成字节码后,由JVM的解释器将其转换为机器码执行。JIT(Just-In-Time)编译器则会在运行时将频繁执行的热点代码编译为本地机器码,提高运行效率。 7. **异常处理与线程模型**:...

    cmm语言解释器

    CMM语言解释器是一种专为CMM编程语言设计的软件工具,它的主要任务是读取CMM源代码并执行相应的操作。CMM语言可能是一种类似于C或C++的低级编程语言,或者是某个特定领域定制的语法。这个简易的解释器包含了语言的...

    一个面向Ruby、基于Java虚拟机(JVM)的解释程序

    jvm,JRuby是面向Ruby、基于Java虚拟机(JVM)的一种解释程序,它结合了Ruby语言的简易性和功能强大的JVM的执行机制,包括与Java库 全面集成。适用人群:计算机,电子信息工程、数学等专业的大学生课程设计、期末大...

Global site tag (gtag.js) - Google Analytics