CN103140828A - 基于硬件限制利用可调事务尺寸来动态优化代码的装置、方法和系统 - Google Patents

Abstract

在本发明中描述了用于条件提交和/或推测设定事务的检查点的装置和方法，这可潜在地导致事务的动态尺寸调整。在二进制代码的动态优化期间，事务被插入以提供存储排序保护，这使得动态优化器能更激进地优化代码。并且条件提交实现动态优化代码的更高效执行，同时试图防止事务用尽硬件资源。同时推测检查点实现在事务中止后的快速且高效的恢复。处理器硬件适合于执行事务的动态尺寸调整，诸如包括识别条件提交指令、推测检查点指令或两者的解码器。并且处理器硬件还适合于响应于解码器这种指令执行用于支持条件提交或推测设定检查点的操作。

Description

基于硬件限制利用可调事务尺寸来动态优化代码的装置、方法和系统

技术领域

本发明涉及处理器领域，尤其涉及处理器上的代码优化和执行。

背景技术

半导体处理和逻辑设计领域的进步已经允许集成电路器件上可存在的逻辑量增加。以前，在单线程处理器上，曾允许诸如二进制代码之类的代码的优化过度主动，因为不害怕被其它执行线程影响。然而，计算机系统配置已经从系统中的单个或多个集成电路发展到存在于各集成电路上的多个核、多个硬件线程以及多个逻辑处理器。处理器或集成电路通常包括单个物理处理器管芯，其中处理器管芯可包括任意数量的核、硬件线程或逻辑处理器。集成电路上处理元件（核、硬件线程和逻辑处理器）数量的不断增加使得能够并行完成更多任务。这种从单线程处理器向更多并行的多线程执行的发展已经导致对代码优化的限制。

伪代码A:单线程代码优化的实施例

例如，伪代码A示出二进制代码的优化，其中来自[r2]和[r2+4]处的存储器的加载通过部分冗余加载消除（PRLE）优化从循环提升到头部块（B3）。并且通过部分死存储消除（PDSE）优化，将对[r2+4]处的存储器的存储从循环下沉到尾部块（B4）。这种优化可工作在单线程环境。然而，在多线程应用中，其它线程在循环执行期间可向[r2]或[r2+4]处的存储器写入/从其读取，由于存储器操作的执行循序的变化，这可能导致无效执行。

附图说明

本发明通过示例进行说明，而且不旨在受限于附图的各图。

图1示出适合于支持原子区的原子执行和动态尺寸调整的多处理元件处理器的逻辑表示的实施例。

图2a示出优化代码的方法的流程图的实施例，包括基于硬件资源限制提供事务的动态尺寸调整。

图2b示出用于插入条件提交代码（conditional commit code）的图2a的流程图的实施例。

图3a示出用于在执行期间动态调整事务尺寸的方法的流程图的实施例。

图3b示出图3a的流程图的实施例，用于确定在条件提交点处是否存在足够的硬件资源以继续执行。

图4示出适合于支持事务的动态尺寸调整的硬件的逻辑表示的实施例。

图5示出适合于支持事务的动态尺寸调整的硬件的逻辑表示的另一个实施例。

图6示出适合于支持事务的动态尺寸调整的硬件的逻辑表示的另一个实施例。

图7a示出用于优化代码的方法的流程图的实施例，包括提供事务内的推测检查点。

图7b示出用于插入推测检查点代码的图7a的流程图的实施例。

图8示出用于在事务执行期间推测地设定存储器的检查点的方法的流程图的实施例。

图9示出适合于支持设定存储器的推测检查点的硬件的逻辑表示的实施例。

图10示出适合于支持设定寄存器文件的推测检查点的硬件的逻辑表示的另一个实施例。

图11示出适合于支持设定高速缓存存储器的推测检查点的硬件的逻辑表示的另一实施例。

具体实施方式

在以下描述中，陈述了诸如特定类型的处理器核、特定处理器配置、特定指令类型、特定硬件结构、特定代码优化技术等的多个特定细节以提供对本发明的透彻理解。然而对本领域普通技术人员显而易见的是，不一定要采用这些特定细节来实施本发明。在其它实例中，未详细描述公知的组件或方法，诸如特定或替代的处理器体系结构、用于所描述算法的特定逻辑电路/代码、特定代码实现方式、特定编译器细节以及微处理器的其它特定操作细节，以避免不必要地遮蔽本发明。

本文描述的方法和装置用于基于硬件约束利用动态调整尺寸的事务来优化代码。具体地，关于利用硬件约束推测设定事务的检查点和/或事务的条件提交，来讨论代码优化。然而，本文中描述的装置和方法不限于此，因为它们可按照动态调整尺寸的事务的任何形式来实现。例如，可静态地或动态地以及在硬件、软件或其组合内执行代码优化。

参考图1，示出了包括多个核的处理器的实施例。处理器100包括任何处理器，诸如微处理器、嵌入式处理器、数字信号处理器（DSP）、网络处理器或用于执行代码的其它装置。在一个实施例中，处理器100包括至少两个核——核101和102，它们可包括非对称核或对称核（所示实施例）。然而，处理器100可包括可以是对称的或非对称的任何数量的处理元件。

在一个实施例中，处理元件指的是线程单元、线程槽、处理单元、上下文、逻辑处理器、硬件线程、核和/或任何其它元件，这些元件能够保持处理器的诸如执行状态或体系结构状态之类的状态。换言之，在一个实施例中，处理元件指的是能够独立地与代码（诸如软件线程、操作系统、应用或其它代码）相关联的任何硬件。典型地，物理处理器指的是集成电路，该集成电路潜在地包括任何数量的其它处理元件（诸如核或硬件线程）。

核通常指的是位于集成电路上的能够维持独立体系结构状态的逻辑，其中每个独立维持的体系结构状态与至少一些专用的执行资源相关联。与核相比，硬件线程典型地表示位于集成电路上的能够维持独立体系结构状态的任何逻辑，其中被独立维持的体系结构状态共享对执行资源的访问。如可以看到，当某些资源被共享而其它资源专属于一体系结构状态时，硬件线程与核的命名之间的界限交迭。不过，核和硬件线程通常被操作系统视为单独的逻辑处理器，其中操作系统能够单独地调度每个逻辑处理器上的操作。

如图1所示的物理处理器100包括两个核，即核101和102。在此，核101和102被视为对称核，即这些核具有相同的配置、功能单元和/或逻辑。在另一个实施例中，核101包括无序处理器核，而核102包括有序处理器核。然而，核101和102可从任何类型的核中单独地选择，诸如原生核、受软件管理核、适于执行原生指令集体系结构（ISA）的核、适于执行转换指令集体系结构（ISA）的核、协同设计的核或其它已知核。不过，为进一步讨论，以下将进一步详细描述在核101中示出的功能单元，因为核102中的单元以类似方式操作。

如所描绘，核101包括两个硬件线程101a和101b，两个硬件线程101a和101b也可称为硬件线程槽101a和101b。因此，在一个实施例中，诸如操作系统之类的软件实体潜在地将处理器100视为四个独立的处理器，即能够并发地执行四个软件线程的四个逻辑处理器或处理元件。此外，第一线程与体系结构状态寄存器101a相关联，第二线程与体系结构状态寄存器101b相关联，第三线程可与体系结构状态寄存器102a相关联，并且第四线程可与体系结构状态寄存器102b相关联。如图所示，体系结构状态寄存器101a在体系结构状态寄存器101b中被复制，因此能够针对逻辑处理器101a和逻辑处理器101b存储单独的体系结构状态/上下文。在核101中，也可复制用于线程101a和101b的其它较小资源，诸如指令指针和重命名分配器逻辑130中的余下逻辑。诸如重排序器/隐退单元135中的重排序缓冲器、ILTB120、载入/存储缓冲器、以及队列之类的一些资源可通过分区来共享。诸如通用内部寄存器、页表基本寄存器、低级数据缓存、数据TLB115、执行单元140、以及无序单元135的部分之类的其它资源潜在地被完全共享。

处理器100通常包括其它资源，其它资源可被完全共享、通过分区被共享、或由处理元件专用/专属于处理元件。在图1中，示出了具有处理器的说明性的逻辑单元/资源的纯示例性处理器的实施例。注意，处理器可包括或省去这些功能单元中的任意功能单元，且可包括未描绘的任何其它已知的功能单元、逻辑或固件。如图所示，核101包括简化的、代表性的无序（OOO）处理器核。OOO核包括用于预测要被执行/进行的分支的分支目标缓冲器120以及用于存储指令的地址转换条目的指令转换缓冲器（I-TLB）120。

核101进一步包括耦合至取出单元120以用于解码所取出的元素的解码模块125。在一个实施例中，取出逻辑包括分别与线程槽101a、101b相关联的单独定序器。通常，核101与第一指令集体系结构（ISA）相关联，该第一指令集体系结构（ISA）定义/指定能在处理器100上执行的指令。在此，通常作为第一ISA一部分的机器码指令包括该指令的一部分（称为操作码），该指令引用/指定待执行的指令或操作。解码逻辑125包括由这些指令的操作码来识别这些指令并在流水线上传递所解码的指令以进行如第一ISA所定义的处理的电路系统。例如，在一个实施例中，如以下将更详细讨论的，解码器125包括被设计成或适于识别诸如条件提交指令和/或推测检查点指令之类的特定的新指令的逻辑。作为解码器125识别的结果，体系结构或核101采取特定的、预定的动作以执行与适当指令相关联的任务。

在一个示例中，分配器和重命名器块130包括分配器，分配器用于保留资源（诸如用于存储指令处理结果的寄存器文件）。然而，线程101a和101b潜在地能够无序执行，其中分配器和重命名块130还保留其它资源（诸如用于跟踪指令结果的重排序缓冲器）。单元130还可包括寄存器重命名器，用于将程序/指令引用寄存器重命名为处理器100内部的其它寄存器。重排序/隐退单元135包括诸如上述的重排序缓冲器、加载缓冲器和存储缓冲器之类的组件，用于支持无序执行的指令的无序执行和稍后的有序隐退。

在一个实施例中，调度器和执行单元块140包括调度器单元，用于调度执行单元上的指令/操作。例如，在具有可用浮点执行单元的执行单元的端口上调度浮点指令。也可包括与上述执行单元相关联的寄存器文件，以存储信息指令处理结果。示例性的执行单元包括：浮点执行单元、整数执行单元、跳跃执行单元、加载执行单元、存储执行单元以及其它已知的执行单元。

较低级的数据高速缓存和数据转换缓冲器（D-TLB）150耦合至执行单元140。数据高速缓存用于存储最近使用/操作的元素（诸如数据操作数），这些元素在存储器一致性状态下潜在地被保持。D-TLB用于存储最近的虚拟到物理地址转换/线性到物理地址转换。作为特定示例，处理器可包括页表结构，用于将物理存储器分割成多个虚拟页。

在此，核101和102共享对较高级或进一步的高速缓存110的访问，较高级或进一步的高速缓存110用于缓存最近取出的元素。注意，较高级或进一步指的是高速缓存级增加或进一步远离执行单元。在一个实施例中，较高级高速缓存110是最后级数据高速缓存——处理器100上的存储器层次中的最后级高速缓存，诸如第二或第三级数据高速缓存。然而，较高级高速缓存110不限于此，因为它可与指令高速缓存相关联或包括指令高速缓存。替代地，跟踪高速缓存——一种类型的指令高速缓存——可耦合在解码器125之后，用于存储最近解码的跟踪。

在所描绘的配置中，处理器100还包括总线接口模块105，用于与处理器100外部的设备（诸如系统存储器175、芯片组、北桥或其它集成电路）通信。存储器175可专属于处理器100或与系统中的其它设备共享。存储器175的类型的常见示例包括：动态随机存取存储器（DRAM）、静态RAM（SRAM）、非易失性存储器（NV存储器）以及其它已知的存储设备。

在一个实施例中，处理器100能够进行硬件事务执行、软件事务执行或其组合或混合。事务也可称为代码的关键或原子段/区，该事务包括将作为原子组执行的指令、操作或微操作的编组。例如，指令或操作可用于对事务或关键段进行划界。在一个实施例中，如下更详细描述地，这些指令是诸如指令集体系结构（ISA）之类的指令集的一部分，该指令集可由诸如以下描述的解码器之类的处理器100的硬件来识别。通常，这些指令一旦从高级语言被编译成硬件可识别组件语言，即可包括解码器在解码阶段识别的操作代码（opcode）或指令的其它部分。

