CN1270348A - 用于结构仿真的动态优化目标码翻译器和翻译方法 - Google Patents

Abstract

一种优化目标码翻译系统和方法,完成编译和翻译源操作系统上的标的目标码,并同时完成优化。对目标码的编译和优化是实时动态执行的。编译器完成分析和优化,与基于模板的翻译和解释相比使仿真得到改善,从而使处理较大量级指令(如32位指令)的处理器可以仿真处理较小量指令(如16位或8位指令)的目标处理器。优化目标码翻译器不需要在运行时之前知道静态程序流程图或目标指令存储器位置。

Description

用于结构仿真的动态优化目标码 翻译器和翻译方法

本发明涉及在一主处理系统中运行以仿真第二操作系统的目标码翻译器技术。更具体而言，本发明涉及动态目标码翻译器技术，这种翻译器在一个具有主处理器目标码指令集的主处理器上执行过程中实时地完成对原始目标码指令集的分析和计算。

在目标码翻译器领域中，有必要把已在一个计算机上开发的目标码转换到具有不同计算机结构的另一个计算机上。这种目标码的转换方法包括一种名为“静态目标码转换方法”的转换方法，用这种方法时指令语句要首先转换成第二种结构的目标码，然后再执行。第二种转换方法是“动态目标码转换方法”，使用这种方法时第一目标码被转换成第二种目标码而同时执行指令。

在静态目标码转换方法技术中，执行时间不受转换所需时间的影响。然而，在执行静态目标码转换时，被转换成的目标码的实际大小变大了。换句话说，使用静态目标码转换方法时，被转换成的目标码中许多操作步骤不可避免地增大了。结果，出现了被转换成的目标码性能下降和效率不高的问题。

另一方面，使用动态目标码转换方法时，与静态转换成的目标码相比，其转换成的目标码的大小变得比较小。然而，传统的动态目标码转换方法有一个问题，即全部目标，包括很少使用的目标，都被转换。换句话说，传统的动态目标码转换方法不能够识别出那些被多次执行的目标，从而增加了转换目标码所需时间而牺牲了效率。

因此，本发明的一个目的是提供一种目标码翻译器，它解决这项技术中的问题同时提供对翻译成的目标码的动态优化。

本发明的又一目的是给出主程序的“概要分析(profile)”，直至编译器完成编译为止，该概要分析结果被编译器用于编译和优化该程序。

本发明的又一目的是在动态优化和编译过程中从未被翻译的代码跳到被翻译后的代码。

本发明的又一目的是提供一种带有软件反馈的动态优化目标码翻译器，它计算发送给编译器的翻译请求数与已完成的翻译数之差。

本发明的又一目的是提供从一种机器语言的计算机程序到另一种计算机语言的动态翻译而该程序同时在运行过程中。

再有，本发明的一个目的是提供一种动态目标码翻译器，它从对应于源目标码中多个分支的多个种子中确定要翻译的段。

本发明的这些目的是由一个计算机结构仿真系统实现的，它在一个目的计算机上仿真一个源计算机，该系统包括一个解释器用于把源目标码单个地翻译成相应的翻译后的目标码，并计算源目标码中分支指令的执行次数；还包括一个编译器，用于当相应的分支指令执行次数超过一阈值时把源目标码指令组合成段，并用于动态编译该段。

本发明的这些目的还由一个计算机结构仿真系统实现，它在一个目的计算机上仿真一个源计算机，该系统包括多个解释器用于把源目标码单个地翻译成相应的翻译后的目标码，这里这多个解释器的每一个都在执行翻译后的目标码指令的同时实时地概要分析源目标码分支信息；还包括一个编译器，用于根据源目标码中相应的分支指令把来自这多个解释器中任何一个的源目标码指令组合成段，并当相应的分支指令大于一阈值时动态编译这些源目标码段。

本发明的又一些目的由一个计算机结构仿真系统实现，它在一个目的计算机上仿真一个源计算机，该系统包括一个解释器用于把源目标码单个地翻译成相应的翻译后的目标码，这里该解释器通过存储每个分支指令的执行次数来记录源目标码的分支指令，从而使超过阈值的分支指令成为种子；还包括一个编译器用于根据这些种子把源目标码指令组合成段并在由解释器进行翻译和记录的过程中动态编译这些源目标码段。

本发明的另一些目的由一个多任务计算机结构仿真系统实现，它在一个多任务目的计算机结构上仿真一源计算机结构，该系统包括一个解释器任务用于把源目标码单个地翻译成相应的翻译后的目标码和用于确定源目标码中分支指令的执行次数；还包括一个编译器任务，它在多任务目的计算机结构上与解释器一起运行，用于在相应的分支指令执行次数超过一阈值次数时把源目标码组合成段，并用于动态编译该段。

由下文中结合附图对最佳实施例的描述，本发明的这些和其他目的和优点将变得更加明显和易于理解。这些图件是：

图1是根据本发明的一个最佳实施例，一个OOCT系统的高级结构的框图。

图2是一个流程图，说明优化目标码翻译的组成部分以及用于编译一段源代码的控制流。

图3是一个流程图，说明在正常执行过程中优化目标码翻译的控制流。

图4是一示意图，说明用于一组变量的OOCT缓冲器。

图5a、5b和5c是说明一翻译表结构的示意图。

图6是用于进入和退出一段的解释器方框图。

图7是用于创建一段、使该段可被解释器达到、使老的段不可被达到以及删除老段的编译方法方框图。

图8是说明BRANCH-RECORD(分支记录)结构的方框图。

图9是一示意图，说明一个分支记录的结构，该记录是存储BRANCH-RECORD的大散列表的一部分。

图10是一示意图，说明一个L1高速缓存的结构，它是若干BRANCH-RECORD的2维阵列。

图11是一示意图，说明由一解释器对L1高速缓存执行操作的方法。

图12是一示意图，说明根据本发明一个实施例的编译器的总体结构。

图13是一示意图，说明根据本发明一个实施例的块检出器的举例。

图14是一代码轮廓的方框图，该代码轮廓带有两个外部入口点，这里在ENTRY(入口)指令和GOTO(转向)指令之间插入了填充指令。

图15是说明一个OASSIGN(赋值)插入举例的方框图。

图16是一方框图，说明死代码删除和地址检验删除的举例。

图17是地址检验删除举例的方框图。

图18是公共子表达式删除(“CSE”)举例的方框图。

图19是复制传播举例的方框图。

图20具体说明一常数合并的举例。

图21具体说明上述过程的举例，它有一个根据本发明一实施例的比较基础结构。

图22具体说明对于有不同相邻指令的同一指令产生代码的举例。

图23说明根据本发明第二实施例用于动态优化目标码翻译的系统配置。

图24说明根据本发明第三实施例用于并发动态翻译的系统配置。

图25说明根据本发明第三实施例把解释器和编译器组合(例如在执行过程中组合成一个任务)和把它们分开(例如分成不同的任务)二者之间的差别。

图26说明根据本发明第四实施例的翻译表用于记录哪些指令是可翻译的而哪些指令是不可翻译的。

图27说明根据本发明第四实施例该方法如何减小仿真器上进行概要分析的负担。

图28说明根据本发明第五实施例具有单独解释器和编译器的动态翻译系统的总体结构图。

图29说明根据本发明第五实施例的软件反馈机制的组成部分。

图30说明根据本发明第六实施例在翻译任务忙时如何使用一队列来保持翻译请求。

图31说明根据本发明第六实施例如何由OOCT请求队列把便宜的共享存储器请求与系统调用请求组合在一起。

图32显示根据本发明第七实施例一个动态翻译器如何会容易引起页面错误，而这种错误在源指令的正常执行过程中是不会发生的。

图33显示根据本发明第七实施例用于从页面错误中恢复和继续进行翻译的算法。

图34说明根据本发明第八实施例在常有分支概要分析器(profiler)的动态翻译系统中的控制流图象。

图35说明根据本发明第九实施例该动态翻译器如何使用分支概要分析信息去计算一个基本块的执行概率。

现在将详细参考本发明的最佳实施例，在附图中说明了它们的举例，这里相似的参考数字始终代表相似的部件。本发明第一实施例I.系统概述

一般而言，本发明涉及一种优化目标码翻译器(下文中称作“OOCT”)，它作为一个计算机结构仿真系统的一部分，完成一个微处理器指令集的动态编译。编译是动态的，因为在运行时之前没有对应用指令集的任何简单的访问。相对于基于模板翻译和基于模板的解释而言，使用一编译器作为目标码翻译系统一部分可允许系统完成分析的优化，从而改善仿真的性能。

仿真用主处理器最好是市场上可得到的处理器，如英特尔奔腾(IntelPentium)处理器。奔腾处理器指令集的体系结构有利于管理不同大小的数据，从而有利于仿真16位和8位两种目标码指令。16位和8位目标码指令可以是为第二处理器上的原始应用设计的，例如来自富士通的K系列处理器。

只有知道指令流程图才可能完成有意义的编译器类型优化。在传统的编译器中，流程图是给出的而且是定义得很好的。因为在开始优化之前整个程序例程被完全地语法分析过。对于OOCT，则不是这种情况。在运行该程序之前，指令在存储器图象中的位置是未知的。这是因为指令长度是可变的，并带有任意插入的非指令数据集。指令的位置如同所有到指令中的结合点的位置一样，都是未知的。

所以，为确定流程图，该程序必须被运行。一个解释器第一次运行该程序。在解释器执行该程序时，解释器每当完成一个分支操作时便通知OOCT。这一信息记录标识出一些指令和一些结合点。随着该程序的运行，关于流程图的信息变得更完全，尽管永远不会全部完全。OOCT被设计成借助关于流程图的部分信息进行工作：优化是根据可能不完全的流程图进行的，而且该系统被设计成允许当能得到更多信息时替换被优化的代码。

动态编译根据解释器收集的概要分析信息选择对哪些部分内容进行优化。当某一分支被执行的次数超过一个阈值数时，那个分支的目的地变为编译的种子。这个种子是对要被编译的一部分K指令作为一个单元进行语法分析的起始点。

一个段所包含的主处理器指令是从种子开始对原处理器指令进行优化的结果。一个段作为一个单元被安装或卸下。当解释器调用OOCT以通告有一个分支时，如果用于目的地的代码存在的话，OOCT可能选择把控制转交给该段。类似地，该段可能包含代码用于把控制转交回解释器。

一个段本身可能是不完全的，这样该段只代表原始程序的可能流程路径的一个子集。但这种不完全的表达不影响该仿真的正确操作。如果发生了新的未预料到的穿过原代码的流程路径，那么控制流程将跳回解释器。然后，这同一段能被替换，以考虑新的控制流程。II.OOCT代码结构

根据本发明的一个实施例，OOCT可以在传统的操作系统环境，如Windows(视窗)下运行。然而，根据本发明的第二实施例，OOCT可以被构成为与第二操作系统的仿真固件链接，如富士通的KOI操作系统。III.体系结构

图1说明OOCT系统100的高级体系结构。图1显示两个任务，即解释器110和编译器104。解释器110和编译器104在一多任务操作系统下同时操作。这两个任务即能借助分支记录器112访问分支记录，又能访问编译过的代码段108。此外，解释器110能向编译器104发送编译请求。在下文中的通信部分中将给出这两个任务之间通信的更完全描述。编译流程控制

图2说明OOCT 100的主要组成部分以及编译一部分原始代码的控制流程。主要OOCT级如下。首先，解释器110通过与分支记录器112通信记录下分支信息。然后分支记录器112使用种子选择方法确定把哪个种子发送到编译器104。然后，块检出器114使用种子和分支概要分析信息选择一段原始代码以进行编译。然后该块检出器114建立一个描述待编译原始指令的控制流程图(CFG)，并把CFG传送给块布局(layout)单元116。

然后块布局单元116把控制流程图展平为线性的指令列表。优化代码产生单元118完成从原始指令到翻译后的代码段指令的实际编译。所产生的翻译后代码与关于被编译代码段的信息一起最后被传送给段安装单元120，它使这些代码对解释器110可用。OOCT执行控制流程

图3说明在正常执行过程中OOCT中的控制流程。在解释器110执行代码过程中，当执行某些指令时，OOCT能进入分支记录器112。分支记录器能返回解释器110，或者若该分支的目的已被编译则进入被安装的编译后代码段之一。由被编译的代码，能逐段进行翻译，或回到解释器110。编译后代码或者能调用解释器110去执行单条原始指令，或者能跳到解释器110，把所有控制转交给解释器110。

对主体应用的第一实施例的描述可分解如下。第一部分描述解释器110和编译器104之间的接口。第二部分描述为了OOCT而对解释器110所做的修改。第三部分描述编译器104。最后一部分描述一个视窗测试环境。

在第一实施例描述之后将描述本发明第二至第九实施例。IV通信(公共单元)

解释器110和编译器104彼此以多种方式通信。解释器110通过与分支记录器112通信，把分支信息记录到分支日志中。编译器104也能读这个分支日志。编译器104创建编译后代码段并把它们的入口点存入翻译表，解释器110读此表。解释器110还通过一缓冲器向编译器104发送种子地址。由编译器104和解释器110两者用于这种通信的源代码是在公共单元中。这一部分描述这种通信如何进行。共享OOCT缓冲器

编译器104和解释器110之间的所有通信都直接通过OOCT缓冲器，它是一个大的共享存储区。某些通信还利用系统调用从解释器110向编译器104发送消息以及反向发送。

下面列出的表1显示了OOCT缓冲器的静态分配部分图。缓冲器的其余部分动态分配给不同的数据结构，如下面给出的表2所示。在OOCT缓冲器的静态分配部分中的某些字段(field)指向动态分配部分中的数据结构。这些指针有上标号显示它们指向什么。例如，在静态分配部分中的分区字段有标号2，而且该分区字段指向动态分配部分中的分区存储器，该分区存储器也有标号2。

                   表1. OOCT缓冲器的静态分配部分

字  段	偏  移	内  容
			jump-table(转跳表)	0h	在解释器110中的入口点数组，例如IC_FETCH02，IU_PGMxx。OOCT_INIT写它们，而编译器104读它们。编译器104用它们产生到解释器110的转跳。
trans_master_target_table(发送主控目标表)	1000h	指针数组，在ASP地址空间中每页有一个指针。对于ASP未使用的页，指针为0。对于ASP使用的页，指针指向OOCT缓冲器动态分配部分中的一个数组(见下表)。
			unallocated(未配分配的)	41004h	一个指针，指向缓冲器动态分配部分中的第一个未用字节。只在初始化过程中使用。
length_left(剩余长度)	41008h	在缓冲器动态分配部分中的剩余字节数。只在初始化过程中使用。
			num_execs(解释器数)	4100Ch	解释器110个数。
zones2(分区)	41010b	一个指针，指向OOCT缓冲器的动态分配部分中的分区存储器。OOCT_INIT写此指针而编译器104读此指针。编译器104在编译过程中使用该分区存储器。
			zones_length(分区长度)	41014h	分区存储器的大小。由OOCT_INIT写，由编译器104读。
segments3(段)	41018h	指向段存储器的指针，该段是OOCT缓冲器的动态分配部分中。OOCT_INIT写此指针而编译器104读此指针。编译器104用该段存储器存储编译后的代码。
			segments_length(段长)	4101Ch	段存储区的大小。由OOCT_INIT写，由编译器104读。
branch_l1_tables4	41020h	指向一级(L1)分支高速缓存结构的指针，这些结构是在OOCT缓冲器的动态分配部分中。
			branch_record_free_list5(未使用分支记录列表)	41024h	未使用的BRANCH_RECORD(分支记录)结构列表，这些结构是在OOCT缓冲器的动态分配部分。
branch_beader_table6(分支标题表)	41028h	含有BRANCH_RECORD(分支记录)结构的混列表。该表是在OOCT缓冲器的动态分配部分中。

branch_log_lock(分支日志锁)	4102Ch	在写分支日志时必须持有的锁。
			branch_seed_buffer(分支种子缓冲器)	41030h	解释器110向编译器104发送种子时使用的缓冲器。
num_monitor_seed_messages(监视器种子消息数)	41060h	一个计数器，告知已由解释器110向编译器104发送了多少个消息，但编译器104尚未结束。
			seed_threshold_mode(种子阈值方式)	41064h	一个标志，告知解释器110如何检出一个种子。该种子或者是OOCT_DEBUG_MODE(OOCT调试方式)或OOCT_PERFORMANCE_MODE(OOCT运行方式)
seed_production_threshold(产生种子阈值)	41068h	在一个分支的目的地成为编译器104的种子之前该分支必须执行的次数的阈值。
			trickle-flush-l1-rate(L1细流-倾泄率)	4106Ch	在分支从L1级高速缓存泄出并写回存储器之前，在此L1级高速缓存中该分支能被更新的次数。
seeds_sent(发送种子数)	41070h	未使用
			seeds_handled(处理种子数)	41074h	未使用
exit(退出)	41078h	编译器104使用这一标志告知解释器110；在收到一个信号后编译器104已经关闭。
			segment_exit(段退出)	4107Ch	在解释器110中的一个入口点，它是在一旦退出时编译后代码要转跳去的地方。必要时，在这一入口点代码释放锁。
segment_exit_inter-p(段退出解释器)	41080h	在解释器110中的一个入口点，在结束一个必须解释的指令的编译后代码要转跳去的地方。必要时，在这一入口点代码释放锁。
			segment_exit_log(段退出日志)	41084h	在解释器110中的一个入口点，在结束一个非固定分支指令时编码后代码要转跳去的地方。必要时，在这一入口点代码释放锁。
sbe_impl(应用sbe)	41088h	在解释器110中的一个入口点，编译后代码调用它以执行SBE指令。
			cc-impl(应用CC)	4108ch	在解释器110中的一个入口点，编译后代码调用它以执行CC指令。

mv_impl(应用mv)	41090h	在解释器110中的一个入口点，编译后代码调用它以执行MV指令。
			mv_impl_same_size(同样大小时应用mv)	41094h	在解释器110中的一个入口点，当两个字符串的长度相同时，编译后代码调用它以执行MV指令。
segment_lock_mousestrap(段锁捕获器)	41098h	在解释器110中的一个入口点，编译后代码调用它以证实它仍持有锁。这只用于程序调试。
			breakpoint_trap(断点捕获器)	4109Ch	在解释器110中的一个入口点，编译后代码调用它以停在程序调试器中。这只用于程序调试。
segment_gates(段门)	410A0h	SEGMENT_GATE(段门)结构数组。SEGMENT_GATE用于锁住编译后代码段。
			gate_free_list(未用门列表)	710A0h	当前未用SEGMENT_GATE(段门)列表。
ooct_stack_bottom7(OOCT堆栈底)	710A4h	编译器104堆栈的最低地址。它指向OOCT缓冲器动态分配部分之中。
			ooct_stack_top7(OOCT堆栈顶)	710A8h	编译器104堆栈的最高地址。它指向OOCT缓冲器的动态分配部分之中。
build_options(建造选项)	710Ach	建造解释器110所用的选项。在ooct_compiler_start(OOCT编译器启动)中，编译器104检验它曾以同样的选项被构建。
			code_zone2(代码区)	710B0h	指向动态分配存储器的一个区域的指针。编译器104使用这一存储器暂时创建一个目的指令数组。在编译结束时，这个数组被拷贝到段存储器区域，然后该数组被删除

在OOCT缓冲器的动态分配部分，数据结构的大小取决于若干变量。一个变量是原始处理器(如富士通的ASP)的操作系统所用系统页面数。对于含有要被翻译的指令的ASP地址空间的每个页面，在翻译表中有一个翻译过的页。另一个参数是该系统预期记录的分支指令数。它当前预期2²⁰个分支，这影响BRANCH_RECORD(分支记录)数组和分支头段表二者的大小。解释器110数影响L1级分支记录器高速缓存的大小，因为对每个任务有一个高速缓存。

图4是对于一组变量其OOCT缓冲器的构成图。在图4中，ASP页面数是10MB个ASP指令，解释器110个数是4，OOCT缓冲器的总大小是128MB。

表2：OOCT缓冲器的动态分配部分

名    称	内    容
		Translation Table1(翻译表)	对于ASP所用地址空间的每个页面，在翻译表中被分配一个有16KB的页面。大小＝Num system pages(系统页面数)*16KB。
BRANCH_RECORDarray5(分支记录数组)	我们猜测在ASP中会发生多少分支指令(当前的猜测是220)，并对每个分支指令分配一个BRANCH_RECORD(分支记录)。大小＝220*24字节＝24MB。
		Branch header table6(分支标题表)	对每个估计的分支有一个指针指向一个BRANCH_RECORD(分支记录)。大小＝220*4字节＝4MB。
Branch L1 caches4(分支L1级高速缓存)	对每个解释器110，有一个带有32个组的高速缓存，每组有4个BRANCH_L1_RECORD(分支L1级记录)。大小＝Num execs(解释器数)*32*4*24字节。最大大小＝16*32*4*24字节＝49152字节。
		OOCT堆栈7	一个1MB的堆栈
