脚本解释器构架(三)
来源:互联网 发布:k线公式源码 编辑:程序博客网 时间:2024/04/29 02:32
运行时环境
脚本的运行时环境(Run-Time Environment, RTE)是解释器的核心。运行时环境与语法分析器可以相互独立,但是又有联系。脚本的解释方式主要有两种:1、基于伪指令的解释;2、基于语法树的解释。我的脚本解释器采用第二种解释方式。
基于伪指令的解释
由于我的脚本解释器不是采用这种解释方式,因此先介绍这种方式,然后详细介绍我的脚本解释器的基于语法树的解释方式。而且,在基于伪指令的解释方式下更容易对解释器的运行构架进行阐述。
基于伪指令的解释方式要求不仅仅将脚本分析为语法树,还要将语法树编译为伪指令(或叫做中间指令)。运行时环境就是模拟一个以伪指令为指令集的“CPU”,对翻译后的伪指令文件(可能只存在于内存中)逐条指令进行解释执行。
这种模拟出来的可以执行伪指令的“CPU”与一般的CPU一样,也有类似的构架特征:
1. 运算单元,用来执行基本的数学和逻辑运算(+、-、×、/、AND、OR、NOT等等);
2. 内存编址,用连续的真实内存空间来模拟虚拟内存,内存地址的连续性可以加快访问速度;
3. 堆栈,用来存放局部变量和函数调用信息;
4. 动态内存,用来创建、保存运行时对象。
有了这些功能的对应指令,并对每条指令的动作进行定义、编码,一个基于伪指令的解释器就基本完成了。
基于语法树的解释
脚本可以直接在语法树上被解释执行。因为脚本语言基本是由操作构成。仅有的几个变量和函数的声明语法也都可以看作是对象的初始化操作语句。语法树中每个结点代表了一个动作,对应于一条伪指令。因此对语法树的解释基本上可以看作是对语法树的后序遍历(先解释完所有子节点,再解释根节点)。
基于语法树的解释和基于伪指令的解释是等效的,这个可以很直观的证明:语法树上每个根节点都可以设计出一条单独的伪指令,与此同时,每条伪指令又可以看作是以操作数为子节点的树,因此两种解释方式可以相互转化。只不过从伪指令转化为一颗直观的语法树比较复杂而已。
由于两者的等效性,因此两者的运行时环境也是等效的,具有相同的特征。
运行时环境的设计
1.名字表
上面提到的模拟“CPU”构架中没有提到名字表,因为真实的CPU没有名字表,基于伪指令的翻译也不需要有名字表,只要有内存地址或者偏移量即可。但是脚本对象的成员是按名取值,必须要查对应的名字表获取要操作的对象。
2.左值与右值
左值都是引用,右值都是对象。可以根据左值获得右值,或者根据右值获得左值。
3.操作的重载
一个对象必须重载所有的操作,允许产生运行期错误。因为脚本中每一个变量,都有可能引用全部类型的变量,因此有可能遇到任何操作。
4.对象的继承结构
在我的脚本编译器中,所有对象都是引用计数的。因此他们从同一个基类继承出来。
5.变量的寻址和传递
我的脚本中没有全局变量,所有变量都是局部的或者成员的。局部变量都放在堆栈中。传递是是按引用来传递,即传递的是右值对象。
6.函数的调用、返回和参数传递
一个函数被调用,必须记录函数的返回地址。在我的脚本运行环境中,负责处理脚本调用的函数会随着每一次的脚本调用而递归。当然,这个递归做了层数限制(目前只能递归1000层),超过限制则发出堆栈用完的错误。返回也是随着C++代码的返回而返回。
函数调用之前,需要将所有参数准备好,从左至右依次压入堆栈中。压入的参数数目不得少于形参数目。如果代码中实参数目比形参少,则自动补入空对象。有更多的实参,则全部压入堆栈。压入参数之前和之后都有变量记录堆栈指针的位置。压入参数之后的位置是当前函数局部变量的起始位置,压入参数之前的位置供函数返回后清空局部堆栈使用。
- 脚本解释器构架(三)
- 脚本解释器构架(一)
- 脚本解释器构架(二)
- 实现一个数字电路的脚本解释器(三)——SymbolList的实现
- 小型脚本解释器
- 脚本解释器
- 指定脚本解释器
- Visual C# 插件构架实战(三)
- Visual C# 插件构架实战(三)
- java基础(三)------集合构架
- 解释器构造实践-ANTLR(三)
- 词语解释(三)
- VB6语言脚本解释器
- 我的脚本解释器
- C++ 脚本解释器cint
- 编写简单脚本解释器
- PB动态脚本解释器
- 实现一个数字电路的脚本解释器(一)
- MySQL 建表语法
- Makefile符号说明
- 把杯子放下
- 对文件进行二进制的循环处理时byte[ ]比blob更有效率
- 绘制透明按钮的另外一法
- 脚本解释器构架(三)
- 爱你却无缘牵手
- 唐僧师徒用了手机之后
- AWK 常用功能
- 请教!!!
- 伪静态以及修改UrlRewrite以对域名进行重写
- 见怪不怪
- 大学生是干嘛来的?
- 必读