通常，在事务执行期间，在事务提交之前对存储器的更新并非全局可见。例如，对位置的事务写入对本地线程可能可见，然而，响应于来自另一个线程的读取，该写入数据在包括事务写入的事务提交之前不会被转发。如以下进一步详细描述地，在事务仍未决时，从存储器加载以及写入存储器的数据项/元素被跟踪。一旦事务达到提交点，如果还未检测到事务的冲突，则事务被提交并且使在事务期间进行的更新全局可见。然而，如果事务在其未决期间被无效，则事务被中止并且有可能重新开始，而不使更新全局可见。结果，正如本文所使用的，事务未决指的是事务已经开始但未提交或中止，即未决。

软件事务存储器（STM）系统通常涉及执行访问跟踪、冲突解决或软件代码执行中或至少主要通过软件代码执行的其它事务存储器任务。在一个实施例中，处理器100能够利用硬件/逻辑执行事务，即在硬件事务存储器（HTM）系统内。当实现HTM时从体系结构和微体系结构两个角度看均存在很多特定实现细节；在本文中对其大部分均不进行讨论，以免不必要地混淆本发明。然而，出于说明的目的公开了一些结构、资源和实现。然而，应注意这些结构和实现不是必需的，并且可增大和/或替换为具有不同实现细节的其它结构。

作为组合，处理器100能够在无限事务存储器（UTM）系统内执行事务，这试图利用STM和HTM系统二者的优点。例如，HTM对于执行小事务通常快且高效，因为它不依赖于软件执行所有的访问跟踪、冲突检测、确认和事务提交。然而，HTM通常仅能够处理较小的事务，而STM能够处理无限尺寸的事务。因此，在一个实施例中，UTM系统利用硬件来执行较小事务，并且利用软件执行对于硬件而言太大的事务。从以下的讨论可以看出，既使当软件处理事务时，硬件也可用于帮助和加速软件。此外，重要的是要注意相同的硬件也可用于支持和加速纯STM系统。

如上所述，事务包括通过处理器100内的本地处理元件以及潜在地通过其它处理器元件对数据项的事务存储器访问。在没有事务存储器系统中的安全机制的情况下，这些访问中的一些将潜在地导致无效数据和执行，即，数据写入使读取无效或无效数据的读取。结果，如下所讨论地，处理器100潜在地包括用于跟踪或监视至数据项和来自数据项的存储器访问以标识潜在的冲突的逻辑，诸如读取监视器和写入监视器。

数据项或数据元件可包括如硬件、软件或其组合所限定的任何粒度级别的数据。数据、数据元素、数据项或其引用的示例的非详尽列表包括存储器地址、数据对象、类、动态语言代码的类型的字段、动态语言代码的类型、变量、操作数、数据结构及对存储器地址的间接引用。然而，任何已知的数据编组可被称为数据元素或数据项。诸如动态语言代码的类型的字段和动态语言代码的类型之类的以上示例中的一些指的是动态语言代码的数据结构。为了说明的目的，诸如来自Sun Microsystems公司的Java^TM之类的动态语言代码是强类型语言。每个变量具有编译时已知的类型。这些类型被分为两类——原始类型（布尔型和数字，例如，整数、浮点）和引用类型（类、界面和阵列）。引用类型的值是对对象的引用。在Java^TM中，由字段构成的对象可以是类实例或阵列。给出类A的对象，通常使用符号A::x指代类型A的字段x，并且使用a.x指代类A的对象a的字段x。例如，表达式可以是a.x=a.y+a.z。此处，字段y和字段z被加载以便增加，并且结果被写入字段x。

因此，可在任何数据级别粒度上执行监视/缓冲对数据项的存储器访问。例如，在一个实施例中，在类型级别上监视数据的存储器访问。此处，对字段A::x的事务写入和字段A::y的非事务加载可被监视为对相同数据项（即类型A）的访问。在另一个实施例中，在字段级别粒度上执行存储器访问监视/缓冲。此处，对A::x的事务写入和A::y的非事务加载未被监视为对相同数据项的访问，因为它们是对不同字段的引用。注意，可在跟踪数据项的存储器访问中考虑其它数据结构或编程技术。例如，假设类A的对象的字段x和y（即A::x和A::y）指向类B的对象，被初始化到新分配的对象，并且在初始化之后决不被写入。在一个实施例中，对由A::x指向的对象的字段B::z的事务写入未被监视为关于由A::y指向的对象的字段B::z的非事务加载的相同数据项的存储器访问。从这些实例推断，可确定监视器可在任何数据粒度级别上执行监视/缓冲。

在一个实施例中，处理器100包括用于检测或跟踪与数据项相关联的访问以及潜在的后续冲突的监视器。作为一个示例，处理器100的硬件因此包括读取监视器和写入监视器，以跟踪确定要监视的加载和存储。例如，无论下面的存储结构的粒度如何，硬件读取监视器和写入监视器将以数据项的粒度监视数据项。在一个实施例中，通过相关联的跟踪机制以存储结构的粒度对数据项进行划界，以确保至少整个数据项被适当监视。

作为特定的说明性示例，读取和写入监视器包括与高速缓存位置相关联的属性，诸如较低级数据高速缓存150（它可包括推测高速缓存）内的位置，以监视来自与那些位置相关联的地址的加载和对这些地址的存储。此处，一旦有对关联于高速缓存位置的地址的读取事件，就设置数据高速缓存150的高速缓存位置的读取属性，以监视潜在的对相同地址的冲突写入。在这种情况下，对于写入事件，写入属性以类似方式操作，以监视潜在的对相同地址的冲突读取和写入。该实例进一步，在读取和/或写入属性被设置成指示高速缓存位置被监视的情况下，硬件因此能够基于对高速缓存位置的读取和写入的监听来检测冲突。相反，在一个实施例中，设置读取和写入监视器或更新高速缓存位置至缓冲状态导致监听，诸如读取请求或读取所有权请求，这顾及与要检测的其它高速缓存中监视到的地址的冲突。

因此，基于该设计，高速缓存一致性请求和所监视的高速缓存线的一致性状态的不同组合导致潜在的冲突，诸如在共享的读取监视状态中保持数据项的高速缓存线和指示对数据项的写入请求的监听。相反，在缓冲写入状态中保持数据项的高速缓存线和指示对数据项的读取请求的外部监听可被视为潜在的冲突。在一个实施例中，为了检测访问请求和属性状态的这种组合，将监听逻辑耦合到诸如监视器和/或用于冲突检测/报告的逻辑之类的冲突检测/报告逻辑以及状态寄存器，以报告冲突。

然而，条件和场景的任意组合可被视为对于事务无效。对于未提交的事务可考虑的因素的示例包括检测到对事务访问的存储器位置的冲突、丢失监视器信息、丢失缓冲数据、丢失与事务访问的数据项相关联的元数据以及检测到其它无效事件，诸如中断、环形转变或明确的用户指令。

在一个实施例中，处理器100的硬件以缓冲方式保持事务更新。如上所述，在事务提交之前不使事务写入全局可见。然而，与事务写入相关联的本地软件线程能够访问对于后续事务访问的事务更新。作为第一示例，在处理器100中提供单独的缓冲器结构，以保持缓冲的更新，这能够向本地线程提供更新而不向其它外部线程提供更新。

相反，作为另一个示例，诸如数据高速缓存150之类的高速缓存存储器用于缓冲更新，同时提供相同的事务功能。在此处，高速缓存150能够在缓冲的一致性状态中保持数据项；在一种情况下，新缓冲的一致性状态被添加之高速缓存一致性协议，诸如经修正的共享无效（MESI）协议以形成MESIB协议。响应于对缓冲的数据项（在缓冲的一致性状态中被保持的数据项）的本地请求，高速缓存150将数据项提供给本地处理元件以确保内部事务顺序排序。然而，响应于外部访问请求，提供未命中响应，以确保在提交前不使事务更新的数据项全局可见。此外，当高速缓存150的线被保持为缓冲的一致性状态并且被选择为用于驱逐时，缓冲的更新未被写回较高级的高速缓存存储器——缓冲的更新不会通过存储器系统扩散，即不会全局可见直到提交之后。相反，事务可中止，或者驱逐线可被存储在数据高速缓存和较高级高速缓存存储器之间的推测结构中，诸如牺牲高速缓存。在提交之后，缓冲的线转变到修改状态以使得数据项全局可见。

注意，内部和外部的项通常是相对于与共享高速缓存的事务或处理元件的执行相关联的线程的角度而言的。例如，用于执行与事务的执行相关联的软件线程的第一处理元件指的是本地线程。因此，在以上的讨论中，如果至先前由第一线程写入的地址的写入或来自该地址的加载（这导致该地址的高速缓存线被保持在缓冲的一致性状态）被接收，则该高速缓存线的缓冲版本被提供给第一线程，因为它是本地线程。相反，第二线程可在同一处理器内的另一个处理元件上执行，但不与造成高速缓存线被保持在缓冲状态的事务的执行（外部线程）相关联；因此，来自第二线程的对该地址的加载或存储未命中高速缓存线的经缓冲版本，并且将普通的高速缓存替换用于检索来自较高级存储器的高速缓存线的未缓冲版本。

在一个实施例中，处理器100能够执行编译器/优化代码177以编译应用代码176以支持事务执行，并且潜在地优化应用代码176。此处，编译器可插入操作、调用、函数和其它代码以实现事务的执行。

编译器通常包括用于将源文本/代码转换成目标文本/代码的程序或程序组。通常，利用编译器对程序/应用代码的编译以多个阶段和多遍进行，以将高级编程语言代码变换成低级机器或汇编语言代码。然而，仍可利用单遍编译器以进行简单编译。编译器可利用任何已知的编译技术，并执行任何已知的编译器操作，诸如，词法分析、预处理、解析、句法分析、代码生成、代码变换以及代码优化。正如本文所描述的，事务执行和动态代码编译的合并潜在地导致实现更激进的优化，同时保留必要的存储器排序保护。

较大的编译器通常包括多个阶段，但通常这些阶段被包括在两个一般阶段内：（1）前端，在前端中通常进行句法处理、语义处理以及一些变换/优化；以及（2）后端，在后端中通常进行分析、变换、优化以及代码生成。一些编译器涉及中端，中端说明编译器的前端与后端之间的界定的模糊。因此，对编译器的插入、关联、生成或其它操作的引用可在编译器的上述阶段或遍次以及任何其它已知的阶段或遍次中的任意之中进行。作为例示性示例，编译器潜在地将事务操作、调用、函数等插入到一个或多个编译阶段中，诸如将调用/操作插入到编译的前端阶段中，并且随后在变换阶段期间将该调用/操作变换成较低级代码。注意，在动态编译期间，编译器代码或动态优化代码可插入此类操作/调用，并且优化代码用于在运行时间期间的执行。作为特定例示性示例，二进制代码（已编译代码）可在运行时间期间被动态地优化。在此，程序代码可包括动态优化代码、二进制代码或其组合。

然而，不管编译器的执行环境和动态或静态特性如何，在一个实施例中，编译器编译程序代码以实现事务执行和/或优化程序代码段。因此，在一个实施例中，对程序代码执行的引用涉及：（1）编译器程序或优化代码优化器的动态或静态执行，以编译主要的程序代码、维持事务结构、执行其它事务相关的操作或优化代码；（2）主要程序代码的执行，包括事务操作/调用，诸如已经被优化/编译的应用代码；（3）与主程序代码相关联的诸如库之类的其它程序代码的执行，或（4）它们的组合。

通常在软件事务存储器（STM）系统中，编译器通常用于插入与要编译的应用代码内联的一些操作、调用和其它代码，同时在库中单独提供其它操作、调用、函数和代码。这潜在地提供库分配器的能力，以优化并更新库而不必重新编译应用代码。作为特定示例，对提交函数的调用可被内联地插入事务提交点处的应用代码内，同时在可更新的库中单独提供提交函数。另外，将特定的操作和调用置于何处的选择潜在地影响应用代码的效率。