Zone memory2(区存储器)	对区存储器使用一个剩余存储器百分比。当前使用50％存储器。
		Segment memory3(段存储器)	对段存储器使用一个剩余存储器百分比。当前使用50％存储器。

分支日志(分支记录器112)

分支日志数据结构是BRANCH_RECORED(分支记录)数组、分支标题表和分支L1级高速缓存。对于分支记录器112如何工作的解释，请看下文中的解释器修改部分。这一部分将描述分支日志怎样用于从解释器110向编译器104传送信息。

图4说明初始化后的OOCT缓冲器。各区域的大小是按比例尺画出的。对于这一实例，OOCT缓冲器的大小是128MB，ASP页面数是2560，解释器110的个数是2，预期分支指令数是220。

编译器104读取分支日志，以发现有多少次条件分支指令被采用，有多少次条件分支指令未被采用。编译器104以两种方式使用这一信息。第一，当编译器104语法分析指令时，编译器104试图只分析那些已被最频繁执行的指令。如果出现了一个条件分支指令，它检验有多少次是分支了，有多少次它未能通过。第二，当编译器104产生代码时，编译器试图把一条件分支指令的最可能的后继指令放在紧跟该分支指令的后面。这使生成的代码运行得更快。为了辩别哪个指令更可能是后继指令，编译器104使用分支日志信息。请参考下文提出的编译器104信息集，以得到更多细节。

BRANCH_Get_Record(ooct/compiler/branch.c)

当编译器104想要读分支日志信息时，它以分支指令地址调用过程BRANCH_Get_Record(得到分支记录)。该过程在分支日志中寻找该分支，并返回指向BRANCH_RECORD(分支记录)数组的元素之一的指针。编译器104于是能看到该分支曾执行过多少次，有多少次它分支了，有多少次它没能通过。翻译表(TRANS UNIT(单元))

翻译表含有关于ASP地址空间中每条指令的信息。该翻译表记录该指令是否是一个分支的目的地(JOIN(联结))，该指令是否被作为一个种子发送到编译器104(BUFFERED(被缓存))以及是否存在该段的编译后代码入口点(ENTRY(入口))。当OOCT被初始化时，该翻译表是空的。当分支指令被记录时，它们的目的地被标记为JOIN(联结)点。如果该分支执行次数多于阈值，则该目的地将被作为种子发送给编译器104并且翻译表入口将被标注为BUFFERED(被缓存)。在编译器104结束了对翻译后版本的编译之后，它把入口点的地址存入该翻译表，并把它们标注为ENTRY(入口)。

图5a、5b和5c说明根据本发明的一个最佳实施例的翻译表结构。如图5a中所示，一个ASP地址被分成两部分。高20位是页面号，低12位是页面偏移。

图5b表明，页面号被用作进入第一级翻译表的索引。ASP作用的页面在第一级表中。ASP未使用的页面没有指针，因为决不会有任何指令带有那个页面号。这些指针指向第二级翻译表。把页面偏移加到该指针上便给出一个翻译表的入口。

如图5c所示，每个入口条目是32位长，它的各字段示于其底部。第一位说明该ASP指令是否是一个联结点。第二位说明对该指令是否有一个段入口点。第三位说明该指令是否曾作为种子发送给编译器104。如果对该指令存在入口点的话，则该翻译表入口条目的其余各位是该入口点地址，如果没有入口点的话则为0。

由于K机器结构有可变长指令，所以翻译表对每个ASP地址有一个入口条目，包括在指令地址及数据地址中部的地址。翻译表的构造示于图5a、5b和5c中。如前所提，第二级翻译表对每个ASP地址有一个32位的入口条目。所以，如果ASP使用10MB空间，则第二级翻译表使用40MB。有若干过程和宏读和写翻译表的入口条目。

TRANS_Set_Entry_Flag(ooct/common/trcommon.h)TRANS_Set_Entry_Flag(翻译设置入口条目标志)宏启动翻译表入口条目的标志JOIN(联结)、ENTRY(入口)或BUFFERED(被缓存)之一。它使用带有锁前缀的汇编语言指令，从而使它自动设置该位。

TRANS_Reset_Entry_Flag(ooct/common/trcommon.h)

TRANS_Reset_Entry_Flag(翻译复位入口条目标志)宏关掉翻译表入口条目的JOIN(联结)、ENTRY(入口)或BUFFERED(被缓存)标志之一。它使用带有锁前缀的汇编语言指令，从而使它自动复位该位。

TRANS_Entry_Flag P(ooct/common/trcommon.h)

TRANS_Entry_Flag P(翻译入口条目标志P)宏读和返回翻译表入口条目的标志JOIN(联结)、ENTRY(入口)或BUFFERED(被缓存)之一的状态。

TRANS_Test_And_Set_Entry_Flag(ooct/common/trcommon.h)

TRANS_Test_And_Set_Entry_Flag(翻译测试和设置入口条目标志)过程自动读标志JOIN(联结)、ENTRY(入口)或BUFFERED(被缓存)之一的状态，如果它尚未被启动则把它启动。它返回调用该过程之前该标志的状态。

TRANS_Set_Entry_Address(ooct/common/trcommon.h)TRANS_Set_Entry_Address(翻译设置入口点地址)过程写入翻译表入口条目的入口点地址。它使用带有锁前缀的汇编语言指令，从而使它自动写此地址。请注意，如果没有段锁，则入口点地址是一目标指令的地址，如果存在段锁，则它是SEGMENT_GATE(段门)数据结构的地址。

TRANS_Get_Entry_Address(ooct/common/trcommon.h)TRANS_Get_Entry_Address(翻译取入口点地址)过程读和返回翻译表入口条目的入口点地址。请注意，如果没有段锁，则一入口点地址是一目标指令的地址，但如果有段锁，则它是一SEGMENT_GATE(段门)数据结构的地址。段

段是可由KOI系统执行的一个编译后代码单元。下文中提供的编译器104材料描述如何创建和删除一个段。这一部分描述编译器104如何告知解释器110关于一段的信息，解释器110如何进入和退出该段，以及编译器如何告知解释器去停止使用一段和切换到另一段。

当一个段被创建时，存在若干个ASP指令地址，在那些地址解释器110能进入此段。对这些地址的每一个，编译器104创建一个到该段的入口点。一个入口点是该段中的一个特殊点，解释器110被允许转跳到那里。在该段的其他点，编译后代码假定某些值在寄存器中，所以转跳到那里是不安全的。为告知解释器110这些入口点在哪里，编译器104为每个第n次TRANS_Get_Entry_Address(翻译取入口点地址)调用TRANS_Set_Entry_Address(翻译设置入口点地址)。

当编译后代码段进入分支记录器112时，解释器110检验这些编译后代码段。它们调用TRANS_Entry_Flag P(翻译入口条目标志P)看当前ASP地址是否有一入口点。如果有，则它们调用TRANS_Get_Entry_Address(翻译取入口点地址)去读该地址。如果段锁被设置，则它们锁住该段(见下文)，然后跳到该入口点。如果段锁未被设置，则它们只是跳到该入口点。编译后代码决定何时它应退出。通常，当它需要执行的一条指令不是这同一段的一部分时发生这种情况，于是它转跳到解释器110。

编译器104能删除一个编译后代码段，并告知解释器110去使用另一段。编译器104这样做的作法是：取消翻译表入口条目的ENTRY(入口)位，改变入口点地址，然后再次设置ENTRY(入口)位。段锁

段锁是OOCT系统的一个可选特性。随着系统运行过程中分支记录器积累更多的信息，编译器104能产生一段的新版本，它优于那老的一个。段锁允许编译器104用新的段替换老的段，并重新声明被老段使用的存储器。可惜的是，段锁使分支记录器112和编译后代码变慢了。所以在执行OOCT代码的时间和它所用空间之间有一个权衡。这一部分描述段锁如何工作。

段锁代码有两部分。第一部分是用于除实现段锁外的OOCT系统所有部分的接口。这一接口保证一段只能处于四个很好定义的状态之一，而且将以很好定义的方式自动改变状态。第二部分是段锁本身的实现，它满足由该接口做出的保证。设计

图3中给出一个段可能处于的状态。一个段可以是可达到的或者是不可达到的，以及它可以是被锁住的或未被锁住的。当在翻译表中有一个或多个入口点时，这些段是可达到的。当在翻译表中没有到该段的入口点时，该段是不可达到的。一个入口点是一个结构，它含有一个锁和一个指令地址。该锁能被不只一个解释器110同时使用，它对有多少解释器110使用该入口点及包含该入口点的段进行计数。当一段的一个或多个入口点被锁住时，该段即被锁住。当它的所有入口点都未被锁住时，它即未被锁住。

如果一段是不可达到的和未被锁住的，则编译器104可以重新声明和删除该段。每个段在编译器104创建它时开始处于U/U状态。当编译器104把它的入口点写入翻译表时它进入到R/U状态。当一解释器110进入和退离该段时，它能进入R/L状态和返回R/U状态。编译器可以创建一个新段，它与老段翻译的指令相同。在这种情况下，它将重写翻译表中老的段入口点，这使老段成为不可达到的。当编译器104重写该段最后一个入口条目时，如果一个解释器110正在使用它的话，它从R/L状态进入U/L状态，或者，如果没有解释器110在使用它，则它从R/U状态进入U/U状态。最终，使用该段的所有解释器110将释放它们的锁，于是该段将处于U/U状态。于是编译器104能重新声明和删除它，因为没有任何解释器110在使用它，而且没有任何一个能进入它。

    表3.一个段能处于的状态

状态	可达到	被锁住	描述
				U/U	否	否	没有任何解释器110在使用它，而且没有任何解释器110能进入它。编译器104能在任何时候删掉它。
R/U	是	否	没有任何解释器110在使用该段，但一个解释器110…
				R/L	是	是	一个或多个解释器110在使用该段，而且其他…
U/L	否	是	一个或多个解释器110在使用该段，但没有任何…

图6显示根据本发明的一具实施例解释器110进入和退离一段122的情况。图中央的段122是由编译器104产生的代码单元。当由解释器110使用该段时，它必须在所有时候都被锁住。因此，在进入段122之前一个锁计数器(未画出)被增量，而在退离段122之后该锁计数器被减量。由于解释器110不能自动地查寻入口点和锁住该入口点，所以必须确定在被锁住后该入口点没有改变。

图7显示编译器104创建一段、使该段可由解释器110达到、使老的段不可达到、以及删掉老段的方法。在步骤S200，编译器104创建一新段并把相关的入口点加入翻译表。当在步骤S200中添加一个入口点时，一个老的入口点可能被重写。这老的入口点现在是不可达到的了，于是可以被重新使用，如果没有任务(如解释器110或编译器104)持有对它的锁的话。该老入口点被放到一个重新声明列表(未画出)上。

步骤S202说明编译器104如何使用重新声明列表。步骤S202检验一个入口点是否被锁住。如果该入口点未被锁住，那么该入口点未被任何解释器110使用，所以能从拥有它的段中移走。然而，如果该段再没有任何入口点，那么该段未被一任务(如解释器110和编译器104)使用，而且没有任务能进入它。所以，该段能被删掉。

段锁接口允许OOCT的大部分能忽略同步的细节，因为一个段总是看起来处于很好定义的状态，而且所有状态过渡看起来都是自动发生的。然而，在段锁代码内部这种转换不是自动的，因为Intel目的地在硬件中不支持这种复杂的操作。所以，段锁代码使这种转换看起来是自动的。实现

执行解释器110和编译器104所用的过程分别示于图6和图7。这两个过程合作以保证每个转换看起来是自动的。在下文描述中的编号参考是指图6和图7而言的。

在段接口的四个状态当中有六种可能的转换，它们归于四组。第一个转换是U/U到R/U，这是当编译器104把段入口点写入翻译表(^*6)从而使该段成为可达到的时候出现的。因为编译器104是允许写翻译表的唯一任务，所以不需要同步化来使这一转换自动化。

第二组转换是R/U到U/U及类似的从R/L到U/L转换。当编译器104把一段的最后的入口点重写入翻译表(^*306)时便发生这些转换。虽然编译器104能自动地把一新入口点写入翻译表，但解释器110不能自动读和锁住一个入口点(^*301，^*302)。解释器110得要在一个操作中读该入口点并在另一操作中锁住它。如果解释器110从翻译表中读一个老入口点，然后编译器104写一个新入口点，然后解释器110锁住这老的入口点，这时会暴露出一个潜在的问题。在这种情况下，编译器104假定入口点是不可达到的，但解释器110能进入该段，这是一个错误。为防止这一问题，解释器110验证翻译表在锁住后包含同一入口点(^*303)。如果翻译表包含这同一入口点，那么它仍是可达到的，而且进入该段是安全的。如果翻译表不包含这同一入口，则解释器110必须释放它的锁并且不进入该段。

第三组转换是R/U到R/L及其逆转换R/L到R/U。这第一种情况发生于一解释器110从翻译表中读出入口点并将其锁住(^*302)之时。第二种情况发生于该解释器110在其退出点离开一段(^*304)和进入解锁过程(^*305)之时，锁住和解锁指令本身不在该段中是重要的，因为任何时候该段被解锁，编译器104都可能删掉它(^*3011)。

第四种转换是从U/L到U/U。它也发生于解释器110退离一段(^*304)和进入解锁过程(^*305)之时。在这一转换发生之后，该段被解锁，而且编译器104将通过两种测试(^*309，^*3010)并删掉该段(^*3011)。

由于解释器110能保持锁住一段达任意长时间，所以让编译器104等待一个锁是低效率的。因此，编译器104不试图以锁住入口点来防止解释器110使用它们。其替代作法是它只是使该段成为不可达到的，其后再检验锁是否已被释放(^*309)。一旦锁被释放，该入口点能成为自由入口点并被重新使用。监视消息队列

解释器110向编译器104发送种子地址。它们使用两个消息队列来发送种子地址。第一个使用KOI系统调用ScMsgSnd和ScMsgRcv来发送和接收种子。第二个队列使用OOCT缓冲器中的一个共享存储区。这共享区叫做branch_seed_Buffer(分支种子缓冲器)。

使用两个队列的理由是每个队列有一个优点和一个缺点。解释器110去使用KOI系统调用是代价昂贵的，所以不应很频繁地使用。然而，KOI系统调用允许在没有种子要编译时使编译器104锁住。这允许KOI系统使用编译器104的CPU去做某些其他工作。共享存储缓冲器的优点在于它对解释器110而言很便宜，而它的缺点在于当没有种子时编译器104不能锁住。

通过使用两个队列，OOCT获得这两种方法的优点。当编译器104空闲时，它调用ScMsgRcv去锁住。在这种情况中，解释器110以ScMsgSnd调用发送下一个种子以唤醒编译器104。当编译器104工作时，解释器110通过branch_seed_Buffer(分支种子缓冲器)区发送种子，它比较快些。在编译器104结束一次编译时，它检验sch_Seed_Buffer(分支种子缓冲器)区。如果存在任何种子的话，那么它编译它们。当它结束以所有种子的编译时，它再次调用ScMsgRcv并锁住。V.解释器修改(执行单元)

OOCT的设计包括对解释器110的三类修改。第一，OOCT需要由解释器110初始化。第二，解释器110已被修改成使用分支记录。最后，解释器110已被修改成允许向编译后代码转换和由编译后代码转换回来。本报告将详细描述这些修改。

OOCT解释器代码能在两种方式下运行，这两种方式是OOCT_ERFORMANCE_MODE(OOCT运行方式)和OOCT_DEBUG_MODE(OOCT调试方式)。本报告描述OOCT_PERFORMANCE_MODE(OOCT运行方式)的所有特性，并指出OOCT_DEBUG_MODE(OOCT调试方式)的不同之处。初始化

在OOCT编译任何代码或记录任何分支之前，解释器110调用OOCT_INIT(OOCT初始化)来初始化OOCT数据结构。OOCT_INIT(OOCT初始化)以及它调用的过程完成下列步骤。

初始化翻译表。MCD指令告知OOCT在系统地址空间中的页面。过程TRANS_Execution_Init(翻译执行初始化)创造第一级翻译表，从而使系统页面的入口条目指向第二级翻译表数组。这些数组在初始化时被充零。请参见通信部分以了解关于翻译表的细节。

初始化分支记录器112。过程BRANCH_Execution_Init(分支执行初始化)为若干数据结构初始化OOCT_buffer(OOCT缓冲器)中的存储器。第一，有一个分支日志本身，它含有关于分支指令的概要信息。第二，有一个第一组(L1)高速缓存，它使分支记录器112操作快些。第三，有一个种子缓冲器，它包含从分支记录器112向编译器104发送的种子。第四，有若干个由编译后代码调用的全局函数。在BRANCH_Execution_Init(分支执行初始化)过程中这些全局函数的地址被存储在OOCT_buffer(OOCT缓冲器)中。关于分支日志和第一级高速缓存的更多信息，请参见上文中关于分支记录器112的部分。

分配编译器104的堆栈存储器。编译器104使用一个被分配到OOCT_buffer(OOCT缓冲器)中的特殊大堆栈。

1.分配编译器104的区存储器。在编译过程中编译器104使用这一存储器，该存储器在OOCT_buffer(OOCT缓冲器)中。

2.分配编译后段存储器。编译后代码被放在OOCT_buffer(OOCT缓冲器)的这一区域中。

3.对统计信息充零。当OOCT被初始化时，在OOCT统计区域中的绝大部分信息被复位。分支记录器与解释器的接口

当解释器110执行系统代码中的一个分支指令而且OOCT方式位已被设置时，解释器110通过下述例行程序之一来调用分支记录器112：

-declspec(naked)OOCT_Log_Uneonditional_Fixed_Branch()(OOCT日志无条件固定分支())
		解释器以一个分支调用
变元：	ecx：分支指令地址
		回送：	不回送(其表现如同转跳到IC_FETCHO2)

-declspec(naked)OOCT_Log_Unconditional_Non_Fixed_Branch()(OOCT日志无条件非固定分支())
		解释器以一个分支调用
变元：	ecx：分支指令地址
		回送：	不回送(其表现如同转跳到IC_FETCHO2)

-declspec(naked)OOCT_Log_Conditional_Fixed_Branch_Taken()(OOCT日志条件固定分支被采取())
		由解释器以一个分支调用
变元：	ecx：分支指令地址
		回送：	不回送(其表现如同转跳到IC_FETCHO2)

-declspec(naked)OOCT_Log_Conditional_Fixed_Branch_Not_Iaken()(OOCT日志条件固定分支未被采用())
		由解释器以一个分支调用
变元：	ecx：分支指令地址
		回送：	不回送(其表现如同转跳到IC_FETCHO2)

这四个例行程序检验编译后代码入口点以找到目的地地址，如果该入口点存在，则转跳到该入口点。如果它不存在，则例行程序调用branch_L1_Touch(分支L1级接触)(见下一部分)以更新分支日志，然后转跳到解释器110的“提取”例行程序。更新分支日志表

图8显示根据本发明一个实施例的BRANCH_RECORD(分支记录)的结构。

分支记录代码对于一个分支已执行了多少次进行计数。有两个数据结构由分支记录器112用于存储这计数。第一，分支日志，它由多处理器系统中所有仿真处理器共享。第二，系统中每个仿真处理器有一个一级(L1)高速缓存。分支执行计数首先被写入高速缓存，然后写入分支日志。这一部分描述L1高速缓存和分支日志的结构。它还描述分支记录器112如何使用它们。

关于每个分支的信息存储在称作BRANCH_RECORD(分支记录)的结构中。它包括该分支地址、该分支目的地、跟随该分支的失败指令、该分支已执行的大约次数、以及该分支已被采取过的大约次数。BRANCH_RECORD(分支记录)的最后一个字段是指向另一个BRANCH_RECORD(分支记录)的指针。它用于在一个链接表中连接各BRANCH_RECORD(分支记录)。

散列表被组织成一个链接列表数组。

图9显示分支日志的结构。它是一个存储各BRANCH_RECORD(分支记录)的大散列表。每个解释器110有其可变local_branchheader_table(本地分支头段表)的自己的付本，但它们都指向OOCT缓存区中的同一数组。local_branch_header_table(本地分支头段表)的元素是指向BRANCH_RECORD(分支记录)列表的指针。查寻一BRANCH_RECORD(分支记录)以找到一个分支的过程有三个步骤。

1.散列目的地地址。(index＝BRANCH_HASH)(destination_address)％BRANCH_TABLE_SIZE.)(索引＝分支散列(目的地地址)％分支表大小)。

2.得到列表头段。(list＝local_branch_header_table[index].)(列表＝本地分支头段表[索引]。)

3.沿着该列表走下去直至你发现一条记录具有这同一分支地址。

(while(list＞branch_address！＝branch_address)list＝list-＞next.)

