Adobe AVM2 虚拟机详解：ActionScript 运行机制

5星 · 超过95%的资源需积分: 10 62 浏览量更新于2024-07-28 1 收藏 400KB PDF 举报

"这篇文档是关于Adobe ActionScript Virtual Machine 2 (AVM2)的概述，主要关注于DOABC解析，适用于AS3和Flash开发。" Adobe ActionScript Virtual Machine 2（AVM2）是Adobe Systems开发的一个关键组件，它是ActionScript 3编程语言的执行环境，用于运行在Flash Player和Adobe AIR中的多媒体应用程序。AVM2是在ActionScript 2（基于ECMAScript 3）之后推出的，它引入了对ActionScript 3的支持，一个更加面向对象、性能更强大的脚本语言。 ActionScript 3（AS3）带来了许多重要的改进，包括： 1. 类型系统：AS3引入了强类型，使得代码更加严谨，提高了编译时错误检测的效率。 2. 命名空间和包：允许开发者更好地组织代码，避免命名冲突。 3. 更快的性能：AVM2优化了执行效率，特别是在处理大量数据和复杂计算时。 4. 面向对象编程：支持类、接口、抽象类和继承，使代码结构化更强。 5. 动态语言特性：虽然AS3是静态类型的，但它仍保留了一些动态语言的特性，如运行时类型检查和动态属性访问。 DOABC（Data-Oriented ABC）是AVM2中使用的字节码格式，用于编译和存储ActionScript代码。ABC字节码是一种中间表示形式，它在编译时生成，并在运行时由AVM2解释执行。DOABC解析是AVM2运行时的重要组成部分，负责将这些字节码转化为实际的机器可执行的操作。在使用AVM2和AS3进行开发时，开发者可以利用其提供的各种库和API来创建丰富的交互式内容，如动画、游戏、数据可视化和网络应用。例如，Flash Player提供了对位图、矢量图形、音频、视频和网络通信的内置支持。然而，随着Web技术的发展，特别是HTML5的普及，Flash逐渐被替代，AVM2和ActionScript的重要性也有所下降。尽管如此，理解AVM2的工作原理和AS3的特性仍然是理解Web开发历史和某些遗留项目的关键。在使用AVM2和AS3时，开发者需要注意的是，由于AVM2的设计和优化，代码的性能会受到编写方式的影响。因此，良好的编程实践，如避免不必要的类型转换和使用高效的数据结构，对于获得最佳性能至关重要。总而言之，Adobe ActionScript Virtual Machine 2（AVM2）和ActionScript 3（AS3）是Flash平台上开发高级互动内容的关键技术，它们提供了强大的功能和高效的性能，尽管随着技术的演变，其在现代Web开发中的地位已被其他技术所取代。了解AVM2和AS3的工作原理对于理解过去和现在的Web应用开发具有重要意义。

Adobe ActionScript Virtual Machine 2 (AVM2) Overview 16

3.3.4 Execution mechanics

Execution begins with the first instruction of the code in the method_body_info. The address of this first

instruction is 0. The first byte of each instruction is the opcode, which is followed by zero or more bytes of

operands. The instruction may modify the local data areas as well as objects on the heap, and it may create new

objects on the heap either directly or indirectly. (The AVM2 instruction set is defined in Section 2.5.)

Branch and jump instructions add a signed offset to the program counter to effectuate the branch. The base

value for the program counter is the instruction address following the instruction.

3.3.5 Calling and returning

When one of the call instructions is executed, a new local data area is created for the called function. The called

function has no access to the local data area of its caller. The actual parameter values are coerced to the types

expected by the called function as part of the call protocol.

The return instructions transfer a single value from the returning function’s stack, or the implied value

undefined, to the caller. The returned value is coerced to the returning function’s declared return type as part

of the return protocol. The coerced value replaces the operands of the call instruction in the calling method’s

stack, and the called method’s local data area is destroyed.

3.3.6 Exception handling

Exception handlers are defined by a table associated with each method. The table defines a range of bytecode

addresses across which a particular handler is active, the bytecode address of the handler, and a type which is

