KR101370314B1 - Optimizations for an unbounded transactional memory (utm) system - Google Patents

Abstract

Disclosed herein are methods and apparatus for optimizing an unbound transactional memory (UTM) system. Hardware support for monitoring, buffering, and metadata is provided, and abstract address spaces orthogonal to the metadata are combined in isolation with the thread and / or software subsystems within the thread. In addition, metadata may be retained through hardware in a manner that is transparent to software, in a manner that compresses data. In addition, in response to metadata access commands / operations, the hardware may support mandatory metadata values that enable execution of various modes of transaction. However, when a monitor, buffered data, metadata, or other information is lost or a conflict is detected, the hardware polls the transaction status register for that loss or conflict and jumps to any label as it detects the loss or conflict. Provides variations of the missing instruction that can be done. Similarly, several variations of commit instructions are provided so that software can define commit conditions and information to clear at commit. In addition, the hardware provides support for holding and restoring transactions at the ring level transition.

Description

OPTIMIZATIONS FOR AN UNBOUNDED TRANSACTIONAL MEMORY (UTM) SYSTEM}

The present invention relates to the field of processor execution, and more particularly to the execution of instruction groups.

Advances in semiconductor processing and logic design allow for an increase in the amount of logic that can exist on integrated circuit devices. As a result, computer system configurations have evolved from single or multiple integrated circuits in the system to multiple core and multiple logic processors residing on separate integrated circuits. The processor or integrated circuit typically includes one processor die, which may include any number of cores or logic processors.

The ever increasing number of cores and logic processors on integrated circuits allow more software threads to run simultaneously. However, the increase in the number of software threads that can run simultaneously creates a problem associated with synchronizing data shared between software threads. One typical solution for shared data access in a multi-core or multi-logic processor system involves the use of locks to ensure mutual exclusion over multiple accesses to shared data. However, the ability to continually improve to potentially execute multiple software threads results in serialization of execution and false contention.

For example, consider a hash table with shared data. Using the lock system, the programmer locks the entire hash table so that one thread can access the entire hash table. However, the throughput and performance of other threads can have an adverse effect, because other threads cannot access any entries in the hash table until the lock is released. As another alternative, each entry in the hash table may be locked. Either way, you can extrapolate such a simple example into a large scalable program and then lock contention, serialization, fine-grain synchronization, and deadlock avoidance are extremely cumbersome for programmers. Becomes

Another recent data synchronization technique involves the use of transactional memory (TM). Transactional execution often involves grouping a plurality of microoperations, operations, or instructions. In the above example, both threads run in a hash table and their memory accesses are monitored / tracked. If both threads access / change the same entry, conflict resolution may be performed to ensure data validity. One type of transaction execution includes software transactional memory (STM), where memory access tracking, conflict resolution, task abort, and other transactional tasks are typically performed through software without hardware support.

Other kinds of transaction execution include hardware transactional memory (HTM), which includes hardware to support access tracking, conflict resolution, and other transactional tasks. Earlier, the actual memory data arrays were extended with additional bits that would hold information such as hardware attributes to track reads, writes, and buffering, with the result that the data went with the data from the processor to the memory. Usually this information is said to be persistent, that is, it does not disappear during cache eviction because it travels with the data throughout the memory hierarchy. The persistence here imposes more overhead on the entire memory hierarchy system.

In addition, previous hardware transactional memory (HTM) systems have struggled with numerous inefficiencies. As a first example, HTMs do not provide any efficient way to switch between unbuffered, buffered and unmonitored states to buffered and monitored states to ensure consistency before the commit of the current transaction. . As another example, there are several inefficiencies with the interface of the HTM with software. Specifically, the hardware does not provide any mechanism to properly speed up software memory access barriers that take into account various forms of strong atomicity between transactional and non-transactional operations. In addition, during the commit of the attempted transaction, the hardware provides no convenience to determine when the transaction should abort or commit based on the loss of monitoring, buffering, and / or other attribute information. Similarly, the instruction set for these older HTMs does not provide commit instructions that define the information to retain or remove depending on the commit of the transaction. Other examples of inefficiency include instructions for HTMs to efficiently perform vector or jump execution depending on current HTMs inability to process ring level priority transactions and detecting collision or loss of information during execution of transactions. It does not include that.

The invention is shown by way of example and is not intended to be limited by the accompanying drawings.
1 illustrates one embodiment of a processor that includes multiple processing elements capable of executing multiple software threads simultaneously.
2 illustrates one embodiment of associating metadata with a data item.
3 illustrates one embodiment of orthogonal abstract address spaces for respective software subsystems within a plurality of processing elements.
4 illustrates one embodiment for the compression of metadata for data.
5 illustrates one embodiment for a flowchart of a method of accessing metadata.
6 illustrates one embodiment of a metadata storage element to support acceleration of a transaction in a strongly atomic environment.
7 illustrates one embodiment of a flow diagram for accelerating non-transactional operations while maintaining atomicity in a transactional environment.
8 illustrates one embodiment for a flow diagram of a method of efficiently transitioning a block of data to a buffered dimming monitored state prior to transaction commit.
9 illustrates one embodiment of hardware that supports a loss instruction that jumps to a destination label based on a state value in a transaction status register.
10 illustrates one embodiment of a flow diagram of a method of executing a loss instruction that jumps to a destination label based on a conflict or loss of specific information.
Figure 11 illustrates one embodiment of hardware that supports the definition of commit conditions and clear control in commit instructions.
12 illustrates one embodiment of a flowchart for a method of executing a commit instruction that defines a commit condition and a clear control.
13 illustrates one embodiment of hardware that supports privilege level switching processing during execution of a transaction.

In the following description, to provide a thorough understanding of the present invention, specific hardware structures for transaction execution, specific types and implementations of access monitors, specific type cache coherency model to detect access conflicts, and specific data granularities And numerous specific details, such as examples of specific types of memory access and location. However, it will be apparent to one skilled in the art that these specific details are not to be used to practice the present invention. Coding of transactions through software, insertion of operations to perform functions enumerated by the compiler, demarcation of transactions, certain alternative multicore and multithreaded processor structures, specific compiler methods / implements, and microprocessors Well known components or methods, such as specific operating details, have not been described in detail in order to avoid unnecessarily obscuring the present invention.

The methods and apparatus described herein are for optimizing hardware and software for running unbounded transactional memory (UTM). Specifically, such optimizations are primarily discussed in connection with UTM system support. However, the methods and apparatus described herein may be implemented with a UTM system in hardware that supports or accelerates a software transactional memory system (STM), a pure hardware transactional memory system (HTM), or a combination thereof. Can be utilized in any form of different transactional memory system.

Referring to FIG. 1, one embodiment of a processor capable of executing multiple threads simultaneously is illustrated. It should be appreciated that the processor 100 may include hardware support for hardware transaction execution. In conjunction with hardware transaction execution, or on its own, processor 100 may also provide hardware support for their association, such as hardware acceleration of software transactional memory (STM), individual execution of STM, or hybrid transactional memory (TM) systems. . Processor 100 includes any processor, such as a microprocessor, an embedded processor, a digital signal processor (DSP), a network processor, or another device to execute code. The processor 100 as illustrated includes a plurality of processing elements.

In one embodiment, a processing element refers to a thread unit, process unit, context, logic processor, hardware thread, core, and / or any other element that can hold a processor's state, such as an execution state or a structural state. In other words, in one embodiment, a processing element refers to any hardware that can be associated independently with code such as a software thread, operating system, application, or other code. Physical processor typically refers to an integrated circuit, which potentially includes any number of other processing elements, such as cores or hardware threads.

The core is generally referred to as logic located on an integrated circuit that can maintain its own structural state, where each independently maintained structural state is associated with at least some dedicated execution resources. In contrast to cores, a hardware thread typically refers to some logic that resides on an integrated circuit that can hold its own structural state, where the structural states that maintain its own share access to execution resources. As can be seen, when certain resources are shared and other resources are dedicated to some structural state, the boundary between the names of hardware threads and cores overlaps. Also, cores and hardware threads are often considered as separate logic processors by the operating system, where the operating system can schedule operations on each logical processor individually.

Physical processor 100 as illustrated in FIG. 1 includes two cores, cores 101 and 102, that share access to upper level cache 110. The processor 100 may include asymmetric cores, ie cores having different configurations, but functional units, and / or symmetric cores are illustrated. As a result, the core 102 illustrated as being the same as the core 101 will not be discussed in detail to avoid repeated discussion. In addition, core 101 includes two hardware threads 101a and 101b, and core 102 includes two hardware threads 102a and 102b. Thus, software entities such as an operating system regard the processor 100 as four separate processors, or four logic processors or processing elements capable of executing four software threads simultaneously.

Here, the first thread is associated with the structure state registers 101a, the second thread is associated with the structure state registers 101b, the third thread is associated with the structure state registers 102a, and the fourth thread. Is associated with the structure status registers 102b. As illustrated, structure state registers 101a are replicated to structure state registers 101b, so that individual structure state / contexts may be stored for logic processor 101a and logic processor 101b. Other smaller resources, such as the instruction pointers of the rename allocation logic 130 and the rest of the logic, may also be replicated for the threads 101a and 101b. Some resources, such as reorder buffers, load / store buffers, and queues within the reorder / retirement unit 135 may be shared through partitioning. General purpose internal registers, page-table base registers, low-level data cache and data-TLB 115, execution unit (s) 140, and part of out-of-order unit 135 The same other resources are likely to be fully shared.

Processor 100 typically includes other resources that may be fully shared, shared via partitioning, or dedicated to / by processing elements. In FIG. 1 an embodiment of a simple exemplary processor with exemplary functional units / resources of the processor is illustrated. The processor may include or omit any of such functional units, or may include any other known functional units, logic, or undepicted firmware.

As illustrated, the processor 100 may include a bus interface module 105 for communicating with devices external to the processor 100, such as system memory 175, chip configuration, northbridge, or other integrated circuits. Include. The memory 175 may be dedicated to the processor 100 or shared with other devices in the system. The higher-level or higher-out cache 110 must cache elements recently retrieved from the higher-level cache 110. By higher level or above is meant a cache level that is further or improved from the execution unit (s). In one embodiment, the high level cache 110 is a second level data cache. However, the high level cache 110 is not so limited because it may be associated with or include an instruction cache. A sort of trace cache, or instruction cache, may instead be connected to store the recently decoded traces behind the decoder 125. Module 120 may also include a branch target buffer that predicts the branches to be executed / taken and an instruction-translation buffer (I-TLB) to store the address translation entry of instructions.

Decoding module 125 is coupled with fetch unit 120 to decode the imported elements. In one embodiment, the processor 100 is associated with an instruction set architecture (ISA) that defines / specifies instructions executable on the processor 100. Machine code instructions, which are usually recognized by ISA, include some of the instructions called opcodes that cite / specify instructions or operations to be performed.

In one example, allocator and reamer block 130 includes an allocator to reserve resources such as register files to store instruction processing results. However, threads 101a and 101b may be capable of out of order, where the allocator and renamer block 130 also reserve other resources, such as a reorder buffer to keep track of instruction results. Unit 130 may also include a register renamer to rename the program / instruction reference registers to other registers within processor 100. The reorder / retirement unit 135 includes components such as the reorder buffers, load buffers, and storage buffers described above, for subsequent sequential retirement of out of order execution and out of order executed instructions. Support

In one embodiment scheduler and execution unit block 140 includes a scheduler unit that schedules instructions / operations on execution units. For example, floating point instructions are scheduled on a port of an execution unit that has an available floating point execution unit. Register files associated with execution units are also included to store information instruction processing results. Typical execution units include floating point execution units, integer execution units, jump execution units, load execution units, storage execution units, and other known execution units.

The low level data cache and data translation buffer (D-TLB) 150 are coupled with the execution unit 140. A data cache is one that stores recently used / operated elements such as data operands that can be maintained on memory coherency states. The D-TLB is to store recent virtual / linear physical address translations. As a specific example, the processor may include a page table structure that breaks up physical memory into a plurality of virtual pages.

In one embodiment, processor 100 has hardware transaction execution, software transaction execution, or a combination or hybrid execution function thereof. A transaction, which may be called a critical or atomic section of code, includes a group of instructions, operations, or microoperations to be executed as an atomic group. For example, instructions or operations may be used to demarcate a transaction or critical section. In one embodiment, as described in detail below, these instructions are part of a set of instructions, such as an instruction set structure (ISA) that can be recognized by the hardware of processor 100, such as the decoders described above. Usually, such instructions compiled into a hardware-recognizable assembly language in a higher language include operation code (operation code), or other instruction portions, that decoders recognize during the decode phase.

Typically during the execution of a transaction, updates to memory are not seen as a whole until the transaction is committed. By way of example, a transaction record to one location is likely to be visible to the local thread in response to a read from another thread whose record data has not been delivered until the transaction including that transaction record is committed. As discussed in more detail below, when a transaction is still pending, data items / elements loaded into or written into memory are tracked. When a transaction reaches a commit point, if no conflict was detected for that transaction, the transaction is committed and the updates made during the transaction are visualized as a whole.

However, if a transaction is invalidated during its pending, the transaction may be aborted and restarted without the update being fully visible. As a result, the pending of a transaction as used herein refers to an undetermined transaction that has started execution but has not been committed or aborted.

A software transactional memory (STM) system usually refers to access tracking, conflict resolution, or other transactional memory operations within or at least partially within software. In one embodiment, the processor 100 may execute a compiler to compile program code that supports transaction execution. Here, the compiler can insert code that enables operations, calls, functions, and other transactional execution.

Compilers usually contain a program or set of programs that will convert source text / code into target text / code. Usually, the compilation of program / application code through a compiler is performed in several steps and passes to convert the high level programming language code into lower level machine or assembly language code. The single pass compiler can still be utilized for simple compilation. The compiler utilizes some known compilation techniques and performs some known compiler operations such as lexical analysis, preprocessing, parsing, lexical analysis, code generation, code conversion, and code optimization.

Larger compilers usually include several steps, but most often those steps fall into two general steps: (1) front-end, ie generally syntax processing, word processing, and some conversion / Where optimization can occur, and (2) back-end, i.e., analysis, transformation, optimization, and code generation in general. Some compilers have a middle end that indicates blurring of the demarcation between the front end and the back end of the compiler. As a result, references to insertions, associations, generations, or other compiler operations may occur in any of the above mentioned steps or passes, as well as in any other known compiler steps or passes. As an illustrative example, the compiler may perform transaction operations, calls, and functions within one or more compilation steps, such as inserting a call / operation at the front end of compilation and then converting the low level code of the call / operation during a transaction memory translation step. Etc. can be inserted.

Despite the compiler's execution environment and dynamic or static nature, the compiler compiles the program code to enable transactional execution in one embodiment. Thus, in one embodiment, reference to the execution of program code refers to (1) the execution of a dynamic or static compiler program to compile main program code, maintain transaction structure, or perform other transactional association operations, (2) Execution of main program code including transaction operations / calls, (3) execution of other program code such as libraries associated with the main program code, or (4) combinations thereof.

Usually in software transaction memories (STMs), other operations, calls, functions, and code are provided separately in libraries, while the compiler is used to insert certain operations, calls, and other code that matches the application code to be compiled. Will be. This can provide the ability of library distributors to optimize and update libraries without having to recompile the application code. As a specific example, a call to a commit function may be inserted into the application code at the commit point of a transaction, while the commit function is provided separately in an updatable library. In addition, the choice of where to put certain operations and calls has a potential impact on the efficiency of the application code. For example, if a filter operation discussed in more detail with respect to access barriers with reference to FIG. 6 is inserted in line with the code, the filter operation is inefficiently vectoring to the barrier and then performing the filtering operation instead of performing the filtering operation. The filter operation may be performed before the execution move to.

In one embodiment, processor 100 may utilize hardware / logic, ie, execute transactions within a hardware transactional memory (HTM) system. There are numerous details of specific embodiments in terms of both structural and microstructural aspects when implementing HTM, many of which are not discussed herein to avoid unnecessarily obscuring the present invention. However, some structures and embodiments are disclosed for illustrative purposes. In addition, it is to be understood that these structures and implementations are not essential and that other structures with other implementation details may be added and / or replaced.

As a combination, processor 100 may execute transactions in an unbound transactional memory (UTM) system that seeks to take full advantage of both STM and HTM systems. For example, HTM is usually fast and efficient in executing small transactions because it does not rely on software in performing both access tracking, conflict detection, validation, and committing of transactions. However, HTMs can usually handle only smaller transactions, while STMs can handle transactions of unlimited size. Thus, in one embodiment, the UTM system utilizes hardware to execute smaller transactions and software to execute larger transactions relative to that hardware. As will be appreciated from the discussion below, even when software handles transactions, hardware can be used to support and accelerate the software. In addition, it is important to know that the same hardware can also be used to support and accelerate pure STM systems.