图9具体说明可变的local_branch_header_table(本地分支头段表)是一个指向各列表的指针数组。每个列表含有具有相同目的地地址的那些BRANCH_RECORD(分支记录)。当没有列表时，在local_branch_header_table(本地分支头段表)中的那个指针是NULL(空)。

分支日志含有关于分支的全部信息，但它有两个问题。第一，查寻和插入BRANCH_RECORD(分支记录)是慢操作。它们太慢了，以致不能在每次解释器110记录一个分支时都进行这两种操作。第二，每个解释器110使用这同一个分支日志。为了保持BRANCH_RECORD(分支记录)列表的一致性，在一个时刻只有一个Exec(解释器)能访问该分支日志，这使多处理器系统减慢，甚至比单处理器系统减慢得还厉害。为了修复这些问题，对每个解释器110有一个L1级高速缓存。L1级高速缓存能被快速访问，而且解释器110能并行访问它们的L1级高速缓存。每个L1级高速缓存是一个BRANCH_L1_RECORD(分支L1记录)结构的二维数组。该数组的基地址存于变量branch_L1_table(分支L1表)中。

图10显示L1级高速缓存的结构。该高速缓存是BRANCH_L1_RECORD(分支L1记录)的二维数组。第一维是BRANCH_L1_SETS(分支L1集合)(当前为32)，第二维是BRANCH_L1_SETSIZE(分支L1集合大小)(当前为4)。数组的每行是一个集合。同一分支指令总是使用高速缓存的同一集合，但它能位于不同的位置。

如图10中所示，L1高速缓存被组织成集合。对于一个分支，其集合号等于(branch_address+branch_destination)％BRANCH_L1_SETS。该集合的4个成员保持具有同一集合号的4个最新近的分支。这被称作4路集合结合性(associativity)。当几乎在同一时刻执行具有相同集合号的若干分支时，这种4路集合结合性改善了高速缓存的性能。

图11说明根据本发明的一个实施例由解释器110执行L1级高速缓存操作的一种方法。换句话说，图11说明使用L1级高速缓存的分支记录方法。

优化目标码翻译方法利用两种存储器形式来记录未编译的分支，即

1.一个分支日志，其动态变化的大小与被记录的分支数成比例，以及

2.一个分支高速缓存，名为L1级高速缓存，其中有限个数未被编译的被记录分支按增强访问的顺序存储。

分支日志和L1级高速缓存代表由操作系统管理的虚拟存储器位置。这样，术语“L1级高速缓存”是任意给予存储未编译分支的高速缓存的，不应与通常在处理器(例如Pentium Pro(奔腾处理器))上发现的L1级高速缓存混淆。

根据本发明的优化目标码翻译器提供的解释器110可以调用多个不同的分支记录例行程序。然而，每个分支记录例行程序本身调用一个子例程，它决定是转跳到编译后代码还是记录一个分支指令。这一子例程具体显示在图11中。

鉴于上述，为执行具有L1级高速缓存的分支记录方法，该方法首先从步骤S400开始。在步骤S401中，解释器110首先检验该分支目的地的编译后代码入口点(即所针对的段先前是否被编译过)。如果有一个入口点，即“是”，则存在一个编译后的段，于是流程跳到S402以立即执行编译后代码段。然后执行编译后代码段直至达到结束标志，于是流程返回以执行下一段。当然，该段未被记录在分支日志中，因为该分支被编译过了。

如果在步骤S401中没有入口点，即“否”，于是没有对应于分支指令的编译后代码。于是流程转向步骤S404，解释器110观察L1级高速级存以确定该分支与存储在L1级高速缓存中的多个分支之间是否有可能的匹配。

步骤S404确定该分支与存储在L1级高速缓存中的多个分支之间是否存在一个匹配。L1级高速缓存被分成多个集合，每个集合由一个唯一的集合号表示。根据本发明的一个实施例，每个集合含有4个分支。

步骤S404首先确定一个高速缓存集合号“S”，它对应于当前的分支地址，其S＝(branch_address+branch_destination)％BRANCH_L1_SETS。接下来，针对当前分支地址和目的地，顺序检验branch_L1_table[S]的每个元素。如果检测到一个匹配，即“是”，则流程进入步骤S406，字段“encountered_sub_count”(一个字段，它指出该分支已被遇到过多少次)和“taken_sub_count”(一个字段，它指出该分支被采取过多少次)被更新。然后流程进入S407。

在步骤S407，确定当前分支地址已被遇到的次数是否大于一个预先确定的阈值数。最佳阈值是在1000次的数量级。这样，在步骤S407中，字段encountered_sub_count与该阈值比较。如果该阈值被超过，即“是”，则流程进入步骤S410，于是对这一分支高速缓存的信息被写回分支日志。另一方面，如果该阈值未被超过，即“否”，则流程进入步骤S412。步骤S412是当前子例程的一个终点，它跳到IC_FETCHO2，即解释器110的入口点。

如果当前分支不在高速缓存中，即在步骤S404中为“否”，于是流程进入步骤S408，于是在前面由“S”指定的集合中的一个BRANCH_L1_RECORD记录(即含有所有可能被更新字段，如encountered_sub_count和taken_sub_count，的记录)被从L1高速缓存中删除并写到分支日志中。接下来，当前分支信息被写入由“S”指定的集合中。再有，在把当前分支记录写入集合“S”的过程中，当前分支记录作为该集合的第一元素放置。这是因为这同一分支很可能被再次执行，从而提高了系统的性能和效率。换句话说，步骤S404将被执行得更快些。即使当该分支在高速缓存中，即“是”，如果自它最后一次被泄出后已被执行过多次，那么它可以被拷贝到分支日志中。

当使用L1级高速缓存时，步骤序列几乎总是S400，S404，S406，S407和S412。因此，本发明试图使那些步骤尽可能快。当把当前分支信息放在该集合的第一元素中时，该分支信息使步骤S404变快，因为解释器110可能再次执行这同一分支。

上面提出的分支记录方法通过执行先前已被编译的代码和增强对尚未达到编译阈值水平但经常被调用的分支指令的访问能力，从而减轻了处理器的负担。在这方面，OOCT的主要目的是使步骤S400几乎每次都取“是”分支。如果一个分支被频繁地执行，那么对于它的目的地应有编译后的代码段。

第二个目标是使跟随步骤S401的“否”路径更快些，从而使当未被编译的分支将不会显著地减慢程序的执行。“否”路径的最慢部分被称作“泻出(flush)”。在步骤S408和S410中，分支信息被从L1级高速缓存中“泻出”并写入分支日志。为了把一种子发送到编译器，把分支信息泻出变为必要，这将使得产生编译后代码并使步骤S400在未来对这一分支回答“是”。

然而，并不是每次执行一个未被编译分支地址时都必须泻出分支信息。对于每100次执行或少于100次执行进行一次泻出往往是可行的。所以，本发明试图提高不包括泻出的步骤S400、S404、S406、S407及S412的速度。这样，总是取较快的路径，除非发生两件事之一。在步骤S404，有可能在该集合中未发现分支信息，于是我们取到S408的“否”路径。在步骤S407，如果分支被执行次数超过“阈值”次数，它将取“是”路径到S410，S410也包括一个泻出。

在OOCT_DEBUG_MODE(OOCT调试方式)中，仍然使用L1级高速缓存方法，但泻出该高速缓存的阈值设为l，于是每次分支执行时其信息被写入分支日志。种子选择

当一个分支指令被很频繁地执行时，分支记录器112把它的目的地地址发送给编译器104。这一地址被称作“种子”，而且选择种子是OOCT系统的很重要部分。

种子应是在一过程开头或一循环头处的地址。所以，分支记录器112只发送作为无条件分支目的地的那些种子。种子应是频繁被执行的地址，所以只有当一个分支的encountered_count(遇到次数)字段大于一阈值时该分支目的地才成为一个种子。该阈值存于OOCT缓冲器中名为“seed_production_threshold(种子产生阈值)的字段中。该阈值能随时改变，在下一部分中将描述它。阈值设置

关于使用固定的阈值来确定是否发送一个种子，有两件不好的事情。第一，当编译器104空闲时，该阈值可能太高。在这种情况中，对于编译器104而言，有有用的工作去做，但分支记录器112没有告知编译器104去做什么。第二，当消息队列满时，该阈值可能太低。在这种情况中，分支记录器112将试图把一种子发送出去，即使该种子将不会添入队列中，这是浪费时间。

幸好，有可能检测这两种情况，即何时编译器104空闲及何时消息队列满，并改变该阈值。分支记录器112在过程branch_Update_Entry(分支更新入口)中通过读名为num_monitor_seed_messages的OOCT缓存区字段。以检测编译器104是否空闲。如果该字段为0，则表明编译器104已经结束了被发送来的全部种子。该阈值太高，于是分支记录器112降低它。当分支记录器112试图发送一个种子而得到一个出错代码指出该消息未被发出时，它在过程branch_Send_Seed(分支发送种子)检测到一个满的消息队列。该阈值太低，于是分支记录器112提高它。

在OOCT_DEBUG_MODE(OOCT调试方式)，该阈值从不改变。在这种情况中它的值被设置到过程OOCT_INIT(OOCT初始化)的第三变元中。处理多任务

OOCT在具有多个解释器110的多任务系统中运行。这些任务有各自的分支L1级高速缓存，但它们使用同一个分支日志表。当分支信息从L1级高速缓存泻出到分支日志表时，解释器110获得一个关于该表的记录，从而使它不与任何其他解释器(Exec)冲突。有两种方式处置对分支日志锁的关注。第一个是使解释器110等待直至该锁可以得到，然后得到该锁并写它的分支信息。这使解释器110运行得更慢，但使分支日志更准确。第二个是如果解释器110不能得到锁，则放弃，不去写分支信息。这种方式使解释器110更快些，但失掉了某些分支记录信息。OOCT使用第二种方式，因为解释器110的速度比分支日志的准确性更重要。为了使系统功能发挥得好，分支日志信息只需近似正确。

当OOCT以多个解释器110运行时，任务之一是特殊主控任务，它调用OOCT_INIT去初始化OOCT缓冲器和分支记录数据结构。其他任务是从属任务，它们只需初始化某些局部变量和它们的L1级高速缓存。在主控任务已结束初始化OOCT_buffer(OOCT缓冲器)之后，从属任务调用Slave_OOCT_Init(从属OOCT初始化)。主控任务和从属任务之间的同步使用下述方法。主控任务方法

1.执行MCD指令启动OOCT。

2.调用OOCT_INIT，它初始化OOCT缓冲器和分支记录数据结构。

3.唤醒从属任务。

4.转跳到解释器。从属任务方法

1.进入睡眠状态。当主控任务执行时(上述步骤3)醒来。

2.调用Slave_OOCT_Init，它初始化该任务的单独分支L1级高速缓存。

3.转跳到解释器。用户/系统空间转换

OOCT系统只编译来自ASP地址空间系统页面的指令。它忽略用户页面。解释器110单独区的OOCTSTS位控制分支记录器112是否被调用。这一位主要由两个宏NEXT_TO和NEXT_OUN来控制。然而，有一种情况，其中OOCT不得不设置这一位。当编译后代码段以非固定分支指令结束时，它可能使PSW-IA从系统空间移动到用户空间，这需要把OOCTSTS置于0。于是，一个以非固定分支结束的编译后代码段跳到例行程序branch_Exit_Log(分支退出记录)它检验目的地地址和正确设置OOCTSTS位。编译后代码接口向/从编译后代码转换

当解释器110调用一个分支记录例行程序并为该分支目的地找到一个编译后代码段时，解释器110把执行传送给编译后代码(见图11)。当段锁被断掉时，解释器110直接跳到该入口点。当段锁被启动时，解释器必须在跳到入口点之前试图锁住该段。如果它锁住该段，则它跳到该入口点。如果它未能锁住该段，则它跳回解释器110。

有几种方式使执行退离编译后代码段，它们在表4中描述。在所有情况中，当控制跳回解释器110时，ESI和EDI寄存器有正确值，而解释器110的单独区有完好的K状态。

                   表4.如何控制退离一编译后代码段

最终K操作码	编译后代码所做之事
		固定分支或直线K	测试目的地地址是否有编译后入口点。如果有，则它做一次段间转跳

操作码	到达该入口点。如果没有，则在IC_FETCHO2处将控制传送回解释器110，或当段锁被启动时传递到branch_Exit(分支出口)。
		非固定分支	跳到branch_Exit_Log(分支出口记录)，它设置OOCTSTS位，然后调用分支记录器112，如果PSW_IA仍处在系统页的话。
LPSW，SSM，STNSM，MCD，CALL，RRTN，SVC，MC，BPC，LINK，LINKD，LOAD，LOADD，DELT，DELTD，FBFCC	没有段锁：跳到IC_FETCHO2以执行该操作码。有段锁：跳到branch Exit_Interpret(分支出口解释)。
		SAM操作码，它切换到RISC方式	没有段锁：跳到IC_FETCHO2以执行SAM操作码有段锁：跳到branch_Exit_Interpret

当段锁被启动时，解释器110将在执行那个代码时保持对该编译后代码段的锁住。在它退离该段后它必须释放这锁，于是编译后代码调用分支记录器112中的某些过程，这些过程释放该锁，然后跳到解释器110。中断

在编译后代码执行过程中能发生若干中断，如IO中断或MCHK中断。编译后代码检验其单独区的INTINF字段以检测是否已发生了中断。它检测在任何可能的无限循环内部的这一字段，这保证它不会永远忽略该中断。如果一个中断确已发生，则编译后代码调用解释器110的带有完好K状态的例行程序IU_OINTCHK。它预期解释器110将返回编译后代码。解释器回调

某些K操作码不被OOCT翻译。代之以编译后代码调用解释器110子例行程序IC_OOCT去解释该操作码然后返回编译后代码。编译后代码确保在调用IC_OOCT之前ESI和EDI寄存器有正确值而且单独区有完好的K状态。

如果解释器110在执行IC_OOCT子例行程序过程中检测到错误，它调用OOCT_EXCP而且不返回到编译后代码。如果段锁被启动，则OOCT_EXCP释放段锁。例外

当编译后操作码有一无屏蔽例外时，如一操作例外或零除数例外，则编译后代码调用一解释器子例行程序IC_PGMxx，这里xx是01h和21h之间的出错代码号。解释器110试图处置这一例外并返回。当解释器110不能返回时，它调用OOCT_EXCP，它释放任何段锁。使用全局函数

某些K操作码，如字符处理操作，翻译成大量的目标操作码。对这些操作码作多重翻译将会占用太多的段存储器…，称作全局函数的子例行程序由编译后代码调用以执行这些操作码。这些全局函数恰如同执行K操作码的解释器110例行程序，只是它们被专门设计成由编译后代码调用和返回编译后代码。有用于5个操作码即SBE、CC、MV、TS和C的全局函数。实验表明，全局函数比调用解释器110的IC_OOCT入口点快得多，而且它们使用的存储器比多次把操作码编译成目标指令所使用的存储器小得多。VI.编译器概述

在钻研编译的细节之前，重要的是在高一级理解编译器104的主要目的和理解编译器104的结构。编译器104的目的是把当前执行程序中多次执行的部分翻译成优化目标码并使解释器110能得到这些代码去执行。

图12具体说明编译器104的总体结构。编译器104接收来自分支记录器112(前面讨论过)的种子，它们启动编译过程。种子是一个原始指令的地址，它已是当前执行程序中大量分支的目标。这是要给出一个起始点，以找出当前执行程序中的频繁执行部分。块检出器114利用这个种子以及由分支记录器112提供的其他信息去检出程序中应被编译的部分。

一旦已选出了要被编译的原始代码，则要经过三个主要阶段。第一阶段是把K操作码转换成被编译器104的其余部分使用的中间语言(IL)。中间语言是由IL发生器124产生的。第二阶段是由前以描述并称作优化器126的优化方法完成对IL的各种分析和优化变换。最后阶段是把IC转换成可重新分配地址的机器代码，这一阶段被命名为优化代码产生单元118。

编译器104的最后一项工作是使优化的代码能被解释器110使用。于是，借助段安装单元以优化代码付本创建一个段数据结构。然后该段被安装在OOCT缓冲器(未画出)内的一个共享区中。最后，翻译表被更新，从而使解释器110到编译后K代码的任何分支将使用新的目标代码代替。

这一部分的其余内容将详细讨论上述编译器104各个阶段。在这部分的末尾还将讨论许多其他实施细节。块检出

编译器104接收一单个种子地址以开始编译。在种子处开始，它读取原始指令，其至已经读到如过程体之类的东西。然后，它把这一组原始指令传送到编译器104的下一阶段，即产生IL阶段。由编译器104读出的指令单元被称作基本块，所以这一阶段被称作块检出器，即块检出器114。

一个基本块是一个指令序列，在那里控制只能在第一条指令处进入，而且只能在最后一条指令处退出。这意味着只有第一条指令能是一个分支的目标，而且只有这最后一条指令能是分支指令。这还意味着如果该块的第一条指令被执行，那么所有指令将被执行。块检出器

图13显示根据本发明一实施例的块检出器114的一个实例。过程OOCT_ParseFrom实现块检出器114。它一次读一个基本块。由于5个理由之一而结束一个基本块。

1.如果分析器读到一个分支指令，则该块以此分支结束。

2.如果下一条指令曾已经分析过，则该块以当前指令结束，因为每个K操作码在一段中只应出现一次。

3.如果下一条指令是一结合点，则该块以当前指令结束，因为结合点得要在一基本块的开始。

4.如果当前指令是一个因子“on(启动)”，而且它能后跟数据而不是指令，则该块以当前指令结束。

5.如果当前指令是一个非法指令，则该块以当前指令结束。

在读每块之后，块检出器114决定下一步采取什么行动，这要根据该块的结束方式。可能的行动列于表5。

表5：读一块后的行动

当前块的结尾	块检出器114的行动
		条件分支	在归于结束的指令和分支目的地指令处继续分析。
无条件固定分支	在分支目的地指令处继续分析。
		非固定分支	停止分析，因为分支目的地未知。
结束指令或非法指令因子	停止分析，因为下一字节可能不是一条指令。
		其他指令	在归于结束的指令处继续分析。

一个举例示于图13。块检出器114在种子指令处开始，它是一条LB指令。由于它不是一个分支或结束指令因子，所以它继续下一条指令。那是一条TH指令，它是一个条件分支。由于该条件指令，块检出器114停止读当前块。它在LH和LF指令处继续读新块。当它读SVC指令时，块检出器114结束那块，因为SVC是结束指令的一个因子。当它读GO指令时，块检出器114结束那块，因为GO是一个分支指令。在L8指令处它继续读，因为L8指令是一个分支目的地。在读ST8指令之后，块检出器114结束该块，因为它已经读过下一条指令。

对于块检出器114将读的指令数有一个上限。这一限制的目的是防止编译器104在编译源指令过程中运行超出存储器。这一限制由OOCT_trace.c(OOCT跟踪)中的常数MAX_KINST_NUM(最大K指令数)设置，当前值为500。

当块检出器114试图读一指令时，它能引起页面错。如果块检出器114得到一个页面错，它停止读当前块，但它从尚未试过的任何分支目的地开始继续读。这允许编译器104创建一个段，即使它不能分析一个种子能达到的全部指令。块布局

在选择基本块之后，块检出器调用过程OOCT_GenerateIL(OOCT产生IL)以创建IL指令，编译器104的其余部分将使用它们。在此时，有可能重新安排块的顺序。这叫做块布局，这有助于编译器104为PentiumPro(奔腾处理器)处理器产生更好的代码，因为如果不采取向前的条件分支的话，Pentium Pro(奔腾处理器)会运行得更快。

考虑图13中的例子。它有一个条件分支，即TH指令。在原始指令中，归于结束的基本块是以LH开始的一个块，而目的地块是以LF开始的一个块。如果在75％的时间里该条件分支被采取，那么如果LF基本块放在归于结束的位置而LH基本块放在采取分支的位置，则运行得要较快。

OOCT_GenerateIL过程根据分支日志中的信息对各块进行布局。只要可能，它便把条件分支的最通用后继者放在归于结束的位置。这一过程产生一个IL指令列表，它们被传送到编译器104的优化阶段。中间语言(IL)的产生

这一部分将讨论产生代表K操作码的编译器104中间语言(IL)的过程。在直接讨论如何产生IL之前，先给出IL概述并描述对理解有重要性的数据结构。IL概述

编译器104的主要分析和翻译过程(pass)是在一种中间语言上操作的，这种中间语言是一种不依赖机器的指令集。由于两个主要理由，使用中间语言是一种标准的编译器104技术。第一，IL通常有一种结构体系，它简化了分析和变换。第二，IL允许许多不同的源语言使用相同的优化和代码产生阶段并易于重新指向不同的平台。