如背景部分所述，在多线程系统中代码的激进优化相对于存储器排序问题而言是潜在危险的。然而，在一个实施例中，代码优化与事务存储器保护结合，以允许激进优化，同时保留存储器排序保护。此处，包括优化代码的原子区可被插入程序代码中，使得在优化代码的执行之后，事务保护确保没有存储器排序违例。结果，优化代码能够被激进地优化，并且原子区确保检测到存储器排序违例以免提交该区域。

然而，原子区与代码优化的组合也可从进一步的修改中获益。因此，在一个实施例中，处理器100能够基于处理器100内的硬件资源的可用性来动态调整程序代码176内的事务的尺寸。通常，原子区被完全提交或中止。

然而，在该示例中，当存在低效或无效资源以完成事务（或事务内的一部分代码）的执行时，可在事务的端点之前提交该事务，即将事务的尺寸动态调整为较小的事务。作为说明性示例，假设高速缓存存储器150用于保持试探性事务信息连同相关联的事务跟踪信息。在这种情况下，当高速缓存150在可用高速缓存条目上变低或溢出（选择事务访问线用于驱逐并且牺牲高速缓存满）时，可在该点提交执行事务，这导致试探性信息变得全局可见。然后，新的事务可从该提交点重新开始至原始的事务端点。因此，事务性的硬件资源（在该示例中为高速缓存存储器150）被释放。并且该事务能够作为两个较小的硬件事务完成，而不是退回整个事务或将事务扩展到软件，诸如在UTM系统中。

因此，在一个实施例中，处理器100包括用于支持事务存储器系统的硬件，不管它是HTM、STM或是UTM，诸如解码器、高速缓存存储器、推测性存储结构、跟踪机制、存储缓冲器、寄存器文件、检查点存储机制以及支持事务执行的任何其它已知的硬件的任意组合。此外，处理器100还包括硬件/逻辑，对于这种硬件适合于跟踪、提供或指示其可用性、使用或表示，以支持事务执行。作为第一示例，使用度量（硬件使用的表示）包括诸如高速缓存存储器、牺牲高速缓存、存储缓冲器或加载缓冲器之类的存储结构中可用或被不利地占用的条目的数量。作为另一个示例，使用度量可包括诸如存储器溢出、中断事件或条目驱逐之类的事件的出现。然而，可使用任何使用度量，不管是真实的还是抽象的。

作为更抽象使用度量的示例，假设计数器对代码内循环迭代的数量进行计数，并且当计数器命中阈值时，事务被提交。此处，可基于随时间的代码分析（code profiling）动态调整该阈值，诸如当发生由于不充分的硬件资源引起的事务中止时降低该阈值。在该情况下，不提供硬件资源或特定事件的精确的实际使用。然而，通过计数器阈值的动态调整，在硬件资源被耗尽之前，即在由于高资源利用率而进行中止或退回，硬件在本质上估计循环的数量。结果，在一个实施例中，这种硬件估计被称为硬件资源的使用或使用表示，因为它估计可用于代码执行的资源。

在一个实施例中，处理器100中的硬件能够异步地确定何时对事务进行动态尺寸调整。例如，当硬件资源的利用率高时，处理器100可提交该事务并且重新开始另一个事务，这从处理器100上执行的程序代码176的角度看是透明的。此处，包括事务的程序代码176由执行逻辑140执行。并且从程序代码的角度看，事务被无缝执行。然而，从硬件的角度看，诸如存储缓冲器之类的资源具有高利用率（溢出），所以硬件在事务端点之前提交事务，在该提交点重新开始第二事务，然后在该事务的最初端点处提交第二事务。

在另一个实施例中，利用硬件和固件/软件的组合来执行事务的动态尺寸调整。此处，处理器100包括硬件资源以支持事务执行和跟踪这些资源的利用率/可用性。并且来自程序代码176的条件代码在被执行时导致执行逻辑140基于这些硬件资源的利用率/可用性进行动态尺寸调整（在端点之前提交事务）。本质上，作为软件指令的结果，潜在的条件提交和资源利用率的检查同步执行，而不与通过硬件执行特定指令无关（异步）。

例如，动态优化代码177（可以是动态编译器代码的一部分）由执行逻辑140/141执行以在处理器运行时间期间动态编译/优化程序代码176。在这种编译/优化期间，原子区连同该原子区内的条件提交代码被插入到程序代码176的段中。执行逻辑140/141然后在运行时间期间动态优化代码176并且执行经过动态优化的代码176。具体地，执行逻辑140/141执行原子区和其中优化的代码。响应于解码阶段遇到/解码条件提交代码，确定该硬件资源利用率。注意，先前可能已经跟踪该利用率/可用性，但响应于该条件提交代码，该利用率随后被报告/评估。然后基于硬件资源可用性/使用做出是否提交原子区的判定。

在一个实施例中，由硬件响应于条件代码执行判定，以判定是否基于资源使用进行提交。换言之，硬件可独立地评估硬件使用，并且确定利用率是否足够高，以导致早提交。作为示例，条件提交代码包括可由解码器125识别的条件提交指令。条件提交指令或区域检查指令包括分支目标地址。并且硬件响应于利用解码逻辑125解码条件提交指令确定硬件资源利用率是否太高或者是否存在不足的资源。如果利用率太高或存在不足的资源，则执行逻辑140使执行跳到分支目标地址。

在一个实施例中，硬件基于预定算法确定利用率是否太高或者是否存在不足的资源。例如，当硬件资源包括存储缓冲器时，利用率太高包括预定数量的存储缓冲器条目被使用或发生溢出（无可用的存储缓冲器条目）。该硬件可基于先前的执行（代码分析）估计预期的代码使用，并且利用该估计连同当前的硬件使用来确定是否存在足够的资源来继续执行而不条件提交。

或者条件提交指令还可包括预期的使用。并且硬件将预期的使用与硬件使用比较以确定是否存在资源不足。例如，假设条件代码176被插入程序代码176的原子区内的循环中。结果，在循环的每个迭代之后执行条件代码。此处，条件提交指令引用在循环迭代期间使用的存储缓冲器条目的预期数量，它可基于通过代码或通过动态代码概况分析而估计的将被触及的独特存储缓冲器条目的数量。响应于解码逻辑125解码条件提交指令，相对于由处理器100的硬件确定的存储缓冲器中可用条目的数量比较预期的条目数量。如果预期条目的数量大于可用条目的数量，则执行跳至条件提交指令引用的分支目标地址。分支目标地址可包括程序代码176或其它代码内的地址引用代码，诸如库代码，以执行原子区的早提交并且重新开始第二原子区。

在另一个实施例中，软件确定何时硬件利用率太高或硬件可用性太低。在该示例中，处理器100包括保持硬件使用的表示（硬件使用度量）的存储元件，诸如寄存器。此处，条件代码包括加载/读取使用度量、评估它以及确定是否执行早提交的操作。如果将执行早提交，则条件代码包括跳跃操作，该操作在由执行逻辑140执行时使执行跳至分支目标地址，这提交当前事务并且可开始另一个原子区。

注意，硬件和软件可执行类似的评估。然而，硬件解决方案通过允许硬件完全处理早提交或仅接收条件提交指令而潜在地实现代码简洁。然而，允许软件执行评估在确定何时执行早提交方面提供更多的灵活性。结果，硬件和软件之间的任何组合梯度可用于基于实现和期望的优点来确定硬件利用率/可用性何时太高/低。

图1示出示例性处理器的抽象的逻辑视图，其具有不同模块、单元和/或逻辑的表示。然而，注意，利用本文中描述的方法和装置的处理器不一定需要包括所示出的单元。而且，处理器可省去所示的一些或全部单元。此外，图1仅描绘两个核；然而，处理器可包括任何数量的核，诸如同一类型的多个核以及类型各不相同的两个以上核。

图1示出以点对点方式通过接口耦合至外部存储器控制器（控制器中枢170）的处理器的实施例。然而，许多现有处理器已经开始包括具有用于互连多个核的环形配置的处理器上存储器接口模块（芯片上模块），以及共享的高速缓存和其它接口。虽然未示出，但在一个实施例中，处理器100包括耦合核、高速缓存以及存储器控制器组件的环形互连。

在此，利用高速缓存代理来管理物理分配的高速缓存的片。作为示例，每个高速缓存组件管理用于并置核（高速缓存代理出于管理高速缓存的分配片的目的而与其相关联的核）的高速缓存的片。很大程度上类似于高速缓存代理处理环形互连上的业务量并与高速缓存片对接，核代理/组件用于处理业务量并与核对接。附加地，环形互连可耦合存储器控制器接口逻辑（MCIL）和/或其它控制器以与其它模块（诸如存储器和/或图形处理器）对接。

转到图2a，描述了利用原子区优化代码的方法的流程图的实施例。尽管图2a中的流程的框基本上以顺序方式示出，然而所示方法的流程可按任意顺序以及部分或完全并行地执行。例如，可在插入原子区开始和结束指令之前插入条件提交代码。此外，所描述的框不是必须被执行的。并且未示出的其它框可与所绘出的框结合或代替所绘出的框来执行。

在框205，标识将优化的程序代码段。如上所述，程序代码可涉及编译器代码、优化代码、应用代码、库代码或任意其它已知的代码组成。作为特定的说明性示例，程序代码包括将在处理器100上执行的代码，诸如准备好执行的、动态编译以便在处理器100上执行的和/或动态优化以在处理器100上执行的二进制代码。此外，通过诸如编译器和/或优化代码之类的程序代码的执行来进行代码（操作、函数调用等）插入和代码优化。作为示例，在运行时间期间在处理器100上动态执行优化代码以恰好在处理器100上的程序代码执行之前优化程序代码。

伪代码B:将要优化的伪代码区

在一个实施例中，将要优化的程序的代码段（诸如来自伪代码B的区）包括指示将要优化的程序代码段/区的代码。例如，利用特定的指令或界限来指示将要优化或可能得益于优化的代码段。作为另一个选项，程序员提供有关程序代码段的提示，它将由优化代码用于标识优化的段。在另一个实施例中，基于概况分析信息来标识/选择区域。例如，程序代码在由硬件、在处理器上执行的软件、固件或其组合执行期间被概况分析。此处，代码的概况分析生成提示或修改最初的软件提示以及提供区域的直接标识以用于优化。此外，段代码潜在地由某些属性标识，诸如特定类型、格式或代码顺序。作为特定的说明性示例，包括循环的代码是潜在优化的目标。并且在执行期间的循环概况分析确定哪些循环应被优化。而且，如果循环包括诸如加载和存储之类的将要优化的特定的代码，则标识包括这些代码的区域以用于优化。如从伪代码B所看到的，区域包括能够从循环提升和下沉的加载和存储以便优化循环执行。

伪代码C：具有插入的开始和提交原子区指令的代码区

在一个实施例中，被标识用于优化的代码段转换成原子区。或者至少该代码段的一部分被转换成原子区。此处，如框210-215所示，通过开始和结束（提交）事务（原子区）指令来划界代码的部分。如从伪代码C所看见的，分别在代码区之前和之后插入区开始和区提交指令。在一个实施例中，代码包括多个入口和多个出口。结果，可分别在每个入口点和每个出口点插入开始原子区和结束原子区指令。然而，可使用指示区域为原子的任何已知方法。

伪代码D:具有插入的条件提交代码的代码区

在框220，确定条件提交点。注意，可在将要优化的代码区内确定/分配多个条件提交点，但为了便于讨论，以下仅更详细地讨论一个提交点。确定条件提交点可基于任意已知的用于试图避免用尽条件提交点之间的硬件资源的分配/确定算法。作为第一示例，条件提交点被插入在循环内，使得每次迭代都会遇到条件提交点。此处，确定条件提交点在循环的开始处。作为另一个示例，代码的动态概况分析指示通常导致硬件资源用尽的执行路径。所以，条件提交点被分配给这种执行路径以避免在那些路径的执行期间用尽资源。类似地，已知是独占或资源沉重的执行路径可具有分配给它们的条件提交点。