As mentioned above, transactions include transactional memory access to data items by both local processing elements and other processing elements in processor 100. Without the safety mechanism of a transactional memory system, some of these accesses will likely result in invalid data and execution, i.e., data writes that invalidate reads or reads of invalid data. As a result, processor 100 includes logic to track or monitor memory access to and from data items for identification of possible conflicts, such as read monitors and write monitors discussed below.

A data item or data element may comprise data of any granularity level as defined through hardware, software, or a combination thereof. A non-exclusive list of data, data elements, data items, or references to them may be stored in memory addresses, data objects, classes, type fields of dynamic language code, types of dynamic language code, variables, operands, data structures, and memory addresses. Contains an indirect reference to However, any known group of data may be called a data element or data item. A few of the examples such as the type field of the dynamic language code and the type of the dynamic language code refer to the data structure of the dynamic language code. To illustrate, dynamic language code such as Java ™ from Sun Microsystems is a strongly typed language. Each variable has a type known at compile time. Types are divided into two category-primitive types (Boolean and numeric, such as int, float) and reference types (class, interface and arrays). The value of the reference type is a reference to the object. In Java ™, an object made of fields can be a class instance or an array. Given object a of class A, it is customary to use A :: x to refer to field x of type A and a.x notation for field x of object a of class A. For example, the expression can be expressed as a.x = a.y + a.z. Here, fields y and z are loaded for addition and the result is written to field x.

Thus, monitoring / buffering memory accesses to data items may be performed at any data level granularity. For example, in one embodiment, memory accesses to data are monitored at the type level. Here, the transaction record to field A :: x and the non-transactional load of field A :: y can be monitored as access to the same data item, type A. In yet another embodiment, memory access monitoring / buffering is performed at field level granularity. Here, transaction records to field A :: x and non-transactional load of field A :: y are not monitored as access to the same data item because they are references to proprietary fields. It should be appreciated that other data structures or programming techniques may be considered in tracking memory accesses to data items. As an example, assume that the fields x and y of an object of class A, that is, A :: x and A :: y point to objects of class B, are initialized with newly allocated objects, and are never overwritten after initialization can do. In one embodiment, the transaction record of the object pointed by A :: x to field B :: z is the memory for the same data item with respect to the non-transactional load of field B :: z of the object pointed to by A :: y. It is not monitored as an access. Inferring from these examples, it is possible to determine that monitors can perform monitoring / buffering at any data granularity level.

In one embodiment, processor 100 includes monitors for detecting or tracking access and possible subsequent conflicts associated with data items. As one example, the hardware of the processor 100 includes read monitors and write monitors to track the load and storage determined to be monitored accordingly. By way of example, hardware read monitors and write monitors should monitor data items with the corresponding granularity of data items, despite the granularity of underlying storage structures. In one embodiment, the data item is in contact with tracking association mechanisms at a granularity of storage structures that allow at least the entire data item to be properly monitored.

As a particular illustrative example, read and write monitors may include attributes associated with cache locations, such as locations in lower level data cache 150, such as load from and store in addresses associated with those locations ( Storage). Here, the read attribute for the cache location of the data cache 150 is set upon a read event to an address associated with the cache location for monitoring for potentially conflicting writes to the same address. In this case, the write attributes are operated in a similar manner for write events that monitor read and writes that potentially conflict for the same address. In a further example, the hardware may detect a collision based on snoops of read and write to cache locations with read and / or write attributes set to indicate that cache locations are monitored accordingly. Conversely, in one embodiment snooping, such as reading a read request or an owning request, taking into account conflicts with addresses monitored in other caches to be detected, setting the read and write monitors or updating the cache location to a buffered state is detected. Deriving Swadle

Thus, depending on the design, different combinations of cache consistency requests and monitored consistency states of cache lines result in a potential conflict, such as a cache line having a snoop indicating a data item in a shared read monitoring state and a write request for the data item. Conversely, a cache item with an external snoop indicating a data item in a buffered write state and a read request for the data item may be considered to be collidable. In one embodiment, to detect such a combination of access request and attribute status, the snoop logic is connected to conflict detection / reporting logic such as monitors and / or logic for collision detection / reporting as well as status registers for reporting a conflict. Connected.

However, a combination of conditions and circumstances may be considered for invalidating a transaction that may be defined by any instruction, such as a commit instruction discussed in more detail below with reference to FIGS. 11-12. Examples of factors that can be considered for non-commit of a transaction include: detection of conflicts with transactionally accessed memory locations, loss of monitor information, loss of buffered data, transactionally accessed data items Loss of metadata associated with and detection of other invalidation events such as interrupts, ring transactions, or explicit user instructions.

In one embodiment, the hardware of the processor 100 allows for retaining transaction updates in a buffered manner. As mentioned above, transaction records are not visible at all until the transaction is committed. However, the local software thread associated with the transaction record can access transaction updates of subsequent transaction accesses. As a first example, a separate buffer structure is provided within processor 100 that holds buffered updates that can provide updates to a local thread rather than other external threads. Including separate buffer structures can be expensive and complex.

Conversely, as another example, cache memory such as data cache 150 may be utilized to buffer updates while providing the same transactional functionality. Here, cache 150 may hold data items in a buffered coherency state, in which case a newly buffered coherency state is added to a cache coherency protocol such as a Modified Exclusive Shared Invalid (MESI) protocol to form the MESIB protocol. . In response to a local request for a data item held in a buffered data item-buffered coherency state, the cache 150 provides the data item to a local processing element to ensure an internal transaction follow-up command. However, in response to an external access request, a miss response is given to ensure that the data item updated in a transactional manner is not fully visible until committed. Also, when a line of cache 150 is held in a buffered coherency state and selected for eviction, the buffered update is not rewritten to higher level cache memories-the buffered update is incremented through the memory system. This is not the case, ie it is not entirely visible until after commit. Upon commit, the buffered lines are transitioned to a transformed state that makes the data item visible as a whole.

It should be noted that internal and external conditions usually relate to the view of a thread associated with the execution of a transaction or processing elements that share a cache. For example, the first processing element for executing a software thread associated with the execution of a transaction refers to a local thread. Thus, as discussed above, upon receiving or loading from an address previously written by a first thread that derives a cache line for an address held in a buffered coherency state, the buffered version of the cache line is removed. Since thread 1 is a local thread, it is given as the first thread. Conversely, the second thread can run on other processing elements within the same processor, but is not associated with the execution of a transaction that is responsible for the cache line held in a buffered state—external thread; Thus, loading or storing from the second thread to the address omits the buffered version of the cache line, and normal cache replacement is utilized to retrieve the unbuffered version of the cache line from the upper level memory.

Here, internal / local and external / remote threads run on the same processor, and in some embodiments may run on separate processing elements within the same core of the processor sharing access to the cache. However, the use of these conditions is not limited thereto. As mentioned above, local refers to a number of threads that are not specific to a single thread associated with a transaction execution but share access to a cache, and external or remote may refer to threads that do not share access to that cache. .

As described above in the initial reference of FIG. 1, the structure of the processor 100 is merely illustrated for purposes of discussion. Similarly, certain examples of translating data addresses that reference metadata are also exemplary because any method of associating data with metadata of individual entries in the same memory can be utilized.

Abstract address space for metadata

Metadata

2, an embodiment of retaining metadata for a data item in a processor is illustrated. As depicted, metadata 217 of data item 216 is retained inside memory 215. The metadata includes certain properties or attributes associated with the data item 216, such as transaction information associated with the data item 216. Some illustrative examples of metadata are included below; Examples of the disclosed metadata are also merely illustrative and not inclusive of a comprehensive list. In addition, metadata location 217 may hold any combination of other attributes for data item 216, examples discussed below, and not specifically discussed.

As a first example, metadata 217 may reference a reference to a backup or buffer location of data item 216 that has been written transactionally, if data item 216 was previously accessed, buffered, and / or backed up during any transaction. Include. Here, in some implementations a backup copy of a previous version of data item 216 is retained in another location, such that metadata 217 includes an address or other reference to the backup location. Alternatively, the metadata 217 itself may act as a backup or buffer location for the data item 216.

As another example, metadata 217 includes filter values for accelerating repetitive transaction access to data item 216. Usually, during execution of a transaction utilizing software, access barriers are enforced in transactional memory access to ensure consistency and data validity. For example, prior to a transaction load operation, a read barrier is executed to test whether the data item 216 is unlocked, determine if the current set of transaction reads is still valid, update filter values, and verify the transaction to enable later verification. Read barrier operations such as writing of version values in a read set. However, if a read of that location has already been performed during the execution of a transaction, there is a possibility that the same read barrier operations are unnecessary.

As a result, one solution is to indicate that the data item 216 or its address has not been read during the execution of the transaction and that the data item 216 or its address has already been accessed during the transaction's pending. Utilizing the read filter to retain a second access value for presentation. In practice, the second access value indicates whether the read barrier should be accelerated. In this example, if a transaction load operation is received and the read filter value in metadata location 217 indicates that the data item 216 has already been read, in one embodiment the read barrier does not perform unnecessary repetitive read barrier operations. As such, they are removed to speed up transaction execution-they are not executed. Note that the write filter value can be operated in the same way with respect to the write operation. However, the individual filter values are merely exemplary, as in one embodiment a single filter value is used to indicate whether an address has already been accessed-written or read. Here, metadata access operations that check 216 metadata 217 for both load and store are different from the above examples where the metadata 217 includes separate read filter values and write filter values. To utilize. In a particular exemplary embodiment, four bits of metadata 217 are read filters that indicate whether a read barrier will be accelerated for an associated data item, a write filter that indicates whether a write barrier will be accelerated for an associated data item, canceled ( undo) is assigned to the undo filter indicating that operations should be accelerated, and to other filters to be utilized in some way by the software as filter values.

A few other examples of metadata include, but are not limited to, an address indication, representation, or reference of a handler specific to or inclusive of a transaction associated with the data item 216, a non-reversible / hard to process transaction of the transaction associated with the data item 216. Loss of item 216, loss of monitoring information for data item 216, collision detected for data item 216, address of a read set associated with data item 216 or a read entry in the read set, a data item The previously recorded version of 216, the current version of data item 216, the lock that allows access to data item 216, the version value of data item 216, and the transaction of the transaction associated with data item 216. Descriptors, and other known transaction association description information. In addition, as described above, the use of metadata is not limited to transaction information. As a result, metadata 217 may also include data item 216 association information, properties, attributes, or states that are not associated with a transaction.

Continuing to discuss the metadata example, the hardware monitor and buffered coherency states described above are also considered for the metadata of certain embodiments. The monitors indicate which location should be monitored for an external read for an ownership request or an external read request, and the buffered coherency state indicates whether the associated data cache line holding the data item is buffered. Further, in the above examples, the monitors are maintained as attribute bits added to or directly associated with cache lines, and the buffered coherency state is added to the cache line coherency state bits. As a result, in this case, the hardware monitors and buffered coherency states are part of the cache line structure, rather than being held in a separate abstract address space like the illustrated metadata 217. However, in other embodiments the monitors may be retained as metadata 217 of a different memory location than the data item 216, likewise metadata 217 indicates that the data item 216 is a buffered data item. May contain a reference. Alternatively, instead of the update-in-place structure in which the data item 216 is updated and held in a buffered state as described above, the metadata 217 may retain the buffered data item, The overall visualized version of the data item 216 is kept in its original location. Here, at commit, the buffered update held in metadata 217 replaces data item 216.

Lost  Metadata

Similar to the above discussion with reference to buffered cache coherency states, metadata 217 is lossy local information provided for external requests outside the memory 215 domain in one embodiment. In one embodiment, assuming memory 215 is shared cache memory, a miss in response to the metadata access operation is not serviced outside the cache memory 215 domain. In practice, since the lost metadata 217 is only held locally within the cache domain and does not exist as persistent data throughout the memory subsystem, there is no reason to forward such misses out of service to service requests from higher level memory. none. As a result, misses on lost metadata are likely to be serviced quickly and efficiently; Immediate allocation of memory in the processor can be made without waiting for an external request for metadata to be generated or serviced.

Abstract address space

As the illustrated embodiment depicts, the metadata 217 is held at a memory location—another address—separate from the data item 216, which derives a separate abstract address space for the metadata; Metadata access operations on an abstract address space-abstract address space orthogonal to the data address space do not touch or modify the physical data entry. However, in embodiments where metadata is held in the same memory, such as memory 215, the abstract address space may affect the data address space through contention for allocation in memory 215. By way of example, data item 216 is cached in some entry in memory 215, and metadata 217 of data 216 is retained in another entry in the cache. Here, subsequent metadata operations may result in memory location selection of data item 216 for retirement and replacement of other data items with metadata. As a result, operations associated with the address of metadata 217 do not touch data item 216, but the metadata address of the metadata element may replace physical data, such as data item 216 in memory 215.

In this example, even though metadata is likely to compete with data for space in cache memory, the ability to retain metadata internally does not allow metadata to be consumed without the expensive cost of perpetuating persistent metadata across the memory hierarchy. Efficient support can be derived. As estimated through the assumption of this example, the metadata is held in memory 215 which is the same memory; However, in another alternative embodiment / metadata 217 for data item 216 is retained in a separate memory structure. Here, the metadata and the address of the data may be the same, and the abstract portion of the metadata is indexed into a separate metadata storage structure instead of the data storage structure.

In a one-to-one ratio of metadata to data, the abstract address space shadows the data address space, but remains orthogonal as discussed above. Conversely, as discussed below, metadata can be compressed for physical data. In this case, the size of the abstract address space for the metadata does not shadow the size of the data address space but remains in an orthogonal state.

Abstract address translation

Continuing with the discussion of the abstract address space, any method of translating a data address, such as the address of data item 216 in the data address space, into an abstract address, such as the metadata address of metadata 217 in the abstract address space, may be used. . In one embodiment, abstract translation logic 210 is used to translate an address, such as data address 200, into a metadata address. The depicted address 200 includes an address associated with or referring to the data item 216. Ordinary data translations, such as translations between physical or linear addresses and virtual addresses, may be used to index into data items 216 in memory 215. In addition, the association of the metadata 217 with the data item 216 includes a similar translation of the address 200 referring to the data item 216 into another separate address referring to the metadata 217, Thus, the translation of the data address using the data translation logic 205 and the address 200 translation to a separate abstract address using the abstract translation 210 results in separate accesses that do not interfere with each other-creating orthogonal characteristics of the two address spaces. . As discussed in more detail below, the use of data translation 205 or abstract transformation 210 in one embodiment is based on the type of operation that accesses address 200—usually accessing data item 216. Access of the data uses the data transformation 205 and the metadata access operation to access the metadata 217 uses the abstract transformation 210, which is identified through a portion of the instruction / operation operation code (operation code). Can be.

In another embodiment, the instruction identified by the operation code can access both data and metadata for a given metadata address, thereby performing a complex operation such as conditional storage for data based on the metadata. Can be. For example, a command is decoded into a test and setup metadata operation that tests the metadata and sets it to a value, as well as an additional operation that sets the data to a value when the test of the metadata is successful. As another example, data items may be moved to matching metadata addresses based on reading data from the data memory.

Examples of translating data address 200 into a metadata address of metadata 217 are included directly below. As a first example, translating a data address into a metadata address utilizes a physical address or a virtual address—after normal data translation 205—and adds abstract values using abstract translation logic 210 to add data. Separating the addresses from the metadata address. In situations where virtual addresses are used without translation, abstract translation logic 210 includes logic to associate virtual addresses with abstract values. However, if a general virtual address to physical address translation is utilized, then general data translation 205 is used to obtain a translated address from address 200, where abstract translation logic 210 abstracts the translated address. Logic to form a metadata address in association with the value. As another example, data address 200 may be translated using separate translation structures, tables, and / or logic within abstract translation 210 to obtain separate metadata addresses. Here, the abstract transformation logic 210 may reflect or include a logic that associates the address 200 with a separate logic-abstract value compared to the data transformation logic 205, while the abstract transformation logic 200 may include an address 200. ) Is used to convert page table information to other distinct metadata addresses. Through addition of information to obtain metadata addresses, expansion with attached information, replacement of information, or conversion of data addresses, the result is that separate metadata addresses are orthogonal from incorrectly updating or reading data items. It is associated with the data item via an add, extend, replace, or transform algorithm, while maintaining it.

A few specific illustrative examples of converting a data address into a metaaddress, or in other words determining a metadata address based on / from the data address, are described below. (1) converting the first data address into a second data address using a normal virtual address to physical address translation, and adding or including an abstract value to the data address to form a metadata address; (2) do not perform a virtual to physical address translation for the data address or add or include abstract values in the data address to form a metadata address; (3) convert the data address using abstract translation table logic, which may include, but not necessarily include, abstract values in the translated metadata address to form the metadata address. To converted metadata addresses. In addition, any of the above-described transformation techniques may include storing the metadata separately for each compression ratio, including, based on, the compression ratio of data to metadata.