由OOCT使用的IL(从这里起只称作IL)当前由表6所列40个不同的操作码组成。这些指令归于三类。第一，如ADD和LOAD等功能性操作码，它们有到标准机器操作码的直接映射。第三，如LABEL和CGOTO等管理控制流程的操作码。最后，有多个特殊操作码，它们被编译器104用作为特殊的标记，它们不直接对应于由后端产生的代码。这些特殊的标记操作码在另一部分中描述。由于IL代表一个虚似机器，所以如果需要更多的功能，则只要对IL增加其他操作码。

IL由指令组成，每条指令指定一个操作码，一个类型，和若干个伪寄存器变元。由编译器104支持的类型是有符号和无符号8位、16位及32位值。除了由SET操作码使用的立即值和由LOAD操作码从存储器加载的值外，所有变元都由伪寄存器传递。伪寄存器就是IL虚拟机器寄存器。编译器104允许任意个数伪寄存器，其中每个有一预先定义的大小(例如16位)。每个伪寄存器直接对应于一个具体的存储器位置。对于OOCT，这些存储器位置是在单独区的OOCT特定部分之中。伪寄存器到存储器位置的这种映射给出两个好处。第一，它使IL成一流线，不需要把公用值加载到临时位置和把它们存回存储器的IL操作。第二，编译器104往往能把公用值分配到机器寄存器，从而消除了多余的加载和存储。

表6：IL操作码

操作码	描    述
		LABEL	在流程图中标记一个位置，它能成为转跳操作的目标
GOTO	到一标号的转跳
		CGOTO	根据一伪寄存器的布尔值，到一标号的条件转跳
IGOTO	间接转跳到由一伪寄存器之值确定的地址
		SET	把一立即值放入一伪寄存器
ASSIGN	把一伪寄存器中之值移到另一伪寄存器中
		OASSIGN	一个特殊的标记指令，它显示若干伪寄存器重叠的地方，以使混淆现象显现出来
CVT	把一伪寄存器从一种类型转换到另一种类型(例如符号扩展，零扩展)
		NEG，CMPL，BSWAP	一元非，逻辑补，字节交换
ADD，SUB，MUL，DIV，REM	二进制加、减、乘、除、求余
		ASL，ASR	算术左移、右移
LSR	逻辑右移
		BAND，BOR，BXOR	二进制逻辑与、或、异或
EQ，NE，LT，LE，GT，GE	比较两个输入操作数，如果op1＝＝op2，po1！＝op2，op1＜op2，op1＜＝op2，op1＞op2，op1＞＝op2，则设输出操作数为真
		TESTZ，	比较两个输入操作数，如果(op1&op2)＝＝0，

TESTNZ	(op1&op2)！＝0，则设输出操作数为真
		CMP	比较两个输入操作数，如果op1＜op2，则设输出操作数为-1，如果op1＝＝op2，则设输出操作数为0，如果op1＞op2，则设输出操作数为1。这一操作码当前未被OOCT使用
LOAD	以指定来自一存储器位置之值加栽一伪寄存器
		STORE	把一伪寄存器之值存储到一个指定的存储器位置
GCALL	对一组预先确定的全局函数之一进行函数调用
		ICALL	进行间接函数调用，类似于IGOTO
EXIT	退出编译后的块。当前OOCT未使用
		ENTRY	标记一个点，控制能在该点进入流程图
SYNC	标记一些点，在这些点一组伪寄存器被泻入存储器
		EXTMOD	把一个伪寄存器标记为外部修改的。这用于处置由函数调用对伪寄存器的修改
SETCC	根据一个操作对一个条件代码值设定一个布尔值。这用于代表使用标志的地方。当前，所有SETCC操作都被叠到后继者之中，从而使这些操作不被传播，但SETCC的使用使得条件代码值流显现出来，不需要编译器104去为单个IL操作代表多个目的地。

特殊IL操作码

OOCT IL包含少量具有特殊目的的操作码。大多数IL操作码对应于由后端产生的代码。不同的是，这些特殊指令的作用是向编译器104发出的信号，说明有某种特殊事情正在发生。IL含有如下特殊操作码：ENTRY，SYNC，EXTMOD以及OASSIGN。这部分讨论这些操作码中的头三个。OASSIGN已在前文中充分说明了。

ENTRY操作码标记出在那里控制能进入流程图的一点。由OOCT产生的代码可以有多个外部入口点，它们代表外部联结点。每个外部入口有一个相应的ENTRY IL指令。ENTRY指令发生在代码结尾，而且立即跟随一个GOTO指令，它跳到代码主体内的一个标号处。使用一个入口代替外部入口直接跳到该标号的理由是允许代码发生器在ENTRY和转跳到该标号之间插入内容。

图14是具有两个外部入口点的代码轮廓，这里在ENTRY指令和GOTO指令之间插入了填充指令。换句话说，图14具体说明了根据本发明一个实施例的一个入口举例。

SYNC操作码用于保证一组伪寄存器被泻入存储器。具体地说，OOCT使用SYNC操作码来保证所有K寄存器处于解释器110预期找到它们的那些存储器位置。SYNC的作用如同对寄存器分配器的一个指示，指出一个处于已被修改的机器寄存器中的伪寄存器被泻掉。SYNC的作用还在于使用任何活的数据，它使编译器104免于以死的代码删除只具有修改K寄存器作用的代码。

EXTMOD操作码用于指出伪寄存器被修改，但编译器104没有关于该寄存器已被如何修改的细节。这样，EXTMOD有两个作用。第一，它对优化过程，如常数合并或副本传播，起到阻挡层的作用。第二，它迫使编译器104的寄存器分配器在下次死用伪寄存器之前插入一个填充。在OOCT中，EXTMOD指令用于回调解释器104之后，以指出哪些K寄存器可能已被修改。IL数据结构

在讨论如何从K操作码构建IL之前，熟悉一下编译器104中所用主要数据结构是有用处的。

ZONE(compiler/zone.[h，c])

在编译器104中的存储器分配是由一个叫做ZONE(分区)的抽象(abstraction)来处理的。ZONE抽象是分配存储器的一种有效方式，以致它能立即释放全部所分配的存储器。使用ZONE抽象，分配是快速的，而且程序员不必担心存储器泄漏，因为对ZONE的破坏将会重新声明所用的全部存储器。

在编译器104中，一个ZONE创建了，于是分配存储器的所有调用(即通常会是malloc(存储器分配)调用)调用带有初始创建的ZONE的ZONE_Alloc(区分配)。当编译器104完成时，它调用ZONE_Destroy(区破坏)它把整个ZONE免去分配(即等效于释放全部存储器)。

ZONE的底层实现使用大块存储器。例如，当创建ZONE时，它可能‘malloc’(存储器分配)大小为0×2000字节的一块存储器。在这一大块存储器用完之前，对ZONE_Alloc的调用将使用这个‘大块’存储器。当初始-0×2000字节中没有空间服务于ZONE_Alloc请求时，便创建一个新的‘大块’存储器。再有ZONE_Alloc调用时，将使用这个‘大块’，直到它也被用完为止。

在编译器104中，由于存储器全都是预先分配的，所以情况稍有些复杂，这样便不能使用malloc。代替作法是使用了一个特殊的ZONE分配器单元(ZALLOC单元)。这ZONE分配器以一个大的存储器空间(例如0×10000字节)来初始化。它把存储器分成同样大小的大块，ZONE将使用这些大块进行分配，它还保持一个空余大块列表。这样，‘malloc’请求由对ZALLOC_get_chunk的调用替代，它给回一个空余的‘大块’存储器。类似地，在ZONE_Destroy中对‘free(释放)’的调用由对ZALLOC_free_chunk的调用替代。在当前的实现中，能由ZONE_Alloc处置的最大分配区是初始大块的大小。把ZALLOC改变成处置可变大小的分配以代替简单地处置一个大小，则会‘修补’这种限制(这类分配器的一例可参见段分配单元)。这里没有这样做的理由有两个。第一，可变大小的分配器复杂得多，而且会引起破碎等问题。第二，这大块的大小可做得很大而几乎不付出什么代价。当大块的大小足够大时，如果编译器104已经运行超出存储器，那它也将只是请求了一次大于这大块大小的分配而已。这样，要产生ZALLOC单元去处理可变大小的分配并没有真正的好处。

IL_CTXT(compiler/oc_common/include/il_internal.h)

编译器104维持一个单一数据结构IL_CTXT来跟踪编译的当前状态。IL_CTXT数据结构存储一指针指向一个被链接的IL_NODE列表，这些IL_NODE代表当前被编译的代码。IL_CTXT还存储许多其他字段，它们用于整个编译过程，如所使用的ZONE和IL_FRAM。编译器104的每个阶段有IL_CTXT作为变元并且对这个数据结构进行修改，例如许多阶段要添加或删除某些IL_NODE。

IL_NODE(compiler/oc_common/include/il_internal.h)

IL_NODE数据结构代表编译器104中间语言中单一的一个作为从K操作码翻译过来的抽象指令。

那些IL_NODE从K操作码翻译而来，被保持在一个双链接列表中。指向该列表中第一和最后元素的指针保持在IL_CTXT中。这个列表代表当前被编译器104作用的代码。编译器104的每次扫描都要遍历这一列表，或者产生关于该列表中代码的信息，或者变换这一列表。

每个IL_NODE含有一个操作字段‘op’，它指出该指令的基本性质。它还含有一个操作数字段矢量，代表该指令的各操作数。对操作数字段的解释取决于该指令的操作类型。除了操作和操作数外，所有IL_NODE含有许多字段由所有节点(node)类型共享，例如该指令的Kpc，该指令就是从它翻译过来的，还有为该代码产生的目标机器码的首地址等。

根据操作类型，在一个节点中的操作数字段个数是不同的。事实上，在某些情况下，同一类的两个节点可能有不同数量的操作数；例如，一个调用操作的操作数个数将取决于传送给目标方法的变元个数。操作数个数的这种变化表明IL_NODE的大小不是一致的，而且操作数矢量是IL_NODE结构中的最后一项。操作数矢量被声明为一个入口条目长，各IL_NODE的地址分配是通过计算/分配为公共字段和操作数字段所必须的存储总量和通过把所分配的存储器加到一个IL_NODE指针来实现的。在大多数情况中，但不是在所有情况中，每个操作数实际上需要操作数矢量中两个相继的入口条目。在伪寄存器中将找到操作数，该伪寄存器的入口条目是operand[i]。如果该操作数是一目的地操作数，操作数[i+1]将指向一个节点列表，该列表使用由这一操作定义的值；如果该操作数是一个源操作数，则操作数[i+1]将指向含有该值定义的一个节点列表。

如果一个操作有一目的地操作数，该操作数将总是存储在operand[0]和operand[1]中。

如果operand[i]是一个源(输入或使用)操作数，则operand[i+2]也将是一个源操作数；就是说，所有的源寄存器必须在操作数列表的末尾。

在一个节点中的操作数字段从来不会被直接访问。相反，是由一大组形为ILOP_xxx(N)的宏进行访问的，这里N是指向一个IL_NODE的指针。这些宏知道对于所有各种指令类型各种操作数在操作数矢量中是如何存储的。

一些节点类型如下(该列表没有包括全部)：

一元操作

这些代表各种简单的一元(1个源操作数)指令，包括赋值。

type(类型)

    操作的类型

ILOP_DEST(N)

    目的地寄存器；结果进到这里

ILOP_DEST_use(N)

    使用该目的地寄存器的指令列表

ILOP_SRC(N)

    源寄存器

ILOP_SRC_def(N)

    定义该源的指令列表

二元操作

    这一类代表大量的二元(2个源操作数)指令。

type(类型)

    该操作的类型

ILOP_DEST(N)

    目的地寄存器；结果进到这里

ILOP_DEST_use(N)

    使用该目的地寄存器的指令列表

ILOP_SRC1(N)

    第一源寄存器

ILOP_SRC1_def(N)

    定义该第一源的指令列表

ILOP_SRC2(N)

    第二源寄存器

ILOP_SRC2_def(N)

    定义该第二源的指令列表

ILOP_DIVEX(N)

    这一操作数只出现于DIV和REM操作，并指向一个(单独)列表，该列表含有的节点代表“被零除例外”的起始，如果存在这个例外的话。LABEL

一个LABEL(标号)指令代表节点中的能由分支转到的一点。它包含如下操作数：

ILOP_LABEL(N)

    标识该标号的唯一整数

ILOP_LABEL_refs(N)

    指向这一标号的指令的列表

ILOP_LABEL_live(N)

    显示出哪些寄存器在这一标号处有效的一个BITSET(位组)

ILOP_LABEL_rd(N)

    达到这一标号的每个寄存器的定义列表矢量

ILOP_LABEL_ misc(N)

    任何扫描过程暂放关于该标号的私用信息的地方GOTO一个GOTO指令代表到一个标号的无条件分支。

ILOP_LABEL(N)

标识目标标号的唯一整数

ILOP_LABEL_refs(N)

目标LABEL(标号)指令的单独列表CGOTO

一个CGOTO指令代表到一个标号的条件分支。它含有与GOTO指令相同的操作数以及某些附加操作数。

ILOP_COND(N)

    含有分支条件的寄存器。这个寄存器必须含有一个布尔(B1)型值。如果这条件为TRUE(真)，则该分支将被采取。

ILOP_COND_def(N)

    定义这个寄存器的指令的列表

ILOP_COND_live(N)

    显示如果该分支未被采取的话哪些寄存器有效的BITSET(位组)。

除了指定指令的ILOP宏以外，还有许多能在任何指令上使用的类属宏。

ILOP_HasDEST

    如果该指令有一目的地寄存器，则返回TRUE(真)。在这种情况中，对这一指令可以使用ILOP_DEST和ILOP_DEST_use两个宏。

IL_OP_START，IL_OP_DONE，IL_OP_NEXT

    用于通过一指令各源寄存器的重复。

IL_OP_START返回一个IL_OP_INDEX指出第一个这种源寄存

器。IL_OP_DONE测试一个IL_OP_INDEX看它是否指向了一

个源寄存器；如果它沿有，则返回TRUE(真)。IL_OP_NEXT

用于继续到下一个源寄存器。

IL_ OP，IL_OP_def

    这些对一给定IL_OP_INDEX返回具体的源寄存器及其定义

列表。这五个宏一般用于如下形式的循环中：for(op＝IL_OP_

START(n)；

！IL_OP_DONE(n，op)；op＝IL_OP_NEXT(n，op))