used to determine whether the handler will handle a particular exception.

When an exception is thrown, the call stack is unwound until a method is found that contains a handler which

covers the current program counter and whose type is a supertype of the type of the object thrown. The

method containing the handler is reactivated and the program counter is set to point to the first address of the

handler. The value and scope stacks in the handling method are cleared before the handler is entered.

finally clause is normally translated as an exception handler that accepts any type of value, which it catches

and rethrows after the body of the

finally block finishes executing.

3.4 Verification

As noted earlier, verification does not happen all at once. Verification is often put off until a datum is actually

needed or until some dependent object has been loaded, so that forward references will be possible.

The following list summarizes some of the verification errors signaled by the AVM2. (Not all verification errors

are listed.)

• There must be no nonzero bits above bit 30 in a u30 value.

• No control flow instruction must cause control to be transferred outside the code vector or into the

middle of another instruction.

• Multiple control flow instructions to the same instruction must have compatible scope stacks, operand

stacks, and register values.

• Named types (for example, in

coerce instructions or in a base class reference) must always be

uniquely resolvable.

• Names may not reference index zero of the name pool unless explicitly specified for that particular

name field.

Adobe ActionScript Virtual Machine 2 (AVM2) Overview 18

4 The ActionScript Byte Code (abc) format

Syntactically complete sections of ActionScript code are processed by a compiler into ActionScript Byte Code

segments. These segments are described by the

abcFile structure, which is defined below. The abcFile

structure is the unit of loading and execution used by the AVM2.

The

abcFile structure describes the interpretation of a block of 8-bit bytes. Despite the name, the contents of

abcFile does not need to be read from a file in the file system; it can be generated dynamically by a run-

time compiler or other tools. The use of the word “file” is historical.

The

abcFile structure comprises primitive data, structured data, and arrays of primitive and structured data.

The following sections describe all the data formats.

Primitive data include integers and floating-point numbers encoded in various ways.

Structured data, including the

abcFile itself, are presented here using a C-like structural notation, with

individual named fields. Fields within this structure are in reality just sequences of bytes that are interpreted

according to their type. The fields are stored sequentially without any padding or alignment.

4.1 Primitive data types

Multi-byte primitive data are stored in little-endian order (less significant bytes precede more significant bytes).

Negative integers are represented using two’s complement.

 The type u8 represents a one-byte unsigned integer value.

 The type u16 represents a two-byte unsigned integer value.

 The type s24 represents a three-byte signed integer value.

 The type u30 represents a variable-length encoded 30-bit unsigned integer value.

 The types u32 and s32 represent variable-length encoded 32-bit unsigned and signed integer values

respectively.

 The type d64 defines an 8-byte IEEE-754 floating point value. The high byte of the double value

contains the sign and upper bits of the exponent, and the low byte contains the least significant bits of

the significand.

The variable-length encoding for u30, u32, and s32 uses one to five bytes, depending on the magnitude of the

value encoded. Each byte contributes its low seven bits to the value. If the high (eighth) bit of a byte is set,

then the next byte of the

abcFile is also part of the value. In the case of s32, sign extension is applied: the

seventh bit of the last byte of the encoding is propagated to fill out the 32 bits of the decoded value.

Adobe ActionScript Virtual Machine 2 (AVM2) Overview 19

4.2 abcFile

abcFile

{

u16 minor_version

u16 major_version

cpool_info constant_pool

u30 method_count

method_info method[method_count]

u30 metadata_count

metadata_info metadata[metadata_count]

u30 class_count

instance_info instance[class_count]

class_info class[class_count]

u30 script_count

script_info script[script_count]

u30 method_body_count

method_body_info method_body[method_body_count]

}

The abcFile structure describes an executable code block with all its constant data, type descriptors, code, and

metadata. It comprises the following fields.

minor_version, major_version

The values of major_version and minor_version are the major and minor version numbers of the

abcFile format. A change in the minor version number signifies a change in the file format that is

backward compatible, in the sense that an implementation of the AVM2 can still make use of a file of an

older version. A change in the major version number denotes an incompatible adjustment to the file

format.