Here, the address for translation and / or compression ignores specific bits of the address, removes specific bits of the address, changes the bit range of the address used to select various granularities for the data, converts specific bits and Specific bits may be modified by adding or replacing certain bits to metadata association information. Compression is discussed in more detail below with reference to FIG. 4.

Multiple abstract address spaces

3, an embodiment that supports several abstract address spaces is illustrated. In one embodiment, each processor element is associated with an abstract address space, allowing each processing element to maintain its own metadata. Four processing elements 301-304 are depicted. As discussed above, the processing element may include any of the elements described above with reference to FIG. 1. As a first example, processing elements include cores of a processor. However, as an illustrative example further discussed below, processing elements 301-304 will be discussed with reference to hardware threads (threads) in the processor; Each hardware thread executes a software thread and possibly several software subsystems.

Thus, it may be desirable to enable individual threads of threads 301-304 to maintain separate metadata. In one embodiment, abstract translation logic 310 is to associate access from several threads 301-304 with their appropriate abstract address spaces. As an example, the thread identifier (ID) used with the address referenced by the metadata access operation is indexed into the appropriate abstract address space.

For illustration, it may be assumed that a metadata access operation is received that is associated with thread 302 and references data address 300 of data item 316. As described above, any translation method may be used to translate the data address of the data item 316 into a metadata address. However, the translation further includes an association with thread ID 302, which may be obtained, for example, from a control register of thread 302 or an operation code of an instruction received from thread 302. Such association may include adding thread ID 302 to an address, replacing bits in the address, or other known method of associating a thread ID with an address. As a result, abstract translation logic 310 may select / index into an abstract address space associated with data item 316 of processing element 302.

Inferred from the example, by utilizing the thread IDs of the threads 301-304 as part of the translation to an abstract address, each processing element 301-304 maintains its own metadata for the data item 316. Can be. However, the programmer does not need to manage the abstract address spaces separately because the hardware can keep them separate through the use of thread IDs in a way that is transparent to software. In addition, abstract address spaces are orthogonal—one metadata access from one thread does not access metadata from another thread, each associated with a separate set of addresses containing a reference to a unique thread ID. Because it becomes.

As discussed below, for instructions / operations that access metadata, access to metadata from another thread is supported for metadata access from one thread. That is, in some implementations, access to PEIDs and / or MDIDs (discussed below) may be desirable. For example, determine if the hardware has detected a conflict, check the metadata monitor from another thread, determine if an associated data item is being monitored by another thread, remove metadata from another thread, or commit conditions. To determine, a thread can check, modify, or clear the metadata of another thread associated with data item 316.

Here, a specific operation code for an operation that accesses another thread's metadata is recognized, and as a result, abstract translation logic 310 performs translation of address 300 to all metadata addresses so that the metadata is accessed. As a specific illustrative example, four bits are added to address 300 and each bit represents one of the processing elements 301-304, and a metadata access operation, such as a clear operation, is performed on all data items 316. If it is necessary to clear the metadata, the abstract transformation logic 310 sets each of the four bits to access all metadata 317. Here, the lookup logic for the memory 315 where a single access with all four bits set accesses all metadata 317 is designed, or the abstract transformation logic 310 is set to access all metadata 317. Four separate accesses can be created using different thread ID bits of the four bits. As an illustrative example, a mask can be applied to an address value so that one thread can touch the metadata of another thread.

As illustrated, each processing element 301-304 may be associated with several abstract address spaces to interleave several contexts or software subsystems within a single thread into several metadata address spaces. For example, in some situations, it may be desirable to allow multiple software subsystems within a single processing element to maintain unique metadata sets. Thus, in one example, orthogonal metadata address spaces may be provided at various processing element levels, such as core level, hardware thread level, and / or software subsystem level. In an example, each processing element 301-304 is associated with two abstract address spaces, each one of which must be associated with software subsystems to execute in one of the processing elements.

A software server system includes any task or code to be executed on processing elements that can utilize a separate abstract address space. As an illustrative example, four subsystems that may be associated with individual abstract address spaces include a transactional runtime subsystem, a garbage collection runtime subsystem, a memory protection subsystem, and a software translation system. May be executed on the processing element. Here, each software subsystem can control the processing elements at different points in time. As another example, the software subsystem includes individual transactions executed within one processing element. In fact, it may be desirable for nested transactions executing on the same thread to be associated with separate abstract address spaces. For illustrative purposes, a second test filter for accessing the same data item in an internal nested transaction may be failed, so that the filter test for accessing the data item in an external transaction may fail. It may be desirable to provide. In addition, when nested transactions are aborted so that metadata for external transactions can be maintained, each nested transaction-subsystem is associated with a separate metadata space so that the clearing of the metadata of internal nested transactions is external. Do not affect the metadata of the transaction. However, the software subsystem may be any task or code capable of managing metadata, so it is not limited to such.

In one embodiment, to provide orthogonal abstract address spaces at the software subsystem level, an address is associated with a processing element ID (PEID) as discussed above; It is also associated with other metadata IDs (MDIDs) or context IDs. Thus, each metadata is uniquely identified for a subsystem within a processing element. Using the example above, it can be assumed that the processing elements 301-304 are hardware threads, and the thread 302 executes an external transaction and an internal transaction nested within the external transaction. For external transactions, metadata 317c converts data address 300 of data item 316 to address plus thread ID (TID) and metadata ID (MDID) for external transactions that reference metadata 317c. Associated with the data item 316 through an abstract transform 310 that transforms.

By way of example only, the metadata 317c may include four filter value-read filter values, a write filter value, a cancel filter value, and other filter values, pointers or other references to the location of the entry of the data item 316, data A monitoring value indicating that monitors for item 316 have been lost, a transaction descriptor value, and a version of data item 316. Similarly, an internal transaction is associated with metadata 317d that includes metadata fields such as in metadata 317 for data item 316. As above, the abstract translation 310 translates the data address 300 of the data item 316 into an address associated with the thread ID and metadata ID for the internal transaction, which refers to the metadata 317d.

Here, the only difference between the metadata address referring to metadata 317c and the metadata address referring to metadata 317d may be the metadata ID for the external transaction and the internal transaction; This address difference causes the address space to be dismantled / orthogonal-access to metadata from an inner transaction will not affect metadata from an outer transaction, which means that the MDID for access from an inner transaction is Because will be different. As mentioned above, this may be desirable for rolling back nested transactions or holding different metadata values for different levels of transactions. Specifically, if the internal transaction is aborted, the backup data of the data item 316 held in the internal transaction metadata 317d without removing or affecting the backup data of the external transaction held in the metadata 317c. May be removed or used to roll back data item 316 to an entry point prior to an internal transaction.

It should be appreciated that the metadata ID (MDID) for distinguishing software subsystem abstract address spaces can be of any size and can come from several sources. As an oversimplified example, when using four processing elements (PEs) 301-304, the PEID may come from a combination of two bits-00, 01, 10, 11. Similarly, if four respective abstract address spaces are supported, two bits of MDID-00, 01, 10, 11 can likewise distinguish between the four subsystems. For illustration purposes, the value for representing both the processing element 302 and the subsystem within the PE 302 includes 0101 (the first two bits are 01 for the PE 302 and the second two bits are secondary subs). 01 for the system). In this example, the abstract translation logic associates this value with metadata address 300 or its translation value to refer to PE 302 MDID 01, which includes metadata location 317d.

However, both thread ID and MDIDs can be more complex. For example, one can assume that threads 301-302 share access to memory 315, and threads 3030-304 are remote processing elements that do not share access to memory 315. FIG. have. In addition, each of threads 301-302 has two totals of four orthogonal address spaces of threads 301-302-PE 301 MDO, PE 301 MDl, PE 302 MDO, and PE 302 MDl address spaces. Support subsystems. In this case, the value of the thread ID associated with the MDID used to obtain the metadata address may come from an operation code, a control register, or a combination thereof. For illustration, the operation code provides one bit for the context / MDID, and the control register provides one bit for the processing element ID (PEID) —only two processing elements, and metadata control such as MDCR 320. Assume a register provides four bits to identify a particular software subsystem / context for larger granularity. Thus, when a metadata access operation referring to the address 300 of the data item 316 is received from the second thread-PE 302, it contains one to indicate one bit-second context of the operation code. And a second bit from the control register for the processing element 302-including 1 pointing to the processing element 302-from the metadata control register (MDCR) 320 associated with the second thread. Associated with MDID; The MDCR has been previously updated by the MDID of the current subsystem controlling second thread-0010- to identify the appropriate subsystem associated with the received operation. The abstract translation logic takes an associated value, such as 110010, and again associates it with the referenced data address 300 or its translation to obtain a metadata address. However, since the 110010 portion of the metadata address is unique to the subsystem from which the access operation originated, it is the metadata addresses 317a, b, c, e, f, g, h) —the second thread and two other threads. It will only touch or modify the metadata address 317d in memory 315 without touching or affecting orthogonal abstract address spaces of other subsystems within it.

As a specific illustrative example, a discussion of certain forms of MDCR is included. In some embodiments, ISA may be extended using a thread-specific metadata identifier register (MDID register) that sources MDID to MDID-sensitive metadata load / store / test / setup instructions. In some embodiments, it is convenient to have such a plurality of registers. For example, the MDCR: Metadata Control Register is a 32 bit read-write register and contains the current Metadata Context ID (MDID). It can be updated by the CR MOV. A typical bitfield definition is as follows:

MDID 0 and MDID 1 are metadata IDs that can be accessed simultaneously in the instruction set. The number of bits actually used in these fields is MDID_size, which is only read at certain tolerance levels as specified in the processor design in one embodiment. However, in one embodiment various level privilege levels may modify the size. There will not be any hardware check that the MDID guarantees to match the bit allocation within that size. In one embodiment, MDID 0 and MDID 1 can be written and read at any acceptable level. It may also be possible to specify special metadata spaces that are always read as 0 or 1 using special MDID values. This may be used by software forcing all metadata tests in a block to be true or false in a manner similar to the discussion of registers to enforce metadata values with reference to FIGS. 6 and 7.

However, in another example, as described above, abstract transformation logic 310 associated with decoders (not shown) may cause metadata access operations to access metadata from the thread's metadata address space from thread 302. And may allow access to such specific instructions / operations to read or modify the thread 301's metadata.

Compression of Metadata for Data

Above, the one-to-one mapping from data to metadata to uncompressed metadata is discussed; In some circumstances, however, utilizing a smaller amount of metadata than data—compression of the metadata when the size of the metadata is smaller than the data—is more efficient. 2-3, the abstract address translation logic 210 and 310 may refer to the compressed metadata accordingly in consideration of compression when performing the translation and modification of the address. Referring to FIG. 4, an embodiment of modifying an address to perform compression of metadata is illustrated; In particular, an embodiment is described in which the compression ratio of data to metadata is eight. Control logic, such as abstract address translation logic 210 and 310 from FIGS. 2-3, must receive the data address 400 referenced by the metadata access operation. By way of example, compression includes shifting or removing a log2 (N) number of bits in or out of address 400, where N is the compression ratio of data to metadata. In the example shown for a compression ratio of eight, three bits are shifted down and removed for metadata address 405. Practically, address 400, which contains 64 bits to refer to a particular data byte in memory, forms the metadata byte address 405, which is used to refer to metadata in memory in three subsections, with the three bits truncated. ; Among them, the bits of metadata are selected using the three bits previously removed from the address to form the metadata byte address.

In one embodiment the shifted / removed bits are replaced with other bits. As illustrated, the upper bits are replaced by zero after the address 400 is shifted. However, the removed / shifted bits may be replaced with other data information, such as processing element ID, context identifier (ID), and / or metadata ID (MDID) associated with the metadata access operation. In this example, the least significant bits are removed, but bits at any location based on any number of factors, such as cache structure, cache circuit timing, locality of metadata for data, and minimizing collisions between data and metadata. Even they may be removed and replaced.

For example, the data address will not be shifted by log ₂ (N), instead address bits 0: 2 are zeros. As a result, the bits of the same physical address and the virtual address are not shifted as in the above example, but consider the setting and preselection of the bank with unmodified bits such as bits 11: 3.

It should be noted that discussions associated with transformations may be associated with compression. That is, the compression ratio may be input into the abstract address translation logic 210 from Figures 2-3, which translation logic may be a PEID, CID, MDID, abstract value, or other for converting a data address into a metadata address. Use that compression ratio with the information. The metadata address is utilized here to access the memory holding the metadata. As discussed above, since metadata is a lossy local structure, there is no generation of miss-external miss service requests for memos based on metadata addresses and no allocation of memory locations of memory locations waiting for external requests to be serviced. Allocation can be serviced quickly and efficiently. Here, an entry is assigned in the usual way for metadata. For example, an entry, such as entry 217 from FIG. 2, is selected, assigned, and initialized with a metadata default value based on a cache replacement algorithm, such as metadata address 405 and Least Recently Used (LRU) algorithm. As a result, while metadata is likely to compete with regular data for space, it remains compressed and decomposed from other software subsystems / processing elements.

It should be noted that the compression ratio of 8 is merely exemplary and any compression ratio may be used. As another example, a compression ratio of 512: 1 is used-one bit of metadata represents 64 bytes of data. As above, the data address is translated / modified from the metadata address via a downward shift of log2 (512) bits-9 bits. Here, bits 6: 8 instead of bits 0: 2 continue to be used to select the bits, effectively making compression through the selection of 512 bit granularity. Since the data address has been shifted nine bits, the upper portion of the data address has nine bit positions open to hold information. In one embodiment, the 9 bits are for holding identifiers such as context ID, thread ID, and / or MDID. In addition, abstract spatial values may also be held in these bits, or the address may be extended by an abstract value. In one embodiment, multiple simultaneous compression rates are supported by the hardware.

Here, the representation of the compression ratio is retained as part of the abstract value associated with the data address to obtain the metadata address. As a result, the compression ratio is taken into account during memory retrieval using data addresses, and the compression ratio does not match the addresses of other compression ratios. Software may also rely on hardware to not forward stored information to loads of different compression ratios.

In one embodiment, the hardware is implemented using a single compression ratio but includes other hardware support that provides multiple compression ratios to the software. As an example, it can be assumed that the cache hardware is implemented using an 8: 1 compression ratio as illustrated in Figure 4: A metadata access operation that accesses metadata at various granularities is a microcomputer for reading the default amount of metadata. It is decoded to include a microoperation for testing the appropriate portion of the operation and metadata readout. As an example, the default amount of metadata read is 32 bits. However, the test operation for another granularity / compression of 8: 1 tests the appropriate bits of the 32 bits of metadata read, which may be based on the context ID and the number of bits in the address, such as the number of LSBs in the metadata address. do.

For example, in a scheme that supports metadata of unaligned data for one bit of metadata per data byte, the lower eight bits of the 32 read bits of metadata based on the three LSBs of the metadata address. One bit is selected from. In the word of data, two consecutive metadata bits are selected from the lower 16 bits of the read metadata 32 bits based on the three LSBs of the address, and continue to 16 bits for a 128 bit metadata size.

Metadata Access Command / Operation

5, a flow diagram of a method of accessing metadata associated with data is illustrated. Although the flowchart of FIG. 5 is illustrated substantially sequentially, at least some may be performed in a parallel manner and possibly in other orders.

In step 505, a metadata operation that references a data address of a predetermined data item is encountered. It was mentioned in the above discussion that metadata instructions / operations may be supported through hardware that reads, modifies, and / or clears metadata. That is, the instructions are supported through the processor's instruction set structure (ISA), allowing the decoders of the processor to recognize the operation codes (operation codes) of the instructions to access the data and hence the logic to perform the access. Note that the use of an instruction may mean an operation. Some processors are decoded into a metadata test operation / microoperation that tests the metadata, and if the correct boolean value is obtained as a result of the test operation, then the set operation will update the metadata to a specific value, such as test and setup metadata macro instructions. It utilizes the concept of macro instructions that can be decoded into a plurality of microoperations that perform tasks.

However, metadata access operations are not limited to explicit instructions to access metadata, but rather also implicit micro-operations that are decoded as part of a larger and more complex instruction that includes access to data items associated with metadata. It may include. Here, the data access instruction can be decoded into a plurality of operations, such as an access to data and an implicit update of the associated metadata.

As discussed above, in one embodiment the physical mapping of metadata on hardware to data is not directly visible in software. As a result, metadata access operations refer to the data addresses in this example to properly access the metadata and rely on hardware to perform the correct translation, ie mapping. Metadata access operations may individually reference each abstract address space depending on which thread, context, and / or software subsystem they originate from. Thus, the memory can hold metadata for data items in a manner that is transparent to software. When the hardware detects an access operation for metadata through explicit operation code (op code of the instruction) or through instruction decoding into the metadata access micro operation (s), the hardware accesses the metadata accordingly. To perform the necessary translation of the data address referenced by the access operation.