在框225，至少在条件提交点处插入条件提交代码。如果确定没有足够的硬件资源支持执行至下一提交点，则条件提交代码导致事务的尺寸调整，即早提交。简单地转向图2b，示出用于插入条件提交代码的流程图的实施例。在流程226中，在条件提交点插入条件提交指令。如在伪代码D中所看到的，在一个实施例中，条件提交指令包括插入在原子区内的提交点L1处的区检查指令。

作为第一示例，诸如区检查指令或条件分支指令之类的条件提交指令包括对分支目标地址的引用。并且作为确定没有足够的资源来支持执行至下一提交点的结果，响应于条件提交指令，执行跳至分支目标地址。此处，条件提交代码还可包括在分支目标地址处的提交代码。本质上，在该示例中，条件提交指令将发起确定是否存在足够的资源的测试/询问。并且在分支目标地址处的代码将在没有足够资源存在时提早提交该事务。因此，在框227，提交指令被插入在分支目标地址处。

在伪代码D中，第一区_提交(region_commit)指令被插入在B4处的原子区的退出点/端点处，而第二区_提交被插入在框B6中的分支目标地址点L2处。此处，如果响应于在L1处的区_检查指令确定不足的资源，则执行跳至由区_检查指令引用的分支目标地址（B6）。执行区_提交指令，诸如对事务库内的提交函数的调用或体系结构识别的提交指令，以早提交原子区（在端点B4之前）。此外，在框228（从伪代码D的B7），第二开始原子区指令（区_开始）被插入在区_提交指令之后。结果，原子区的执行在B3开始（区_开始）。并且继续，直到由L1处的区_检查指令确定不足的资源或者遇到端点B4。然而，如果在L1处确定不足的硬件资源，则调整最初的事务的尺寸，即在提交点L2提交，B6。然后，第二原子区在B7开始，并且区执行作为第二事务继续，直到提交点B4或资源在L1处再次受到限制。因此，可对单个原子区进行动态尺寸调整以调整为较小的事务以避免用尽硬件资源，这在以前可能导致中止或扩展至软件事务执行。

注意，条件提交指令可包括任意信息。例如，如前所述，在一个实施例中，条件提交指令包括下一提交点之前的预期硬件资源使用，诸如在通过伪代码D中的代码B2的循环期间使用的预期的条目数。此处，在确定是否存在足够的资源来支持循环B2的另一个迭代的执行时利用该预期使用。作为特定的说明性示例，预期使用包括在下一提交点之前响应于代码区的执行预期将被唯一触及的存储结构中的条目的数量。

另外，条件代码不限于条件提交指令。例如，在硬件确定使用并将该使用置于寄存器中（参考图5更详细地讨论）的实施例中，条件代码可包括从寄存器读取/加载使用的操作、评估使用、然后发出跳跃或分支操作，该操作分支到类似于来自伪代码D的B6和B7的提交和重新开始代码。在其它实施例中，软件可估计硬件使用，而不是与硬件通信或询问硬件。在这种情况下，条件代码包括用于执行这种估计的代码。例如参考图6更详细描述地，贯穿软件的执行保持计数，以限制在执行条件提交之前的循环迭代的数量。在该示例中，用于保持计数而执行的代码可被视为条件提交代码。

在框230，优化程序代码段。伪代码E描绘优化后的代码的示例。

伪代码E:优化后的代码区

尽管在某些实施例中将原子区的划界和条件提交代码的插入视为优化程序代码，然而在其它实施例中程序代码段被进一步优化以获得执行优点，同时依赖于事务执行的存储器排序保护。作为特定示例，利用部分冗余加载消除（PRLE）和部分死存储消除（PDSE）来使加载和存储提升和下沉到循环之外。伪代码E描绘在PRLE提升[r2]和[r2+4]加载且PDSE下沉[r2+4]存储之后的原子区。注意，在一个实施例中，应用进一步的存储器排序规则。此处，有利的是确保没有违背存储器排序的存储器优化穿越区开始和提交。可在伪代码E中看到该示例，其中[r2+4]存储被插入在B6处的区_提交之前，且[r2]和[r2+4]加载被再次插入到B7处的区_开始指令之后。结果，如果该区域被早提交（尺寸调整为条件提交点），则在B6处提交该区之前执行[r2+4]存储。并且在B7中的新事务的重新开始之后执行[r2]和[r2+4]加载。

尽管以上已经研究了加载和存储优化，然而可利用任意已知的代码优化技术。代码优化的另外若干示例包括但并非是详尽列表且仅仅是说明性的：循环优化、软件流水线化、数据流优化、代码生成优化、边界检查消除、分支偏移优化、死代码消除和跳跃线程。

参考图3a，描述用于动态尺寸调整原子代码的流程图的实施例。在框305，执行包括优化程序代码的事务（原子区）。在一个实施例中，优化程序代码在运行时间中被动态优化，即动态优化代码在运行时间中被执行以及时优化“运行中”的程序代码以供执行。通常这种类型的动态优化或编译不知道整个程序，诸如在静态编译期间，但能够编译/优化段中的部分代码。

在框310，遇到区检查指令。在一个实施例中，遇到区检查指令包括解码逻辑解码该指令。然而，遇到可表示流水线的任意级接收或服务于该指令（或指令的操作）。例如，遇到区检查指令可替代地指代在缓冲器中分配条目以用于与该指令相关联的操作、分派操作、利用执行单元实际执行该指令以执行关于该指令的操作或微操作，或任意其它已知的流水线级。如上所述，在一个实施例中，区检查指令是由处理器的解码器可识别的ISA的一部分以询问硬件。该询问可仅仅是用于询问硬件使用的加载。然后，软件确定是否有足够的资源可用而不需要硬件的更多参与。相反，询问可包括对硬件的请求以确定是否存在足够的资源来继续原子区的执行。此处，如果没有足够的资源存在，则询问提供硬件分支到达的目标地址。然而，询问可更复杂，其中区检查指令还提供硬件的预期使用，以在确定是否有足够的资源可用时使用。

响应于区检查指令，在框315，确定在区检查点处硬件单元诸如在下一条件提交点之前是否具有足够的资源来完成事务区。确定是否存在足够的硬件资源实际上可按任意方式测量或近似。作为第一示例，硬件本身跟踪和/或确定使用等级。并且硬件、固件、软件或其组合确定使用等级/度量是否包括足够的可用性以完成事务区。然而，注意使用等级也可以是仅在软件的指导下近似/测量的。在这种情况下，测量可能没有上述其中硬件执行其自身跟踪的示例那样精确，但不需要增加用于支持测量的附加硬件钩（hook）。

临时参照图3b，示出用于确定是否有足够的资源来完成事务区的执行的流程图的实施例。在流程350，确定一个硬件单元或多个硬件单元的预期使用。硬件、固件、软件或其组合可用于确定预期使用。

在一种情况下，对包括事务的程序代码的执行进行概况分析。在概况分析期间，跟踪由于有限资源引起的中止的数量、没有中止的提交和/或硬件使用。随后，诸如编译器之类的代码提供基于过去的执行概况的预期使用的提示或建议。在另一种情况下，预期使用可包括估计。例如，如果硬件单元是存储缓冲器，则在这种情况下，预期使用包括代码区中的独特存储的数量（可能在新的存储缓冲器条目中分配的存储操作）。本质上，代码中存储的数量可估计在代码区的执行期间使用的存储缓冲器条目的数量。然而，确定预期使用不限于软件概况分析或估计。替代地，硬件可执行类似的概况分析或估计，并且与代码结合以确定预期使用。

类似地，在流程355中，在硬件、软件、固件或其组合中确定硬件单元的可用使用。从上面继续该示例，假设条件提交指令基于估计和过去的分析通知硬件32条目存储缓冲器的预期使用包括十存储缓冲器条目。然后存储缓冲器利用其头部和尾部指针能够确定当前分配了20条目（12个可用条目）。根据该确定，可在流程360中执行比较。并且因为可用条目的数量大于预期使用，所以在流程360中确定存在足够的资源来继续执行。或者，如果仅九个条目可用，则在流程370中确定不存在足够的资源。

然而，比较不限于精确地确保硬件资源中有足够的空间可用。替代地，可通过使用阈值来提供缓冲器区。例如，如果使用为高（高于阈值）或者可用性低（低于阈值），则可在流程365、370中进行类似的确定。作为特定的说明性示例，假设六个条目的缓冲器区用于可用性。在这种情况下，如果在32条目缓冲器中要使用的预期条目的数量为十并且20个正在使用中，则仅12个条目可用。所以如果将分配十条目的预期使用，则将仅留下两个可用条目。因为留下的六个可用条目的缓冲器区被使用，则在流程370中确定不足的资源。相反，如果20个条目可用（仅12个条目被使用），则存在足够的资源（如流程365中），因为分配10个条目用于代码区仍将留下10个可用条目。

另外，使用和可用性可考虑线程优先级和使用。此处，如果多个线程共享对硬件资源的访问，则资源可被分割或完全共享。结果，与预期使用相比较的使用和可用性可将该共享考虑在内，所以一个线程不会独占硬件资源（不为其它线程留下足够的可用性）。例如，如果两个线程通过划分来共享对高速缓存的访问，则来自一个线程的事务可被限于高速缓存的一半条目。所以，使用和可用性是针对一半高速缓存的，而不是整个高速缓存。

以上的讨论引用存储缓冲器以及简要地引用高速缓存；然而，使用/可用性可针对任意单个硬件资源或硬件资源的组合，该硬件资源例如是存储缓冲器、加载缓冲器、高速缓存存储器、牺牲高速缓存、寄存器文件、队列、执行单元或其它已知的处理器硬件。例如，如果硬件资源包括高速缓存存储器，则预期的使用可包括将触及/利用的多个高速缓存线；使用可包括多个高速缓存线保持数据或多个高速缓存线处于一致性状态/不处于一致性状态，诸如多个共享的、独占的或经修改的高速缓存线，并且可用性可包括多个可用条目或线处于/不处于特定一致性状态（诸如无效一致性状态）。此外，参考硬件测量可用性/使用来进一步讨论可用性/使用。然而，如上所述，可通过软件、硬件或其组合来直接或间接测量以及估计使用和可用性。

返回到图3a，如果确定有足够的资源来完成区域，则执行流程返回到流程305。换言之，执行继续直到下一个条件提交点；在该点可再次执行硬件资源的评估。然而，如果确定不存在足够的资源，则在流程320在事务结束前提交事务（动态尺寸调整）。并且在一个实施例中，为了提供无缝执行，在流程325中开始新事务，以继续原子执行。此处，单个较大的事务基本上被动态分成可由硬件处理的较小事务，而不扩展到用于提供更多执行空间的虚拟或系统存储器。

转到图4，示出用于支持事务执行的逻辑框的实施例。如所示，存储器405适合于保持程序代码410，诸如操作系统（OS）代码、管理程序代码、应用代码动态编译器代码等。作为示例，程序代码410包括将根据图2a-2b动态优化（在运行时间或部分程序编译期间）的应用代码的至少一部分。在运行时间中，执行代码410，该代码410包括优化代码且具有代码的事务以支持动态尺寸调整。在一个实施例中，如前所述，程序代码410包括条件提交指令415，诸如区检查指令。

此处，解码器425（处理器的解码逻辑）适合于识别条件提交指令415。例如，解码逻辑425被设计并互连成将操作码418标识为指令集体系结构的一部分。结果，将由逻辑430、硬件435和执行逻辑440响应于解码器425解码包括操作码（opcode）418的条件指令415来执行特定（预定）的操作/微操作。如所述，条件指令415包括对预期硬件使用（硬件使用度量）416和分支地址420（诸如库地址之类的地址位置以及代码内相对另一个目标地址的偏移）的引用。

在一个实施例中，当解码器425解码/遇到条件指令415时，硬件确定是否有足够的硬件资源可用于供给由条件提交指令415指示的所执行的硬件使用。任何已知的方法和装置可用于确定硬件资源使用以及是否有足够的资源可用于供给硬件资源的预期使用。然而，以下讨论特定的示例以提供用于实现这种确定的一个实施例的说明。