{use IL_OP(n，IL_FRAME(compiler/oc_common/include/il_

frame.h，compiler/OOCT_Frame.c)

IL_FRAME数据结构用于给出关于编译后代码将在其中运行的上下文。该框架定义每个伪寄存器的大小和存储器位置，这些伪寄存器与其他伪寄存器怎样重叠，以及在该分配器中使用哪些机器寄存器是合法的。此外，IL_FRAME结构规定对于正被编译的代码是否需要一个C堆栈框架。在OOCT中不使用C堆栈框架。

在编译器104中，IL_FRAME结构由OOCT_Frame.c中的函数初始化。这些函数建立对应于K寄存器和PSW位置的每个伪寄存器。此外，还设置编译器104的临时伪寄存器，它们对应于解释器110的工作空间区。还建立了关于K寄存器如何重叠的信息。

NL_LIST(compiler/oc_common/[include，src]/nl_nodelist.h)

在许多地方编译器104使用IL_NODE列表，NL_LIST数据结构提供了管理这些节点列表的一个抽象。例如，前文提出的UseDef分析创建使用给定定义的IL_NODE列表以及可能是为给定用途下定义的IL_NODE列表。NL_LIST抽象是直接的，它提供了创建、添加、删除、替换、查寻和重复节点列表的能力。K操作码到IL的翻译

在前文提出的块检出器114已选择了要编译的那些K操作码之后，从K操作码到IL的翻译涉及3个主要步骤。第一步是确定为基本块产生的代码的顺序。块布局方法已在前文中提出。第二，由于K操作码基本块已由块布局方法选择，这些操作码被检验以确定它们能否组合成逻辑操作码。最后，根据K操作码及其变元，调用IL产生过程。

Opcode Combination(操作码组合)(compiler/ooct_opcode_combine.c)。

某些K操作码序列能被描述成单个逻辑操作码。例如，已经确定，两个TR指令构成的一个序列曾用于测试一个32位寄存器对之值，作法是测试每个单独的一半。这两个TR指令代表一个在K结构中得不到的32位测试逻辑操作码。为这两个TR指令创建的IL创建过程会比识别出这一模式而创建的代码的效率低得多。幸好，由于OOCT是软件，增加一个新代码是容易的，它有一个特殊单元去识别模式，并代之以产生高效率的IL。

在对给定的操作码产生标准的IL之前，OOCT_opcode_combine例行程序被调用。这一例行程序重复已被定义的所有模式，试图使用一个‘逻辑’操作码，如果它合适的话。当前只定义了两种模式，但定义其他组合是直接了当之事。如果模式之一被匹配，则使用那个逻辑操作码的建立过程去创建IL指令，而且OOCT_opcode_combine将返回TRUE(真)以指明不需要调用正常的IL建立过程。

IL Building Procedures(IL建立过程)(compiler/ooct_il_build.c)

对于每个K操作码，有一个特定的IL建立过程。IL建立过程取两类变元：该指令地址和作为原始指令中字段的变换的列表。IL建立过程还使用一个共享全局变量global_gen_state，它用于在产生IL过程中跟踪伪寄存器和标号。每个IL建立过程向IL_CTXT结构中添加IL指令。所有产生IL的例行程序都创建标号IL_NODE，并以原始指令的地址作为标号的标识符(如果该标号不是另一指令的目标。它将在优化过程中的早期被删除)，一般不试图完成优化，把优化留给编译器104的以后阶段，但有少数特殊情况是要处理的，如对能在编译时检测出来的例外进行检验。

一旦熟悉了IL以及要产生代码的原始指令，那么大多数IL建立过程是直接了当的。有几点小技巧可帮助理解代码：

IL的建立被设计成对任何给定操作码的编译能被容易地关掉以进行调试。这主要由REALLY_COMPILE宏和COMPILE_SECTION_XX宏来控制。当REALLY_COMPILE被关掉时，所有IL建立例行程序都将只建立一个调(或跳)回到解释器110。当COMPILE_SECTION_X被关掉时，对于段号X中的操作码，所有IL建立例行程序都将只建立一个调(或跳)回到解释器110。

因为IL是分类的，所以使用具有正确类型的正确大小伪寄存器是至关重要的。例如，把一个16位值加载到32位寄存器中，首先对一个16位伪寄存器完成16位加载，然后使用一个CVT操作把这个16位值加成一个32位值(LOAD_CVT32宏完成这件事)。

每当插入一个到解释器110的回调或转跳，都必须添加一个SYNC以保证解释器对K寄存器有正确值。编译后代码在其向前运行时并不试图保持ESI寄存器之值(事实上该寄存器被用于保持其他值)。这样，所产生的代码必须在调用或转跳到解释器110之前把正确值放入ESI。当进行回调时，代码还必须使每个伪寄存器含有一个EXTMOD指令，因为伪寄存器可能已被该回调所修改(MODIFIES_REG宏完成这件事)。

处置例外条件(如溢出)的代码不在线上。代之以在IL指令列表的结尾处产生代码。这允许这种共同的情况被编译成一种失败，这一般会改善所产生代码的性能。

入点口，中断检验除了为块检出器114选取的每个K操作码产生IL外，还为入口点和中断检验产生IL。

为了允许发生更多的优化，没有把每个分支目的地作为外部入口点包括在内(外部入口点的作用是阻碍优化)。具体而言，应该构成外部入口点的唯一指令是那些从段外转跳来的指令。当编译一给定段时，在分支日志中可得到关于哪些指令满足这一判据的部分信息(见前文关于分支日志的信息)。编译器104使用这一信息去选择那些应该有外部入口的基本块。对于每个这种入口，产生一个ENTRY_IL_NODE以及一个GOTOIL_NODE，后者转跳到为入口原始指令所产生的IL。

OOCT说明书指出，编译器104应在任何循环内插入中断检验。在产生IL时，通过在段内的任何向后分支内和在任何计算出的转跳指令之前插入中断检验，从而构成一种保守的估计。中断检验插在该基本块中用于最后一条原始指令的标号之后。像其他例外条件一样，用于中断的IL代码也产生在线外，从而使正常情况简单地成为该条件分支的失败情况。编译器中间目标描述

    概述

编译器104的‘中间目标’的主要目的是改善IL的质量，从而在产生代码阶段中将产生更好的代码。编译器104的其余部分被构成为一系列扫描过程，它们或者完成对IL的分析，或者完成修改IL的变换。这些扫描过程可被应用多次，尽管各扫描过程之间有某些依赖性。从这一点起，编译器104的其余部分不再有关于K指令的任何知识，它只处理IL。

这一部分的其余内容分成：第一，讨论完成OASSIGN插入的阶段。第二，讨论编译器104的分析扫描过程。最后，讨论编译器104的变换扫描过程(它完成主要的优化)。

图15具体说明了一个OASSIGN插入的实例。

OASSING INSERTION(compiler/ooct_add_overlap_defs.c)。OASSING操作码是一个特殊的标记指令，它使伪寄存器之间的混淆成为显然的。在OOCT中产生对OASSIGN的需求是因为某些K操作码使用16位寄存器而其他操作使用32位寄存器，它们与16位寄存器有混淆。在OOCT中，对所有16位和32位寄存器使用单独的伪寄存器。这样，某些伪寄存器隐形地彼此重叠。这造成两个问题。第一个问题是在优化扫描过程中产生不正确的变换。对于每个伪寄存器定义，编译器104跟踪使用该定义的那些指令，而对于每个伪寄存器应用，编译器104跟踪它的定义。这一信息称作use/def(应用/定义)信息。编译器104在诸如常数映射扫描过程等扫描过程中使用use/def(应用/定义)信息。当伪寄存器能彼此混淆时，这需要use/def(应用/定义)计算和使用该信息的编译器104扫描过程变得复杂得多。由于伪寄存器重叠造成的第二个问题出现在寄存器分配当中。当寄存器分配器把两个重叠的伪寄存器同时赋予机器寄存器时，对一个寄存器的修改可能要求另一寄存器变为无效。一般而言，跟踪这种信息是很困难的。而且造成不必要的复杂性。

不去对付这些困难问题和显著增加编译器104的复杂性，代之以设计了一种插入特殊标记器OASSIGN指令，它会允许编译器104忽略这个问题。在产生IL之后紧跟着的一个特殊编译器扫描过程插入OASSIGN指令。在这个编译器104扫描过程之后，则允许其他分析扫描过程段定伪寄存器不重叠(针对use/def)(应用/定义)分析。此外，使用OASSIGN指令能相当容易地处置寄存器分配。每当寄存器分配器到达一个OASSIGN指令时，它在源的定义处把源泻出并把目的地填在OASSIGN之后。这一方法使用被混淆的存储器以保证对重叠定义的任何应用都使用正确值。

在两个阶段中处理OASSIGN插入。第一，运行Use Def(应用-定义)分析的特殊版本。Use Def的这一版本知道伪寄存器的重叠，并创建含有重叠伪寄存器的应用列表和定义列表。编译器104的其余部分不准备去处理含有重叠伪寄存器的use/def列表，所以Use Def的这一选项不应普遍使用。在完成这一分析之后，过程OOCT_Add_Overlap_Defs完成OASSIGN的实际插入。对于有重叠定义(该定义定义一个与应用的伪寄存器重叠的伪寄存器)的每个应用和对于在标号处达到这些定义的重叠，插入一个OASSIGN。

图15说明了要插入OASSIGN的情况的实例。在此例中，伪寄存器GRPAIR1和GR1重叠，所以在代码第一行中对GRPAIR1的赋值是对GR1的隐含修改。OASSIGN使这种情况变成显然的。分析扫描过程

UseDef(compiler/oc_common/src/oc_usedef.c)最基本的编译器104分析之一是计算给定定义的应用及给定应用的潜在定义。每个编译器104优化扫描过程使用这个use/def信息。每条IL指令可以有一个被写入的伪寄存器变元(dest(目的地))和一个或多个从中读出用的伪寄存器变元(src(源))。在Use Def分析之后，每个dest伴有一个列表，它存储指向所有可能应用该值的IL指令的指针(称作du链)。类似地，每个src伴有一个列表，它存储指向所有可能定义该值的IL指令的指针(也称作ud链)。下面描述计算use/def信息的方法。它是一个试图到达一固定点的叠代方法(即直至进一步叠代不造成改变时为止)。

重复下列步骤，直至对于在任何标号处的达到定义没有变化为止。

消除regdefs中每个伪寄存器的定义列表(由伪寄存器索引的NL_LIST陈列。

按静态程序顺序在IL_NODE上叠代。

如果该指令使用一个伪寄存器，则把该伪寄存器的定义从regdefs复制到该操作数的ud链中。

如果该指令是一个分支指令，则把regdefs与存在该分支标号(LABEL)中的达到定义组合。改变到该达到定义使整个循环被重复。

如果该指令是一个标号(LABEL)，则把该regdefs与已在该标号处的达到定义组合。

如果该指令定义一个伪寄存器，则让regdefs中的定义列表只包含这一指令。

如果该指令是一个无条件分支指令，则把regdefs数组改变成存在下一个标号(LABEL)中的达到定义集合。这样做的原因是这些指令在它们的静态顺序中被处理，而达到该无条件分支的那些定义与达到其静态后继者的那些定义是不同的。

有效变量分析(compiler/oc_common/src/oc_usedef.c)

分析的另一种形式用于有效变量分析。有效变量分析主要用于寄存器分配，但也能用于引入变量变换和死代码删除。如果一个伪寄存器在被重定义之前可以沿一执行路径被使用，便认为该伪寄存器在程序中的一个特定点是有效的(live)。有效变量分析还标记出一给定伪寄存器的最后一次使用(如果在一伪寄存器被重定义之前再没有使用该伪寄存器的任何可能执行路径，则这次使用是最后一次使用)。下面描述计算有效变量信息的基本方法。它的工作方式是在代码上重复向后扫描过程，直至达到一个固定点。

重复下列步骤，直至对于在任何标号处的达到定义没有变化为止。

清除live(有效)(伪寄存器的一个位组)按反静态程序顺序在IL_NODE上叠代。

如果该指令使用一个伪寄存器，则设置live位组中的该伪寄存器位。如果以前该伪寄存器不曾有效，则把它标记为最后一次使用。

如果该指令是一个分支指令，则把live位组与存在分支LABEL(标号)中的有效寄存器组合。改变有效寄存器使整个循环被重复。

如果该指令是一个标号(LABEL)，把live位组与已在该标号处的有效伪寄存器组合。

如果该指令定义一个伪寄存器，则从live位组中清除该伪寄存器。

如果该指令是一个无条件分支指令，则清除live位组。这样做的理由是按其反静态顺序处理这些指令，而在无条件分支处的有效变量不同于在其后继者处的那些有效变量。

寄存器分配(compiler/oc_common/src/oc_regalloc.c)

在编译器104中的寄存器分配以两阶段完成。第一阶段完成代码分析并根据目标机器的一个高级模型确定一组推荐的寄存器赋值。第二阶段使用来自第一阶段的分析结果以及不那么抽象的机器模型，去实际修改使用物理寄存器的代码。这一部分将讨论这第一阶段。

寄存器分配方法是基于使用图染色的传统技术。该“图”的节点是伪寄存器有效范围，在各有效范围之间带有重叠的边缘。一个N色图染色把N个颜色之一赋予每个节点，从而没有任何两个相连的节点有相同的颜色。显然，如果这个有效范围图能有N种颜色(这里N是可用的物理寄存器的个数)，则每个有效范围被赋予一个寄存器。可惜，图染色是一个NP硬问题(即它需要指数时间)，所以在实际的试探法中是不使用的。

寄存器分配是一个复杂的多步骤过程。下面详细描述这些步骤。

1.分开独立的有效范围并分配REGINFO结构

ComputeRegInfo函数做这件事。它把每个伪寄存器分开成独立的有效范围，并为每个有效范围分配一个REGINFO结构。REGINFO结构用于容纳关于所考虑的有效范围的信息，该信息用于寄存器分配，REGINFO结构最终容纳“目标”寄存器一为该有效范围分配的物理寄存器。由于伪寄存器有效范围(一个逻辑结构)和REGINFO结构之间有1∶1对应关系，所以名词REGINFO常用于指有效范围和数据结构二者。

ComputeRegInfo作有效范围分开这件事几乎是分配REGINFO结构的副产品。它的工作从一个尚没有REGINFO的定义开始，为它创建一个REGINFO，然后递归地观察它的全部应用和它们的全部定义，(以及它们的全部应用…)并把新的REGINFO与每个定义和可达到的应用关联起来。

一旦创建了所有REGINFO，这些REGINFO被分开成‘简单的’和‘复杂的’。一个‘简单的’REGINFO：

正好有一个定义和一个应用

这应用紧跟在定义之后

这应用不是一个BINOP(目标特定要求)的第二操作数。

所有其他REGINFO都是复杂的。每个REGINFO被给于一个唯一的ID(标识)。复杂的REGINFO在[0..c-＞ri_complex)区间，简单的REGINFO在[c-＞ri-_complex..c-＞ri_total)区间。这样区分的目的是在容纳作为BITSET(位组)存储在每个REGINFO中的冲突矩阵时节省存储器。上述‘简单’REGINFO的定义所起的作用是决不含有两个简单REGINFO彼此冲突。

2.计算冲突和相容

下一步骤是计算REGINFO结构的冲突图。如果两个REGINFO的有效范围重叠，则这两个REGINFO是冲突的。如果两个REGINFO由复制连接，则这两个REGINFO是相容的。冲突的REGINFO不能被赋予相同的寄存器，因它们在同时是有效的。两个相容的REGINFO应被赋予同一寄存器，如果可能的话，因为这样做删除一个副本。

这种冲突即可看作是一个图(每个REGINFO有一个节点和把每个REGINFO节点与每个与它冲突的其他节点连接的无方向边缘——这是图染色方法所用的观点)，或者作为一个对称二元矩阵。这后一种形式更接近于这些冲突的实际存储状况。

每个REGINFO包含一单个BITSET(位组)，它是该冲突矩阵的一行(的一部分)。因为没有任何两个简单REGINFO能冲突，所以矩阵的右下象限全为零。由于该矩阵是对称的，所以右上象限是左下象限的转置。结果，该矩阵的左侧是需要存储的全部。于是每个冲突BETSET(位组)只是c-＞ri_complex个二进位，而不是c-＞ri_total那么多位。

为了确定两个来自BITSET的REGINFO，A和B是否冲突，首先需要测试看它们是简单的还是复杂的(把id(标识)与c-＞ri_complex比较)。如果其中一个是复杂的，在其他REGINFO的冲突BITSET中查看对应于该ID的位。如果两个都是复杂的，你可以查看其中任一个的位；它们必定是相同的。如果没有一个是复杂的，则它们不冲突。

冲突是从存在IL中的有效性信息(由Computelive产生)中计算出来。ComputeConflicts在IL代码上进行单次扫描过程，由在当前点有效的一组伪寄存器中产生出在那一点有效的复杂REGINFO的BITSET。当每个复杂REGINFO被添加到该live(有效)组时，它被标记为与在该live(有效)组中的每个REGINFO冲突。当遇到每个简单REGINFO时，它被标记为与当前live(有效)组冲突。

3.对REGINFO按‘寄存器优先级’分类

OC_SortRI根据多个可调优参数对REGINFO结构赋予优先级。加权参数是彼此相对值，所以对它们全都乘以一个常数是没有影响的。

OC_RegAllocConflictWeight：

放在冲突图的图染色上的权。对这一参数的较高设置将有利于分配，它把更多的不同REGINFO放入寄存器，不管这些REGINFO实际被应用是否经常。请注意，很少应用的REGINFO也将趋于有短的生命时间，所以最好是有利于具有长生命时间的REGINFO。

OC_RegAllocDefWeight：放在定义上的权。OC_RegAllocDefWeight的较高值将有利于具有更多不同意定义IL语句的REGINFO。

OC_RegAllocUseWeight：放在应用上的权。

OC_RegAllocDefWeight和OC_RegAllocUseWeight二者将趋于有利于具有长生命时间和许多use/def的REGINFO(尽管不是那些仅只长时间‘挂起’而不被应用的REGINFO)。

OC_RegAllocResortRate：这个参数控制它进行多少分类查询以得到一个好的染色。如果OC_RegAllocConflictWeight为零，这个参数是没有关系的而且应为零。小的值(＞0)表明要用掉更多时间但得到更好的染色。

4.寄存器选择。

一旦REGINFO放在一系列约束上。第一类约束是需要的，于是在应用这些约束之后如果没有寄存器留下来，则该REGINFO不被赋予一寄存器(目标＝-1)。其余约束是希望的但不是必需的，于是，如果任何给定约束会造成一组可能的寄存器变成空寄存器，则该约束被跳过。一旦全部约束都已用过，则选择该组中编号最低的寄存器并使用它。

TYPE[required(需要的)]：必需选择能容纳这一类型的值(信息来自Machine Model(机器模型))。

INUSE[required(需要的)]：不能选择一个寄存器，如果它已被分配给冲突的REGINFO(或与其重叠的任何东西)

BASEREGS[required(需要的)]：不能选择一个寄存器，如果该框架已保留它作为某种frame/stack/base指针

CLOBBERED(被弄成乱码的)：尽量不要使用这样一个寄存器，它在REGINFO生命时间内已被某人弄成乱码了

DEF CONSTRAINTS(DEF约束)：对于定义这个REGINFO的每条IL，尽量使用满足来自机器模型的DEST约束的寄存器

USE CONSTRAINTS(USE约束)：对于定义这个REGINFO的每条IL，尽量使用满足来自机器模型的SRC约束的寄存器

COMPATABILITY(相容性)：尽量使用这样的寄存器，它与相容性列表中已被赋予寄存器的另一REGINFO相容。

一旦所有REGINFO已被赋予寄存器(或失败了)，它在REGINFO上进行另一个扫描过程，通过相容性约束查寻要改变的寄存器(即在这个之后赋予的相容REGINFO，由于某种其他原因它不能进入这同一寄存器)。变换(优化)扫描过程

变换扫描过程处于优化编译器104的心脏。每个扫描过程试图重写部分代码，从而使代码的含义保持不变但所产生的最终代码将运行得更快些。某些变换扫描过程本身并不改善代码质量，而是它们允许其他扫描过程去改善代码。这样，这些过程趋于组合起来做得最好，而当单独使用时便不那么有效。由于这一原因，许多扫描过程，如删除死代码(DeadCode Elimination)被重复地运行。

删除死代码(compiler/oc_common/src/oc_usedef.c)

删除死代码扫描过程(OC_ElimDeadCode)根据数据流和控制流信息去掉所有死代码。数据流信息用于删除没有副效应和其结果不被使用的那些IL_NODE。控制流信息用于去掉那些将永不会被执行的所有IL_NODE(不可达到的代码)。此外，完成某些分支的目标重定。所用方法扫描如下：

重复下列步骤，直至没有任何改变为止。

1.按静态程序顺序在IL_NODE上叠代。

a)如果该指令是不可达到的，则删掉它。如果一条指令是一个标号(LABEL)而没有任何其他指令以它为目标，或者如果它是一个GOTO或CGOTO到下一指令的指令，或者如果该指令直接在一无条件分支指令之后而又不是一个标号，那么这条指令便是不可达到的。

b)如果该指令没有副作用而且它除其本身外无其他任何应用，则去掉它。

c)如果一固定分支指令转跳到一个无条件分支，则重定该指令的目标(例如GOTO到一GOTO)。

d)查出指向下一条指令的条件分支，而且该条件分支后接的是到其他某个地方(L2)的分支指令。在这种情况中，条件被转换，该条件分支被重定目标到L2。

图16具体说明删除死代码的一个实例，以及地址检验删除(compiler/ooct_clim_achk.c)。

地址检验删除扫描过程使用数据流分析技术去删除不必要的地址对齐检验。代码通过在偶数和奇数代数上完成值推断来进行工作。换句话说，对代码进行分析，以确定在任何给定点一个伪寄存器是否保持有一个偶数，奇数或未知值。这一分析是在全局进行的并且穿过分支进行工作。这表明它将对循环工作而且通过其他控制流工作，如果完成的是单个不滚动循环，则工作得特别好。下面描述所用的方法。这是一个叠代方法，它试图达到一个保守的固定点。以三种主要方式对值进行推断。第一，当一伪寄存器被赋予一常数时，该值能被推断。第二，当一伪寄存器是具有已知变元的操作的结果时，该值能被推断。第三，条件分支指令给出关于伪寄存器值的信息。例如，如果一个伪寄存器被测试看其是否为偶数，则沿着一个分支我们知其为偶数，而沿另一分支它是奇数。

重复下列步骤，直至在任何标号处所推断值没有任何改变为止。

1.清除infvals(由伪寄存器给出索引的INFVAL数组)中每个伪寄存器的定义列表。

2.按静态程序顺序在IL_NODE上叠代。

a)如果在给定当前已知推断值的情况下该指令能被简化，则用更简单的形式代替该指令。对该指令的改变使整个循环被重复。

b)根据当前指令的执行情况更新infvals。

i)如果该指令是条件指令，对此条件能推断一值，则以适当的推断值去更新那些存储在该目标LABEL(标号)处和在CGOTO处的推断值。

ii)如果该指令是无条件的而且定义了一个伪寄存器，则更新infvals中那个伪寄存器的值。这个值是未知的，除非该操作是SET，或者是一种特殊情况，如两个偶数相加。

c)如果该指令是一个LABEL，则把infvals与已在该标号处的推断值组合在一起。

d)如果该指令是一个分支，则把infvals与存在该分支的LABEL(标号)处的推断值组合在一起。对infvals的改变使整个循环被重复。

e)如果该指令是一个条件分支，从那个条件推断出的任何值都与infvals组合在一起。

f)如果该指令是一个无条件分支，把infvals数组改变成存储在下一个LABEL(标号)处的推断值。这样做是按其静态顺序处理指令，在无条件分支处的推断值不同于在其静态后继者处的那些推断值。

图17具体说明地址检验删除的一个实例。为改善该分析的性能，一个伪寄存器可取简单的ODD(奇数)、EVEN(偶数)或UNKNOWN(未知)以外的其他值。一个伪寄存器还可标记为EQUIVALENT(等效于)另一伪寄存器或EQUIVALENT(等效于)两个伪寄存器的一个二元操作。这通过允许关于一个寄存器的信息传播到其他伪寄存器来改善该分析的能力。例如假定发现伪寄存器R1和伪寄存器R2是等效的。如果该方法能表明R1是偶数(例如通过分支测试结果)，那么R2必定也是偶数。

请注意，该方法是一个保守的方法，被推断的值必须是单调增加的。换句话说，如果在执行该方法过程中的任何时候确定在程序中一点处的一个值是EVEN(偶数)，它必定是该值真正为EVEN(偶数)的情况。该方法决不会指出在一次叠代过程中一个伪寄存器是EVEN(偶数)，而在另一叠代过程中它是UNKNOWN(未知的)。由这一性质导出该方法的结束是直接明了的。

吊起(Hoisting)(compiler/oc_common/src/oc_hoist.c)

吊起，通常是指循环不变代码运动，它是把对一个循环而言为常数的计算移到该循环之外的过程。这通常会显著提高速度，因为该代码将只被执行一次，而不是对每次循环叠代都执行一次。

1.对IL重新编号(即使将标识码按顺序排列)

2.对于每个向后分支(即潜在的循环)，尽量把一些东西吊出去。

a)如果有进入该循环的另一入口，则没有任何东西要从该循环中吊出去

b)按静态顺序在该循环内部在IL_NODE上进行叠代。

i)如果一个节点满足下列条件，则它能被吊出：

(a)它没有使用或定义一个‘实整数’

(b)它没有使用在该循环内设置的一个伪寄存器

(c)它没有副效应

ii)对任何能被吊出的操作码，重命名它定义的任何伪寄存器

iii)把该IL_NODE移到该循环的上方

iv)对所有IL_NODE重新编号

v)如果检测到一个分支，则跳到该分支的目标处(因为不能确定该分支是否被执行，所以该代码不能被吊出)。

对于OOCT，吊出扫描过程并不总是有效。其主要理由是许多循环也是入口点，所以它们有进入循环的多个入口，而且未被吊起扫描过程查看。这个问题能通过完成‘标号分开’加以修补，在标号分开过程中能创建一个新的标号作为该循环的目标。于是被吊起的操作能被抬到原始标号和新创建标号之间。不久将实现这一点。

公共子表达式删除(CSE)(compiler/oc_common/src/oc_cse.c)

公共子表达式删除(CSE)是一种技术，其目的是删除冗余计算。编译器104使用一种全局CSE方法。

下面结合图18中的说明实例，描述该基本方法。

1.当进行改变时，对每个有目的地的IL_NODE(实例中的第一行)，做如下事情：

a)按时检验该目的地的所有应用，看是否一个控制其他(如果到B的所有路径必须通过A，则称A控制B)。对于每个这种A、B对(行2和行4)，做如下事情：

ii)检验A和B是否‘匹配’(相同操作码，或相同源)，如果不匹配，则到下一对表达式。A和B是一个‘公共子表达式’。

iii)按下述方式从A和B开始尽量找出更大的公共子表达式。如果A和B有目的地，而且B的目的地有一唯一应用C(行5)，检验A的目的地是否有任何应用D(行3)使得D控制C而且D与C匹配。如果是这样，把D和C添加到公共子表达式中，并试图找到具有A＝D，B＝C的更大的子表达式。