As shown in this example, the program may include individual operations that reference the same address of the data item, such as data items 216 and 316 from FIGS. 2-3, such as data access operations or metadata access operations, Can map these accesses to different address spaces, such as a physical address space and an abstract address space. In some embodiments, the ISA may be extended with instructions to load / store / test / set metadata for a given virtual address, MDID, compression ratio, and operand width. Any of those parameters may be explicit instruction operands, encoded with an operation code, or obtained from a separate control register. The instructions can associate a metadata load / store operation with other operations, such as operations that load some data, test some of its bits, and set a condition code for subsequent conditional jumps. The instructions may also flush all metadata, or only metadata for a particular MDID. Several exemplary metadata access operations are listed below. Some of the typical instructions are associated with particular 64x compression ratio instructions, although similar instructions for other compression ratios and uncompressed metadata may be used, although not specifically discussed.

Testing and setting metadata bits MDLT )

The metadata load and test instructions (MDLT) are two arguments: a data address to which metadata is associated as a source operand and a register into which metadata of different sizes, including bytes, words, words, or bits, is written. Destination operand). The value of the tested metadata bit is written into the register. The programmer must not assume any knowledge of the data stored in the destination register of the MDLT instruction and must not manipulate this register. This register should only be used as the source operand of the Metadata Save and Set Instruction (MDSS) for the same address. In one embodiment, the MDLT instruction will associate test and setup operations, but will squash the setup operation if the test is successful.

Save and set up metadata MSS )

The Metadata Save and Set Instruction (MDSS) takes two arguments: a data address with which the metadata is associated and a register to which metadata of different sizes, including bytes, words, words, or bits, appears and is stored in memory. (Source operand). The MDSS instruction will set the correct bit in the value from its source operand.

Metadata save and reset command ( MDSR )

The MDSR instruction has two source arguments: a data address with which the metadata is associated as a source operand and a register to which other size metadata, including bytes, words, words, or bits, is returned and reset. The MDSR instruction will reset the correct bit to the value from its source operand.

The metadata address is determined from the referenced data address. Examples of determining metadata addresses are included in the abstract address translation and various abstract address space sections. However, such a transformation may include storing the metadata separately for each compression ratio, including, based on, the compression ratio of data to metadata.

Test metadata ( CMDT )

The CMDT instruction converts the memory data address into a memory metadata address using a compressed mapping function that is implementation-dependent, and tests whether the metadata bit corresponding to the memory metadata address is set. As an example, the compression ratio CR is 1 bit for 8 bytes. The metadata address calculation includes one of the context IDs from the MDCR register to provide a unique set of MDs for each individual context ID addressing MDBLK [CR] [MDCR.MDID [MDID number]]. META. . The instruction forces alignment by aligning the address 'mem' to the specified data size. The command tests whether metadata is set.

Below is an example pseudo code associated with the CMDT (ZF flag is set to 0 to indicate zero metadata value. All other flags are cleared):

if (TxCR.FORCE == 0) {

cr: = 64 // only 1 bit for 8 bytes is supported

mdid: = MDCR [MDID_0] // bits 0:14

ZF: =! GetMetaDataBit (addr, cr, mdid)}

64MDT1 addr

FLAGS: = 0

if (TxCR.FORCE == 0) {

cr: = 64 // only 1 bit per 8 bytes is supported

mdid: = MDCR [MDID_1] // bits 15:27

ZF: =! GetMetaDataBit (addr, cr, mdid)}

Store compressed metadata ( CMDS )

The CMDS instruction converts memory data addresses into memory metadata addresses using a compressed mapping function that is implementation dependent. The compression ratio is 1 bit for 8 bytes of data. The encoding of imm8 values is as follows: 0-> MD_Value; Value to be stored in MD, and 7: 1-> spare; Not used

The following includes example pseudo code associated with a CMDS:

Write MDBLK [64] [MDCR.MDID [MDID number]] (addr) .META = MD_value

operation

C64MDS0 addr

cr: = 64 // only 1 bit per 8 bytes is supported

mdid: = MDCR [MDID_0] // bits 0:14

StoreMetadataBit (addr, cr, mdid, imm8 [0])

C64MDS1 addr

cr: = 64 // only 1 bit per 8 bytes is supported

mdid: = MDCR [MDID_1] // bits 15:27 StoreMetadataBit (addr, cr, mdid, imm8 [0])

Implementation Note: The instruction will perform a read-set bit-write operation on the metadata.

Flags Affected: None

Exceptions in protected mode and compatibility mode

#UD if CR4. OSTM [bit 15] = O

No #PF

64-bit mode exception

#GP (0) When the memory address is in a format not defined by the definition

Compressed Metadata clear ( CMDCLR )

The CMDCLR instruction resets all MDBLK [CR] [MDCR.MDID [MDID number]]. META corresponding to any data in the range including MBLK (mem).

Typical pseudo code associated with a CMDCLR is included below:

operation

C64MDCLR0

cr: = 64 // only 1 bit per 8 bytes is supported

mblk: = floor (addr, MBLK_SIZE)

mdblkStart: = mblk

mdblkEnd: = floor (mblk + MBLK_SIZE-1, MDBLK_SIZE)

mdid: = MDCR [MDID_0)] // bits 0:14

StoreMetadataBit (addr, cr, mdid, 0) for all mdblks in Mblk DO

C64MDCLR1

cr: = 64 // only 1 bit for 8 bytes is supported

mblk: = floor (addr, MBLK_SIZE)

mdblkStart: = mblk

mdblkEnd: = floor (mblk + MBLK_SIZE-1, MDBLK_SIZE)

mdid: = MDCR [MDID l] // MDCR [27:15]

StoreMetadataBit (addr, cr, mdid, 0) for all mdblks in Mblk DO

Implementation Note: The first implementation will be 1 byte clear for 64: 1 CR supported.

Flags Affected: None

Exceptions in protected mode and compatibility mode

#UD CR4.OSTM [bit 15] = 0

64-bit mode exception #GP (0) The memory address is in an undefined format

Next, in step 510, the metadata address is derived from the data referenced in the metadata access operation based on the compression ratio, processing element ID, context ID, MDID, abstract value, operand size, and / or other abstract address space translation association values. Is determined. Any of the methods described above, such as combining ID values with no data address translation, normal data address translation, or separate abstract address translation of data addresses, may be used to obtain appropriate metadata addresses.

In addition, as described above, in some cases one version of a test, set, clear, or other instruction is provided so that one thread or metadata context can test, set, or clear the metadata of another thread or metadata context. do. As a result, the translation to metadata address may include modification of the address, such as application of a mask, to allow access from one thread or context ID to access another thread or context ID.

In step 515, the metadata referenced by the metadata address is accessed. Normally, the disjoint location of the metadata associated with the local request thread or context ID is accessed and appropriate operations such as test, set, and clear are performed. In other cases, however, metadata for other threads or context IDs may also be accessed at this stage as described above.

abstraction

Included herein are embodiments of abstract concepts for software. The given CR is a power of 2 indicating how many data bits are mapped to one bit of metadata. It is an implementation that defines which CR's values can be used, if any. CR> 1 represents compressed metadata. CR = 1 Indicates uncompressed metadata.

MDBLK [CR] [*] are ceil (CR / 8) bytes in size and are of course aligned. MDBLKs are associated with physical data rather than their linear virtual addresses. All valid physical addresses A with the same value floor (A / MDBLK [CR] [*] _ SIZE) represent the same sets of MDBLKs.

For a given CR, there may be several separate MDIDs, each representing a unique metadata instance. The metadata of a given CR and MDID is distinguished from the metadata of any other CR or MDID. For example, for Thd # 0, assuming that addr is QWORD aligned, the metadata block referenced by MDBLK [CR = 64] [MDID = 3] (addr) is MDBLK [CR = 64] [MDID = 3] (addr + 7), but is distinct from MDBLK [CR = 64] [MDID = 4] (addr) and MDBLK [CR = 512] [MDID = 3] (addr).

Certain implementations may support multiple concurrent contexts, the number of contexts will depend on the CR and certain configuration information associated with the particular system to which the processor is part. For uncompressed metadata, there is a QWORD of metadata for each QWORD of physical data.

Metadata is interpreted only by software. The software can set, reset, or test the META for a particular MDBLK [CR] [MDID], reset the META for all MDBLK [*] [*] s of Thd, or cross a given MBLK (addr). You can reset the META of all MDBLKS [CR] [MDID] of Thd.

Metadata Loss. Some META characteristics of Thd may be spontaneously reset to zero to generate a Metadata Loss event.

Forced Metadata Value

With reference to FIG. 6, an embodiment is provided that provides hardware support for forced metadata values. STMs usually utilize access barriers to ensure consistency between memory access operations. For example, prior to memory access to a data item, the metadata location or lock location associated with that data item is checked to determine if the data item is available. Other possible barrier operations are to acquire a lock, such as a read lock, write lock, or other lock, on a data item at the metadata or lock position, to record / store a version of the data item in the read or record set to be transacted, and at that point in time. Determining if the read set to be transacted is still valid, buffering or backing up the value of the data item, setting monitors, updating filter values, as well as some other transactional operations.

However, subsequent accesses to the same data item, usually within a transaction, incur the overhead of executing an associated transaction barrier whenever an access to that data item occurs. Three writes to address A are performed within a transaction, and in this scenario it illustrates an example in which it results in executing the write barrier three times separately to obtain a write lock for address A. Since the lock on address A has already been obtained through the execution of the write barrier of the first transaction write, the two write barrier runs that follow before the last two transaction writes become unnecessary—the lock on address A does not need to be acquired again.

Thus, in one embodiment, the hardware retains filter values to speed up execution associated with these barriers. The filter value may be included in the cache as annotation bits, such as read and write monitors, or held in metadata locations in the abstract address space as described above. Using the above example, when the first write barrier is encountered, it updates the write filter value from the non-access value to the access value to indicate that the write barrier for address A has already met within the transaction. Thus, in the subsequent two transaction write operations within a transaction, the write filter value for address A is checked before leading to the write barrier. The filter value here does not need to run the write barrier-it includes an access value that indicates that the write barrier has already been run in a transaction. As a result, execution does not lead to a record barrier for the last two write operations. In other words, the filter value accelerates transaction execution-compared to the previous example without using a filter, there is no need to omit or include the execution of the write barrier for the last two accesses.

Read filters for load / read, cancel filters for cancel operation, and other filters for general filter operation may be used in the same manner as the write filter was used for the write / store operation.

Again, the concept associated with transaction barriers is a strong atomic, which deals with separating transaction operations from non-transactional operations. Here, transaction records to a non-transactionally loaded memory location may be a conflict that derives invalid data used by non-transactional load operations, just as transaction records to a transactionally loaded memory location may potentially conflict. Can be. In weak atomic systems, the weak atomic systems run the risk of invalid execution because no barriers or minimal barriers are inserted in non-transactional operations. Conversely, in strong atomic systems, transaction barriers are also inserted in non-transactional operations; This provides protection and separation between transactional and non-transactional operations, but at a cost—the cost of executing a transaction barrier in every non-transactional operation.

Thus, in one embodiment, the filters described above along with the ferromagnetic barriers in non-transactional operations may be considered to support various modes of the weak atomic operation. An exemplary embodiment simplified for illustration is shown in FIG. 6. Here, metadata 610 is retained in hardware for data 605 as discussed above. Metadata access 600 is received to access metadata 610. In one embodiment, metadata access includes test metadata operations for testing filters such as read filters, write filters, cancellation filters, or other filters.

Test metadata operations that test filters can come from transactional or non-transactional access operations. In one embodiment, the compiler inserts a test filter operation as a condition for executing a call to a transaction barrier in transactional and non-transactional accesses in accordance with the application code when compiling the application code. Thus, within some transactions, the filter operation is executed before the call to the barrier, and if it returns successfully, the call to the transaction barrier is not executed, thus providing the aforementioned acceleration.

When using non-transactional operations, in one embodiment, the hardware may operate in a weak atomic mode in which transaction barriers in non-transactional operations are executed, and in a strong atomic mode in which transaction barriers are executed.

An operation mode, or control 625, may be set in the metadata control register (MDCR) 615, which may be combined with the above-described MDCR version or may be a separate control register to hold the MDIDs. In other embodiments, control 625 of operation mode may be held in a general transaction control register or status register. Here, the first execution mode includes a strong atomic mode in which transaction barriers must be executed in non-transactional operations. In this case, control 625 represents a first value to indicate the strong atomic and non-transactional operation mode, such as 00. In response, logic 620, which is listed as a typical multiplexer, selects a metadata value from hardware retained metadata 610 associated with data address A to be provided to a destination register 650 of metadata access 600. In practice, barriers in the strong atomic mode are accelerated based on the actual hardware retention metadata. Alternatively, during the second execution mode, such as weak atomic and non-transactional mode, as indicated by the control 625 indicating a second value, such as 01, the metadata access 600 instead of the hardware retaining metadata 610 may be used. In response, a fixed or forced value from the MDCR is provided to the destination register 650.

In practice, in weak atomic mode, the forced value is returned in response to the test filter operation 600 to ensure that the test of the filter value always succeeds and that no call to the transaction barrier is executed prior to non-transactional memory access. 650). This assumes that the test filter operation returns a boolean value to indicate whether the filter test succeeded (the barrier would not be executed) or failed (the barrier should be executed). As a result, operation mode-weak atomic mode as long as all barriers are omitted in non-transactional operations, and second mode of operation-strong atomic mode where barriers are executed or accelerated based on hardware retained metadata in non-transactional operations To provide, such a filter software architecture is considered that accelerates transactions by omitting barriers based on the filter value. In other embodiments, various forced values may be provided for each collection. Here, in strong atomic mode, the forced value will ensure that the barrier is always executed if the test filter operation fails, and in weak atomic mode, the forced value will ensure that the barrier is not executed if the test filter succeeds.

Providing a forced or fixed value from a control register such as MDCR 615 based on control information such as control 625 has been described in connection with providing a fixed / forced or metadata value based on a mode operation. Or fixed values may be utilized for certain general metadata purposes, such as allowing data-invariant aspects to be used for general monitoring and debugging of memory accesses that can be performed on demand.

7, one embodiment of a flow diagram for speeding up non-transactional operations while maintaining atomicity in a transactional environment is depicted. In step 705, a metadata (MD) access operation occurs that references the data address. As one specific illustrative example, the MD access operation is previously used by the compiler to omit the transaction barrier from non-transactional memory access when the test returns a value (success) and the test returns a second value (failure), Contains test operations inserted to match the application code that executes the barrier. However, the test MD operation is not limited thereto and may include any test operation for returning a Boolean success or failure value.

In step 710 the operation mode is determined. Here, examples of the operation mode may be transactional or non-transactional in combination with strong or weak atomicity. Thus, one or two respective registers may hold a first bit to indicate a transactional or non-transactional operation mode and a second bit for a strong or weak atomic operation mode.

If the operation mode is transactional or non-transactional and strong atomic, then the hardware retention metadata value is provided to the metadata access operation-the hardware retention value is located in the destination register specified by the MD access operation. Conversely, if the operation mode is non-transactional and weakly atomic, then a forced MDCR fixed value is provided to the MD access operation instead of the hardware retained MD value. As a result, barriers are accelerated or not based on the hardware-retained MD value during strong atomic mode, and barriers are accelerated based on the forced MDCR value in weak atomic mode.

Buffering and Monitored  Efficient transition to state

8, one embodiment for a flowchart of a method of efficiently transitioning a block of data to a buffered dimming monitored state prior to transaction commit is illustrated. As discussed above, blocks of memory, such as cache lines holding data items or metadata, may be buffered and / or monitored. For example, coherency bits for a cache line include a representation of a buffered state, and attribute bits for the cache line indicate whether the cache line is unmonitored, read monitored, or write monitored.

In some embodiments, a cache line is buffered but not monitored, which means that data held in that cache line is lost and no monitoring is applied so that no collision for the cache line is detected. For example, data such as metadata that is local to a transaction but should not be committed can be buffered but kept unmonitored.

When a collision is detected between the buffered data and writes to the same addresses, read monitoring is applied to that data. The cache line is then moved to a buffered and read monitored state; However, a read request is sent to external processing elements that force all other copies to switch to some shared state to reach that state. Such external read requests may conflict with other processing elements that hold a write monitor on the same block / cache line.

Similarly, when a collision is detected between the buffered data and reads for the same memory blocks, write monitoring is applied to that cache line. The cache line is then moved to a buffered and write monitored state, which is accomplished by sending a read request for ownership to other processing elements that force all other copies to go into some invalid state. Similarly, collisions with any processing element that holds a read or write monitor for the same memory block are detected.