此处当解码器425接收条件指令415时，由处理器流水线内的解码器425和逻辑430执行其它操作/微操作。例如，解码器425可将条件提交指令415解码成多个操作（微操作），诸如将执行的操作踪迹。注意根据以上的讨论，踪迹可在解码之后存储/构建在踪迹高速缓存中。并且例如，如果操作之一包括寄存器的读取或来自硬件435的加载以指示硬件资源的使用等级，则逻辑430可在加载缓冲器中分配条目并且在执行逻辑440上调度加载的执行。

此外，硬件435适合于确定这种使用等级435，这种使用等级435是响应于条件指令415而提供、确定或加载的。根据上述内容，支持可具有预定使用等级的事务执行的硬件的很多示例包括高速缓存存储器、推测性高速缓存存储器、存储缓冲器、加载缓冲器、寄存器文件、推测性寄存器文件、检查点寄存器文件等。结果，指令415可包括用于一个或多个硬件资源的一个或多个预期使用度量。并且单独的硬件或资源本身适合于跟踪其使用等级。例如，在一个实施例中，用于高速缓存存储器的高速缓存控制逻辑适合于跟踪高速缓存存储器的使用等级，诸如保持在高速缓存存储器中的无效高速缓存线的数量或高速缓存存储器中的可用线的数量。

然后，基于与所确定的硬件使用等级相比较的预期使用等级，确定是否存在足够的资源来继续事务的执行而不早提交（动态尺寸调整）。并且如果将执行早提交，则在所示示例中，执行逻辑440跳至分支目标地址420，如由条件提交指令415所提供的。如上所述，分支目标地址可包括代码，该代码在被执行时用于提早提交事务并且重新开始另一个事务以继续原子执行。

作为特定的说明性示例，假设通过解码器425接收条件提交指令415。并且条件指令415包括十个存储缓冲器条目和十个高速缓存线的预期使用度量416。硬件435（事务高速缓存存储器和存储缓冲器）确定其使用等级。注意，这些硬件条目可连续跟踪使用，并且它们在条件提交指令415询问/请求时提供这种使用。或者，当接收到来自条件提交指令415的请求时，逻辑可实际确定使用。无论如何，硬件使用等级/度量436被提供给存储元件，诸如保持用于由执行逻辑440进行的操作的信息的寄存器。然后，比较硬件使用等级436和预期的硬件度量416以确定是否有足够的资源可用于继续执行而不需要早提交。注意，根据以上内容，比较可利用缓冲器区、阈值或直接比较，以基于设计者的任意算法偏好确定是否有足够的资源可用。

此处，假设存储缓冲器利用32个存储缓冲器条目中的16个（16个可用条目）并且事务高速缓存使64个条目中的60个标记为事务访问（事务已经访问这些线且这种线的替换将导致信息丢失，造成中断或扩展到软件事务执行，即4个可用条目）。并且假设设计者算法指定在顾及到预期的条目数量之后将有4个可用条目。在这种情况下，利用10个预期的存储缓冲器条目和16个可用的条目，在存储缓冲器中存在足够的可用空间用于在下一条件提交点之前的原子执行。然而，仅有四个未被标记为事务可访问的高速缓存条目，所以没有足够的事务高速缓存空间。结果，诸如跳执行单元之类的执行逻辑440跳至分支目标地址420以取得、解码并执行代码，从而早提交事务（动态收缩事务）并且重新开始另一个事务。

注意已经参考包括预期硬件使用度量和分支目标地址的条件提交指令讨论了以上示例。然而，条件提交指令可包括导致硬件评估或估计是否有足够的硬件可用于支持代码执行的任何指令。例如，条件提交指令可仅是条件跳指令，其中硬件相对于过去的硬件代码概况分析评估当前使用等级以确定是否应提交事务。并且硬件在进行评估之后能够跳至由条件提交指令提供的分支地址。

注意，在另一个实施例中，硬件可异步地（并非约束或响应于特定的条件提交指令）确定事务将被提交。此处，当处理器执行事务代码并且发生溢出事件（指示在硬件资源中没有留下空间的事件，诸如已经进行事务标记的条目的驱逐）时，硬件可提交硬件事务并且重新开始新事务，而无需代码了解更多。

接下来参考图5，示出支持事务的动态尺寸调整的硬件的另一个实施例。前面（关于图4），讨论了可将确定的硬件使用等级/度量置于诸如寄存器之类的存储元件中，用于执行逻辑440的操作。类似于该示例，确定的硬件使用等级/度量可类似地加载到诸如寄存器550之类的存储元件中。然而，在一个实施例中，寄存器550（可包括特定模型寄存器（MSR））适合于被诸如用户级应用代码之类的程序代码访问（暴露于程序代码），以执行硬件资源可用性的评估。在先前的示例中，硬件基于来自软件的预期使用进行评估。然而，此处，软件能够询问硬件（MSR550）并且接收一个或多个硬件资源的使用等级。然后，软件能够基于自身的准则确定是否有足够的资源来继续原子执行至下一提交点。这可向用户提供更多的灵活性，因此它允许用户确定有多少硬件可用。结果，处理器设计者可选择处理器是否应保持更多的控制或用户是否能进行这种确定。

作为特定的说明性示例，假设处理器执行动态编译器代码以优化并执行包括用于潜在的动态尺寸调整的插入/优化事务的程序代码510。此处，用于处理器（未示出）的获取逻辑基于处理器线程（也未示出）的指令指针取得加载操作515。在加载缓冲器中的逻辑530/硬件535中分配加载缓冲器条目。该加载通过逻辑530调度和分派，以及通过执行逻辑540执行，以从硬件535加载确定的使用等级536（支持事务执行的资源，诸如高速缓存、缓冲器或寄存器文件）。注意，加载或在前的指令可同步地导致硬件535确定利用率和/或将利用率置于MSR550中。或者，硬件535可（基于事件或按周期性）异步地将利用率等级置于MSR550中。无论如何，通过操作516读取和评估使用等级。

例如，操作516可包括使用等级或软件定义的其它阈值等级来评估加载的硬件使用等级与预期的布尔表达式。事实上，布尔表达式可以是条件陈述和/或跳指令517的一部分，下面更详细地讨论。此处，如果硬件使用等级的评估指示事务应早提交，则执行由解码器525识别的穿过操作码517o的跳指令517以分支到目的地地址520，如上所述，从而提交事务并且重新开始另一个事务。

现在转到图6，示出支持事务的动态尺寸调整的硬件的另一个实施例。在一个实施例中，计数器650适合于对贯穿循环615的执行的迭代数进行计数。注意，计数器可用硬件、固件、软件或其组合来实现。例如，计数器650可以是保持值的寄存器。并且，软件代码读取当前值、修改（递增/递减）当前值至新值，并且在贯穿循环的每次迭代后将新值存储在寄存器中。本质上，软件维持计数器。然而，硬件计数器也可在循环的每次迭代的开始或结束时递增/递减。

在一个实施例中，计数器650的计数器值用于确定何时发生事务的早提交。例如，计数器650对循环的迭代数进行计数直到它达到阈值。在达到阈值后，计数器到期或溢出，导致早提交。注意，计数器可以零开始并且向上计数直到达到阈值（溢出）或以一个值开始并且向下计数直到零（过期或下溢出）。

可按任意方式确定阈值（或递减到零的计数器的开始值）。它可以是静态预定值，它包含在硬件中或由软件设置。此处，可通过硬件或软件基于任意已知的特性（诸如处理器中包含的硬件的类型或尺寸以及所执行的代码的类型或尺寸）静态智能地选择预定值。或者懒惰地选择静态预定值，诸如将循环迭代的数量限制到使退回显著减少的足够小的数量的保守值。

作为可选实施例，阈值（开始值）是动态选择的且可改变的。此处，硬件、软件或其组合可基于任何特性选择最初开始值（阈值）。例如，可用高速缓存线或存储缓冲器条目的数量（例如32）除以代码的单个循环迭代中存储数量的计数（例如8）以确定阈值（例如4）。在一个实施例中，存储数量的估计适度保守，因为多个存储可仅触及单个高速缓存线。所以，也可使用更激进的初始值。作为另一个示例，代码或硬件基于代码尺寸/类型、硬件单元尺寸/类型或确保循环执行具有足够资源以便完成的其它已知的因素，选择激进或保守值。此外，硬件或软件可对代码进行概况分析并提供开始/阈值。此处，在循环执行开始之前提供包括阈值数的软件提示，并且基于该阈值数设置计数器。或者，硬件可类似地对代码进行概况分析并且基于代码的区的概况分析历史来设置计数器。

在一个实施例中，在初始化计数器之后，阈值（开始值）被动态修改，诸如基于循环的执行分析（代码分析或退回确定）调节。本质上，在一个实施例中，计数器650用于估计在退回之前循环迭代615能够执行的次数或者由于有限的硬件资源而发生的可接受的退回数量。因此，如果发生高于可接受数量的退回，则减小先前的阈值以通过在提交发生前减少迭代的数量来减少退回的数量。在这种情况下，太频繁的退回浪费执行时间并且潜在地导致延迟。然而，为了确保阈值不太保守（在仍有大量可用资源时额外地进行早提交，这导致低效的原子执行），在一个实施例中，增加阈值直到确实发生退回。注意可按单个、多个或指数增量进行递增/递减。作为示例，假设开始值最初设为63（在提交前允许64次迭代）。如果检测到由于硬件限制引起的中止/退回的数量，则阈值递减到62。在随后的重新开始后，进一步递减2(60)、4(56)、8(48)等，直到确定允许执行高效完成的平衡开始值。

注意图6的讨论参考用于对循环迭代的数量进行计数的计数器，而没有特别参考条件提交指令。此处，达到阈值的计数器可通过硬件异步地发起提交。然而，在另一个实施例中，计数器650结合来自图5和6的条件提交代码工作。例如，计数器可以是确定/估计可用的硬件资源的量的硬件机制，并且条件提交指令导致基于硬件计数器跳至提交代码。例如，假设计数器650被初始化为九（在条件提交发生前允许10次迭代）。在循环615的每次迭代后，如果计数器已经到期（达到0），则诸如条件跳指令之类的条件提交指令被执行以跳至分支目标地址。当10次迭代完成且执行条件跳时，执行流跳至目标地址以用于执行原子区的提交。

尽管计数器不是各硬件单元的精确具体的使用等级测量，然而它潜在地是更加全面的估计。如上所述，通过阈值的动态调整，可得到基于硬件限制减少退回的最优迭代数量。因此，如果任意先前未标识的硬件限制导致退回，则动态计数器阈值能够捕捉它，同时由设计者或程序员的单独标识可不考虑这种未标识的原因。此外，计数器还可连同特定的硬件单元利用率测量一起使用，以提供单元级粒度以及超越(overreaching)、全局粒度。

先前的讨论主要集中在硬件资源耗尽之前的条件提交事务。或者响应于预期利用率确定硬件利用率以确定是否有足够的资源可用于支持执行。然而，在一些实施例中，有利的是贯穿原子区执行。并且，周期性地设定（响应于用户指令、事件或硬件限定时间）原子区的检查点。所以，在遇到实际的硬件限制、异常、中断或其它故障时，原子区能够退回至最近的中间检查点并且被提交以释放资源。本质上，取代进行向前看的估计和主动的提交事务，在一个实施例中，事务仅在遇到通常需要中止和重新开始整个事务的实际资源限制时重新开始。这通过在事务内执行多个检查点来完成，以确保如果发生退回，它仅仅是可接受量的退回的执行。

转到图7a，示出用于优化代码的方法的流程图的一个实施例，包括提供事务内的推测检查点。在框705，标识将优化的程序代码段。类似于图2a的讨论，可基于关于段的用户标识/提示、程序分析、代码概况分析、代码属性（区的特定类型、格式、顺序或特性——存储的循环或数量）或其它用于标识将要优化的代码区的已知方法，来标识代码的段/区。在一个示例中，代码包括二进制代码。并且在二进制代码的执行期间，它将被动态优化。结果，在优化执行期间，在二进制代码中遇到循环。所以，确定循环将被优化（插入的推测检查点）以确保检查点之间的距离足够小，退回不会导致大量的执行损耗。例如，以下的伪代码F示出将要优化的代码区的示例。

伪代码F:将要优化的代码区