iv)既然我们有两个公共子表达式A(行2，3)和B(行4，5)存在，那我们需要重写代码以使对B的应用现在由A代替。如果A的目的地在被B使用之前可能会改变，则对新的伪寄存器使用一个复制。

图18具体说明公共子表达式删除(“CSE”)的一个实例。

复制传播(compiler/oc_common/src/oc_copyprop.c)

复制传播是一种变换，它试图以赋值的源代替对赋值的目标的使用。尽管复制传播本身并不改善代码质量，但它经常产生代码使那里的赋值结果不再被使用，这样该赋值能被删除。下面描述复制传播的方法。

1.对每个ASSIGN(赋值)操作。

a)如果ASSIGN的源是一简单定义而且该定义的使用只是这个ASSIGN，而且该ASSIGN的目的地在定义和ASSIGN之间既未被修改也未被使用，则把该定义修改成对ASSIGN目的地的定义，并删去这个ASSIGN。

b)对ASSIGN目的地的每个应用，测试该ASSIGN是否是那个应用的唯一定义并测试该ASSIGN的源在ASSIGN和该应用之间是否即存在且有效。如果这两个测试为真，则以源的应用替代该目的地的应用。

图19具体说明一复制传播的举例。图20具体说明一常数合并的举例。

常数合并(Constant Folding)(compiler/oc_common/src/oc_cfold.c)

常数合并是一种变换，它在编译时间对于常数值操作进行求值。例如，如果IL把两个常数值相加在一起，常数合并将以一个SET指令代替那些IL指令，该SET指令把该相加的目的地赋值为这两个数值之和。

常数合并扫描过程所用方法是很直接了当的。每个IL指令被按顺序检验。对每个算术的和逻辑的操作(ADD，SUB，BAND，BOR，等)，如果它的变元全为常数，则该IL操作以一SET操作代替，该SET操作设目的地伪寄存器为对常数变元操作的结果。

模式匹配(Patter Matching)(compiler/oc_common/src/oc_pattern.c)编译器104还有一个模式匹配优化扫描过程，它以更有效的形式替代IL指令的已知模式。目前没有模式能共同地匹配由OOCT产生的IL指令，所以模式匹配扫描过程没有运行。产生目标码

在已产生IL并已应用若干变换来改善代码质量之后，三个主要的编译器104扫描过程被用于产生代码，到这一点为止，IL和变换扫描过程都一直是独立于机器的，但这三个扫描过程则强烈依赖于目标的体系结构。

指令合并(INSTRUCTION/FOLDING)/(compiler/oc_ommon/src/ix86_ifold.c)。

OOCT是类似于RISC的结构，不经修改则不能有效地映射到目标结构。具体而言，对每个IL指令产生一个目标指令将是不那么有效的。因为目标结构是一个CISC结构，多个IL指令常能被合并成单个目标指令。所设计的指令合并扫描过程通过标记出能被组合成单个目标指令的IL指令组来解决这一问题。

指令合并扫描过程通过查寻大量预先定义的不同指令组合之一来进行工作。下列组合被使用：

·常数被合并成ADD、SUB等各种操作。

·SETCC指令被合并成它们在设定条件代码时所基于的指令。

·具有相同变元的DIV、REM对被合并到一起。

·ADD、SUB和ASL操作能被合并成单个‘lea’操作，或者合并成LOAD或STORE的地址计算。

·16位BSWAP、STORE组合被合并成两个单独的8位存储。

·LOAD操作被合并成各种操作，此时它们的结果被用作为第二变元。

指令合并扫描过程只是简单地决定指令是否应被合并，它并不作实际的合并，实际的合并留给产生机器代码扫描过程。指令合并扫描过程以两种方式标记出要被合并的指令。第一，节点的每个操作数可被标记为一‘合并’位。第二，以IL_COMBINE(IL_组合)标志和mmFold字段标记出其全部应用均被合并成另一指令的那些指令，这里mmFold字段给出关于该指令合并方式的信息。寄存器分配器和产生机器代码都使用这些字段以便正确地完成任务。

目标寄存器分配(Target REGISTER ALLOCATION)

(compiler/oc_common/src/ix86_regalloc.c)

一旦寄存器分配器对所有REGINFO已检出了它能检出的寄存器，便有必要遍历该代码并对其进行修改，以使用那些物理的寄存器代替伪寄存器。此外，有必要把某些额外的伪寄存器暂时放入真实寄存器中，从而使汇编器能为那些指令产生代码。这通常需要插入分流(spill)和填充(fill)代码以存储和恢复由RegAlloc曾放在那些寄存器中的值。为此，OC_RegUseAlloc使用一个约束分配器(GetReg)，并插入分流和填充以重新使用寄存器。

OC_RegUseAlloc在代码上做单次扫描过程，修改和跟踪‘stat’数组中的物理寄存器状态。这stat数组记录任何给定时刻每个寄存器中是(或应该是)什么，以及在该寄存器或分流处(或这二者)中的值是否正确。OC_RegUseAlloc的工作作为一系列阶段，每个阶段对当前被处理的指令进行特定的修改。如果有多个IL指令已在指令合并扫描过程中被合并到一起，它们便作为单个指令对待。这些阶段如下述：

1.如果该指令直接使用任何物理寄存器，要确保在这一应用之后才发生对那些寄存器的任何填充。修改该指令，以使用由RegAlloc分析为伪寄存器分配的寄存器。锁住所有寄存器以使它们将不被重新使用。

2.修改指令，以使用由先前对GetReg的调用暂时分配的寄存器。锁住所有这些寄存器。

3.清掉stat数组中的状态信息，以反映被该指令乱码的任何寄存器，必要时插入分流。把目的地寄存器改变成由RegAlloc分配的寄存器，如果存在的话(请注意，没有必要锁住这个寄存器，因为需要时它能用于容纳一个src(源))。

4.修改代码，以把寄存器中的源放到产生目标代码所需要的地方。这涉及调用GetReg以得到需要在寄存器中的那些源操作数。

5.对所有已被锁住的寄存器解锁。

6.修补目的地，以在目标代码需要的地方使用真实寄存器。这涉及调用GetReg。

7.使stat数组确定下来，以反映这一操作的结果，修补所有使用过的寄存器，把它们的‘以前’位置设置到下一指令中(从而使任何分流/填充都放在这一完成后的指令之后)。

理解stat数组是重要的。它是由物理寄存器编索引的数据结构数组(在MM_NumRegs以下的所有寄存器都是物理寄存器)，它指出那个给定物理寄存器的状态。该结构包含以下字段：

1.ri：REGINFO结构，标识当前与这真实寄存器关联的伪寄存器(可以是0，以指示无关联)。这或者可以是由RegAlloc分配给该寄存器的一个伪寄存器，或者是由GetReg暂时指定的一个。

2.alt_ri：一个REGINGO结构，标识一个也在这一寄存器中的额外伪寄存器。这用于GetReg把一伪寄存器赋予一个物理寄存器而RegAlloc同时把另一个放在这里(在ri中)的时候。

3.flags：标识寄存器状态的标志。例如，RegValid用于指出该寄存器中之值是有效的。如果RegValid未被设置，该寄存器在能被使用之前必须被填充。见ix86-reg alloc以得到对可能的标志的完全描述。

4.before：该指令应把对这一寄存器的分流或填充放在什么地方。产生机器码

在两个扫描过程中产生该目标的机器码。第一扫描过程用于确定指令的长度，从而能计算出分支偏移。第二扫描过程完成实际的产生代码过程。这两个扫描过程是完全相同的，只是第一扫描过程把代码产生到一个暂存缓冲器和没有正确的分支偏移，所以几乎所有代码都是共享的。

两个扫描过程由依序通过IL指令的一个单一扫描过程构成。对于每个指令，由操作码和类型构成索引的一张表用于提取一函数以产生该代码。这些产生代码的函数使用EMIT宏，这些宏是产生目标指令的一般化方法，无需知道目标的内部细节(见ix86_Asm_Emit.[h，c])。这些宏简化了那些使用任何目标编址方式的指令的汇编过程。段管理

由OOCT编译的代码存储在一个SEGMENT(段)数据结构中。有许多与段管理有关的重要事项。第一，段有特殊的存储器分配器去处置段存储。第二，讨论如何创建段和将其安装到系统中。第三，讨论如何删除段(如果这一选项被启动的话)。最后，讨论段锁住，它用于段删除选项被启动之时。段分配器(compiler/SegAlloc.[h，c])

OOCT中段的存储管理由一个特殊的分配器处置。在OOCT初始化时，段分配器(SegAlloc)被一个大片存储器初始化。然后，SegAlloc单元提供请求可变大小的未用的一片存储器的能力(类似于malloc)，释放先前分配的一片存储器的能力(类似于free)，以及请求对当前存储器使用情况进行统计的能力。

SegAlloc比ZONE(区)分配器更复杂，因为它必须处置可变大小的分配。SegAlloc使用一种相当标准的分配方法。该分配器维持一个分类排队的自由片列表，并为分配的块使用一个32位头段以指明块的大小。为分配一片存储器，查寻这自由列表以找到满足所请求大小的一片。如果该片的剩余部分大于一个最小大小，它便被分开，并把这剩余部分添加到freelist(自由列表)中。为释放一片，它被加到freelist(自由列表)中。由于释放存储器的速度不是一个至关重要的因素，所以查寻freelist(自由列表)以寻找相邻的自由块，这些块被组合到单一自由块中。段创建和安装(compiler/ooct_trace.c，compiler/SegMgr.[h，c])

在编译的主要阶段完成之后，其最终结果是含有可重定位目标码的一块存储器。下一步是为那代码创建一个段，并把它安装到为那些段分配的空间中。OOCT_Install完成这一功能。初始时，用于此段的空间被分配在ZONE存储器区域。该段以块检出器114选出的基本块列表初始化(从而在其后能查寻这些段以发现它们是否包含给定的原始指令)，并以所产生的代码进行初始化。对SEGMGR_Install的调用把该段变成连续的存储器块，并把它复制到用SegAlloc单元为这些段分配的空间中。

在创建段并将其移到段分配空间之后，指出哪些原始指令有为其编译的代码的翻译表需要被更新。对于每个作为外部入口条目的原始指令，利用为那个入口条目产生的代码中的正确地址来更新翻译表。此外，该翻译表用TRANS_ENTRY_FLAG做标记，以指出该K指令有一个有效入口条目。段删除(compiler/ooct_trace.c，compiler/SegDel.[h，c])

当编译器104把一入口条目写入该翻译表时，它可能重叠写在已经在那里的一个老条目上。没有任何解释器110将能读那老的条目和跳到这老的段。当一段在该翻译表中没有入口条目时，则没有解释器110使用该段，于是它可被删除，它的存储器可用于其他段。这一段描述编译器怎样检测出一段可被删除和然后如何删除它。通信部分也很详细地描述了段锁住和段删除。

当编译器重叠写翻译表中的一个入口点时，它把老的入口点放到一个删除列表上。在安装一个新块之后，编译器104调用SEGDEL_TryDeletions。这个过程检验删除列表上的每个条目。如果没有解释器在使用一个入口点，则该入口点被删除，从而其后能被重用。

每段在其中有一个入口点计数器。当一个入口点被删除时，编译器104对包含该入口点的段减少入口点计数器之值。当一段的入口点计数器达到0时，则没有任何解释器110在使用该段而且没有任何新的解释器110能跳入它。编译器104删除该段，并释放它的存储器以供其他段使用。段锁住

到一段的每个入口点有一个计数器，它的作用是该入口点上的一把锁。该计数器记录正在使用该入口点的解释器110个数。当该计数器之值大于零时，该入口点及它的段被锁住，于是编译器104将不删除它们。入口点锁的最重要特性是锁住和解锁该段的指令不是该段本身的一部分。这使得一个解释器110不可能执行该段中的任何指令，除非它持有该锁。关于编译器104和解释器110的报告很详细地解释了这一段锁机制。其他事项

在编译器104中还有许多其他事项，它们不能很好地放到其他部分中，但理解它们是重要的。堆栈变形(STACK WARPING)(common/ooct_warp.[c，h])

初始时编译器104被分配一个小的堆栈，它不是动态扩展的。不幸的是，由于编译器104使用大量递归过程，它需要的堆栈大小往往大于所提供的那个。当在Gran Power上运行程序时，观察到这样的情况，即由于堆栈溢出而发生了编译器104不能从中恢复的页面错。不去试图重写编译器104的一些部分或确定如何正确处置由于堆栈溢出造成的页面错，而是代之以使用比从OOCT_buffer(OOC缓冲器)分配的那个堆栈大得多的堆栈。这个堆栈的选取是要使堆栈大小永不会成为一个限制因素(其他因素，如ZONE的大小，是更大的限制)。为了使用这个堆栈，设计了一个清洁界面OOCT_Warp_Stack，它允许调用一个函数去使用OOCT的大堆栈空间。在从OOCT_Warp_Stack返回时，堆栈指针将不被改变。这样，当经由编译种子的主入口点ooct_Compile_Seed进入编译器104时，它被使用OOCT_Warp_Stack调用。认定(ASSERTIONS)(common/assert.[c，h])

在编译器104中的代码有大量认定语句。认定被用于整个编译器104以检验一致性约束和其他出错条件。认定起两个主要作用。在调制环境中，一个认定失败使程序停止，同时显示或存储对追踪程序有用的信息。在产出环境中，认定用于抓住出错条件并在这些条件发生时安全地退出编译。例如，如果编译器104运行超出存储器时，一个认定将使编译器放弃编译那个种子。服务例行程序(common/service.h)

服务单元提供的服务通常在标准C库中提供，如printf和memset，它们不是由KOI监视器提供。这个单元想要抽象掉在Windows(视窗)和固件构成中不同地处置这些系统调用的需要。这些服务例行程序有两个底层实现，一个用于Wintest目标，另一个用于固件构成。VIII.视窗测试环境

在快速开发和测试OOCT系统中视窗测试环境起了至关重要的作用。通过在视窗下开发，在MSVC下提供了标准调试工具。其他有用的工具，如profilers，也能得到。为了测试目的，已在视窗下开发了专用测试方法，它们已提高了测试的速度和测试覆盖范围。

首先描述仿真Granpower环境。然后讨论实现大多数高级测试技术的比较单元。最后描述编译器104的代码转储(dump)仿真GRANPOWER环境

为了完成对OOCT的初始测试以及更高级的测试和性能分析，需要一个会在视窗(Windows)下运行的解释器。解释器110本身不需要修改，但需要写GranPower系统中提供的初始化调用和AOI系统调用。此外，对于在视窗下运行的OOCT，需要一种设计去运行多重‘任务’，因为编译器104是作为与解释器110分离的任务运行的。初始化

创建视窗下仿真环境的第一部分是创建正确初始化KOI数据结构和为OOCT任务仿真KOI初始化API的代码。解释器110期望大量数据结构被适当地初始化以便能执行任何代码。此外，某些数据结构元素控制是否使用OOCT。通过把我们的初始化代码放在固件初始化过程基础上，仿真正确的初始化以运行解释器110和控制它的一些基本行为。类似地，以KOI初始化API为基础，用于OOCT任务去在固件所用代码上运行。这允许对解释器110之间界面(如对OOCT_Init的调用)的初始写和测试能在标准视窗调试环境中工作。它还使改变和测试界面成为直接了当之事。AOI系统调用(wintest/Misc Stubs.c，wintest/Msg Stubs.c)。

解释器110期望在一个有全部AOI系统调用可供使用的环境中运行。为了甚至能编译和链接一个可执行程序，需要创建用于AOI系统调用的存根(stub)。许多系统调用在视窗下测试系统时并无意义，所以那些调用只是作为空函数留下(只是用于链接目的)。所提供的AOI系统调用的实现用于计时(ScGtmSet，ScGtmRef)和用于messsgAlc，ScMsgSnd，ScMsgRev)。

OOCT强烈依赖于消息传递系统调用，以用于Exec和编译器104之间的过程间通信。在视窗下，那些AOI系统调用的哑形式用于允许同一任务内的各线程进行通信(见前文)。消息系统调用的视窗版本实现使用锁住和消息队列来对系统调用的完全说明。Compiler/EXEC用的单独线程

为了简化视窗下的实现和调试，对编译器104和解释器110使用单独的线程以代替单独的过程。使用线程简化了两个‘任务’之间的消息传递实现。此外，调试更容易了，因为对两个任务(解释器110和编译器104)能使用单个调试器，还因为调试器被设计成在多线程上工作(我们不知道有任何调试器具有调试多过程的工具)。比较单元

OOCT使用一种独特的测试方法，它已被证明是特别有价值的。因为OOCT编译后的代码所产生的结果应与解释器110产生的结果严格相同，所以创建了一种途径去直接比较那些结果。在视窗测试环境下，在OOCT和解释器110两种情况下运行程序的能力和自动比较中间结果的能力已被构建在其中。这些比较可以任意好地细化，可以细到每条指令之后都进行检验。与比较程序行为的能力一起，还写了一个自动测试发生器。该测试发生器创建‘随机’代码，然后运行该代码并进行比较。这个自动测试产生和比较提供了特别大的一套程序来证实OOCT在正确地工作。此外，它已提供了特别有价值的方式去正确地指出发生的错误，因为自动比较能指出编译后代码和解释器110首次发生差异的地方。

这一部分将分两阶段描述比较单元。第一，描述用于比较编译后代码结果和解释器110结果的底层结构。第二，描述测试中所用随机代码的产生。比较底层结构

比较底层结构是基于运行同一K程序的两个版本这一思想，这里在各指定时刻仿真K机器(寄存器和存储器)的机器状态是被检验点。然后对那点检验点的结果进行比较，以确定编译后版本和被解释的版本给出相同的结果。

图21具体说明上述过程的一个实例，它有一个根据本发明一实施例构成的比较底层结构。在实践中，这种比较测试是作为两个视窗过程运行的。父过程运行带有分支记录和编译的整个OOCT系统，而子过程只运行KOI的一个被解释版本。这两个过程都把它们的检验点日志写入存储器(子过程写到共享存储器)以记录它们对仿真K机器状态的影响。父过程比较日志中的数据并报告任何不一致情况。代码生成

由三个单元完成产生比较测试用随机代码。第一，K汇编器提供了一种机制用于使用C函数调用来产生K机器码。第二，提供了创建各类K操作基本块的单元。最后，随机控制流单元允许产生具有多种不同类型控制流的代码。

K汇编器(wintest/OOCT_Assemble.[h，c])K汇编器提供了一种直接了当的机制从C程序内部产生K代码。每个K操作码有一个函数用于汇编专用于那个操作码的指令。单个指令取指向存储代码存储器的一个指针、一个(可能是空的)标号名、以及该指令中所用每个字段的变元作为该指令的变元。该函数只是简单地把这些字段组合到它们的正确位置并把代码写入缓冲器。因为可能在定义一标号之前发生到该标号的分支，所以使用在代码上的第二次扫描过程，以还原分支目的地。

随机K操作码创建单元(wintest/GenArth.c，wintest/GenCassist.c，wintest/GenMisc.c)为了测试各类指令，创建了单个的单元，它们产生含有那些指令类型的基本块(直线代码)具体而言，创建了若干单元以产生算术和移位操作、C辅助指令以及由OOCT实现的所有其他指令。与这些单元的主要接口是通过一个Fill Basic Block例行程序。这个例行程序取存储器缓冲器和指令个数作为变元，并把给定的指令个数(随机选取的)写入该缓冲器。Fill Basic Block例行程序从产生指令函数数组中随机选取以添加指令。对每个被产生的K操作码，这些单元含有一个指令产生函数。这个产生指令函数选择适当的随机值作为提供给汇编器的变元并汇编这些指令。这些指令不是完全随机地产生的。相反，它们的产生受到某些限制。例如，当随机选取一个寄存器作为目的地时，便决不用基寄存器。该代码还被限制于使用若干预先规定的存储器位置，在我们的测试中，这些限制没有被证明是很有意义的。如果在将来证明它们是有意义的，则有可能通过使用更复杂的过程来减少一些限制。

使用随机测试是重要的，因为它测试许多指令之间的相互作用，这对于一个编译器104，例如OOCT，是特别重要的。在OOCT中，由编译一条指令产生的代码会不同，基本上取决于周围的指令。

图22具体说明同一指令有不同的周围指令时产生代码的举例。此外，随机测试所测试的许多情况，程序员是不会去做的。

随机K操作码创建单元本身对某些类测试是有效的。例如，当实现一个新操作码时，创建一个简单的循环去执行使用该操作码的指令基本块，这已经证明是很有效的方法。尽管单个单元能是有效的，但为了充分测试编译器104的某些方面，更复杂的控制流程是需要的。

随机控制流程创建单元(wintest/Gdom控制流程创建单元(GenControl))用于创建测试，这些测试使用比直线代码更复杂的控制流程类型。GenControl以一单个基本块开始，并完成一定数量的变换(随机选择)。当前能完成的变换如下所述：