To minimize transaction conflicts, memory blocks that require transactions but ultimately do not need to be committed can be buffered as described above but kept unmonitored. However, if a block held in a buffered but not monitored state is determined to be committed, an efficient path from the buffered and unmonitored state to the committable state is provided in one embodiment as shown in FIG. 8.

As an example, a buffered update to a memory block—a cache line to hold a block— is received at step 805. Read monitoring is applied to the block before or at the same time as the buffered update. For example, the read attribute for the cache line is set to a read monitor value to indicate that the block is read monitored. However, in order to apply read monitoring, a read request is first sent to other processing elements in step 815. Upon receiving the read request, at step 820 the other processing elements detect a collision due to keeping the line already in the write monitoring state, or transition their copies to the shared state. In step 825, if there is no conflict, the cache line transitions to the buffering and read monitoring state-the cache line consistency bits are updated to the buffering consistency state and the read monitor attribute is set.

In step 830, conflicting writes are detected for the cache line based on read monitoring. In one embodiment, the read attributes are associated with snoop logic to enable an external ownership read request for the cache line to detect a collision with a read monitor set on the cache line.

Later, when step 835 needs to be committed as part of some state of the transaction, write monitoring is applied at step 840. Here, an ownership read request is sent to other processing elements in step 845, which processes the cache line in response to retaining the cache line in a read or write monitoring state to detect a conflict or transition their copy to an invalid state in step 850. . As a result, collision detection in an ownership read request considers any conflicts that will be detected at that point that substantially put the line in a committable state.

As a result, it may be desirable to transition the buffered and unmonitored blocks to a commitable state in two steps- 810 and 840-. Following ownership gain through the staged capture of read and write monitors allows multiple concurrent transactions to update the same block, while reducing conflicts between those transactions. If a transaction fails to reach the commit phase for some reason, updating the block in a buffered and read-monitoring manner will not cause another transaction to arrive in the commit state which would unnecessarily abort. Also, following the sole ownership of a block until the commit phase is a way to achieve higher concurrency between threads without sacrificing data validity.

Table E below depicts one embodiment for collision states between two processing elements, P0 and P1. For example, P0 buffered as shown in the RB column and held by P1 in read monitoring state, and P0 with cache line held in write monitoring state as shown by -W-, RW-, WB, RWB, Some states of C collide as indicated by x in the intersecting cells.

In addition, Table F below illustrates the loss of the associated attribute at the processing element P1 in response to the operations listed under P0. For example, if P1 holds a line in a buffered and read-monitored state as represented by column RB, and a save or set write monitor operation occurs for P0, P1 is at the intersection xx of the store / set WM rows and the RB column. As indicated by both read monitoring and buffering of the line are lost.

For conflicts or loss of transactional data Branch  command( JLOSS )

9, one embodiment of hardware that supports a loss instruction that jumps to a destination label based on a status value in a transaction status register is illustrated. In one embodiment, the hardware provides an accelerated way of checking the consistency of transactions. As examples, the hardware may track the loss of data monitored or buffered from the cache—eviction of buffered or monitored lines—or conflicts such as conflicting accesses to such data—requests to read ownership of the monitored line. Supporting consistency checks can be supported by providing mechanisms to track monitors for detecting snoops.

Further, in one embodiment, the hardware provides structural interfaces that allow software to access such mechanisms based on the state of the monitored or buffered data. Two such interfaces include the following: (1) instructions to read or write a status register that allows the software to explicitly poll the register during execution; (2) An interface that allows software to set up a handler that is triggered whenever the status register indicates a possible loss of consistency.

In another embodiment, the hardware supports a new instruction called JLOSS that performs a conditional branch based on the state of the HW monitored or buffered data. The JLOSS instruction branches to a label if the hardware detects a possible loss of any monitored or buffered data from the cache, or if it detects a possible conflict with any such data. The label contains some destination, such as the address of a handler or other code to be executed as a result of data loss or conflict detection.

As an exemplary embodiment, FIG. 9 depicts decoders 910 that recognize JLOSS as part of the processor ISA and decode an instruction that causes the processor's logic to perform a conditional branch based on the state of the transaction. By way of example, the status of a transaction is held in transaction status register 915. The transaction status register may represent the status of a transaction, such as when the hardware detects a collision or loss of data, referred to herein as a loss event. For illustration purposes, a conflict flag in the TSR 915 is set for the monitor indicating that the address is monitored along with a snoop for the monitored address, and a conflict flag in the TSR 912 indicates that a conflict was detected. Similarly, a loss flag is set for loss of data, such as the retirement of a line containing transaction data or metadata.

Thus, JLOSS here tests the state register when it is decoded and executed, and if there is a loss event-loss and / or conflict, the logic 925 provides the label referenced by JLOSS as execution destination 930 as the jump destination address. do. As a result, using one instruction, the software can identify the state of the transaction and guide execution to a label specified by a single instruction based on that state. Since JLOSS checks for consistency, reporting of false conflicts can be allowed-JLOSS can conservatively report that a collision has occurred.

In one embodiment, software such as a compiler inserts JLOSS instructions into program code to poll for consistency. JLOSS can be used with the main application code, but usually JLOSS instructions are utilized within the read and write barriers provided primarily in libraries to determine consistency on demand, so that execution of program code inserts JLOSS into the code. It can contain a compiler, or any form of execution of JLOSS from program code, inserting or executing instructions. Because JLOSS instructions do not require additional registers-polling by JLOSS is expected to be much faster than explicit read of status registers, since there is no need for a destination register to read status information for explicit reads. There are several embodiments of such an instruction in which a condition for checking consistency is provided either explicitly in the instruction or inherently in another control register.

As an example, the transaction status register 915 or other storage element may be used to determine whether the read monitored location was written by another agent-read conflict, the write-monitored location was written by another agent-write conflict, loss of physical transaction data, or metadata. Holds specific crash and loss status information, such as whether written by loss. Thus, various versions of JLOSS commands can be utilized. For example, JLOSS. The rm <label> command will branch to that label if any read-monitored location has been written by another agent. Hardware-accelerated STM (HASTM) can use this JLOSS.rm to accelerate consistency checks-whenever you want to ensure read-set consistency, such as after each transaction load in a native code TM system. Use JLOss.rm to quickly check for conflicting updates against read settings. In this case, the read settings can be verified using JLOSS in the read barrier, so JLOSS instructions are inserted within the library barrier or after a load operation that matches the main application code. Similar to the JLOSS.rm command that detects writes to read-monitored locations, the JLOSS.wm command may be utilized to detect any reads or writes to write-monitored locations. As another example, in a processor capable of buffering locations, the JLOSS.buf instruction may be used to determine if buffered data has been lost and as a result jump to a specific label.

The following pseudo code, labeled Pseudo Code A, provides a consistent read setting and exhibits a native code STM read barrier using JLOSS. The setrm (void * address) function sets the read monitor for the given address, and the jloss_rm () function is an implicit function for the JLOSS instruction that returns true if any conflicting accesses to the read monitored locations occurred. to be. Although this pseudo code monitors the loaded data, it is also possible to monitor transaction records (ownership records) instead. It is possible to use an instruction to associate the setting of the read monitor with the loading of the data, for example the movxm instruction to load and monitor the data. In addition to monitoring, it is possible to use it in read barriers that perform filtering, as well as in STM systems that only use hardware monitoring for read-set validation-STM systems that do not perform any software read logging and any SW validation.

Pseudo Code A: appropriate update STM , Optimal reading, Native  Code reading barrier

Type tmRd <Type> (TxnDesc * txnDesc, Type * addr) {

setrm (addr); / * Read monitor setting for loaded address * /

TxnRec * txnRecPtr = getTxnRecPtr (addr);

TxnRec txnRec = * txnRecPtr;

val = * addr;

if (txnRec! = txnDesc) {

while (! validateAndLogUtm (txnDesc, txnRecPtr, txnRec)) {

/* retry */

txnRec = * txnRecPtr;

val = * addr;

}

}

return val;

}

bool validateAndLog (TxnDesc * txnDesc, TxnRec * txnRecPtr, TxnRec txnRec) {

if (isWriteLocked (txnRec) ||

! checkReadConsistency (txnDesc, txnRecPtr, txnRec)) {

handleContention (...);

return false;

}

logRead (txnDesc, txnRecPtr);

return true;

}

bool checkReadConsistency (TxnDesc * txnDesc, TxnRec * txnRecPtr, TxnRec txnRec)

{

if (txnRec> txnDesc-> timestamp) {

TxnRec timestamp = GlobalTimestamp;

jloss _ rm Lost :

txnDesc-> timestamp = timestamp;

return true;

Lost:

if (validateReadSet (txnDesc) == false)

abortO;

txnDesc-> timestamp = timestamp;

}

TSR.status_bits = 0;

return (txnRec == * txnRecPtr); / * Check if txnrec has changed * /

}

Similarly, STM systems that do not maintain read-set consistency, such as STM for managed code, use JLOSS.rm instructions such as loop back edges or instructions that can cause exceptions at other critical control point points. By inserting, infinite loops or other inaccurate control flow-exceptions due to contradictions can be avoided.

The following pseudo code, denoted pseudo code B, presents another native code reading barrier that provides consistency. This version of the TM system uses write settings that reside in the cache using updates buffered for writes in a transaction. Reads from previously buffered and then lost locations cause inconsistencies, so to maintain consistency, this read barrier avoids reading from lost locations after any buffering. The COMMIT LOCKING flag is true if STM uses a commit time lock on buffered locations. Jloss_buf () check is used for reads from a previously locked position when not using a commit time lock; In other cases it is utilized for all readings.

Pseudo Code B: appropriate update , Native  code STM  Read barrier

Type tmRd <Type> (TxnDesc * txnDesc, Type * addr) {

setrm (addr); / * Set the read monitor for the loaded address * /

TxnRec * txnRecPtr = getTxnRecPtr (addr);

TxnRec txnRec = * txnRecPtr;

val = * addr;

if (txnRec! = txnDesc) {

while (! validateAndLogUtm (txnDesc, txnRecPtr, txnRec)) {

/ * retry * /

txnRec = * txnRecPtr;

val = * addr;

}

} else if

jloss _ buf Abort;

return val;

}

Abort

AbortO;

bool checkReadConsistency (TxnDesc * txnDesc, TxnRec * txnRecPtr, TxnRec txnRec) {

if ( COMMIT _ LOCKING && jloss _ buf () == false)

abort (); / * Abort if buffered data is lost * /

if (txnRec> txnDesc-> timestamp) {

TxnRec timestamp = GlobalTimestamp;

jloss _ rm Lost :

txnDesc-> timestamp = timestamp;

return true;

Lost:

if (validateReadSet (txnDesc) == false)

abortO;

txnDesc-> timestamp = timestamp;

}

return (txnRec == * txnRecPtr); / * Check if txnrec has changed * /

}

TM systems may combine read monitoring with buffering and write monitoring as discussed above, and thus may include collision checks on the monitored or buffered lines to maintain consistency. Various embodiments include JLOSS.rm.buf (collision to read monitored or buffered locations), JLOSS.rm.wm, (collision to read or write monitored locations), or JLOSS to accommodate such a system. It may provide JLOSS types that branch on a logical combination of various monitoring and buffering events, such as * (collisions for read monitored, recorded monitored, or buffered locations).

In another alternative embodiment, the architectural interface separates the JLOSS instruction from the conditions that cause it to branch by allowing the software to set conditions—collisions for read / write monitored lines or buffered lines—in a separate control register. Let's do it. This embodiment requires only one JLOSS instruction encoding and can support future expansion into a set of events for which JLOSS should branch.

10, one embodiment of a flow diagram of a method of executing a loss instruction that jumps to a destination label based on a conflict or loss of specific information is illustrated. In one embodiment, a JLOSS instruction is received at step 1005. As mentioned above, JLOSS instructions can be inserted by a programmer or compiler into a barrier, such as within a read or write barrier, or main code following a load operation to ensure read set consistency. JLOSS instructions, and variants thereof, as discussed above, may be recognized as part of the processor's ISA in one embodiment. Here, decoders can decode operation codes of JLOSS instructions.

In step 1010, it is determined whether a collision or loss of information has occurred. In one embodiment, the type of crash or loss depends on the type of JLOSS instruction. For example, the received JLOSS command is JLOSS. In the case of the rm command, it is determined whether the read-monitored line was accessed with collision by an external write. However, as mentioned above, any variant of JLOSS can be received, such as a JLOSS instruction that allows a user to specify conditions in a control register.

Thus, if conditions are established from the type of control register or JLOSS instruction, it is determined whether the conditions have been met. As a first example, information in a transaction status register such as TSR 915 is utilized to determine if conditions are met. Here, the TSR 915 may include a read monitor status flag that is set to a no collision value by default and updated with a conflict value to indicate that a collision has occurred. However, the status register is not the only way to determine if a collision has occurred, and any known method can be used to actually determine loss or collision.

As no conflict is detected, such as when the read monitor conflict flag is still set to the default value in the TSR 915, a false value is returned in step 1025 and execution continues normally. However, if a conflict or loss is detected, such as the read monitor conflict flag is set, then at step 1015 JLOSS returns true and jumps execution to the label defined by the received JLOSS instruction of step 1020.

Transactional memory Commit  Hardware support

As discussed above, hardware-assisted transactions can accelerate versioning of software without buffering the transaction records in the cache and making them globally visible. In this case, a simple commit instruction can be used that causes the buffered values to be visible to all processors but fails if any buffered lines are lost. A hardware function that also retains metadata that software can use for acceleration, such as a filter that removes / filters redundant barriers, may wish the commit instruction to fail if the hardware detects some collision. In addition, it may be desirable to clear various combinations of information held in the hardware to transact, such as metadata, monitor, and buffered lines, upon commit.

Thus, in one embodiment, the hardware supports several forms of commit instructions so that the commit instruction can specify both the commit condition and the information to clear upon commit. Referring to FIG. 11, one embodiment of a general case of hardware to support the definition of commit conditions and clear control is illustrated.

As illustrated, the commit instruction 1105 includes an operation code 1110 that can be recognized as part of the processor ISA-the decoders 1115 can decode the operation code 1110. In the illustrated example, the operation code 1110 includes two parts, a commit condition 1111 and a clear control 1112. The commit condition 1111 is for specifying a condition of a transaction to commit, and the commit clear control 1112 specifies information to be cleared at commit of the transaction.

In one embodiment, the two parts include four values, read monitoring (RM), write monitoring (WM), buffering (Buf), and metadata (MD). Practically, if any one of the four values in part 1111 is set-if the associated attribute / characteristic contains a value indicating that it is a commit condition, then that characteristic is the condition to commit. That is, if the first bit of the conditions 1111 corresponding to read monitor information is set, the loss of any read monitoring data from the monitors 1135 associated with the transaction is aborted—commit when certain conditions of the commit instruction have failed. None. Likewise, if a value in 1112 is set, the property is cleared at commit. Continuing in this example, if the RM of the portion 1112 is set, the read monitor information in the monitors 1135 of the transaction is cleared when the transaction is committed. Thus, in this example there is the possibility of four conditions multiplied by four clear controls for a commit that derives 256 possible combinations as a variant to the commit instruction. In one embodiment, by allowing commit conditions to be specified within the operation code, the hardware can support all the variations. However, several variations are discussed below for a more detailed understanding of the various styles of commit instructions and how they can be used.

TXCOMWM

As a first example, the Txcomwm instruction is discussed. This command ends the transaction and causes all buffered, write-monitored data to be visualized globally if no write-monitored data is lost (in case of success); In other cases, it fails if write-monitored data is lost. Txcomwm sets (resets) a flag to indicate success (or failure). On success, Txcomwm clears the buffered state of all write monitored data. Txcomwm allows software to reuse such states in subsequent transactions without affecting read or write monitoring states; It also allows the software to maintain information at those locations without affecting the status of the buffered but not recorded monitored locations. The pseudo code, titled pseudo code C below, illustrates the algorithmic content of Txcomwm. When TSR.LOSS_WMdl 0, the BF property of all buffered and write-monitored BBLKs is automatically cleared and all data so buffered is visible to other agents. TCR.IN TX is cleared. Buffered blocks that lack WM are not affected and continue to be buffered. The CF flag is set upon completion. When TSR.LOSS_WM is 1, the CF flag is cleared and TCR.IN_TX is cleared. The CF flag is set to 1 if the operation was successful and to 0 on failure. OF, SF, ZF, AF, and PF flags are set to zero.

Pseudo Code C: Txcomwm  Of algorithms for operations Example

atomically

{

if (TSR.LOSS WM == 1)

{

CF: = 0;

}

else

{

for (all mblk )

{

CommitAllInMblk (mblk)

}

CF: = 1;

}

}

TCR.IN TX: = 0;

OF: = 0;