同样类似于图2a的讨论，在流程710、715中，代码区被划界（在段的开始处插入开始原子区指令，并且在段的结束处插入结束原子区指令）。并且如上所述，代码区包括多个入口和多个出口。在框720，确定程序代码内的推测检查点位置。注意，可在将要优化的代码区内确定/分配多个推测检查点，但为了便于讨论，以下仅更详细地讨论一个检查点。

确定推测检查点可基于用于使原子区内的退回效果最小化的任何已知的分配/确定算法。作为第一示例，在循环内插入推测检查点，使得在每次迭代之后遇到推测检查点。此处，推测检查点可被确定为在循环的开始或在循环的边缘。作为另一个示例，代码的动态分析指示通常导致硬件资源用尽或具有高指令计数的执行路径。所以，推测检查点被分配给这种执行路径，以避免由于长执行路径中的中止而引起退回整个原子区。类似地，已知是独占或资源沉重的执行路径可具有分配给它们的推测检查点。本质上，取代在整个事务和整个事务的相关联的退回之前的现有技术检查点，通过利用事务内的检查点（本地、内部或临时的检查点）来执行较小的退回（浪费较少的执行）。结果，可优化较大的区域。并且如果遇到资源限制，则执行小的退回。此外，在退回点，事务潜在地被提交，最后的故障被处理，并且另一个事务重新开始。

在流程725，在推测检查点位置插入推测检查点代码。推测检查点代码设定推测硬件资源（诸如存储器、高速缓存存储器和/或寄存器文件）的检查点。并且在一个实施例中，推测检查点代码还可包括响应于后续的中止条件而将硬件资源恢复到检查点的代码。简单地转向图7b，示出用于插入推测检查点代码的流程图的实施例。伪代码G还描绘了在插入推测检查点代码之后的代码的说明性示例。

伪代码G:在插入推测检查点代码之后的代码区

在流程726，推测检查点指令/操作（在B5中的L1）被插入在推测检查点处（B2、B5的循环后边缘）。在一个实施例中，推测检查点指令包括发起推测硬件资源的检查点（当前快照）的任何指令。例如，推测检查点指令可通过处理器的解码器来识别。并且一旦被解码、调度和执行，就导致推测寄存器文件、存储缓冲器或两者被设定检查点（当前状态的快照）成为检查点存储结构，诸如检查点推测寄存器文件和推测高速缓存。

此外，在一个实施例中，推测检查点代码还包括一些其它代码以执行一些动作以潜在地避免导致当前退回的相同退回情况。例如，如果发生由于有限的硬件资源引起的退回，如果不采用减缓动作，则每次可遇到相同的硬件限制，导致没有向前进展。

作为示例，假设伪代码H中左侧上的代码将被优化。

伪代码H:将要优化的代码区

此处，对于如何处理优化代码中的退回，存在多种情况。作为第一示例，如以下的伪代码I所示，推测检查点指令与条件（分支）指令配对，该条件（分支）指令能够在正常循环执行或退回至推测检查点后的再次执行之间进行区分。分支指令在被执行时跳至不同的执行路径以按任意已知的方式处理退回，从而退回至先前的检查点状态。

伪代码I:分支指令与推测检查点指令的配对

在另一种情况下，以下在伪代码J中示出，推测检查点指令与分支指令组合成为单个检查点和分支指令，以上在一些实施例中已经进行讨论。

伪代码J:将分支与推测检查点指令组合

返回讨论伪代码G，在一个实施例中，推测检查点代码还包括固定（也可称为退回、恢复、重新构造、复原等）代码（B5），在被执行时用于从检查点存储结构恢复或复原最近的检查点的精确状态。注意，在一些实施例中，上述其它情况还可被视为推测检查点代码和/或固定代码。然而，此处，如伪代码G所示，固定代码还可包括提交代码（B6）以提交事务/原子区。本质上，推测检查点设定推测硬件的检查点。并且在推测硬件用尽或者遇到导致中止的事件（中断、动态插入、存储器别名检查等）时，检查点代码复原推测硬件中的精确状态。另外，为了释放推测硬件用于再次执行和继续执行，该事务可任选地被提交。根据该讨论，可以看出达到固定代码可按多种方式完成。作为示例，固定代码可从以下事件被输入：（1）推测检查点操作的执行，其中检查点存储结构不具有足够的空间来设定推测硬件的检查点；（2）推测硬件不能容纳的推测操作的执行；（3）在推测执行期间的异常；或（4）导致退回至事务内的临时内部检查点的任意其它事件。

此外，推测检查点可与条件提交组合以提供进一步的优点，诸如避免由于缺乏推测资源引起的中止，同时设定检查点使得由于故障、异常或其它不可预测的原因引起的任何这种退回/中止更加容易（在返回到检查点而不是整个原子区的开始的情况下，更少的执行浪费）。伪代码K描绘这种组合的一个示例。

伪代码K:推测检查点和条件提交的组合

此外，在一个实施例中，使条件提交指令知晓推测检查点，如以下的伪代码L所示。

伪代码L:知晓推测检查点的条件提交

在这种情况下，如果系统将要用尽资源（如上所述）或者执行退回回放（在执行退回至推测检查点），则区_检查（条件提交）指令跳至L2。

此外，不仅推测检查点和条件提交指令可一起使用，在一个实施例中，指令本身也可组合，如以下的伪代码M所示。

伪代码M:用于推测检查点和条件提交的一个指令

此处，当执行组合指令时，执行检查点，并且评估条件提交（如果硬件将用尽或资源快用尽则提交）。此处，如果系统快用尽推测资源或者如果执行退回至所记录的推测检查点，则执行跳至L2并且通过提交推测资源并且服务于最后的错误来处理它（在本示例中）。

尽管参考一旦硬件快用尽、错误被检测到、异常发生或其它不可预测的事件导致中断，就退回到先前的检查点（最近的推测）进行讨论，然而可响应于这种中断来探索其它路径。事实上，在一个实施例中，在中断后，硬件、软件或其组合做出接下来要做什么的判定。例如，假设诸如硬件生成的错误/事件之类的错误在原子执行期间发生。原子执行被中断。并且正常的控制被交付给软件，以确定错误的类型并服务于该错误。

此处，诸如处理程序之类的软件可基于任意数量的因素判决接下来要做什么，这些因素例如是错误的类型、退回至最近的推测检查点的困难性、由于退回到最后的提交点而不是最近点的推测检查点而导致的指令的数量或丢失的执行的量或在选择程序返回的执行点时已知的其它因素。本质上，在该说明性示例中，诸如处理程序之类的软件做出执行是否应退回到原子区的开始、原子区内的最后提交点、或原子区内的最晚推测检查点的确定。并且既使示例已经集中在做出判定的软件上，硬件也可进行这种判定。在一个实施例中，新指令（推测_退回）用于做出这种确定。此处，推测_退回指令包括一旦解码并执行就导致返回到程序代码中的适当位置（推测检查点或最近提交点）的任何信息。

重要的是，注意本文描述的代码不需要配置在相同的块、区、程序或存储空间中。事实上，推测检查点操作可插入在主程序代码内的循环返回边缘处。并且包括退回至最近的检查点并且任选地提交该事务的固定代码可位于库或代码的其它部分中。此处，主要的程序代码正在执行。并且当固定代码被输入时，对库代码的一个或多个功能的调用被执行以执行退回和提交。而且，硬件可执行类似的检查点操作，而不需要软件的指导。此处，硬件透明地设定推测硬件的检查点，如基于周期性或事件驱动。并且响应于推测硬件的用尽，处理器将执行退回至最晚的检查点，提交事务、重新开始事务并且回放检查点和退回点之间的指令。从软件的角度看，执行已经正常继续，同时硬件已经处理所有的资源限制和再次执行。然而，硬件和软件之间的任何等级的合作也可用于实现本地、内部事务检查点。

返回图7a，在框730优化程序代码段。以下的伪代码N描绘来自伪代码M的在优化之后的代码区的示例。

伪代码N:优化代码包括用于推测检查点的单个指令和条件提交

作为优化的另一个示例，以下的伪代码O示出优化的另一个示例（来自伪代码G的代码区的优化）。

1:转到循环B2。在该示例中，两个冷代码用于B2

并且L0：（在B3）是有效目标

伪代码O:优化后的代码区

如上所述，可在原子区内的代码上执行任意已知的优化技术。代码优化的若干示例包括（并非是详尽列表且仅仅是说明性的）：PRLE、PDSE、循环优化、数据流优化、代码生成优化、边界检查消除、分支偏移优化、死代码消除和跳线程。在伪代码O中，在B6处提交之后，在B6处开始另一个事务，并且执行在B2处继续。在其它实施例中（未示出），代码可在B3处再次输入。注意，在一些实施例中，原子区的划界和条件提交代码的插入可被视为优化程序代码。

接下来参考图8，示出用于在事务执行期间推测地设定存储器的检查点的方法的流程图的实施例。在流程805中，执行事务。作为一个示例，事务为在运行时间期间动态优化的二进制代码，以对该事务插入确保原子数的代码优化。

在流程810中，遇到来自事务的推测检查点指令。如上参考图7a-7b所讨论的，在运行时间中由优化器在推测检查点处插入该推测检查点指令。处理器识别推测检查点指令（通常通过检测预先指定的/限定的操作代码的解码器）。并且响应于推测检查点指令，在流程815推测寄存器文件在检查点（推测）寄存器文件中被设定检查点。另外，在流程820中确定推测高速缓存是否包括用于设定存储缓冲器中的检查点的足够空间。如果足够空间可用，则在流程825中，在推测高速缓存中设定存储缓冲器的检查点。然而，如果没有足够的空间，则执行固定/退回程序（以下更详细讨论的框845-855）。

结果，如果在事务的执行期间遇到短期退回事件，则用于当前执行的推测寄存器文件和存储缓冲器能够恢复到检查点状态。作为示例，在流程830中，遇到存储操作。在流程835中，确定存储缓冲器是否包括可用条目，诸如可用于供存储操作的分配的条目。并且如果有可用的条目，或者有释放和再分配的条目，则在框840，条目被如此分配。然而，如果没有可用的存储缓冲器条目，则执行退回程序（框845-855）。

退回/回放程序845-855将恢复来自先前检查点的精确体系结构状态。此处，退回是在还未提交的推测执行期间（还未全局可见）。因此，全局可见的状态（非推测存储结构）应保持相同。然而，恢复支持当前推测执行的推测硬件结构。因为推测高速缓存已经保持来自存储缓冲器的推测更新直至最近的检查点，所以在框850，存储缓冲器被转储清除。换言之，从事务开始至最近的检查点的存储被保持在推测高速缓存中。并且，来自最近的检查点至当前执行点（退回的发起）的存储被保持在存储缓冲器中。所以，被退回的那些存储简单地从存储缓冲器中被丢弃。

此外，从检查点寄存器文件恢复推测寄存器文件。此处，推测寄存器文件保持从事务开始起的全部更新，包括来自最近的检查点的那些更新，所以推测寄存器文件以来自检查点寄存器文件的值重新加载。注意，如果最初的检查点包括整个推测寄存器文件的副本（不仅仅是仅在推测执行期间修改的寄存器的选择性存储），则检查点寄存器文件可被再次标记（利用）为推测寄存器文件，并且先前的推测寄存器文件可被转储清除，并且随后用作检查点寄存器文件。或者推测寄存器文件被转储清除并复制（在一个或几个循环中）到推测检查点寄存器文件。

在流程860中，事务可被任选地提交。因为响应于异常、推测高速缓存中缺少空间或存储缓冲器中缺少空间而达到退回程序，所以事务可被提交以释放那些资源。此处，存储缓冲器和推测高速缓存更新被提交到非推测高速缓存存储器，从而释放这些资源（在流程875-880中示出）。并且类似地，推测寄存器文件被提交到非推测寄存器文件，释放它以用于进一步的推测执行（流程875-880中示出）。此外，如果将执行事务的完全中止（865），则在框870存储缓冲器和推测高速缓存被转储清除以使其恢复到事务前（非推测）的状态。

转到图9，示出适合于支持设定推测检查点的硬件的逻辑表示的实施例。解码器（解码逻辑）910适合或互连成识别推测检查点指令（SCPI）905。例如，包括图9的硬件的处理器的指令的预定格式可以被指定或设计到硬件中。并且具有特定位模式的指令的一部分对应于特定的指令，其中之一是SCPI905。