一个基本块能被分成两个基本块。

一个基本块能被一个菱形代替。这代表一个条件分支，这里两条路径又联结回到一起。

一个基本块能由一循环代替。

一个基本块能由三个基本块代替，这里对第二个基本块进行函数调用并返回到第三个基本块。

在对基本块完成了指定数量的变换后，便存在一个随机产生的控制流程图，它需要以指令填入。这由两部分组成。为产生基本块本身的代码，使用前文讨论的随机K操作码创建单元。第二部分是填入指令以完成分支和循环。循环使用一个预先定义的样板，它重复固定次数。对于条件分支，使用一条随机测试指令。编译器代码转储

为了调试目的和优化目的，在视窗下在OOCT中使用了若干个代码转储机制。有两个主要的转储机制。第一，在编译过程中，可以转储一个代码列表，它包含被编译的K操作码、IL、以及目标代码(如果它已经产生的话)。第二类转储是把目标代码转储为汇编形式，它可以针对测试目的被重新编译和链接。

在某些阶段之后，通过转储IL代码副本，能检验一给定编译器104优化扫描过程效果的正确性和有效性。此外，通过检验所产生的最终代码，人们能人工检验编译器104把每个K操作码翻译成IL的良好程度和为每条IL指令和K操作码所产生的目标代码的质量。这些代码转储由使用COMBDUMP宏来控制，它被插入编译器104各扫描过程之间，放在OOCT_Optimize_IL_And_Gen_Code(见compiler/ooct_trace.c)中。这个宏调用OOCT_Combdump过程(见ooct_combdump.c)，它在K操作码和IL指令上重复。

当前用于视窗的概要分析工具不能正确处置动态产生的代码。这样，第二类转储被使用，从而使来自一个运行的动态代码能被作为静态代码用于另一个运行并正确地记录其概况。这以两个步骤实现。在第一步中，该程序以OC_DUMP标记(见compiler/ooct_dump.h)进行编译，这使被编译的每个K操作码踪迹被记录下来，并使代码以可重编译格式转储到一个文件中。第二，该程序以OC_USEDUMP标志(见compiler/ooct_dump.h)进行编译和运行，它为先前编译的代码关掉动态编译，代之以使用静态版本。然后可运行该程序的这一版本，并以一个概要分析器记录关于该代码质量的统计情况。本发明第二实施例动态优化目标码翻译第二实施例概要

结构仿真是指由一个不同的计算机结构去模仿一个计算机结构，从而能不加修改地去运行用于原始结构的机器代码。目标码翻译是把用于一个计算机结构的机器翻译成用于一个不同计算机结构的机器码的过程。所描述的动态优化目标翻译系统使用编译器优化技术达到的性能高于为结构仿真所用的基于模板的目标码翻译。第二实施例附图描述

图23说明根据本发明第二实施例构成的用于动态优化目标码翻译的系统配置。图23是与程序的解释后执行并发的动态翻译的示意图。每个解释器能向该编译器发出翻译请求。然后编译器造成能为解释器任务使用的翻译后代码。在一个具有多个执行单元的机器上，所有过程可以并发地执行。第二实施例详述

动态优化目标码翻译系统完成一组指令到另一组指令的动态编译，以提供高于基于模板的翻译或解释后仿真的性能改善。动态优化目标码翻译系统把任意多个解释器(它们完成对运行代码的概况记录)与一单独的优化编译器的组合。优化编译器使用来自运行代码的概况记录信息，以确定代码中大量地执行的部分。然后这些部分被编译并提供给解释器使用。系统的总体结构示于图23。

只有知道指令流程图才可能完成有意义的编译器型优化。在传统的编译器中，流程图是给定的和很好定义的，因为在优化开始之前整个例行程序被完全地分析过了。对于一个结构仿真系统，在要被编译的代码实际运行之前该代码是不能得到的。此外，如不实际运行一个程序，一般不能使指令和数据区分开。

所以，为确定流程图，该程序必须运行。一个解释器被用于第一次运行该程序。在解释器执行该程序时，每次它完成一个分支操作时便通知动态编译器。这一信息记录标识某些指令和某些结合点。随着该程序的运行，关于流程图的信息变得更加完全，尽管永远不会整个地完全。该系统被设计成以关于流程图的部分信息进行工作：优化是基于可能不完全的流程图，而且该系统被设计成允许在可得到更多信息时替换已被优化的代码。

动态编译根据解释器收集的概况记录信息选择要优化的内容部分。当某一分支的执行次数超过一阈值时，那个分支的目的地成为供编译的种子。种子是分析一部分要被编译的源指令(作为一个单元)的起始点。这一单元被称作段。

一个段含有对来自种子的源指令进行优化造成的指令。它作为一个单元被安装和去掉安装。当解释器调用该编译器的通知它有一个分支时，如果该目的地的代码存在，解释器可以选择把控制转移到该段中。类似地，该段中可以包含把控制转移回解释器的代码。

一个段可以是不完全的，只代表来自源程序的可能流程路径的一个子集。但这种不完全的代表不会干扰仿真的正确操作。如果发生了一个穿过原始代码的新的未预料的流程路径，那么控制流程将跳回解释器。然后，这同一段能被替换，以考虑这新的控制流程。第二实施例的特别目的

本发明是应用优化的目标码翻译来改进结构仿真系统中的性能。第二实施例摘要所描述的动态优化目标码翻译系统使用编译器优化技术实现比基于模板的结构仿真目标码翻译更高的性能。本发明是应用优化的目标码翻译来改进结构仿真系统中的性能。本发明第三实施例并发动态翻译第三实施例概要

动态翻译是在程序运行过程中把一种机器语言的计算机程序翻译成另一种机器语言的活动。所描述的并发动态翻译系统完成与被解释程序的执行并发的翻译。第三实施例附图描述

图24说明根据本发明第三实施例的并发动态翻译所用的系统配置。图24是与程序解释执行并发的动态翻译的示意图。每个解释器任务能向编译器任务发送翻译请求。然后编译器任务使解释器任务能得到翻译后的代码。在一个具有多个执行单元的机器上，所有过程可以并发地执行。

图25说明把解释器和编译器例如在执行过程中组合成一个任务和把它们分开成例如不同的任务二者之间的区别；这是根据本发明的第四实施例。图25是具有解释器和编译器结合任务与分离任务的延迟示意图。第三实施例详述

并发动态翻译的目的是通过在解释器仍在运行过程中把一执行中的程序编译成更有效的形式，从而提供比解释器强的性能。为了完成与解释器的执行并发的动态翻译，编译器作为一个单独任务运行在一个具有多个执行单元的系统上。该编译器是一个服务器，它接收翻译某些指令的请求并以一片翻译后代码作为回应。把编译器服务器安排成一个单独的任务有许多好处。第一，不只一个解释器任务能向同一个服务器提出请求。第二，解释器任务不必等待得到编译请求结果后再继续进行。第三，解释器和翻译器与其他任务中的故障隔离。第四，解释器和编译器能被独立地安排时间计划，从而在多个可用处理器上的工作能更均匀地平衡。下面将更详细地描述这些好处的每一个。

一些现有的动态翻译系统不具有单独的编译器任务。来自SunMicrosystem的Java虚拟机器是一个实例[2]。在此虚拟机器中的解释器能通过调用一个过程来发出动态翻译请求。在解释器继续执行程序之前，它得等待翻译请求完成。另一个实例是Fujitsu OCT动态翻译系统，它一次翻译一个指令页面[1]。在OCT系统中，解释器在继续执行之前必须等待翻译请求完成。

也还有可用的翻译服务器用于把Java源代码静态翻译成Java字节代码[3]。这些服务器提供了用于静态翻译但不是用于动态翻译的单独编译器任务的优点，因为在Java程序运行时它们不操作。

单独编译器任务安排的第一个好处是多个解释器任务能向同一服务器提出的翻译请求。它们不必在它们的可执行图像中包括编译器代码，这使它们的可执行图像小得多。它们不必高速缓存解释器指令和编译器指令之间或解释器数据和编译器数据之间的冲突。因为在几乎所有现代处理器上有效地使用高速缓存是重要的，这是一个显著的好处。

单独编译器任务的第二个好处是解释器看不见编译器的延迟。图25说明延迟的差异。应用组合的解释器和编译器任务时，在编译器已结束翻译指令之前，解释器不执行任务指令。应用单独的任务，则在编译器工作的同时解释器立即恢复执行指令。由单独任务完成的工作总量是增大了，因为它们必须发送和接收翻译请求，但较小的延迟意味着在编译器工作时系统的使用者观察不到暂停。再有，在编译器工作时解释器任务能响应外部事件，如中断，这在组合任务安排中是不可能的。在实践中，在组合安排中编译器受到编译器的延时这一事实对编译器的复杂性和翻译后代码质量是一个限制。例如，Java Just-In-Time编译器应该执行得足够快。以使与Java系统进行交互作用的使用者看不到暂停，这种情况禁止了某些复杂的优化。类似地，OCT系统只在单条翻译后指令内进行优化，以减少编译时间。单独的编译器任务允许穿过多条指令进行优化。

单独编译器任务的第三个优点是在解释器任务和编译器任务中出现的故障是彼此隔离的。这意味着如果编译器任务得到一个地址例外或其他例外状况，解释器任务不受影响。编译器在故障之后对本身复位，并继续对下一个请求工作。因为解释器不等待编译器结束一个翻译请求，所以它们并不注意编译器是否有了故障。

单独编译器任务的第四个好处是它能平衡编译器和解释器任务的负担。在动态翻译系统中，有时解释器任务很忙并需要全部计算机CPU，而有时解释器任务空闲以至CPU不被使用。在组合的解释器和编译器安排中，大多数编译工作是在解释器忙的时候做的，因为只有当解释器在运行时编译器才被调用。这没有利用空间的CPU周期。在单独的编译器任务安排中，当解释器空闲时编译器继续工作。它产生编译器将来可能使用的翻译后代码。第三实施例的特别目的

本发明第三实施例的目的是与具有多个物理执行单元的系统上执行的多个解释器并发地使用动态翻译，从而提供较小的可执行图像大小，减小的高速缓存竞争，较低的解释器执行延时，故障隔离以及更好的负担平衡。第三实施例摘要

所描述的动态翻译系统与被解释程序的执行并发地完成动态翻译。该系统使用单独的编译器，从而使它不会显著地影响解释器任务的性能。本发明与具有多个物理执行单元的系统上执行的多个解释器并发地使用动态翻译，从而提供较小的可执行图像大小，减小的高速缓存竞争，较低的解释器执行延时，故障隔离以及更好的负担平衡。本发明的第四实施例动态翻译过程中仿真以减轻对仿真器进行记录的负担第四实施例概要

结构仿真是用一个不同的计算机结构对一计算机结构的严格模仿，从而使原始结构的机器码能不经修改地运行。目标码翻译是把一种计算机结构的机器码翻译成另一种计算机结构的机器码的过程。所描述的动态优化目标码翻译系统使用编译器优化技术达到比用于结构仿真的基于模板的目标码翻译更好的性能。然而，它需要进行运行概况记录以实现动态优化目标码翻译。本描述解释一种减轻概况记录负担的方法。第四实施例附图描述

图26说明一个根据本发明第四实施例构成的翻译表，它用于记录哪些指令是可翻译的。哪些指令是不可翻译的。图26是一个翻译表，显示出哪些程序是可翻译的，哪些是不可翻译的。在这种情况中，程序以I字节为单位测量。仿真器检验一个分支后继者对应于哪个入口条目，从而确定该分支是否跳到一个可翻译的程序。

图27说明根据本发明第四实施例如何减轻仿真器上概况记录的负担。图27是一个流程图，它显示仿真器怎样对可翻译程序启动记录过程而对不可翻译的程序关掉记录过程。触发器^*1和触发器^*2指令二者都应被记录，但触发器^*1指令不可以在可翻译程序和不可翻译程序之间转跳。只有触发器^*2指令能在它们之间转跳。日志标志记住该仿真器是在一可翻译程序中运行还是在不可翻译程序中运行。所以，在触发器^*1指令中，仿真器不必检验翻译表或改变日志标志。它只是检验分支后继指令是否已被编译，并立即跳到编译后代码。因为触发器^*1指令代表最频繁执行的触发器指令，所以这一算法能减轻对仿真进行概况记录的负担。第四实施例详述

动态优化目标码翻译通过产生更快的指令而实现了高性能，但它引起存储器和时间的耗费。所以，在结构仿真时，动态优化目标码翻译和仿真二者在一起使用。翻译被用于频繁运行和需要高性能的主要程序。而仿真器为小程序工作，而且还记录主要程序直至翻译器完成编译。一个概况记录被翻译器用于编译和优化程序。

可能从未被翻译代码跳到被翻译代码的指令叫做触发器指令。如果一个触发器指令能从一个小程序跳到一个主要程序，或者能从一个主要程序跳到一个小程序，则称它为触发器^*2指令。如果它只能在一个小程序内转跳，或只能在一个主要程序内转跳，则称它为触发器^*1指令。因为翻译器不对小程序进行工作，所以不必要对主要程序中的触发器^*1指令进行记录，因为该程序的一部分可能已被翻译而另一部分尚未被翻译。有必要对小程序和主要程序中的触发器^*2指令进行记录，因为它们可能会跳到一个主要程序中。

在执行一个触发器^*2指令之后，仿真完成三个检验(见图27)。第一，它检验该翻译器是否起动。如果它已起动，它检验该触发器^*2指令的后继者是不是可翻译的。如果它是可翻译的，则由仿真器设置日志记录标志为真，并检验其后继者是否已被翻译，如果存在翻译后版本的话，则跳到该翻译后版本。

在执行一个触发器^*2指令之后，仿真只完成二个检验(见图27)。第一，它检验日志记录标志是启动还是断掉。如果该标志是断掉，则该指令是在一个小程序中，而且它不需要被记录，如果该标志是启动，则仿真检验它的后的继者是否被翻译。

主要程序和小程序是由它们的存储器地址区分的(见图26)。仿真器使用一个翻译表来记录可翻译和不可翻译程序地址的关系。对于触发器^*1指令，它们从不在可翻译程序和不可翻译程序之间运动，仿真器不必访问翻译表，因为日志记录标志已经包含了那个信息。

通过把对于触发器^*1和触发器^*2指令的仿真器行为分解成两种方法，使对仿真进行概况记录的负担被减轻了。第四实施例的特别目的

本发明第四实施例的目的是实现减轻仿真器上概况记录负担的方法，其作法是：在能跳进或跳出可翻译指令的触发器指令之后放置代码以检验该分支后继者是否是可翻译的，以及在所有其他触发器之后放置代码只检验一个标志，看其是否是可翻译的。第四实施例摘要

把动态目标码翻译与仿真一起使用是有效的，但记录指令概况以指导翻译器的费用是加在仿真上的一个负担。通过区分被记录指令的不同类型，有可能减轻这种负担。本发明是减轻仿真器上概况记录负担的方法，其作法是：在能跳进或跳出可翻译指令的触发器指令之后放置代码以检验该分支后继者是否是可翻译的，以及在所有其他触发器之后放置代码只检验一个标志，看其是否是可翻译的。本发明第五实施例动态翻译的软件反馈第五实施例概要

动态翻译是在程序运行过程中把一种机器语言的计算机程序翻译成另一种机器语言的活动。在一些动态翻译系统中，运行该程序的任务(称作解释器)与翻译该程序的任务(称作编译器)是分开的。解释器向编译器发送请求的速率应与编译器完成请求的速率匹配。还有解释器发送请求的速率不应降到零。软件反馈提供了使这两种速率趋于相等的途径。第五实施例附图描述

图28是根据本发明第五实施例构成的带有单独解释器和编译器的动态翻译系统的总体结构图。图28是一个动态翻译系统的结构图。解释器向编译器发送翻译请求。编译器发送回翻译后代码作为响应。请求和响应的速率应用相等以使该系统运行得最有效。

图29说明根据本发明第五实施例的软件反馈机制的组成部分。图29是说明一软件反馈系统组成部分的示意图。比较过程从请求数中减去完成数。请求速率过程根据这一差值设定其速率。请求发送过程根据当前速率发送请求。第五实施例详述

在一动态翻译系统中，解释器任务向编译器任务发送请求。这请求包括要告知编译器的信息，即程序的哪部分要翻译。编译器翻译该部分并以翻译后代码作为响应。决定何时发送请求的问题是调度问题的一个实例。解释器任务做出请求的速率应与编译器完成请求的速率匹配。所以编译器将不会空闲或因请求而超载。

软件以馈是使两组事件速率相等的一种方法[1]。在动态翻译系统中，它改变翻译请求的速率使其等于完成翻译的速率。如图29所示，软件反馈系统有三个主要部分。第一部分是一个过程，用于比较翻译请求次数和完成翻译次数。第二部分是一个过程，用于根据比较结果去改变翻译请求速率。第三部分是一个过程，用于根据第二过程的输出做出翻译请求。

在动态翻译系统中，解释器任务对一分支指令跳到一特定目的地地址的频繁程度进行计数。当这一计数超过一阈值时，解释器发送一个包含这目的地地址的请求。这个阈值是由软件反馈机制设定的关键性参数。当这阈值低于大多数执行计数时，翻译请求速率是高的。当这阈值高于大多数执行计数时，这请求速率是低的。因为执行计数的典型大小是随被解释的程序而变的，所以软件反馈是设定阈值的理想方式，因为它自动地适应于解释器的行为。

在动态翻译系统中，软件反馈的比较过程是很简单的。它只是计算发送给编译器的翻译请求的次数与完成的翻译次数之差。

请求速率过程根据比较过程计算出的差值改变阈值。如果差值为零，则阈值太高，于是它阻止解释器发送翻译请求。在那种情况中，请求速率过程从阈值中减去一个常数。如果差值是它的最大可能值，则阈值太低，解释器发送太多翻译请求。在那种情况中，请求速率过程向阈值加一个常数。

请求发送过程是在解释器执行一分支指令时被调用的。如果该分支指令已跳到同一目的地地址的次数多于阈值，则解释器发送一个包括该目的地地址的翻译请求。第五实施例的特别目的

本发明是在具有单独解释器任务和编译器任务的动态翻译系统中使用一种软件反馈机制，以使解释器发送翻译请求的速率等于编译器完成翻译的速率，不允许编译器变成空闲的。

使用最小阈值以允许编译器关闭。第五实施例摘要

在一个具有单独的解释器任务和编译器任务的动态翻译系统中，解释器发送请求的速率应与编译器完成这些请求的速率相匹配。还有，解释器发送请求的速率不应降至零。本发明在具有单独的解释器任务和编译器任务的动态翻译系统中使用一种软件反馈机制，以使解释器发送翻译请求的速率等于编译器完成翻译的速率，不允许编译器变成空闲的。本发明第六实施例动态翻译请求排队第六实施例概要

动态翻译是在程序运行过程中把一种机器语言的计算机程序翻译成另一种机器语言的活动。对于每片被翻译的程序，该系统做成向动态翻译器的一个请求。当动态翻译器忙时造成的请求被排队并在翻译器变为空闲时发出。排队的实现把系统调用与共享存储器通信组合起来，以减小它。第六实施例附图描述

图30说明根据本发明第六实施例如何在翻译任务忙时使用一个队列来容纳翻译请求。

图31说明根据本发明第六实施例OOCT请求队列如何把便宜的共享存储器请求与系统调用请求组合起来。第六实施例详述

如图30所示，请求队列的基本功能是记忆动态翻译器忙时做出的请求。在任何动态翻译系统中，都有一个能同时发生的翻译次数的上限。通常这个限度是一个时候只有一个翻译。然而，对于造成的请求总数或造成请求的速率，却没有限制。所以很有可能当翻译器已经忙时又发生一个翻译请求。利用请求队列，翻译请求被放入一个队列，于是不需要重复该请求。当翻译器把该请求从队列中取出时，它将完成翻译。

在OOCT中，动态翻译系统有多重任务，一个是处置请求的动态翻译任务，其他是造成翻译请求的执行任务。如图31所示，OOCT的队列实现使用不昂贵的共享存储器与系统调用消息结合，构成请求队列，从而在一个朴素的队列上得到改善。单是系统调用便足以把种子从执行任务传送到翻译任务，并在没有待决请求时允许翻译任务变为空闲或锁住。然而，系统调用是昂贵的操作。共享存储器能被用于把请求消息从执行任务传送到翻译任务，但翻译任务不能锁住那些消息，所以它得要连续地运行以从简单的共享存储器队列中接收消息。

OOCT实现使用系统调用和共享存储器这两种机制每个所具有的最好特性。它允许翻译任务锁住以等待系统调用消息，但当翻译任务已经在工作时，则通过共享存储器传送请求。