SF: = 0;

ZF: = 0;

AF: = 0;

PF: = 0;

The pseudo code, titled pseudo code D below, shows how the HASTM system can use the Txcomwm instruction to commit transactions that use hardware write buffering to avoid cancellation logging at the appropriate update STM. The CACHE_RESIDENT_WRITES flag indicates this run mode.

Pseudo Code D: Txcomwm  Of pseudo code for the use of instructions Example

Void tmCommitUtm (TxnDesc * txnDesc) {

if ( CACHE _ RESIDENT _ WRITES ) {

if ( LAZY _ LOCKING ) {if ( EAGER _ MONITORING == false ) {

/ * Lazy Lock & Lazy Monitoring * /

setWriteMonitors (txnDesc);

/ * Abort if some buffered lines are lost during setup of write monitors * /

if ( EJECTOR _ ENABLED == false && checkTsrLoss ( LOSS _ BF ))

abort (txnDesc);

}

/ * End transaction to fail ejector while acquiring lock * /

if ( E_ JEcTOR _ ENABLED )

tx ();

acquireWriteLocks (txnDesc);

}

/ * Commit the recorded and monitored lines and end the transaction * /

if ( txcomwm () == false) {

txa (); / * Clear Buffering & Monitoring * /

abort (txnDesc);

}

} else {

/ * Unlimited records * /

tx (); / * End the transaction * /

}

TxnRec myCommitTimestamp = lockedIncrement (&GlobalTimestamp);

if (myCommitTimestamp == txnDesc-> timestamp-l &&

validateReadSet (txnDesc) == false)

tmRollbackAndAbort (txnDesc), myCommitTimestamp);

releaseWriteLocks (txnDesc, myCommitTimestamp);

quiesce (txnDesc);

}

TXCOMWMRM

One variant, txcomwmrm, extends the Txcomwm command to fail if any read monitored locations are also lost. This variant is useful for transactions that only use hardware to detect read-set conflicts. The pseudo code, entitled pseudo code E below, illustrates the algorithmic content of Txcomwmrm. When TSR.LOSS WM and TSR.LOSS_RM are zero, the BF property of all buffered and write-monitored BBLKs is automatically cleared and all data so buffered is visible to other agents. TCR.IN TX is cleared. Buffered blocks that lack WM are not affected and continue to be buffered. The CF flag is set upon completion. When TSR.LOSS_WM or TSR.LOSS_RM is 1, the CF flag is cleared and TCR.IN_TX is cleared. If the operation was successful, the CF flag is set to 1 and cleared to 0 upon failure. OF, SF, ZF, AF, and PF flags are set to zero.

Pseudo Code E: Txcomwmrm Of algorithm content Example

atomically

{

if ((TSR.LOSS_RM == 1) || (TSR.LOSS_WM == I))

{

CF: = 0;

}

else

{

for (all mblk )

{

CommitAllInMblk (mblk)

}

CF: = 1;

}

}

TCR.IN TX: = 0;

OF: = 0;

SF: = 0;

ZF: = 0;

AF: = 0;

PF: = 0;

The next pseudo code, pseudo code F, shows a commit algorithm that utilizes the txcomwmrm of the STM system using hardware for both operations buffering transaction records and detecting read-set conflicts. The HW_READ_MONITORTNG flag indicates whether the algorithm uses only hardware for read-set conflict detection.

Pseudo Code F: txcomwmrm  Command Low  Of the code Example

Void tmCommitUtm (TxnDesc * txnDesc) {

if ( CACHE _ RESIDENT _ WRITES ) {

if ( LAZY _ LOCKING ) {

if ( EAGER MONITORING == false ) {

/ * Lazy Lock & Lazy Monitoring * /

setWriteMonitors (txnDesc);

/ * Abort if some buffered lines are lost during setup of write monitors * /

if ( EJECTOR _ ENABLED == false && checkTsrLoss ( LOSS _ BF ))

abort (txnDesc);

}

/ * End transaction to fail ejector while acquiring lock * /

if ( EJEcTOR _ ENABLED )

tx ();

acquire WriteLocks (txnDesc);

}

/ * Commit the recorded and monitored lines and end the transaction * /

if ( HW _ READ _ MONITORING ) {

if ( txcomwmrm () == false) {

txa (); / * Clear Buffering & Monitoring * /

abort (txnDesc);

}

} else if ( txcomwm () == false) {

txa (); / * clear buffering & monitoring * /

abort (txnDesc);

}

} else {

/ * Unlimited records * /

tx (); / * End the transaction * /

}

TxnRec myCommitTimestamp = lockedIncrement (&GlobalTimestamp);

if ( HW _ READ _ MONITORING == false &&

myCommitTimestamp == txnDesc-> timestamp-l &&

validateReadSetUtm (txnDesc) == false)

tmRollbackAndAbort (txnDesc), myCommitTimestamp);

releaseWriteLocks (txnDesc, myCommitTimestamp);

quiesce (txnDesc);

}

TXCOMWMIRMC

A third discussed variant of the algorithmic content of the pseudo code F is illustrated below. When TSR.LOSS_WM and TSR.LOSS_IRM are zero, the BF property of all buffered and write-monitored BBLKs is automatically cleared and all data so buffered is visible to other agents. In addition to RM, WM and IRM, TCR.IN_TX is cleared. Buffered blocks that lack WM are not affected and continue to be buffered. The CF flag is set upon completion. When TSR.LOSS_WM or TSR.LOSS_IRM is 1, the CF flag is cleared and TCR.IN_TX is cleared. If the operation was successful, the CF flag is set to 1 and cleared to 0 upon failure. OF, SF, ZF, AF, and PF flags are set to zero.

Pseudo Code F: Txcomwmirmc Of algorithm content Example

atomically

{

i f ((TSR .LOSS_IRM == 1) || (TSR .L0SS_WM == I))

{

CF: = 0;

}

else

{

for (all mblk )

{

CommitAl1InMbIk ( mblk )

mblk.RM: = 0;

mblk.WM: = 0;

mblk.IRM: = 0;

}

CF: = 1;

}

}

TCR.IN_TX: = 0;

OF: = 0;

SF: = 0;

ZF: = 0;

AF: = 0;

PF: = 0;

Referring to FIG. 12, one embodiment of a flow diagram for a method of executing a commit instruction that defines commit conditions and clear control is illustrated. In step 1205 a commit command is received. As mentioned above, the compiler can insert commit instructions into the program code. As a specific illustrative example, a call to a commit function is inserted into the main code, and commit functions such as those contained in the pseudo code above are provided in the library; The compiler can also insert commit instructions into a commit function in the library.

After the commit command is received, decoders may decode the commit command. From the decoded information, the conditions specified by the operation code of the commit instruction are determined in step 1210. As mentioned above, the operation code may set some flags and reset others to indicate what conditions should be used for the commit. If the condition is not met, false is returned and the transaction is aborted separately. However, if any conditions for commit are satisfied, such as read monitor, write monitor, metadata, and / or lossless buffering, then a clear condition / control is determined at step 1215. By way of example, any combination of read monitor, write monitor, metadata, and / or buffering for a transaction is determined to be cleared. As a result, the information determined to be cleared is cleared in step 1225.

UTM Memory management for data

As discussed above, the unbounded transactional memory (UTM) architecture and its hardware implementation extend the processor architecture by introducing the following features: monitoring, buffering and metadata. This combination provides software, the means necessary to implement a variety of sophisticated algorithms, including a wide range of transactional memory designs. Each characteristic may be implemented on hardware by extending existing cache protocols or allocating independent new hardware resources in a cache implementation.

Using the UTM features implemented by the HW, the UTM architecture and its hardware implementations can provide a software-only solution to transactions (STM) if they can effectively avoid and minimize events such as UTM transaction abort and subsequent transaction retry operations. This can provide a performance boost. One of the main reasons for hardware transaction abort was due to frequent ring switching caused by external interrupts, system call events and page faults.

The current privilege level (CPL) based on the suspend mechanism activates hardware transactions (executing hardware accelerated transactions using UTM features such as performing buffering and monitoring and ejection mechanisms), The processor operates at privilege level 3 (user mode). Any ring switch from ring 3 causes the currently active transactions to stop automatically (stops to generate UTM characteristics and defaults to the ejection mechanism (disabled)). Likewise, any ring switch back to ring 3 resumes a previously stopped hardware transaction when it is active. A possible disadvantage of this approach is that the use of hardware transactional memory resources at kernel code or any other level except ring 3 is largely excluded.

Another approach is to introduce redundant TM control resources, such as ring 0's transaction control register (TxCR), so that hardware transactions can still be performed for ring 0 code with respective TM resources. However, this approach is likely to lack an efficient solution to handle nested interrupts and exceptions during ring 0 transaction operations.

As a result, FIG. 13 enables a ring 0 transaction on user mode (ring 3) transactions, but an OS such as a virtual machine monitor (VMM) to handle the infinite level of nested interrupts and NMI cases where a ring 0 transaction exists. And one embodiment of hardware that supports privilege level switching processing during transaction execution, providing a hypervisor.

A storage element, such as the EFLAGS register 1310, includes a transaction enable field (TEF) 1311. When TEF 1311 holds some active value, it indicates that the transaction is enabled as the current active state, but when TEF 1311 holds the inactive value it indicates that the transaction is suspended.

In one embodiment, a transaction start operation or other transaction start operation sets the TEF field 1311 to an active value. When a ring level transaction event such as an interrupt, exception, system call, virtual machine exit, or virtual machine entry occurs in step 1300, the state of the PE 0 Eflags register 1310 is pushed onto the kernel stack in step 1301. At step 302, the TEF field 1311 is cleared / updated to an inactive value to withhold the transaction. Ring level transition events are processed or serviced while the transaction is pending. Upon detecting a return event in step 1303, the state of the Eflags register 1310 that was pushed onto the stack in step 1301 is popped in step 1304 to restore the Eflags 1310 to the previous state. Recovery of the previous state returns TEF 1311 to an active value and resumes the transaction as active and enabled.

Specific process examples for example ring level transition events are listed below. In an interrupted or anomaly, the processor pushes the EFLAGS register onto the kernel stack and clears the bit if the "Transaction Enable" bit is set, thus suspending the previously enabled transaction. In IRET, the processor recovers the entire EFLAGS register state of the interrupted thread that includes the "Transaction Enable" bit from the kernel stack, thus releasing the previously enabled transaction.

On SYSCALL, the processor pushes the EFLAGS register and clears it if "Transaction Enable" is set to suspend the previously enabled transaction. In SYSRET, the processor recovers the entire EFLAGS register state of the interrupted thread that includes the "Transaction Enable" bit from the kernel stack, thus releasing the previously enabled transaction.

During VM-Exit, the processor stores the guest's EFLAGS register in the Virtual Machine Control Structue (VMCS) containing the "Transaction Enable" bit and loads the EFLAGS register state of the host with the "Transaction Enable" bit cleared. Suspend the enabled guest's transaction if it is enabled.

Upon VM-Enter, the processor recovers the guest's EFLAGS register containing the "Transaction Enable" bit from the VMCS, thereby releasing the previously enabled transaction of the guest that was enabled.

This enables kernel mode (ring 0) hardware accelerated UTM transactions on top of user mode (ring 3) hardware accelerated UTM transactions, but both OS and VMM allow for NMI cases and nested interrupts where ring 0 transactions exist. Provides ways to deal with infinite levels. None of the prior art has provided such a mechanism.

Module as used herein means hardware, software, firmware, or a combination thereof. Often the boundaries of modules are illustrated as each typically varying and having the possibility of overlap. For example, the first and second modules may share hardware, software, or firmware, or some combination thereof, while retaining some independent hardware, software, or firmware. In one embodiment, the use of the term logic includes hardware such as transistors, registers, or other hardware such as programmable logic devices. However, in other embodiments, the logic also includes software or code integrated with hardware, such as firmware or microcode.

Values as used herein include any known representation of numbers, states, logic states, or binary logic states. Usually, the use of logic level, logic value, or logic logical values is referred to simply as 1s and 0s that represent binary logic states. For example, 1 represents a high logic level and 0 represents a low logic level. In one embodiment, a storage cell, such as a transistor or flash cell, may hold a single logic value or multiple logic values. However, other representations of values have been used in computer systems. For example, decimal 10 can also be represented as binary 1010 and hexadecimal A. Thus, the value includes some representation of the information that may be held in the computer system.

Also, states can be represented by values or parts of values. By way of example, a first value such as logic 1 may indicate a default or initial state and a second value such as logic 0 may indicate a non-default state. In addition, in one embodiment, the terms reset and set up refer to default and update values or states, respectively. For example, the default value may include a high logic value, ie a reset, and the update value may include a low logic value, ie a setting. Combinations of some values may be used to represent any number of states.

Embodiments of the methods, hardware, software, firmware or code described above may be implemented via instructions or code stored on a device accessible or device readable medium that may be executed by a processing element. Device accessible / readable media includes any mechanism for presenting (ie, storing and / or transmitting) information in a form that can be read by a machine, such as a computer or an electronic system. For example, device accessible media may include RAM, such as fixed RAM (SRAM) or dynamic RAM (DRAM); ROM; Magnetic or optical storage media; A flash memory device; Electrical storage, optical storage, acoustic storage, or other forms of propagation signals (eg, carrier waves, infrared signals, digital signals) storage devices, and the like. For example, a device can access a storage device by receiving a radio signal, such as a carrier wave, from a medium capable of holding information transmitted over the radio signal.

Reference throughout this specification to “one embodiment” or “an embodiment” means that a particular configuration, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrase "one embodiment" or "an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. In addition, certain configurations, structures, or features may be associated in one or more embodiments in any suitable manner.

In the foregoing specification, a detailed description of the invention has been given with reference to specific exemplary embodiments. However, it will be apparent that various modifications and changes may be made without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive context. In addition, the use of the above embodiments and other typical languages does not necessarily mean the same embodiments or the same examples, but may also mean other separate embodiments and possibly the same embodiments.

Claims (130)