然后，响应于SCPI，保持在推测存储结构中的推测值935的检查点被设定为推测检查点存储结构中的推测检查点值940。注意，执行逻辑920被视为耦合到解码器以执行SCPI920。然而，显然，在解码和执行之间通常有很多级流水线。例如，SCPI可被解码成踪迹高速缓存中的操作踪迹；并且这些操作可在缓冲器中排队、调度、分派和执行以执行本文所述的操作/方法。

如上简要提及的，检查点包括时间点上的值的状态的快照，或至少恢复时间点上的值的状态的足够信息。因此，在一个实施例中，检查点包括推测值935的整个副本作为推测检查点值940。此处，推测值935可包括来自推测寄存器文件的推测寄存器文件值，而推测检查点值940包括在时间上最近的检查点处的推测寄存器文件的副本。作为另一个示例，推测检查点值仅包括自从最后的检查点以来已经修改的推测值935。此处，推测值935可包括来自推测寄存器文件的推测寄存器文件值，并且推测检查点值940包括来自最后的检查点的推测寄存器文件值，该最后的检查点仅来自自从最后的检查点以来已经修改的推测寄存器文件中的寄存器。作为又一个示例，推测检查点值940包括在时间上从原子区开始至检查点的所有值，而推测值935包括从检查点至当前的执行点的所有推测值。此处，存储缓冲器可保持推测值935，该推测值935被加至推测高速缓存中保持的旧值（从开始值最后的检查点）。

参考图10，示出适合于支持设定寄存器文件的推测检查点的硬件的逻辑表示的另一个实施例。类似于以上的讨论，解码器1010和执行逻辑1020分别适于接收、识别和执行SCPI1005。响应于SCPI1005，推测寄存器文件1035的检查点设定在推测检查点寄存器文件1040中。如上所述，检查点可包括进入检查点寄存器文件1040的寄存器文件1035的闪存副本。或者，当文件1035中的寄存器将被修改时，旧值作为检查点进入寄存器文件1040中。此处，取代响应于SCPI1005复制值，在文件1035中在对应部分的修改之后复制的来自文件1040的旧检查点值被清除或标记为无效。当执行继续时，经修改的寄存器的检查点再次被设定在文件1040中。

响应于（由于如图8的框820中的推测高速缓存缺少空间、图8的框840中的存储高速缓存缺少空间、异常、或其它退回事件）退回到最近的检查点，检查点的值（不管仅是修改的还是完全复制）从推测检查点寄存器文件1040恢复到推测寄存器文件1035。然而，如果存在退回到事务区的最开始，诸如事务的中止，则在一个实施例中，推测寄存器文件1035从非推测寄存器文件1030被再次加载。本质上，推测文件1035是工作中的推测寄存器文件。所以事务与推测寄存器文件1035一起工作（读取和写入）。所以，如果在事务开始处的加载被再次执行，如果非推测值未被再次加载，则加载可无意地加载中止前保持在推测寄存器文件1035中的较晚修改的推测值。

另外，响应于事务的提交，推测寄存器文件1035被提交（复制）到非推测寄存器文件1030。此处，使推测更新作为非推测结果而全局可见。此处，整个寄存器文件1035可被复制到非推测寄存器文件1030。或者仅已经被修改的推测寄存器文件1035中的那些寄存器可被复制到非推测寄存器文件1030中。

转到图11，示出适合于支持推测设定高速缓存存储器的推测检查点的硬件的逻辑表示的另一个实施例。如上关于图9-10，解码器1110和执行逻辑1120适合于解码并执行SCPI1105。此处执行逻辑1120在执行来自原子区的推测存储时，使用存储缓冲器1140保持推测更新。注意，从先前存储加载的来自相同区（加载线程）的加载从保持在存储缓冲器1140中的推测值加载。因此，可在存储缓冲器1140和执行逻辑1120的加载执行单元之间利用运行中的存储机制的类似加载。然而，至存储缓冲器1140中的存储地址的非推测或非本地加载将接收保持在高速缓存1130中的非推测值，而不是存储缓冲器1140中的值。此外，如果存在从原子区至已经设定检查点或移至推测高速缓存1135的存储地址的读取/加载，则推测高速缓存值应当直接地或通过存储缓冲器1140被提供给加载。

响应于SCPI1105，缓冲器1140中的存储缓冲器更新被移至推测高速缓存1135。结果，推测高速缓存1135保持从原子区的开始至最当前检查点的推测更新。并且存储缓冲器1140保持从最当前的检查点至当前执行检查点的推测更新。因此，在原子区提交之后，推测高速缓存1135和存储缓冲器1140中的所有更新被提交/移动/复制到非推测高速缓存1130。如所示，该提交通过将存储缓冲器1140提交到推测高速缓存1135并且将推测高速缓存1135提交到非推测高速缓存1130来完成。但是在另一个实施例中，来自存储缓冲器1140和推测高速缓存1135两者的更新被直接提供给非推测高速缓存1130。在提交之后，更新全局可见，并且可通过存储器层次1150（较高级存储器和本地位置）传播。

此外，响应于本地、内部退回到最近的检查点，存储缓冲器1140被转储清除。如上所述，在该实施例中，存储缓冲器1140本质上保持从最近检查点至当前执行点的更新。所以在退回后，那些更新被丢弃。注意，在一个示例中，响应于存储缓冲器1140不能容纳来自原子区（图8的框840）的新存储操作，发起本地退回。并且在框820，响应于推测高速缓存1135已满并且在SCPI1105后不能高速缓存存储缓冲器1140更新，也可发起退回。然而，当中止（整个原子区的退回）发生时，则存储缓冲器1140和推测高速缓存1135（从原子区的开始至当前执行点的更新）两者被转储清除。

在本文中使用的模块指的是任何硬件、软件、固件、或它们的组合。通常，被示为分开的模块边界一般不同而且有可能重叠。例如，第一和第二模块可共享硬件、软件、固件、或它们的组合，同时可能保留某些独立的硬件、软件或固件。在一个实施例中，术语“逻辑”的使用包括诸如晶体管、寄存器之类的硬件或诸如可编程逻辑器件之类的其它硬件。然而，在另一实施例中，逻辑还包括诸如固件或微代码之类的与硬件集成的软件或代码。

如在本文中所使用的值包括数字、状态、逻辑状态、或二进制逻辑状态的任何已知表示。通常，逻辑电平、逻辑值、或多个逻辑值的使用也被称为1和0，这简单地表示了二进制逻辑状态。例如，1指的是逻辑高电平，0指的是逻辑低电平。在一个实施例中，诸如晶体管或闪存单元之类的存储单元能够保持单个逻辑值或多个逻辑值。不过，使用了计算机系统中的值的其它表示。例如，十进制数字10也可被表示为二进制值1010和十六进制字母A。因此，值包括能保持在计算机系统中的信息的任何表示。

而且，状态也可由值或值的部分来表示。作为示例，诸如逻辑1之类的第一值可表示默认或初始状态，而诸如逻辑0之类的第二值可表示非默认状态。此外，在一个实施例中，术语重置和置位分别指的是默认和已更新的值或状态。例如，默认值可能包括高逻辑值，即重置，而已更新的值可能包括低逻辑值，即置位。注意，值的任何组合可用来表示任意数量的状态。

上述方法、硬件、软件、固件或代码的实施例可通过存储在机器可存取或机器可读介质上可由处理元件执行的指令或代码来实现。机器可存取/可读介质包括提供（即存储和/或发送）诸如计算机或电子系统之类的机器可读的形式的信息的任何机制。例如，机器可存取介质包括：诸如静态RAM（SRAM）或动态RAM（DRAM）之类的随机存取存储器（RAM）；ROM；磁或光存储介质；闪存设备；电气存储设备；光存储设备；声存储设备；或其它形式的用于保持传播信号（例如载波、红外信号、数字信号）的存储设备；等等。

贯穿本说明书，对“一个实施例”或“一实施例”的引用意味着结合该实施例描述的特定特征、结构或特性被包括在本发明的至少一个实施例中。因此，在本说明书通篇中各处出现的短语“在一个实施例中”或“在实施例中”不一定全部指的是同一实施例。而且，特定特征、结构、或特性可按照任何合适的方式在一个或多个实施例中组合。

在上述说明书中，已经参考特定示例性实施例给出了详细描述。然而，显然可对这些实施例作出各种修改和改变，而不背离如所附权利要求所述的本发明的更宽泛精神和范围。因此，说明书和附图应被认为是说明性而非限制性意义。而且，实施例和其它示例性语言的上述使用不一定指的是同一实施例或同一示例，而可能指的是不同和独特的实施例，也有可能是同一实施例。

Claims (46)

1.一种包含代码的机器可读介质，所述代码在被机器执行时使所述机器执行以下操作：

标识将要优化的程序代码段；

确定所述程序代码段内的条件提交点；

响应于确定所述条件提交点，在所述条件提交点处插入条件提交指令；以及

响应于标识将要优化的程序代码段，优化所述程序代码段。

2.如权利要求1所述的机器可读介质，其特征在于，标识将要优化的程序代码段基于程序代码的动态概况分析，且其中确定条件提交点基于从下组中选出的分配算法：在程序代码段内的循环开始处分配条件提交点；基于动态概况分析在执行路径上分配条件提交点；以及在已知独占硬件资源的执行路径上分配条件提交点。

3.如权利要求1所述的机器可读介质，其特征在于，条件提交指令包括条件分支指令，所述条件分支指令在被执行时继续程序代码段的执行作为第一分支或跳至条件提交位置作为第二分支。

4.如权利要求3所述的机器可读介质，其特征在于，所述代码在被机器执行时导致机器进一步执行以下操作：

在程序代码段的开始处插入第一区开始指令；

在程序代码段的结束处插入第一提交指令；

在条件提交代码位置插入第二提交指令；

在第二提交指令之后在条件提交代码位置插入第二区开始指令。

5.如权利要求4所述的机器可读介质，其特征在于，优化程序代码段包括动态优化代码段，而不使违背存储器排序的加载提升到高于第一和第二区开始指令，并且不使违背存储器排序的存储下沉到第一和第二提交指令之下。

6.一种用于在运行时间中动态优化代码的方法，包括：

标识将要优化的程序代码段；

响应于标识将要优化的程序代码段，将程序代码段的至少一部分划界为原子区；

确定原子区内的条件提交点；

响应于确定所述条件提交点，在所述条件提交点处插入区检查指令；以及

响应于标识将要优化的程序代码段，优化所述程序代码段。

7.如权利要求6所述的方法，其特征在于，将程序代码段的至少一部分划界为原子区包括在代码段的部分的开始处插入开始事务指令，并且在代码段的部分的结束处插入结束事务指令。

8.如权利要求6所述的方法，其特征在于，优化程序代码段包括利用选自下组的优化技术优化代码段：部分冗余加载消除（PRLE）、部分死存储消除（PDSE）、循环优化、数据流优化、代码生成优化、边界检查消除、分支偏移优化、死代码消除和跳线程。

9.如权利要求6所述的方法，其特征在于，区检查指令包括条件分支指令，所述条件分支指令在被执行时询问硬件，并且其中条件分支指令响应于对硬件询问的预定响应，分支至未到期的区提交指令和区重新开始指令。

10.如权利要求6所述的方法，其特征在于，在程序代码段的部分内的循环开始处完成插入区检查指令，并且在循环的每次迭代后执行区检查指令。

11.一种包含代码的机器可读介质，所述代码在被机器执行时使所述机器执行以下操作：

执行包括动态优化程序代码的事务；

确定支持事务的执行的硬件单元是否包括足够的可用资源，以在事务结束之前的区检查点处完成事务区；以及

响应于确定支持事务执行的硬件单元将用尽资源，在区检查点提交所述事务。

12.如权利要求11所述的机器可读介质，还包括在区检查点提交所述事务之后开始新事务。

13.如权利要求11所述的机器可读介质，其特征在于，所述硬件单元包括选自下组的单元：存储缓冲器、加载缓冲器、高速缓存存储器以及寄存器文件。