如图31所示，OOCT请求队列在执行任务和翻译任务之间使用两类消息，加上由这两种任务访问的共享存储器缓冲器。第一类消息从翻译任务去到执行任务。它告诉执行任务使用系统调用去发送下一个请求。这一消息通知执行任务：翻译任务已使共享存储器缓冲器变空并且即将要锁住。然后执行任务以系统调用发送请求。翻译任务接收这消息并开始翻译。在以系统调用发送一个请求之后，执行任务知道翻译任务在忙，于是它直接向共享存储器缓冲器发送更多的请求。这比使用另一个系统调用要便宜得多。当翻译任务结束一个请求时，它查看共享存储器缓冲器。如果在缓冲器中有一个请求，则它被移走并被翻译。当共享存储器缓冲器空时，翻译任务再次告诉执行任务去使用系统调用。

OOCT请求队列的好处是当执行任务以高速率发送请求时，它们能使用共享存储器缓冲器，而当请求以低速率到来时，翻译任务能锁住。第六实施例的特别目的

本权利要求是日文的富士通(Fujitsu)专利的译文，加了一个条款。

本发明是当通过向翻译任务发送一个消息从而开始翻译被分支频繁转到的指令时使解释工作能继续进行的一种方法，也是当翻译已在进行之中时使发给翻译任务的消息排成队列的方法；本发明由使用系统调用和共享存储器两种机制发送翻译请求消息改善了性能。第六实施例摘要

所描述的翻译请求队列是另一个翻译在执行时收集翻译请求的一种机制。它允许执行任务在发送一个请求之后立即继续运行。通过一起使用共享存储器和系统调用，使得有可能改善翻译队列的有效性。本发明是当通过向翻译任务发送一个消息从而开始翻译被分支频繁转到的指令时使解释工作能继续进行的一种方法，也是当翻译已在进行之中时使发给翻译任务的消息排成队列的方法；本发明由使用系统调用和共享存储器两种机制发送翻译请求消息改善了性能。本发明第七实施例动态翻译的页面错恢复第七实施例概要

动态翻译是在程序运行过程中把一种机器语言的计算机程序翻译成另一种机器语言的活动。动态翻译器在把源机器指令翻译成目标机器指令之前必须先读出这些源机器指令。在读这些源指令过程中，翻译器由于从页面外存储器中读出能造成页面错，但在存储器内分页是效率低的。所描述的翻译器能从页面错中恢复而无需读页面外数据并继续进行翻译。第七实施例附图描述

图32显示根据本发明第七实施例一个动态翻译器如何能引起页面错，而这些页面错在正常执行源指令时本不会发生的。

图33显示根据本发明的第七实施例，在翻译过程中从页面错中恢复并继续翻译的算法。第七实施例详述

动态翻译器很可能访问一些页面，而这些页面是用于复制到物理存储器中的坏候选者，因为它读出了一条指令的所有可能的后继者，而不只是实际要被执行的后继者。例如，如图32中所示，条件分支指令有两个后继者，即分支归于失败的后继者和分支被采取时的后继者。当CPU执行一条件分支指令时，如果该分支未被采取，则分支被采取时的后继者决不会被加载。所以它将不会引起页面错。当动态翻译器读这个分支指令时，它试图读出分支归于失败的后继者和分支被采取时的后继者这两个后继者，不知道哪个将被实际执行。读分支后继者可能引起页面错，即使该后继者将永不会被执行。

处置页面错的通常方法是分页到请求的存储器中和在软件中完成存储器访问，然后允许在出错指令之后继续执行。这一方法有两种消耗，第一，把一页从物理存储器移到后备存储，再把另一页从后备存储移到物理存储器，然后完成存储器访问，这些是费时间的。第二，它改变了被分页进来的存储器页面集合。被复制到物理存储器中的页面可能在它再次被分页出去之前并未被频繁访问，这就表明把它复制到物理存储器中不是一个好的想法。

由于动态翻译器能造成更频繁的页面错，所以降低那些页面错的费用是有利的。动态翻译器通过不把新页复制到物理存储器和不把已在物理存储器中的页面驱逐出去的办法使额外页面错的费用减至最小。这节省了复制时间并且还保证不经常被访问的页面不被复制进去。不去复制该页，代之以由页面错处理器中断翻译器中的当前指令流，并把控制返回到由翻译器指定的检验点。

翻译器以基本块为单元读源指令。如果在读一个基本块时发生了页面错，则翻译器忽略那个块但继续翻译任何其他块。在所有基本块读完之后，它们被翻译成一组目标指令。忽略引起页面错的基本块的方法示于图33。在读一个基本块之前，翻译器做成一个检验点。在此检验点之前被读出的所有基本块是安全的，不会受到该检验点之后发生的任何页面错的影响。然后翻译器试读下一个基本块。如果有一个页面错，它便立即跳到该检验点。这使它跳过该基本块并试读下一个基本块。第七实施例的特别目的

根据第七实施例的发明是降低动态翻译的存储器访问费用的一种途径，其作法是当一存储器访问失败时不把页面复制到物理存储器中但仍然允许继续进行翻译。第七实施例摘要

所描述的页面错恢复机制是当访问非物理映射存储器时降低动态翻译费用的一种途径。它允许动态翻译即使在由于页面错而不能读出全部源机器指令时也继续工作。本发明是降低动态翻译的存储器访问费用的一种途径，其作法是当一存储器访问失败时不把页面复制到物理存储器中但仍然允许继续进行翻译。本发明第八实施例为动态翻译记录从翻译后代码的退出第八实施例概要

动态翻译是在程序运行过程中把一种机器语言的计算机程序翻译成另一种机器语言的活动。动态翻译器通过在指令执行过程中概要记录它们来选择要翻译的指令。频繁执行的指令被翻译，而不频繁执行的指令则不被翻译。翻译后的指令能使概要记录器丢掉一些指令，这可能会使频繁执行的指令要被解释。通过记录从翻译后代码的具体退出情况，有可能概要记录全部频繁执行的指令和保证它们全都被翻译。第八实施例附图描述

图34说明根据本发明第八实施例构成的带有分支概要记录器的动态翻译系统中的控制流程模式。第八实施例详述

如在报告动态翻译用分支记录器中描述的那样，动态翻译系统在原始程序的分支指令被解释的过程中概要记录它们，以确定哪些指令是频繁执行的，哪些指令不是。分支记录器只概要记录分支指令，并依据这样一个假定，即所有频繁执行的指令都是通过频繁执行的分支来达到的。在一些情况中，动态翻译器本身使这一假定不成立，因为控制将从翻译后代码流回被解释的指令而不去执行一个被概要记录的分支。翻译器能识别那些情况，而且它创建特殊的翻译后指令，这些指令概要记录这个控制流，就如同这个控制流是一个分支。

图34说明控制流如何从被解释指令到翻译后的指令以及又如何回去。每当控制从翻译后指令中退出时，翻译器要确保该退出被概要记录下来，就如同它是一个分支指令。有几种情况中控制流是从翻译后指令到被解释指令。

第一，存在到非固定目的地的分支。翻译器不知道在此分支之后将执行哪条指令，所以它不能把那条指令作为分支结合到这同一翻译单元中。它代之以创建一个从翻译后指令回到被解释代码的退出。

第二，由于翻译过程中的页面错，存在不能被读出的指令。如在报告‘动态翻译的页面错恢复’中描述的那样，翻译器忽略因页面错而不能读出的指令块。所以当翻译后的程序达到那些块时不得不跳回被解释的指令。

第三，当进行翻译时，某些指令被频繁地执行。如在报告‘动态翻译的块检出阈值’中描述的那样，它们没有因为曾经频繁执行而被翻译。但它们在将来可能变为频繁执行的，所以翻译器必须记录退出到那些指令的情况。这一特性使动态翻译系统能适应于改变执行模式，这些模式改变频繁执行的指令的分布。

因为从翻译后代码的退出被记录下来，所以有更多的指令被翻译。这增加了一条指令的翻译后版本存在的机会。所以，在长时间运行这动态翻译系统之后，大多数从翻译后单元的退出会造成转跳到另一个翻译后单元，而不是跳回到被解释的代码。这从更经常地使用较快的翻译后指令当中得到直接益处，而从不那么经常地执行分支记录指令中得到间接益处。第八实施例的特别目的

本发明的第八实施例的目的是提供一种方法，通过概要记录翻译后指令单元的可能退出情况确保频繁执行的指令被翻译，即使通过任何被记录的分支都不能达到它们。第八实施例摘要

一个动态翻译系统必须找到和翻译所有频繁执行的指令，这可由概要记录分支指令来实现。但翻译指令的过程会造成到达那些不包括被记录分支的指令。所以，概要记录被扩展到包括从翻译后指令的退出。本发明是一种方法，通过概要记录翻译后指令单元的可能退出情况确保频繁执行的指令被翻译，即使通过任何被记录的分支都不能达到它们。本发明第九实施例动态翻译的块检出阈值第九实施例概要

动态翻译是在程序运行过程中把一种机器语言的计算机程序翻译成另一种机器语言的活动。动态翻译器应翻译源程序中所有频繁执行的部分而忽略所有不频繁执行的部分。为实现这一点，翻译系统概要记录分支指令，并且不去翻译那些执行概率低于指定阈值的指令。第九实施例附图描述

图35说明根据本发明第九实施例该动态翻译器如何使用概要记录信息去计算一个基本块的执行概率。第九实施例详述

一个动态翻译器的目的是通过把一计算机程序由其原始的源语言指令翻译成更有效的目标语言指令从而该计算机程序的总体执行速度。动态翻译的益处是通过把执行原始程序的总时间与翻译该程序所需时间加上执行翻译后程序的时间进行比较来度量的。翻译程序中任何部分所需时间近似为常数，所以翻译一部分所获得的益处主要决定于使用那一部分的次数。被频繁执行的指令是值得翻译的，但不被频繁执行的指令则不值得翻译。

为了测量不同指令的频度，动态翻译系统可概要记录分支指令。利用这个概要记录信息，它能检出一个被频繁执行的指令并在那一点处开始翻译。在初始指令之后，翻译器尽可能多地读出被频繁执行的后继指令而不去读不频繁的后继者。块检出阈值被用于确定一个后继者是被频繁执行的还是不被频繁执行的。

动态翻译器按称作基本块的单元读出指令。在一个基本块中，所有指令被执行相同次数，所以它们或者全是被频繁执行的，或者全是不被频繁执行的。

动态翻译器使用来自分支指令的概要记录信息以确定一个基本块是被频繁执行的还是不被频繁执行的。这一过程示于图35。翻译器计算从第一条被翻译指令到一给定基本块的执行路径被采取的概率。给第一基本块的执行概率是100％，因为它包含该第一条指令。如果当前块只有一个后继者，那么该后继者的执行概率与当前块的执行概率相同。如果当前块结束于一个条件分支，则根据分支概要记录信息将当前块的概率在这两个后继者之间分配。例如，如果当前块的执行概率是50％，它结束于一个分支指令，该分支指令被执行了40次，其中被采取了10次，于是被采取分支后继者的概率为(50％×25％＝12.5％)，而分支归于失败的后继者的概率是(50％×75％＝37.5％)。

使用了一个称作块检取阈值的可变阈值，用于选择被频繁执行的块。如果一块的执行概率大于或等于该阈值，则认为那一块是被频繁执行的，于是将其翻译。如果执行概率低于该阈值，则认为该块是不被频繁执行的，于是不翻译它。

这种块检出方法的一个重要性质是被检出的一组块是连接的。有一些更复杂的方式去计算执行概率，例如把所有先行指令的概率相加。但这会导致不连接的块组。翻译不连接的块组是可能的，但是，如果块组是连接的，则有更多的机会去优化翻译后的代码。第九实施例的特别目的

本发明第九实施例的目的是提供一种改善动态翻译效率的方法，其作法是使用一个阈值执行概率把被频率执行的指令块与不被频繁执行的指令块区分开，从而选择被频繁执行的指令块供翻译和忽略不被频繁执行的指令块。第九实施例摘要

一个动态翻译系统的耗费正比于被翻译指令数，而其益处正比于翻译后指令的被执行次数。所以最有效的作法是只翻译被频繁执行的指令而忽略不被频繁执行的指令。本发明是改善动态翻译效率的一种方法，其作法是使用一个阈值执行概率把频繁执行的指令块与不被频繁执行的指令块区分开，从而选择被频率执行的指令块供翻译和忽略不被频繁执行的指令块。

虽然已经图示和描述了本发明的一些最佳实施例，但本领域的技术人员应该理解，在这些实施例中可以做出改变而不离开本发明的原理和精神，本发明的范围在权利要求及其等效物中规定。

Claims (34)

1.在目的计算机结构上仿真源计算机结构的一个计算机结构仿真系统，包括：

解释器，用于把源目标码单个地翻译成相应的翻译后目标码并确定在源目标码中分支指令的执行次数；以及

编译器，用于当一相应的分支指令执行次数超过一阈值数时把源目标码指令组合成段并动态地编译该段。

2.根据权利要求1的计算机结构仿真系统，这里对应于未被编译段的分支指令存储在存储器中。

3.根据权利要求2的计算机结构仿真系统，这里尚未超过阈值数的分支指令所对应的段不被编译。

4.根据权利要求1的计算机结构仿真系统，这里在所述解释器执行翻译后目标码指令过程中，对应于未被编译的分支指令的段被存储在存储器中。

5.根据权利要求1的计算机结构仿真系统，这里所述解释器和所述编译器是同时在一多任务操作系统中实时运行的任务。

6.根据权利要求1的计算机结构仿真系统，进一步包括：

分支记录器，用于存储由所述解释器确定的分支指令分支概要分析信息。

7.根据权利要求6的计算机结构仿真系统，这里所述分支概要分析信息包括分支地址、分支后继者、不分支后继者、分支执行计数和分支被采取计数，而且

所述分支概要分析信息是在分支指令仿真过程中由所述解释器记录。

8.根据权利要求1的计算机结构仿真系统，其中：

在执行跳入或跳出可翻译指令的分支指令之后放置代码标志；以及

通过参考相应代码标志来检验对应于分支指令的后继指令是否可被翻译。

9.根据权利要求1的计算机结构仿真系统，其中：

在分支指令的一后继指令执行次数超过一相应阈值时启动翻译该分支指令。

10.根据权利要求1的计算机结构仿真系统，其中：

在所述解释器继续仿真源代码的同时，在所述解释器和所述编译器之间进行通信，通过这种通信启动对频繁被分支的指令所对应段进行翻译。

11.根据权利要求1的计算机结构仿真系统，其中：

当存储要被翻译段的队列达到一预先确定的容量时，通过提高阈值数来控制要被编译段的编译速率。

12.根据权利要求1的计算机结构仿真系统，这里所述编译器在按顺序追踪存储器中每条指令时，使用对应于编译起点地址的概要分析信息建立一个优化的目标。

13.根据权利要求12的计算机结构仿真系统，这里在检测到页面错时所述编译器不去编译该块，而是当一块引起页面错时，所述编译器在所述分支记录器中产生一个记录分支信息的目标。

14.根据权利要求13的计算机结构仿真系统，这里如果一个指令执行过程没能以预先确定的速率及时地执行，则所述编译器利用概要分析信息追踪其执行情况，检验分支计数是否在一预先确定数之下，并产生记录分支信息的一个目标。

15.根据权利要求1的计算机结构仿真系统，进一步包括：

分支记录器，用于存储源目标码中分支指令的概要分析信息，其中包括执行次数，这里所述分支记录器包括一个存储被频繁执行的分支指令概要分析信息的高速缓存和一个存储不被频繁执行的分支指令概要分析信息的分支日志。

16.根据权利要求15的计算机结构仿真系统，这里通过使分支地址信息和分支目的地信息组合，来把概要分析信息组织在高速缓存中。

17.根据权利要求16的计算机结构仿真系统，这里组织在高速缓存中的概要分析信息存储在多个组中，每个组是按照进入各组的概要分析信息的入口条目递减顺序来组织的。

18.根据权利要求1的计算机结构仿真系统，这里每个分支指令是一个种子，所述编译器进一步包括：

块检出器，它根据该种子和该分支的概要分析信息来选择要被编译的源目标码段，

块布局单元，它把该段展平为指令的线性列表，以及

优化码产生单元，它完成从原始指令到翻译后代码段指令的实际编译。

19.根据权利要求18的计算机结构仿真系统，这里块检出器创建一个描述要编译的原始指令的控制流程图，并把该控制流程图传递给块布局单元。

20.在目的计算机结构上仿真源计算机结构的一个计算机结构仿真系统，包括：

多个解释器，用于把源目标码单个地翻译成相应的翻译后目标码，这里所述多个解释器中的每一个在执行翻译后目标码指令的同时，实时地概要分析源目标码分支信息；以及

编译器，用于根据相应的目标码中的分支指令，把来自所述多个解释器中任何一个的源目标码指令组合成段，并在相应的分支指令大于一阈值数时动态地编译该源目标码段。

21.根据权利要求20的计算机结构仿真系统，这里所述多个解释器的每一个概要分析分支指令，并通过调用一分支记录器来存储尚未超过阈值数的分支指令。

22.在目的计算机结构上仿真源计算机结构的一个计算机结构仿真系统，包括：

解释器，用于把源目标码单个地翻译成相应的翻译后目标码，这里解释器通过存储每个分支指令的执行次数并把这执行次数与一阈值数加以比较来概要分析源目标码的分支指令，这样，超过阈值数的分支指令便指定为种子；以及

编译器，用于根据种子把源目标码指令组成段，并在所述解释器翻译和概要分析过程中动态编译源目标码段。

23.根据权利要求22的计算机结构仿真系统，这里

每个段包含根据相应的种子优化源目标码所产生的指令，以及

每个段作为一个单元被安装和去掉安装。

24.根据权利要求23的计算机结构仿真系统，这里与尚未超过阈值数的分支指令相对应的那些段不被编译，而与不被编译的那些段相对应的分支指令被存储在存储器中。

25.根据权利要求23的计算机结构仿真系统，进一步包括：

分支记录器，用于存储由所述解释器确定的分支指令的分支概要分析信息，这里分支概要分析信息包括分支地址、分支后继者、不分支后继者、分支执行计数和分支被采取计数，分支概要分析信息是在分支指令仿真过程中由所述解释器记录的。

26.根据权利要求23的计算机结构仿真系统，其中：

在执行跳入或跳出可翻译指令的分支指令之后放置代码标志的；以及

通过参考相应代码标志来检验对应于分支指令的后继指令是否可被翻译。

27.根据权利要求23的计算机结构仿真系统，其中：

在分支指令的一后继指令执行次数超过一阈值时启动翻译该分支指令。

28.根据权利要求23的计算机结构仿真系统，其中：

当存储要被翻译段的队列达到一预先确定的容量时，通过提高阈值数来控制要被编译段的编译速率。

29.根据权利要求23的计算机结构仿真系统，这里如果一个指令执行过程没能以预先确定的速率及时地执行，则所述编译器利用概要记录追踪其执行情况，检验分支计数是否在一预先确定数之下，并如页面错那样产生记录分支信息的一个目标。

30.根据权利要求23的计算机结构仿真系统，进一步包括：

分支记录装置，用于存储源目标码中分支指令的概要分析信息，其中包括执行次数，这里所述分支记录装置包括一个存储被频繁执行的分支指令的概要分析信息的高速缓存和一个存储不被频繁执行的分支指令的概要分析信息的分支日志。

这里通过使分支地址信息和分支目的地信息组合，来把概要分析信息组织在高速缓存中，而概要分析信息是按进入各组的入口条目递减顺序存储在多个组中的。

31.根据权利要求23的计算机结构仿真系统，这里所述编译器进一步包括：

块检出器，它根据该种子和该分支的概要分析信息来选择要编译的源目标码段，这里块检出器创建一个控制流程图描述要编译的源始指令；

块布局单元，它把控制流程图展平为指令的线性列表；以及

优化代码产生单元，它完成从原始指令到翻译后代码段指令的实际编译。

32.在多任务目的计算机结构上仿真源计算机结构的一个多任务计算机结构的仿真系统，包括：

解释器任务，把源目标码单个地翻译成相应的翻译后目标码并确定在源目标码中分支指令的执行次数；以及

编译器任务，和所解释器任务在多任务目的计算机结构上运行用于用于当一相应的分支指令执行次数超过一阈值数时把源目标码指令组合成段并动态地编译该段。

33.根据权利要求32的多任务计算机结构仿真系统，这里所述多任务计算机结构仿真系统是一个动态翻译系统，所述多任务计算机结构系统进一步包括：

软件反馈，用于使所述解释器任务发送编译请求的速率与所述编译器任务完成编译的速率相等，通过改变阈值数来不允许编译器任务变为空闲。

34.根据权利要求33的多任务计算机结构仿真系统，进一步包括：

存储要被所述编译器任务编译的段的队列，这里将阈值数与一最小阈值数进行比较，以启动或关闭所述编译器任务。

Images