A plurality of processing elements, wherein a processing element of one of the plurality of processing elements is associated with a plurality of software subsystems;
Among the plurality of software subsystems, a metadata access operation associated with a current software subsystem and referring to a data address is assigned to at least a metadata identifier (MDID) associated with the data address and the current software subsystem. And include abstract logic to associate with the abstract address space associated with the current software subsystem based thereon.
Device.
The method of claim 1,
The abstract address space associated with the current software subsystem must be orthogonal to a data address space including the data address and at least one other abstract address space associated with a second software subsystem of the plurality of software subsystems.
Device.
3. The method of claim 2,
Each of the plurality of software subsystems may include a transaction runtime subsystem, a garbage collection runtime subsystem, a memory protection subsystem, a software translation subsystem, an outer transaction of a nested transaction group, and a nested transaction group. Individually selected from the group of inner transactions
Device.
The method of claim 1,
Decoding logic for decoding the metadata access operation, the metadata access operation including an operation code (opcode) recognized as one of a plurality of supported operations within the decoding logic.
Device.
The method of claim 1,
The abstract logic includes abstract translation logic to translate the data address into a metadata address within the abstract address space associated with the current software subsystem based at least on the MDID
Device.
6. The method of claim 5,
The abstract translation logic to translate the data address into a metadata address in the abstract address space associated with the current software subsystem is further based on a processing element identifier (PEID) associated with the processing element.
Device.
The method according to claim 6,
The abstract translation logic to translate the data address into a metadata address in the abstract address space associated with the current software subsystem is further based on a compression ratio of the data to metadata.
Device.
The method according to claim 6,
Further comprising a register modifiable by the current software subsystem, the register responsive to a write from the current software subsystem to indicate that the current software subsystem is currently running on the processing element. The abstract translation logic to retain the MDID and convert the data address into a metadata address within the abstract address space associated with the current software subsystem to present a representation of the data address based on the PEID and MDID. The abstract transformation logic in combination with the PEID and the MDID
Device.
9. The method of claim 8,
The abstract translation logic that combines the representation of the data address with the PEID and the MDID adds the PEID and the MDID to the data address to form the metadata address using the normal data translation tables. Converting the data address into a translated data address and adding the PEID and the MDID to the converted address to form the metadata address; and converting the data address using abstract conversion tables separate from normal data conversion tables. Based on a combination algorithm selected from the group consisting of algorithms for converting to translated metadata addresses and forming the metadata addresses by adding the PEID and MDID to the converted metadata addresses;
Device.
Encountering a metadata operation that references a data address associated with a data item that is in a data address space and held in a data entry in cache memory;
Disjoint with the data address space based on the data address, a processing element identifier (PEID) of a processing element associated with the metadata operation, and a metadata identifier (MDID) for a software subsystem associated with the processing element. Determining metadata addresses in the abstract address space;
Accessing metadata entries in the cache memory based on the metadata addresses
Way.
11. The method of claim 10,
The abstract address space is also separate from the additional abstract address space associated with the additional software subsystem also associated with the processing element.
Way.
11. The method of claim 10,
The software subsystem includes a transaction runtime subsystem, a garbage collection runtime subsystem, a memory protection subsystem, a software translation subsystem, an outer transaction of a nested transaction group, and an inner of a nested transaction group. Selected from a group of transactions
Way.
11. The method of claim 10,
Writing the MDID to the control register associated with the processing element in response to encountering a write operation to a control register from the software subsystem in response to the software subsystem currently running on the processing element, and
Determining the MDID from the control register
Way.
14. The method of claim 13,
Determining the PEID from a portion of an operation code for the metadata operation
Way.
14. The method of claim 13,
Determining the metadata address from the data address, the PEID and the MDID may be performed by using an algorithm, normal data conversion tables to form the metadata address by adding the PEID and the MDID to the data address. Convert the data address using an algorithm that converts a data address into a translated data address and adds the PEID and the MDID to the converted address to form a metadata address, and abstract conversion tables separate from ordinary data conversion tables. The data address, the PEID, and an algorithm selected from the group consisting of an algorithm that converts the converted metadata address and forms the metadata address by adding the PEID and the MDID to the converted metadata address. Combining the MDIDs
Way.
Decoding logic to decode metadata access instructions that will reference the data address of the data item, wherein the metadata access instructions include an operation code (opcode) that can be recognized as part of an instruction set that can be properly decoded by the decoding logic. Hamm
Converting the data address into a separate metadata address transparently in software, and accessing metadata referenced by the separate metadata address in response to the decoding logic to decode the metadata access instruction. Containing metadata logic
Device.
17. The method of claim 16,
The metadata access instruction is selected from the group of instructions consisting of a metadata bit test and set (MDLT) instruction, a metadata store and set (MSS) instruction, and a metadata store and reset instruction (MDSR).
Device.
17. The method of claim 16,
The metadata access instruction is selected from the group of instructions consisting of a compressed metadata test (CMDT) instruction, a compressed metadata storage (CMS) instruction, and a compressed metadata clear (CMDCLR) instruction.
Device.
17. The method of claim 16,
The metadata logic to translate the data address into a separate metadata address in a software transparent manner is based on at least a metadata identifier (MDID) specified in a control register by a software subsystem associated with the metadata access instruction. Including converting the data address
Device.
17. The method of claim 16,
The metadata access instruction also includes a reference to a destination register, and wherein the metadata logic to access metadata referenced by the separate metadata address is the metadata at the referenced separate metadata address. Containing the metadata logic to load the data into the destination register.
Device.
21. The method of claim 20,
The operation code includes a thread identifier field identifying a thread from which the metadata access instruction is issued.
Device.
21. The method of claim 20,
The metadata logic that accesses the metadata referenced by the separate metadata address responds to the referenced separate metadata address in response to the metadata loaded into the destination register being an unset value. The metadata logic to set the metadata to a predetermined setting value;
Device.
The method of claim 22,
The set and unset values are specified in the metadata access instruction.
Device.
Retains program code that, when executed by a machine, causes the machine to perform generation of a metadata access operation for referencing the data address in the data access operation in response to a data access operation referencing a data address,
The metadata access operation causes the machine to be executed when executed by the machine.
Convert the data address into a metadata address separate from the data address,
Access metadata for a data item at the data address based on the metadata address
Machine-readable medium.
25. The method of claim 24,
The metadata access operation is selected from the group of instructions consisting of a metadata bit test and set (MDLT) instruction, a metadata store and set (MSS) instruction, and a metadata save and reset instruction (MDSR).
Machine-readable medium.
25. The method of claim 24,
The metadata access operation is selected from the group of compression instructions consisting of a compressed metadata test (CMDT) instruction, a compressed metadata storage (CMS) instruction, and a compressed metadata clear (CMDCLR) instruction.
Machine-readable medium.
The method of claim 26,
The metadata access operation, when executed by the machine, causes the machine to translate the data address into a metadata address, which causes the machine to convert the data address into A metadata operation to be combined with a metadata element identifier (MDID) combined with the metadata access operation and a processing element identifier (PEID) combined with the metadata operation based on a compression ratio.
Machine-readable medium.
28. The method of claim 27,
The data address may also be translated by virtual to physical address translation logic within the machine to reference the data item.
Machine-readable medium.
25. The method of claim 24,
The metadata access operation also references an operand register and the metadata access operation that causes the machine to access metadata for the data item when executed by the machine is executed to the machine when executed by the machine. A metadata access operation to cause the metadata for the data item to be updated with a value held in the operand register.
Machine-readable medium.
25. The method of claim 24,
The program code includes compiler code, the compiler code for compiling application code that includes the data access operation, and generating the metadata access operation in the data access operation is a compiled version of the application. Generating said metadata access operation in code.
Machine-readable medium.
A machine-readable medium containing program code,
The program code causes the machine to execute when executed by the machine.
A data address referenced by a metadata access instruction in the program code based on a metadata identifier (MDID) associated with a software subsystem currently active on a processing element associated with the metadata access instruction Convert to, and
Perform an operation of accessing metadata based on the metadata address
Machine-readable medium.
32. The method of claim 31,
The metadata access operation is selected from the group of instructions consisting of a metadata instruction to load the metadata, a metadata storage instruction to store the metadata, and a metadata clear instruction to reset the metadata.
Machine-readable medium.
32. The method of claim 31,
The software subsystem includes a transaction runtime subsystem, a garbage collection runtime subsystem, a memory protection subsystem, a software translation subsystem, an outer transaction of a nested transaction group, and an inner of a nested transaction group. Selected from a group of transactions
Machine-readable medium.
32. The method of claim 31,
The operation of translating a data address referenced by a metadata access instruction in the program code to a metadata address based on a metadata identifier (MDID) associated with a software subsystem currently active on a processing element associated with the metadata access instruction is An algorithm for forming the metadata address by adding the MDID to the data address, converting the data address into a translated data address using normal data conversion tables and adding the MDID to the converted data address Converting the data address into a translated metadata address using an algorithm for forming a metadata address and abstract translation tables separate from normal data conversion tables and converting the MDID into the converted And combining the data address with the MDID based on a combination algorithm selected from the group consisting of algorithms for forming the metadata address in addition to the metadata address.
Machine-readable medium.
35. The method of claim 34, wherein adding the MDID adds an MDID selected from the group consisting of an algorithm for adding the MDID at an MSB location, an algorithm for adding the MDID at an LSB location, and an algorithm for replacing address bits with the MDID. Containing algorithms
Machine-readable medium.
35. The method of claim 34,
The program code, when executed by the machine, causes the machine to perform an operation to determine the MDID from the control register of the processing element indicating that the current software subsystem is currently active on the processing element.
Machine-readable medium.
A memory that holds program code including metadata access instructions that reference a data memory address associated with the data item;
A processor coupled with the memory,
The processor is configured to process any one of a plurality of processing elements to be associated with the execution of the metadata access instruction, fetch logic to fetch the metadata access instruction from the memory, and the metadata access instruction. Data including decoding logic to decode at least one metadata access operation, a control register holding a metadata identifier (MDID) associated with an active context on the processing element, and a data entry to hold the data item. A cache memory and an execution unit for executing the metadata access operation,
The execution unit includes an abstract address translation logic in the processor for converting the data memory address into a metadata memory address based on an MDID maintained in the control register, and connected to the data cache memory based on the metadata memory address. Cache control logic to perform metadata access operations on individual entries in the data cache memory.
system.
39. The method of claim 37,
The metadata access instruction is selected from the group of instructions consisting of a metadata load instruction for loading the metadata, a metadata storage instruction for storing the metadata, and a metadata clear instruction for resetting the metadata.
system.
39. The method of claim 37,
The active context includes a transaction runtime subsystem, a garbage collection runtime subsystem, a memory protection subsystem, a software translation subsystem, an outer transaction of a nested transaction group, and an inner transaction of a nested transaction group. Selected from the group consisting of
system.
39. The method of claim 37,
The abstract address translation logic in the processor that translates the data memory address into the metadata memory address is further based on a processing element identifier (PEID) of the processing element and based on the MDID and the PEID held in the control register. The abstract address translation logic in the processor that translates the data memory address into a metadata memory address forms an metadata address by adding the MDID and the PEID to the data address, the data using normal data translation tables. An algorithm that translates an address into a translated data address and adds the PEID and MDID to the translated address to form the metadata address, and an abstract translation table separate from normal data conversion tables. The data address based on a combination algorithm selected from the group consisting of algorithms for converting the data address into a translated metadata address and adding the PEID and MDID to the converted metadata address to form the metadata address. Combining with the MDID and the PEID
system.
An execution module for executing a metadata load operation referencing the address;
In response to the metadata load operation, a force that provides a metadata value associated with an address in response to the processor operating in a first mode and a fixed value in response to the processor operating in a second mode Containing module
Processor.
42. The method of claim 41,
The first mode includes a strong atomicity mode, and the second mode includes a weak atomic mode.
Processor.
43. The method of claim 42,
Further comprising a first register holding the fixed value;
Processor.
44. The method of claim 43,
And a second register holding a mode value, wherein the mode value indicates a first value indicating that the processor is an operation of the strong atomic mode, wherein the mode value indicates that the processor is an operation of the weak atomic mode. Indicating a second value to represent
Processor.
45. The method of claim 44,
The first register and the second register are the same metadata control register
Processor.
45. The method of claim 44,
Wherein the force module provides a metadata value associated with an address in response to the processor operating in the strong atomic mode and provides a fixed value in response to the processor operating in the weak atomic mode; Load the metadata value into a destination register to be specified by the metadata load operation in response to the mode value to be retained in the second register representing the first value to indicate that it is operating in an atomic mode; A force module for loading the fixed value from the first register to the destination register in response to the mode value to be retained in the second register representing the second value to indicate that it operates in the weak atomic mode.
Processor.
Encountering a metadata access operation that references an address,
Determining a mode of processor execution;
In response to determining that the mode of processor execution is a first execution mode, providing a metadata value associated with the address for the metadata access operation;
In response to determining that the mode of processor execution is a second mode of execution, providing a fixed value from a register for the metadata access operation.
Way.
49. The method of claim 47,
Determining the mode of processor execution includes reading a mode flag from a first control register, wherein the mode flag holds a first value indicating that the mode of processor execution is a first execution mode, and Holds a second value indicating that the processor execution mode is a second execution mode
Way.
49. The method of claim 47,
Providing a metadata value associated with the address for the metadata access operation includes loading the metadata value from a memory location associated with the address into a destination register referenced by the metadata access operation.
Way.
50. The method of claim 49,
Providing a fixed value from a register for the metadata access operation includes loading the fixed value from the register into the destination register.
Way.
A memory holding a metadata load operation and a destination register to reference the address,
Including a processor coupled to the memory,
The processor executes execution logic to execute the metadata load operation, a metadata register to hold a forced value, a cache memory to hold a metadata value associated with the address, and to execute the metadata load operation. Responsive to logic to provide the metadata value to the destination register in response to the processor operating in a first mode and to force the value from the metadata register in response to the processor operating in a second mode. Contains force logic provided by registers
system.
52. The method of claim 51,
The force logic further determines whether the processor is operating in the first mode or the second mode.
system.
53. The method of claim 52,
The first mode includes a strong atomicity mode, and the second mode includes a weak atomic mode.
system.
53. The method of claim 52,
The metadata register further holds a mode value, the mode value representing a first value when the processor is operating in the first mode and a second value when the processor is operating in the second mode. And further determining whether the force logic operates in the first mode or the second mode comprises the force logic to interpret the mode value from the metadata register.
system.
53. The method of claim 52,
And a control register to hold a mode value, wherein the mode value indicates a first value when the processor is operating in the first mode and indicates a second value when the processor is operating in the second mode. And further determining whether the force logic operates in the first mode or the second mode includes the force logic to interpret the mode value from the control register.
system.
52. The method of claim 51,
The memory is selected from the group consisting of dynamic random access memory (DRAM), fixed random access memory (SRAM), and nonvolatile memory.
system.
A data cache array holding cache entries,
Coupled with the data cache array, upon buffered update to the cache entry, transition the cache entry from an unmonitored state to a buffered coherency and read monitored state, and then the Cache control logic for transitioning the cache entry to a buffered coherency and write monitored state before transitioning the cache entry to a modified state to commit a buffered update.
Device.
58. The method of claim 57,
A buffering update for the cache entry may include transactional memory access to a data address for a data item to be retained in the cache entry, metadata access to a data address associated with metadata to be retained in the cache entry, and for the cache entry. Containing updates selected from the group consisting of local updates
Device.
58. The method of claim 57,
Cache control logic that transitions the cache entry from an unmonitored state to a buffered coherency and read monitored state updates the coherency bits associated with the cache entry with a buffered value to indicate the buffered coherency state. And cache control logic to update a read monitor attribute bit associated with the cache entry with a read monitored value to indicate the read monitored state.
Device.
60. The method of claim 59,
Cache control logic that transitions the cache entry to a buffered consistency and write-monitored state prior to transitioning the cache entry to a modified state to commit the buffered update may cause the consistency bits associated with the cache entry to be buffered. Cache control logic that maintains the buffered value to indicate a value and updates the write monitor attribute bits associated with the cache entry to a write monitored value to indicate the write monitored state.
Device.
64. The method of claim 60,
The cache control logic to transition the cache entry to the modified state includes the cache control logic to update the coherency bits associated with the cache entry to a modified value to indicate the modified coherency state.
Device.
58. The method of claim 57,
Execution logic that executes the buffered update and then executes a commit operation, wherein the cache entry is buffered for consistency and write monitoring prior to transitioning the cache entry to a modified state to commit the buffered update The cache control logic that transitions to a closed state is responsive to the execution logic executing the commit operation.
Device.
Encountering a buffered update to a block of cache memory,
Applying read monitoring to the block upon encountering the buffered update to the block of cache memory;
Thereafter, applying write monitoring to the block prior to committing the block.
Way.
64. The method of claim 63,
The buffered update to the block of cache memory includes a transaction record for the block of cache memory.
Way.
64. The method of claim 63,
Performing the buffered update on the block of cache memory concurrently with a read monitoring application, wherein after performing the buffered update the block is held in a buffered coherency state.
Way.
64. The method of claim 63,
Performing the buffered update on the block of cache memory after applying read monitoring, wherein after performing the buffered update the block is held in a buffered coherency state.
Way.
64. The method of claim 63,
Upon encountering the buffered update to the block of cache memory, applying read monitoring to the block comprises generating a read request of the block for processing elements outside the cache domain of the cache memory; In response to no conflict detected from processing elements outside the cache domain responsive to the read request for the block, a read monitor attribute associated with the block of the cache memory to apply read monitoring for the block. Updating to the monitor value
Way.
68. The method of claim 67,
Applying write monitoring for the block before committing includes generating a read request for ownership of the block for the processing elements outside of the cache domain of the cache memory, and requesting the read for ownership of the block. In response to no conflict detected from the processing elements outside the cache domain responsive to updating the write monitor attribute associated with the block of cache memory with a write monitor value for applying write monitoring for the block. Containing steps
Way.
69. The method of claim 68,
Committing the block includes transitioning the cache coherency state of the block from a buffered coherency state to a modified coherency state.
Way.
When run by a machine,
Applying read monitoring to the block upon buffered writes to blocks of cache memory;
Performing the buffered write to the block;
Retaining program code for performing an operation of applying write monitoring for the block after applying the read monitoring and before committing the block.
Machine-readable medium.
71. The method of claim 70,
In the buffered read of the block of cache memory, applying read monitoring to the block may include
Generating a read request of the block for processing elements outside the cache domain of the cache memory;
In response to not detecting any conflict from the processing elements outside the cache domain in response to the read request for the block, applying read monitoring for the block to a read monitor attribute associated with the block of the cache memory. Updating the readout monitor value for
Machine-readable medium.
72. The method of claim 71,
After committing the read monitoring and before committing the block, applying write monitoring for the block
Generating an ownership read request for the block for the processing elements outside the cache domain of the cache memory;
Applying write monitoring for the block to the write monitor attribute associated with the block of the cache memory as no conflict is detected from the processing elements outside the cache domain in response to the ownership read request for the block. Updating the history monitor value for
Machine-readable medium.
71. The method of claim 70,
After committing the read mortise and before committing the block, applying write monitoring for the block is responsive to encountering a commit operation.
Machine-readable medium.
71. The method of claim 70,
Committing the block includes transitioning the cache coherency state of the block to a modified coherency state.
Machine-readable medium.
System memory that holds transactional write and commit operations referencing memory addresses;
Coupled with the system memory, generating a read request for a cache line associated with the memory address upon receiving the transaction record, buffering the cache line in response to no conflict being detected based on the read request; Transition to a read-monitored state, generate an ownership read request upon receiving the commit operation, transition the cache line to a buffered and write-monitored state as no conflicts are detected based on the ownership read request, and And a processor including a cache memory for transitioning said cache line to a modified state as said line transitions to said buffered and write monitored state.
system.
78. The method of claim 75,
Cache memory for transitioning the cache line to a buffered and read monitored state updates the coherency bits associated with the cache line with a buffered value to indicate a buffered portion of the buffered and read monitored state and the cache A cache memory that updates a read monitor attribute bit associated with a line with a read monitored value to indicate the read monitored portion of the buffered read monitored state.
system.
80. The method of claim 76,
Cache memory for transitioning the cache line to a buffered and write monitored state maintains the coherency bits associated with the cache line at a buffered value to indicate a buffered portion of the buffered and write monitored state. A cache memory for updating a write monitor attribute bit associated with a write monitored value to indicate the write monitored portion of the buffered write monitored state.
system.
78. The method of claim 77,
In response to transitioning the cache line to the buffered and write monitored state, the cache memory to transition the cache line to the modified state includes updating the coherency bits with a modified value to indicate the modified state.
system.
78. The method of claim 75,
The memory is selected from the group consisting of dynamic random access memory (DRAM), fixed random access memory (SRAM), and nonvolatile memory.
system.
Decode a loss instruction to provide a decoded element, the loss instruction comprising an operation code referring to a label and being part of a set of instructions that can be recognized by the decoding logic. Decoding logic,
A state storage element comprising a loss field holding a loss value indicating that a loss event has been detected;
And jump logic coupled to the state storage element to transfer control to the label based on the decoded element and the loss value indicating that the loss event was detected.
Device.
79. The method of claim 80,
The label includes a jump destination address and includes a read monitor conflict indicating that a write may have occurred on a read monitored cache line, a write monitor conflict indicating that an access may have occurred on a write monitored cache line, and a buffered cache. The loss event is selected from the group consisting of the loss of the line
Device.
79. The method of claim 80,
The state storage element includes a register, the loss field holding a loss value includes a first bit set when a read monitor conflict is detected, a second bit set when a write monitor conflict is detected, and buffered physical data. A third bit set when a loss is detected and a fourth bit set when a loss of the buffered metadata is detected
Device.
79. The method of claim 80,
The loss instruction includes a read monitor loss instruction, wherein the operation code is for specifying a read monitor loss event type and is controlled by the label based on the decoded element and the loss value indicating that the loss event has been detected. The jump logic conveys a jump logic that jumps execution to the label in response to the loss field holding the loss value indicating that the loss event that occurred was of a read monitor loss event type specified by the operation code of a read monitor loss instruction. Containing
Device.
79. The method of claim 80,
The loss instruction includes a write monitor loss instruction and the operation code is for specifying a write monitor loss event type and based on the decoded element and the loss field having a loss value indicating that the loss event was detected. Jump logic transferring control to the label jumps execution to the label in response to a loss field holding a loss value indicating that the loss event that occurred was of a write monitor loss event type specified by the operation code of a write monitor loss instruction. Containing logic
Device.
79. The method of claim 80,
The loss instruction includes a buffered loss instruction and the operation code is for specifying a buffered loss event type, based on the decoded element and the loss field having a loss value indicating that the loss event was detected. Jump logic transferring control to the label jumps execution to the label in response to a loss field having a loss value indicating that the loss event that occurred was of a buffered loss event type specified by the operation code of the buffered loss instruction. Containing logic
Device.
When executed by a machine, cause the machine to respond in response to a loss instruction,
Determining the status of a transaction specified by the loss instruction and held in a transaction status register residing on the machine;
Retain program code for performing an operation for vectoring execution with a label specified by the loss instruction in response to a status of the transaction indicating that a loss event associated with the loss instruction has been detected.
Machine-readable medium.
88. The method of claim 86,
The label includes a jump destination address and includes a read monitor conflict indicating that a write may have occurred on a read monitored cache line, a write monitor conflict indicating that access to a write monitored cache line may have occurred, and a buffered cache. The loss event is selected from the group consisting of the loss of the line
Machine-readable medium.
88. The method of claim 86,
The loss instruction includes a read monitor jump loss (JLOSS) instruction specifying that the loss event is a read monitor conflict, and the operation of determining the status of a transaction held in the transaction status register is a read monitor held in the transaction status register. An operation to determine the state of the conflict bit, wherein the operation to vector execution with a label specified by the loss instruction in response to the state of the transaction indicating that a loss event associated with the loss instruction has been detected. An operation to vector execution to a label specified by the missing instruction in response to the status of the read monitor conflict bit held in the transaction status register indicating that it has been detected.
Machine-readable medium.
88. The method of claim 86,
The loss instruction includes a write monitor jump loss (JLOSS) instruction specifying that the loss event is a write monitor conflict, and the operation of determining the status of a transaction held in the transaction status register is a write monitor held in the transaction status register. An operation to determine the state of the conflict bit, wherein the operation of vectorizing execution to the label specified by the loss instruction in response to the state of the transaction indicating that a loss event associated with the loss instruction was detected. An operation to vector execution to a label specified by the missing instruction in response to the state of the write monitor conflict bit held in the transaction status register indicating that it has been detected.
Machine-readable medium.
88. The method of claim 86,
The loss instruction includes a buffered monitor jump loss (JLOSS) instruction specifying that the loss event is a buffered monitor conflict, and an operation to determine the state of a transaction held in the transaction status register is held in the transaction status register. An operation that determines a state of a buffered monitor conflict bit, wherein the operation of vectorizing execution to the label specified by the loss instruction in response to the state of the transaction indicating that a loss event associated with the loss instruction has been detected is buffering. An operation to vector execution with a label specified by the missing instruction in response to the state of the buffered monitor conflict bit held in the transaction status register indicating that a detected monitor conflict was detected.
Machine-readable medium.
Encountering missing instructions on the processor,
Determining whether a loss event associated with the loss instruction has been detected by the processor in response to encountering the loss instruction;
In response to contacting the missing instruction and determining that the lost event associated with the missing instruction has been detected at the processor, branching to a label referenced by the missing instruction.
Way.
92. The method of claim 91,
The label includes a jump address
Way.
92. The method of claim 91,
The loss instruction includes a read monitor loss instruction and the loss event associated with the read monitor loss instruction includes a write to a read monitored cache line.
Way.
92. The method of claim 91,
The loss instruction includes a write monitor loss instruction, wherein the loss event associated with the write monitor loss instruction includes access to a write monitored cache line.
Way.
92. The method of claim 91,
The loss instruction includes a buffered loss instruction, and the loss event associated with the buffered loss instruction includes eviction of a buffered cache line.
Way.
95. The method of claim 95,
Determining whether retirement of a buffered cache line is detected at the processor includes checking a buffered loss status bit in a transaction status register and in response to the buffered loss status bit being set to a loss value, the buffered cache Determining that eviction of the line has been detected
Way.
Decode commit instructions for a transaction to provide decoded elements, wherein the commit instructions specify an operation condition and include an operation code (opcode) that is part of an instruction set that can be recognized by the decoding logic. and,
And commit logic for determining whether the commit condition specified by the commit instruction is satisfied for the transaction in response to the decoded element.
Device.
98. The method of claim 97,
The commit condition includes any specified combination of lossless read-monitored data, lossless write-monitored data, lossless buffered data, and lossless metadata, and commit logic that determines that the commit condition is satisfied And determining that the specified combination of lossless read-monitored data, lossless write-monitored data, lossless buffered data, and lossless metadata has occurred.
Device.
98. The method of claim 97,
The commit instruction specifying a commit condition is a first bit that, when set, indicates which loss of read-monitored data is a condition to commit, a second bit that indicates which loss of write-monitored data is a condition to commit, when set A third instruction indicating that any loss of buffered data is a condition to commit, and a commit instruction holding four bits of the fourth bit, when set, indicating which loss of metadata is a condition to commit.
Device.
The method of claim 99,
The four bits should be included in the operation code
Device.
The method of claim 99,
The commit logic, which determines whether the commit condition specified by the commit instruction is satisfied for the transaction, checks the corresponding status bits in the transaction status register for each of the four bits set in the commit instruction, Determining that a commit condition is satisfied if none of the corresponding status bits in the transaction register are set to indicate an association loss
Device.
98. The method of claim 97,
The commit instruction further specifies clear controls to indicate that the combination of read monitored data, write monitored data, buffered data, and metadata is cleared at commit, wherein the commit logic is configured to specify the commit specified by the commit command. Clearing the specified combination of read monitored data, write monitored data, buffered data, and metadata after committing the transaction in response to determining that a commit condition is satisfied for the transaction.
Device.
A machine readable medium carrying program code,
The program code, when executed by a machine, causes the machine to encounter a commit instruction specifying at least one commit failure condition for a transaction from the program code;
Determining whether the at least one commit failure condition specified by the commit instruction is detected during the pending of the transaction;
In response to determining that at least one commit failure condition specified by the commit instruction was detected during the pending of the transaction, a value indicating that the at least one commit failure condition specified by the commit instruction was detected during the pending of the transaction Which includes providing an action
Machine-readable medium.
103. The method of claim 103,
The at least one commit failure condition is selected from the group consisting of loss of read monitored data, loss of write monitored data, loss of buffered data, and loss of metadata.
Machine-readable medium.
103. The method of claim 103,
An operation providing a value indicating that the at least one commit failure condition specified by the commit instruction was detected during the pending of the transaction indicates that at least one commit failure condition specified by the commit instruction was detected during the pending of the transaction. An operation that loads the value into a destination register to indicate that
Machine-readable medium.
103. The method of claim 103,
The operation of determining whether the at least one commit failure condition specified by the commit instruction is detected during the pending of the transaction may include an operation of checking a status bit in a transaction status register associated with the at least one commit failure condition. The status bit associated with the at least one commit failure condition is set to indicate that the at least one commit failure condition was detected during the pending of the transaction, the specified by the commit instruction during the pending of the transaction. An operation that determines that at least one commit failure condition has been detected and that the status bit associated with the at least one commit failure condition has not detected the at least one commit failure condition during the pending of the transaction. In response to a reset As shown, including an operation for determining has not the at least one commit failure conditions specified by the commit instruction is detected during the pendency of the transaction
Machine-readable medium.
107. The method of claim 106,
And committing the transaction in response to determining that the at least one commit failure condition specified by the commit instruction was not detected during the pending of the transaction.
Machine-readable medium.
Encountering, within a transaction, a commit instruction that includes an operation code (opcode) specifying a commit failure condition of the transaction;
Determining that a commit failure condition of the transaction specified in the operation code of the commit instruction was not detected during the pending of the transaction;
Committing the transaction in response to determining that a commit failure condition of the transaction specified in the operation code of the commit instruction was not detected during the pending of the transaction;
Way.
108. The method of claim 108,
The first code of the operation code specifying that the loss of read-monitored data is a commit failure condition when the operation code specifying the commit failure conditions of the transaction is a commit failure condition. The second bit of the operation code specifying that the third bit of the operation code specifying that the loss of the buffered data when set, and the loss of the metadata when set is a commit failing condition Containing the fourth bit of the operation code
Way.
108. The method of claim 109,
Determining that a commit failure condition of the transaction specified in the operation code of the commit instruction was not detected during the pending of the transaction is that the read monitor bit of the transaction status register is read monitored as the first bit of the operation code is set. Determining that the write monitor bit of the transaction status register is not set to indicate lossless write-monitored data as the second bit of the operation code is set. Determining that the buffered bit of the transaction status register is not set to indicate lossless of the buffered data as the third bit of the operation code is set, and the operation code Comprising the step of determining the meta-data bits of the transaction status register as the fourth bit is set has not been set to refer to the metadata of the lossless
Way.
108. The method of claim 109,
The operation code further specifies a clear control, and the operation code specifying the clear control is, when set, the fifth bit of the operation code specifying that the read-monitored data is cleared at commit, when set, at commit The sixth bit of the operation code specifying write-monitored data to be cleared, the seventh bit of the operation code specifying the buffered data to be cleared at commit, if set, and the metadata at commit, if set An eighth bit of the operation code that specifies that
Way.
111. The method of claim 111,
The committing of the transaction may include clearing the read-monitored data when the fifth bit is set, clearing the write-monitored data when the sixth bit is set, and the seventh bit. Clearing the buffered data if set and clearing the metadata if the eighth bit is set.
Way.
A memory holding program code including a commit instruction of said transaction comprising an operation code specifying commit failure conditions and clear control information for the transaction;
Decoding logic for decoding the operation code of the commit instruction;
A processor including commit logic to determine whether any of the commit failure conditions specified in the operation code were not detected during a transaction pending and to commit the transaction in accordance with a determination that the commit failure condition was not detected during the transaction pending. ,
The commit logic to commit the transaction includes commit logic to clear transaction information based on the clear control information specified in the operation code of the commit instruction.
system.
112. The method of claim 113,
The commit failure condition is based on a combination of loss of read monitored data, loss of write monitored data, loss of buffered data, and loss of metadata.
system.
115. The method of claim 114,
The commit failure condition may include loss of write-monitored data, loss of read-monitored data or loss of write-monitored data, loss of write-monitored data or loss of buffered data, loss of write-monitored data, or loss of metadata. And loss of write-monitored data, loss of read-monitored data, loss of buffered data, or loss of metadata.
system.
112. The method of claim 113,
The operation code specifying the clear control information includes an operation code specifying which of the read monitor, the write monitor, the buffered consistency, and the metadata should be cleared at commit, wherein the operation code specified by the operation code of the commit instruction The commit logic to clear transaction information based on the clear control information includes read logic specified to be cleared in the operation code, write monitor, buffered consistency, and commit logic to clear metadata.
system.
A storage element that contains a transaction enable field (TEF (transaction enable filed)) indicating that the associated transaction was active and enabled when holding an active value and that the associated transaction was suspended when holding an inactive value; ,
Logic to save at least the state of the TEF in a storage structure in response to a ring level transition event and restore at least the state of the TEF from the storage structure to the storage element in response to a return event. Containing
Device.
118. The method of claim 117 wherein
The ring level switch event includes an event selected from the group consisting of interrupts, exceptions, system calls, virtual machine enters, and virtual machine exits.
Device.
118. The method of claim 117 wherein
The return event includes an event selected from the group consisting of Interrupt Return (IRET), System Return (SYSRET), Virtual Machine (VM) Ender, and Virtual Machine (VM) Escape.
Device.
118. The method of claim 117 wherein
The storage element includes a flag register and the TEF includes a transaction enable flag.
Device.
118. The method of claim 117 wherein
The storage structure includes a stack, and logic to store at least the state of the TEF on the stack includes push logic to push at least the state of the TEF onto the stack, wherein at least the TEF from the stack to the storage element. The logic for recovering the state of the circuit includes pop logic for popping at least the TEF in the stack to restore the TEF to the storage element.
Device.
Memory that holds code that causes ring-level transition events at runtime,
A register comprising a transaction enable field (TEF) that holds an active value indicating that the associated transaction is active, a previous state of the register is pushed onto the stack in response to the ring level switch event, and the associated transaction is And a processor that clears the TEF with an inactive value indicating pending and includes stack logic to restore the previous state of the register from the stack to the register in response to a return event.
system.
123. The method of claim 122 wherein
The ring level switch event includes an event selected from the group consisting of interrupts, exceptions, system calls, virtual machine enters, and virtual machine exits.
system.
123. The method of claim 122 wherein
The return event includes an event selected from the group consisting of interrupt return (IRET), system return (SYSRET), virtual machine (VM) enter, and virtual machine (VM) exit.
system.
123. The method of claim 122 wherein
The register includes a flag register, the TEF includes a transaction enable flag, the active value includes a high logic value of the flag, and the inactive value includes a low logic value of the flag.
system.
Detecting a ring level transition event from the current ring level;
Storing in a storage structure the previous state of a register containing a transaction enable field;
Clearing the transaction enable field to indicate that an associated transaction is pending;
Detecting a return to the current ring level event;
In response to detecting the return to the current ring level event, recovering the previous state of the register from the storage structure.
Way.
126. The method of claim 126,
The storage structure includes a kernel stack, and storing the previous state of the register in the kernel stack includes pushing the previous state of the register onto the kernel stack, wherein the previous state of the register Recovering from the kernel stack includes popping the previous state of the register from the kernel stack to restore the previous state to the register.
Way.
126. The method of claim 126, wherein
The current ring level includes a user ring level
Way.
127. The method of claim 128,
The ring level switch event includes an event selected from the group consisting of an interrupt, an exception, a system call, and a virtual machine enter.
Way.
129. The method of claim 129,
The return to the current privilege level event includes an event selected from the group consisting of an interrupt return (IRET), a system return (SYSRET), and a virtual machine (VM) exit.
Way.

Images