14.如权利要求11所述的机器可读介质，其特征在于，所述硬件单元包括高速缓存存储器，其中确定支持事务执行的硬件单元是否包括足够的可用资源以完成事务区包括：确定完成事务区要触及的预期高速缓存线的数量；确定高速缓存存储器中可用的条目的数量；将预期的高速缓存线的数量与可用高速缓存线的数量进行比较；以及基于将预期的高速缓存线的数量与可用高速缓存线的数量进行比较来确定支持事务执行的高速缓存存储器包括足够的可用资源以完成事务区。

15.如权利要求14所述的机器可读介质，其特征在于，确定完成区要触及的预期高速缓存线的数量基于插入在事务中的编译器提示，所述编译器提示基于事务区的先前执行的动态概况分析。

16.一种包含代码的机器可读介质，所述代码在被机器执行时使所述机器执行以下操作：

标识将要优化的程序代码段；

确定所述程序代码段内的推测检查点；

响应于确定所述推测检查点，在推测检查点处插入推测检查点代码；以及

响应于标识将要优化的程序代码段，优化所述程序代码段。

17.如权利要求16所述的机器可读介质，其特征在于，标识将要优化的程序代码段基于程序代码的动态概况分析，并且其中确定推测检查点基于选自下组的分配算法：在程序代码段内的循环开始处、在程序代码段内的循环的循环返回边缘处分配推测检查点；基于动态概况分析在执行路径上分配推测检查点；在已知独占硬件资源的执行路径上分配推测检查点；以及在执行路径分配推测检查点以避免用尽推测硬件资源。

18.如权利要求16所述的机器可读介质，其特征在于，所述代码在被机器执行时导致机器进一步执行以下操作：在程序代码段处插入开始原子区指令，以及在程序代码段处插入结束原子区指令。

19.如权利要求16所述的机器可读介质，其特征在于，推测检查点代码包括推测检查点操作，所述推测检查点操作在被执行时导致机器在检查点存储结构中设定推测寄存器文件和存储缓冲器的检查点，并且其特征在于，所述代码在被机器执行时导致机器进一步执行响应于存储缓冲器在代码段的执行期间用尽资源而插入固定代码从而退回到推测寄存器文件的检查点的操作。

20.如权利要求16所述的机器可读介质，其特征在于，优化程序代码段包括利用选自下组的优化技术优化代码段：部分冗余加载消除（PRLE）、部分死存储消除（PDSE）、循环优化、数据流优化、代码生成优化、边界检查消除、分支偏移优化、死代码消除和跳线程。

21.一种方法，包括：

标识将要优化的程序代码段；

响应于标识将要优化的程序代码段，将程序代码段的至少一部分划界为原子区；

在所述原子区内确定推测检查点；

响应于确定推测检查点，在推测检查点处插入推测检查点代码；以及

响应于标识将要优化的程序代码段，优化所述程序代码段。

22.如权利要求21所述的方法，其特征在于，将程序代码段的至少一部分划界为原子区包括：在代码段的部分的开始处插入开始事务指令，并且在代码段的部分的结束处插入结束事务指令。

23.如权利要求21所述的方法，其特征在于，所述推测检查点代码包括推测检查点操作，所述推测检查点操作在被执行时导致机器在推测检查点寄存器文件中设定推测寄存器文件的检查点并且在推测高速缓存中设定存储缓冲器的检查点，并且其中所述代码在被机器执行时导致机器进一步执行响应于在代码段的部分的执行期间推测高速缓存或存储缓冲器用尽资源而插入固定代码从而退回到推测检查点寄存器文件中保持的推测寄存器文件的检查点的操作。

24.如权利要求23所述方法，其特征在于，在代码段的部分的执行期间存储缓冲器用尽资源包括：在代码段的部分的执行期间存储缓冲器不包括任何可用条目，并且其中所述推测高速缓存用尽资源包括：在机器执行推测检查点操作时，推测高速缓存不包括足够的可用条目来保持来自存储缓冲器的条目。

25.如权利要求21所述的方法，其特征在于，优化程序代码段包括利用选自下组的优化技术优化代码段：部分冗余加载消除（PRLE）、部分死存储消除（PDSE）、循环优化、数据流优化、代码生成优化、边界检查消除、分支偏移优化、死代码消除和跳线程。

26.一种包含代码的机器可读介质，所述代码在被机器执行时使所述机器执行以下操作：

执行包括动态优化程序代码的事务；

在事务内的检查点处设定推测寄存器文件的检查点进入检查点寄存器文件；

确定支持执行事务的硬件单元将用尽资源；

响应于确定硬件单元将用尽资源，将检查点寄存器文件恢复到推测寄存器文件并且转储清除存储缓冲器。

27.如权利要求26所述的机器可读介质，其特征在于，在事务内的检查点处设定推测寄存器文件的检查点进入检查点寄存器文件响应于执行推测检查点指令，并且其中代码在被机器执行时导致机器进一步执行以下操作：在事务内的检查点处设定存储缓冲器的检查点进入推测高速缓存还响应于执行推测检查点指令。

28.如权利要求27所述的机器可读介质，其特征在于，硬件单元包括存储缓冲器，且其中确定支持执行事务的硬件单元将用尽资源包括：在遇到来自事务的存储和存储缓冲器不包括可用的存储缓冲器条目时确定存储缓冲器将用尽资源。

29.如权利要求28所述的机器可读介质，其特征在于，硬件单元还包括推测高速缓存，且其中确定支持执行事务的硬件单元将用尽资源包括：在同样响应于执行推测检查点指令在事务内的检查点处设定存储缓冲器的检查点进入推测高速缓存时，响应于推测高速缓存不包括足够的可用条目来保持来自存储缓冲器的条目，确定推测高速缓存将用尽资源。

30.如权利要求26所述的机器可读介质，其特征在于，所述代码在被机器执行时导致机器进一步执行以下操作：响应于将检查点寄存器文件恢复到推测寄存器文件而执行事务区的区提交并且响应于确定硬件单元将用尽资源而转储清除存储缓冲器。

31.如权利要求26所述的机器可读介质，其特征在于，响应于确定硬件单元将用尽资源，将检查点寄存器文件恢复到推测寄存器文件并且转储清除存储缓冲器包括：确定硬件单元将用尽资源，执行代码以基于与硬件单元相关联的因素确定恢复至与检查点寄存器文件相关联的检查点而不是最近提交的点，以及响应于确定恢复至与检查点寄存器文件相关联的检查点，将检查点寄存器文件恢复到推测寄存器文件并且转储清除存储缓冲器。

32.一种设备，包括：

适于解码推测检查点指令以获得解码的推测检查点指令的解码逻辑；

适于执行所述解码的推测检查点指令的执行逻辑；

适于在将包括优化代码的软件线程的原子区的开始之前，保持与软件线程相关联的非推测值的第一存储器；

适于在原子区的执行期间并且在所述解码的推测检查点指令由执行逻辑执行之后，保持与软件线程相关联的推测值的第二存储器；以及

适于响应于执行逻辑执行所述解码的推测检查点指令而保持来自第二存储器的推测检查点值的第三存储器。

33.如权利要求32所述的设备，其特征在于，所述第一存储器包括非推测寄存器文件，所述第二存储器包括推测寄存器文件，且所述第三存储器包括推测检查点寄存器文件。

34.如权利要求33所述的设备，其特征在于，所述推测寄存器文件适于在原子区的执行期间并且在所述解码的推测检查点指令由执行逻辑执行之后，保持与软件线程相关联的推测值包括：在原子区的执行期间并且在所述解码的推测检查点指令由执行逻辑执行之后适于保持与软件线程相关联的推测体系结构状态值的推测寄存器文件，且其中推测检查点寄存器文件适于响应于执行逻辑执行所述解码的推测检查点指令保持来自推测寄存器文件的推测检查点值，包括：推测检查点寄存器文件适于在执行逻辑执行推测检查点指令后将与软件线程相关联的体系结构值从推测寄存器文件加载到推测检查点寄存器文件作为推测检查点体系结构状态值。

35.如权利要求32所述的设备，其特征在于，响应于基于不足硬件资源而退回到与推测检查点指令相关联的检查点，将被保持在推测检查点寄存器文件中的推测检查点体系结构状态值被重新加载到推测寄存器文件中；响应于原子区的提交，保持在推测寄存器文件中的推测体系结构状态值被加载到非推测寄存器文件；并且响应于退回到原子区的开始，保持在非推测寄存器文件中的非推测值被加载到推测寄存器文件中。

36.如权利要求32所述的设备，其特征在于，所述第一存储器包括高速缓存存储器，所述第二存储器包括缓冲器，并且存储器包括推测高速缓存存储器。

37.如权利要求32所述的设备，其特征在于，所述缓冲器适于在原子区的执行期间并且在所述解码的推测检查点指令由执行逻辑执行之后，保持与软件线程相关联的推测值，包括：在原子区的执行期间并且在所述解码的推测检查点指令由执行逻辑执行之后适于保持与软件线程相关联的推测存储器值的缓冲器，且其中推测高速缓存存储器适于响应于执行逻辑执行所述解码的推测检查点指令保持来自缓冲器的推测检查点值，包括：推测高速缓存存储器，适于在执行逻辑执行推测检查点指令之后将与软件线程相关联的推测存储器值加载从缓冲器加载到推测高速缓存存储器以作为推测检查点存储器值。

38.如权利要求32所述的设备，其特征在于，响应于原子区的提交，所述缓冲器和推测高速缓存适合于将推测存储器值和推测检查点存储器值加载到高速缓存存储器；响应于退回到与推测检查点指令相关联的检查点，所述缓冲器适于被转储清除；并且响应于退回到原子区之前的点，所述缓冲器和推测高速缓存适于被转储清除。

39.如权利要求32所述的设备，其特征在于，所述解码逻辑、执行逻辑、第一存储器、第二存储器、和第三存储器被包含在多处理元件微处理器中，所述多处理元件微处理器适于耦合在计算机系统中，所述计算机系统包括选自下组的系统存储器：同步动态随机存取存储器（SDRAM）、只读存储器（ROM）和闪存。

40.一种设备，包括：

适于解码推测检查点指令以获得解码的推测检查点指令的解码逻辑；

适于执行所述解码的推测检查点指令的执行逻辑；

适于在原子区的执行期间保持推测更新的存储缓冲器；

适于响应于执行逻辑执行所述解码的推测检查点指令来设定来自存储缓冲器的推测更新的检查点的推测高速缓存；以及

适于在原子区的开始前保持非推测值的非推测高速缓存，其中响应于原子区的提交来自推测高速缓存的推测更新被加载到非推测高速缓存。

41.如权利要求40所述的设备，其特征在于，所述推测高速缓存和存储缓冲器还适于响应于原子区的提交利用推测更新来更新非推测高速缓存。

42.如权利要求40所述的设备，其特征在于，所述存储缓冲器还适于响应于退回到与推测检查点指令相关联的检查点或退回到原子区的开始而被转储清除。

43.如权利要求42所述的设备，其特征在于，所述推测高速缓存还适于响应于退回到原子区的开始而被转储清除。

44.如权利要求43所述的设备，其特征在于，所述推测高速缓存还适于响应于推测高速缓存不包括足够的条目来保持来自存储缓冲器的推测更新而指示没有足够的推测高速缓存条目可用于完成来自存储缓冲器的推测更新的检查点；并且存储缓冲器还适于响应于在遇到来自原子区的存储之后没有存储缓冲器条目可用而指示没有存储缓冲器条目可用，其中响应于推测高速缓存指示没有足够的推测高速缓存条目可用于完成来自存储缓冲器的推测更新的检查点或者存储缓冲器响应于在遇到来自原子区的存储后没有可用的存储缓冲器而指示没有存储缓冲器可用，发起退回到原子区内的检查点。

45.如权利要求42所述的设备，其特征在于，所述非推测高速缓存还适于响应于来自原子区的推测读取而向加载缓冲器提供条目。

46.如权利要求42所述的设备，其特征在于，非推测高速缓存适于来自较高级存储器的高速缓存线，所述较高级存储器选自下组：同步动态随机存取存储器（SDRAM）、只读存储器（ROM）和闪存。

Images