4492人阅读
目前，JavaScript的实现已经成为编译领域的一个重要组成部分。主要包括Google的V8, Mozilla的SpiderMonkey, 还有Webkit使用的JavaScriptCore。
jsc:WebKit的JS引擎( js for webkit)
JavaScriptCore (JSC)正是WebKit的JavaScript实现。
起初，JavaScriptCore是一个基于的树的简单解释器(tree-based interpreter). 但在2008年6月，几位Apple的牛人为JSC重新写一个编译器(compiler)和一个字节码解释器(bytecode interpreter)，将原先的实现抛弃了, 这个新的实现被称为（金鳞鱼）. 在苹果内部的产品代号是&Nitro&。
JSC的字节码解释器(bytecode interpreter)很棒，令人着迷. 我将在下面说说更多的细节。
2008年后, WebKit的伙计们新增了Inline caches, 一个基于正则表达式(regular expression)的JIT, 和一个简单方法(simple method)JIT, 随后新的版本被称为(Nitro Extreme)，可以简称为SFX。正式的名称仍然是JavaScriptCore。
JSC的伙计们做得很棒，以至于Mozilla SpiderMondkey的骇客们(hackers)也直接采用了JSC的基于正则表达的JIT(regexp JIT)和原生汇编程序(native-code assembler)。
对于JSC的2009年和2010年都花在了它的巩固(consolidation)上了. JSC既有一个JIT，又有一个字节码解释器(bytecode interpreter), 他们想要同时维护它们，所以为他们的协作，需要做大量的重构和调整。在这阶段SFX在x86架构上得以加强，同时也增加了ARM和其它架构下的实现。
但随着2010后期V8 Crankshaft(曲轴)的发布, JSC性能又变得不足了。JSC的那些人又开始开发他们称为的DFG JIT (data-flow graph JIT), 使JSC更接近于Crankshaft.
JSC可以由三个引擎组成: 解释器(interpreter), 简单方法JIT(simple method JIT), 和DFG JIT. 三种形式有一个层次化的编译过程:初始的解析和编译生成字节码(byte-code), 再由simple method JIT加以优化, 最后再由DFG JIT加以优化。在实践中, 多数平台下并没有解释器，所有的代码都是通过method JIT运行。DFG JIT随着Mac OS X Lions的Safari浏览器一起发布，但并没有在除了64-bit Mac OS以外的系统上使用。
寄存器式的虚拟机(a register vm)
以下register VM或register machine都是指基于寄存器的虚拟机或寄存器式虚拟机，而stack machine或stack VM都是指基于堆栈的虚拟机或堆栈式虚拟机。网上有专门的论文讨论两者的细节。
解释器有很多有趣的东西,但重要的是字节码的定义。字节码实际上是JSC的高层次的中间表示(intermediate representation,&IR)。
在V8中,高层次的中间表示是JS代码本身。当V8第一次看到一段代码,它先预解析(pre-parses)并报告语法错误。然后当它需要分析源代码,无论是在full-codegen编译器或在Hydrogen中,它都重新解析代码为AST(抽象语法树,abstract syntax tree),然后基于AST运行。
相比之下,JSC首先就将代码完全解析为AST,然后再将AST编译为字节码。这时源代码就不再需要了，所以会被抛弃。解释器直接从字节码解释。简单方法JIT编译器也是直接编译字节码。在进一步优化和生成原生代码前，DFG&JIT必须重新将字节码转成SSA(static
single assignment)风格的中间表示(IR)。这个过程开销较大，但对于频繁使用的hot code是值得的。
正如您可以看到的,字节码是所有JSC引擎的通用语言,所以了解它很重要。
真正进入正题之前,我要说一个关于术语的题外话。以我的经验,一个虚拟机传统上被认为是一个解释虚拟指令序列的软件。相对而言，实体机是在硬件上解释机器码或原生指令序列。
最近这些事变得更复杂了。几年前,一个常见的问题是“JavaScript是解释类语言还编译类语言?“ 这个问题其实很奇怪,因为“解释”或“编译”是属性,而不是语言的实现。再说了，实现可以是编译为字节码,然后解释那些字节码, JSC就是这样做的。
但是最后，如果将所有代码编译为字节码, 那虚拟机的意义又体现在哪里呢？即使V8已经没有解释器了, 但V8的骇客们仍然自称为&虚拟机工程师(virtual machine engineers)&。(ARM的模拟器不算在内的话，qemu下运行的程序又如何呢?).
总之，仍然可以称JSC的高层次的中间表示是基于寄存器的虚拟机，并有一系列的虚拟指令集，就像是解释器和简单方法JIT实现的那样。
&基于寄存器的虚拟机(register machine)&, 是相对&基于堆栈的虚拟机(stack machine)&而言的. 它们间的差异主要是前者中所有的临时变量都有名字且存储在一组stack frame中。而后者临时结果被压入堆栈，并且绝大多数指令都是从堆栈中弹出它们的操作符。
(顺便提一下, V8的full-codegen编译器是使用类似stack-machine的方式执行AST的。 V8中有不少Bug都是来源于从full-codegen到Crankshaft转换时使用的堆栈状态模型(accurately modelling the state of the stack)。)
对于一个解释器来说，我相信基于寄存器的虚拟机才是正确的方式。这里我要说明一些理由。
首先，stack machines不利于临时变量的命名。例如下面的代码(Lisp):
(lambda (x)
(* (+ x 2)
(+ x 2)))&
我们可以删除公共表达式(common sub-expression elimation)来优化它:
(lambda (x)
(let ((y (+ x 2)))
(* y y)))&
以stack machine能否胜出呢? 考虑上面第一段代码的指令序列::
; stack machine, 未优化
0: local-ref 0 x
1: make-int8 2
3: local-ref 0 x
4: make-int8 2
7: return&
上面第二段代码的指令序列:
; stack machine, optimized
0: local-ref 0 push x
1: make-int8 2 push 2
2: pop x and 2, add, and push sum
3: local-set 1 pop and set y
4: local-ref 1 push y
5: local-ref 1 push y
6: pop y and y, multiply, and push product
7: pop and return
两种方式下并没有什么改善, 因为存储到本地变量以及将它们压回堆栈使用是不同的指令集，并且一个过程的时间开销同它所执行的指令数之间是一个线性关系。
而在register machine中，事情变得简单多了，而CSE最终获胜:
0: add 1 0 0 add x to x and store in y
1: mul 2 1 1 multiply y and y and store in z
2: return 2 return z&
在register machine中，变量命令没有任何妨碍。使用register machine可以减少push/pop的干扰，而专注于要做的事。
并且因为在指令中包含了操作符的名称(或者说是位置),register machine可以使用更少的指令来完成同一件工作。这减少了调度成本。
此外,register VM中调用帧(call frame)的大小在调用前都是可知的, 这样你就可以在压入数据时检查以避免溢出。(一些stack machine也有这个属性,比如JVM)。
选择register machine的最大的优势是你可以从传统编译器优化中获益，如CSE和寄存器分配(register allocation)。在上面的例子中,我们使用了三个虚拟寄存器, 但在现实中我们只需要一个。生成的代码也更接近真正的机器码,
因此很容易用于JIT。
不利的一面是, register machine通常占用更多的内存。JSC有一个特别的情况,操作码(opcode)和每个操作数(operand)占满了整个机器字。这样做是为了实现“direct threading”, 这个操作码不是在跳转表(jump tables)中索引, 而实际上是相应地址的标签。这在JS不会将字节码序列化到外部磁盘的情况下还免强可以接受。但对于其它需要的重定位的情况就可能会造成丢失。这个功能默认是关闭的。
解释器的stack frame包含一个6字节的帧(six-word frame), 参数,最后是局部变量。一个程序调用会预留一个stack frame的空间,然后将参数压入堆栈 (或者说将它们设置到stack
frame中n + 6位置的寄存器中)——然后调整帧的指针。JSC中的堆栈被称为“寄存器文件(register file)”, 帧指针(frame pointer)则被称为“寄存器窗口(register window)”。这些名字和堆栈世界(stack world)里的“激活记录(activation records)”一样难以理解。
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：608155次
积分：8530
积分：8530
排名：第733名
原创：178篇
转载：29篇
译文：40篇
评论：279条
新浪微博:Horky
微信:horkychen
Mail:horky.
文章：51篇
阅读：90777
文章：35篇
阅读：158430
(5)(1)(4)(5)(1)(1)(4)(2)(6)(1)(2)(2)(4)(5)(4)(11)(11)(2)(5)(5)(4)(9)(2)(11)(7)(20)(34)(31)(9)(1)(6)(4)(1)(1)(2)(3)(8)(1)(1)(1)(1)(1)(3)(2)(1)(1)(1)(1)(2)(2)(1)有谁有Visual paradigm的key呀，谢谢分享一下_百度知道
有谁有Visual paradigm的key呀，谢谢分享一下
提问者采纳
请点“赞”此条回答以后，请采纳，请按照步骤进行使用，如还有疑问你这个问题有很多人问过，我已发送！ 如果还有哪位朋友想要，在下面的评论里留下您的联系方式！ 希望回答能给你带来帮助~ 如果满意，可继续追问
其他类似问题
paradigm的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁有谁有Visual paradigm的key呀，谢谢分享一下_百度知道
有谁有Visual paradigm的key呀，谢谢分享一下
提问者采纳
没用这个版本的哦，这有VisualAssistX_10.7.1918_Soft711.7z的破解方法，你可以参考如下：1、破解方式一：Visual_Assist_X_DiE.exe运行Visual_Assist_X_DiE.exe，勾选安装的VC版本，点击“Patch”按钮即可俯互碘就鄢脚碉协冬茅。2、破解方式二：vax_patch.exe★ VC6/的破解方法：复制破解补丁vax_patch.exe到Visual Assist的安装目录(例如 C:\Program Files\Visual Assist)，直接运行补丁程序即可。
其他类似问题
paradigm的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