As of the publication of this overview, the major version is 46 and the minor version is 16.

constant_pool

The constant_pool is a variable length structure composed of integers, doubles, strings, namespaces,

namespace sets, and multinames. These constants are referenced from other parts of the

abcFile

structure.

method_count, method

The value of method_count is the number of entries in the method array. Each entry in the method array

is a variable length

method_info structure. The array holds information about every method defined in

this

abcFile. The code for method bodies is held separately in the method_body array (see below).

Some entries in

method may have no body—this is the case for native methods, for example.

metadata_count, metadata

The value of metadata_count is the number of entries in the metadata array. Each metadata entry is a

metadata_info structure that maps a name to a set of string values.

class_count, instance, class

The value of class_count is the number of entries in the instance and class arrays.

Each

instance entry is a variable length instance_info structure which specifies the characteristics of

object instances created by a particular class.

Each

class entry defines the characteristics of a class. It is used in conjunction with the instance field to

derive a full description of an AS Class.

script_count, script

The value of script_count is the number of entries in the script array. Each script entry is a

script_info structure that defines the characteristics of a single script in this file. As explained in the

previous chapter, the last entry in this array is the entry point for execution in the

abcFile.

Adobe ActionScript Virtual Machine 2 (AVM2) Overview 20

method_body_count, method_body

The value of method_body_count is the number of entries in the method_body array. Each method_body

entry consists of a variable length

method_body_info structure which contains the instructions for an

individual method or function.

4.3 Constant pool

The constant pool is a block of array-based entries that reflect the constants used by all methods. Each of the

count entries (for example,

int_count) must be one more than the number of entries in the corresponding

array, and the first entry in the array is element “1”. For all constant pools, the index “0” has a special meaning,

typically a sensible default value. For example, the “0” entry is used to represent the empty sting (

""), the any

namespace, or the any type (

*) depending on the context it is used in. When “0” has a special meaning it is

described in the text below.

cpool_info

{

u30 int_count

s32 integer[int_count]

u30 uint_count

u32 uinteger[uint_count]

u30 double_count

d64 double[double_count]

u30 string_count

string_info string[string_count]

u30 namespace_count

namespace_info namespace[namespace_count]

u30 ns_set_count

ns_set_info ns_set[ns_set_count]

u30 multiname_count

multiname_info multiname[multiname_count]

}

If there is more than one entry in one of these arrays for the same entity, such as a name, the AVM may or may

not consider those two entries to mean the same thing. The AVM currently guarantees that names flagged as

belonging to the “private” namespace are treated as unique.

int_count, integer

The value of int_count is the number of entries in the integer array, plus one. The integer array

holds integer constants referenced by the bytecode. The “0” entry of the

integer array is not present in

the

abcFile; it represents the zero value for the purposes of providing values for optional parameters and

field initialization.

uint_count, uinteger

The value of uint_count is the number of entries in the uinteger array, plus one. The uinteger array

holds unsigned integer constants referenced by the bytecode. The “0” entry of the

uinteger array is not

present in the

abcFile; it represents the zero value for the purposes of providing values for optional

parameters and field initialization.

double_count, double

The value of double_count is the number of entries in the double array, plus one. The double array

holds IEEE double-precision floating point constants referenced by the bytecode. The “0” entry of the

double array is not present in the abcFile; it represents the NaN (Not-a-Number) value for the purposes

of providing values for optional parameters and field initialization.

剩余107页未读，继续阅读

阿唐

粉丝: 0
资源: 11

Adobe AVM2 虚拟机详解：ActionScript 运行机制

AVM2虚拟机逃逸技术深度探究

深入理解Avm2虚拟机与AS3性能优化技巧

掌握AVM2虚拟机：Actionscript字节码与执行解析

AVM2虚拟机逃逸技术研究

Avm2虚拟机浅析与as3性能优化

flash虚拟机源码-AVM2

ActionScript虚拟机2（AVM2）详解

Action Script 虚拟机-AVM2 源码

CrossBridge-Community:用于ActionScript虚拟机（AVM2）的C / C ++编译器-开源

AVM

最新资源