JP5608738B2 - Unlimited transactional memory (UTM) system optimization - Google Patents

Description

  The present invention relates to processor execution. Specifically, it relates to the execution of an instruction group.

  Advances in semiconductor processes and logic design have made it possible to increase the amount of logic provided in integrated circuit elements. As a result, the computer system configuration has evolved from a configuration in which one or more integrated circuits are provided in one system to a configuration in which a plurality of cores and a plurality of logical processors are provided in each integrated circuit. In general, a processor or integrated circuit comprises one processor die, which may have any number of cores or logical processors.

  Since the number of cores and logical processors that can be provided in an integrated circuit is steadily increasing, the number of software threads that can be executed simultaneously is also increasing. However, when the number of software threads executed simultaneously increases, a problem occurs regarding synchronization of data shared among a plurality of software threads. One common solution for accessing shared data in a multi-core or multi-logical processor system is to use locks to ensure mutual exclusion when there are multiple accesses to the shared data. However, the function of executing a plurality of software threads is evolving, and there is a possibility that contention may occur accidentally and execution may be serialized.

  For example, consider a hash table that holds shared data. When utilizing a lock system, the programmer may lock the entire hash table so that one thread can access the entire hash table. However, other threads cannot access any entry in the hash table until the lock is released, which adversely affects the throughput and performance of other threads. Instead, the hash table may be locked for each entry. In any case, considering a large and scalable program based on this simple example, it is clear that the complexity of lock contention, serialization, fine-grained synchronization, and deadlock avoidance can be very burdensome for programmers. It is.

  Another data synchronization technique used in recent years uses a transactional memory (TM). Transactional execution often involves grouping multiple micro-operations, operations or instructions. In the above example, both threads execute in the same hash table and monitor / track their respective memory accesses. If both threads access / modify the same entry, conflict resolution may be performed to ensure the validity of the data. One type of transactional execution is software transactional memory (STM), where memory access tracking, conflict resolution, abort tasks, and other transactional tasks are often not supported by hardware. It is executed by software.

  Another type of transactional execution is a hardware transactional memory (HTM) system, which includes hardware to support access tracking, conflict resolution, and other transactional tasks. Previously, the actual memory data array was expanded with additional bits to hold information such as hardware attributes to track reads, writes and buffering. Therefore, the data is transferred from the processor to the memory together with this data. This information is often referred to as persistent information, that is, it is not lost when cache eviction occurs. This is because this information moves with the data in the memory hierarchy. However, such persistence increases overhead in the memory hierarchy system.

  In addition, conventional hardware transactional memory (HTM) systems have many inefficiencies. As a first example, HTM is currently buffered and monitored from unbuffered or buffered but unmonitored state to ensure consistency before committing the transaction. There is no efficient way to transition to the current state. As another example, the interface to HTM software is often inefficient. Specifically, hardware provides a mechanism to properly accelerate software memory access barriers that take into account various forms of strong and weak atomicity between transactional and non-transactional processing. Not. Also, when attempting to commit a transaction, the hardware does not provide a mechanism for determining when to abort or commit a transaction based on the loss of monitoring information, buffering information, and / or other attribute information. Similarly, such a conventional instruction group for HTM cannot realize a commit instruction that defines information to be held or cleared when a transaction is committed. Another example of inefficiency is that HTM has no instructions to efficiently guide or jump to execution when a conflict or loss of information is detected, and current HTM has a ring at transaction execution. There is a point that level priority transition cannot be processed.

The illustrations in the accompanying drawings illustrate rather than limit the invention.
FIG. 6 illustrates an embodiment of a processor that includes multiple processing elements capable of executing multiple software threads simultaneously. It is a figure which shows embodiment which matches metadata about a data item. FIG. 4 illustrates an embodiment of multiple orthogonal metaphysical address spaces for multiple separate software subsystems in multiple processing elements. FIG. 3 is a diagram illustrating an embodiment for compressing metadata with respect to data. 6 is a flowchart illustrating an embodiment of a method for accessing metadata. FIG. 6 illustrates an embodiment of a metadata storage element that supports acceleration of transactions in a strong atomic environment and a weak atomic environment. 6 is a flowchart illustrating an embodiment for accelerating non-transactional processing while maintaining atomicity in a transactional environment. FIG. 5 is a flowchart illustrating an embodiment of a method for efficiently transitioning a block of data to a buffered and monitored state prior to committing a transaction. FIG. 4 illustrates an embodiment of hardware that supports a loss instruction that jumps to a destination label based on a status value in a transaction status register. 6 is a flowchart illustrating an embodiment of a method for executing a loss instruction that jumps to a destination label based on a conflict or loss of specific information. FIG. 4 is a diagram illustrating an embodiment of hardware that supports defining commit conditions and clear control in a commit instruction. 6 is a flowchart for explaining an embodiment of a method for executing a commit instruction defining a commit condition and a clear control. FIG. 4 is a diagram illustrating an embodiment of hardware that supports privilege level transition processing during transaction execution.

  In the description that follows, for the purposes of a thorough understanding of the present invention, a specific hardware structure for transactional execution, a specific type and implementation of an access monitor, and a specific type of cache coherency for detecting access conflicts. Many specific details are described, such as models, specific data granularity, and examples of specific types of memory accesses and memory locations. However, it will be apparent to those skilled in the art that the specific details described below need not be employed when practicing the present invention. Also, coding transactions in software, inserting processing to perform enumerated functions by the compiler, delimiting transactions, specific and other multi-core and multi-threaded processor architectures, specific compiler methods / implementations, and Well-known components or methods, such as details of specific processing of a microprocessor, have not been described in detail to avoid unnecessarily obscuring the present invention.

  The method and apparatus described herein is a method and apparatus for optimizing hardware and software that implements unlimited transactional memory (UTM). Specifically, optimization will be described mainly in relation to how the UTM system is supported. However, the methods and apparatus described herein may be utilized in any form of transactional memory system, such as hardware supporting or accelerating a software transactional memory system (STM), pure hardware A wear transactional memory system (HTM), or a combination of these, may be used in a hybrid type that differs in mounting method from the UTM system.

  FIG. 1 is a diagram illustrating an embodiment of a processor capable of simultaneously executing a plurality of threads. Note that the processor 100 may include hardware support for hardware transactional execution. The processor 100 may also be in combination with or separately from hardware transactional execution, hardware acceleration of software transactional memory (STM), independent execution of STM, or a combination thereof, eg, hybrid type Hardware support may be provided for a transactional memory (TM) system. The processor 100 includes any processor, such as a microprocessor, embedded processor, digital signal processor (DSP), network processor, or other code execution device. As shown, the processor 100 includes a plurality of processing elements.

  According to one embodiment, a processing element may be a thread unit, a process unit, a context, a logical processor, a hardware thread, a core, and / or any other state capable of maintaining processor state, eg, execution state or architectural state. Means an element. In other words, a processing element according to an embodiment means arbitrary hardware that can be independently associated with code such as a software thread, an operating system, and an application. A physical processor typically refers to an integrated circuit having any number of other processing elements such as cores or hardware threads.

  “Core” often refers to logic provided in an integrated circuit that can maintain independent architectural states, each independently maintained architectural state associated with at least some dedicated execution resources It has been. In contrast to the core, a “hardware thread” usually means any logic provided in an integrated circuit that can maintain independent architectural states, but multiple independently maintained architectural states are Share access to execution resources. As can be seen from the above, when a predetermined resource is shared and another resource is dedicated to one architecture state, the boundary between the hardware thread and the core is overlapped. However, in many cases, the core and hardware threads are recognized by the operating system as separate logical processors, and the operating system can schedule processing separately for each logical processor.

  As shown in FIG. 1, the physical processor 100 includes two cores, a core 101 and a core 102 that share access to the high-level cache 110. Although the processor 100 may include a plurality of asymmetric cores, that is, a plurality of cores having different configurations, functional units, and / or logics, the illustrated are a plurality of symmetric cores. For this reason, the detailed description of the core 102 shown as being the same as the core 101 is omitted to avoid repeated description. The core 101 has two hardware threads 101a and 101b, and the core 102 has two hardware threads 102a and 102b. Thus, a software entity such as an operating system sees the processor 100 as four separate processors. That is, it is assumed that there are four logical processors or processing elements that can execute four software threads simultaneously.

  Here, the first thread is associated with the architecture state register 101a, the second thread is associated with the architecture state register 101b, the third thread is associated with the architecture state register 102a, and the fourth thread is Corresponding to the architecture status register 102b. As shown, the architectural state register 101a is duplicated in the architectural state register 101b so that separate architectural states / contexts can be stored for logical processor 101a and logical processor 101b. Other smaller resources, such as the instruction pointer and rename logic of rename assignment logic 130, may also be replicated for threads 101a and 101b. Some resources, such as the reorder buffer of the reorder / retirement unit 135, the ILTB 120, the load / store buffer, and the queue may be shared using partitioning. Other resources such as general purpose internal registers, page table base registers, low level data cache and data TLB 115, execution unit 140, and part of out-of-order unit 135 may be fully shared.

  The processor 100 often comprises other fully shared resources, resources shared using partitioning, or resources dedicated to certain processing elements. The embodiment of a processor with functional units / resources illustrated in FIG. 1 is merely an example. Note that the processor may include any of the functional units described above, may be omitted, or may include any other known functional unit, logic, or firmware that is not illustrated.

  As shown, the processor 100 includes a bus interface module 105 for communicating with devices external to the processor 100, system memory 175, chipset, north bridge, or other integrated circuits. The memory 175 may be dedicated to the processor 100 or may be shared with other devices in the system. The high level cache or higher level cache 110 caches elements that have been recently fetched from the high level cache 110. Note that “higher level” or “its higher level” means a cache level that increases as the user leaves the execution unit. According to one embodiment, the high level cache 110 is a second level data cache. However, the high-level cache 110 is not limited to this, and may be associated with an instruction cache or may have an instruction cache. Alternatively, a trace cache, or a type of instruction cache, may be coupled to the subsequent stage of the decoder 125 to store recently decoded traces. The module 120 further includes a branch target buffer that predicts a branch to be executed / adopted, and an instruction translation buffer (I-TLB) that stores an address translation entry for the instruction.

  The decode module 125 is coupled to the fetch unit 120 and decodes the fetched element. According to one embodiment, processor 100 is associated with an instruction set architecture (ISA) that defines / defines instructions executable on processor 100. Here, machine code instructions recognized by the ISA often include a portion called an opcode that refers to / specifies an instruction or operation to be executed.

  For example, the allocation / rename block 130 has an allocation unit that secures resources such as a register file for storing the instruction processing result. However, threads 101a and 101b can execute out-of-order, in which case allocation / rename block 130 also reserves other resources such as a reorder buffer for tracking instruction results. The assign / rename block 130 may further include a register rename unit that renames the program / instruction reference register to another register within the processor 100. The reorder / retirement unit 135 includes components such as the above-described reorder buffer, load buffer, and storage buffer to support out-of-order execution and in-order retirement of instructions executed out of order. Yes.

  The scheduler and execution unit block 140, according to one embodiment, includes a scheduler unit that schedules instructions / operations for the execution unit. For example, a floating point instruction is scheduled at a port of an execution unit that has an available floating point execution unit. A register file associated with the execution unit is also included to store information on the instruction processing result. Examples of the execution unit include a floating point execution unit, an integer execution unit, a jump execution unit, a load execution unit, a storage execution unit, and other known execution units.

  A low level data cache and data conversion buffer (D-TLB) 150 is coupled to the execution unit 140. The data cache stores recently used / calculated elements. For example, data operands held in the memory coherency state are stored. The D-TLB stores recent virtual / linear address to physical address translations. As a specific example, the processor may include a page table structure that divides physical memory into a plurality of virtual pages.

  According to one embodiment, the processor 100 can perform hardware transactional execution, software transactional execution, or a hybrid execution that combines these. A transaction, also called a critical or atomic part of code, includes an instruction group, an operation group, or a micro operation group to be executed as an atomic group. For example, instructions or operations may be used to define transactions or critical parts. According to one embodiment, as will be described in more detail below, such instructions form part of an instruction group such as an instruction group architecture (ISA) recognizable by the processor 100 hardware, such as the decoder described above. Yes. In many cases, such instructions include operation code (opcode) or other portions of the instruction that the decoder recognizes in the decoding stage when compiled from a high-level language to an assembly language that can be recognized by hardware.

  During the execution of a transaction, updates to memory are usually not globally visible until the transaction is committed. As an example, a transactional write to a location is visible to the local thread, but until the transaction containing the transactional write is committed, the write data in response to a read from another thread Never transfer. While the transaction is still running, it tracks the data items / data elements loaded from and written to memory. This will be described later in more detail. When a transaction reaches the commit point, if no conflict is detected for the transaction, the transaction is committed and the updates made during transaction execution are globally visible.

  However, if the transaction is invalidated during execution, the transaction is aborted and the update is resumed without global visibility. For this reason, the expression “transaction in progress”, as used herein, means a transaction that has been started and has not been committed or aborted, that is, being executed.

  Software transactional memory (STM) systems typically mean performing access tracking, conflict resolution, or other transactional memory tasks in software, or at least partially in software. According to one embodiment, the processor 100 may execute a compiler that compiles program code to support transactional execution. Here, the compiler may insert operations, calls, functions, and other code that enables execution of transactions.

  A compiler typically includes a program or group of programs that convert source text / code into target text / code. When a program / application code is compiled by a compiler, the program / application code is often divided into a plurality of stages and paths, and the high-level programming language code is converted into a low-level machine language code or assembly language code. However, a one-pass compiler may be used to simplify compilation. The compiler may execute any known compiler process using any known compilation method. For example, lexical analysis, preprocessing, syntax analysis, semantic analysis, code generation, code conversion, and code optimization may be performed.

  When a compiler becomes large, it often includes a plurality of stages, but generally two stages are the most common. (1) Front-end stage, ie, syntactic processing, semantic processing, and part conversion / optimization stage; (2) Back-end stage, ie analysis, conversion, optimization, and code generation It is divided into the stage to execute. Some compilers have a middle end where the boundary between the front-end and back-end phases of the compiler is ambiguous. For this reason, insertion, mapping, generation, or other compiler processing may be performed at any of the stages or passes described above and any other known compiler stage or pass. Good. To illustrate, for example, the compiler inserts transactional operations, calls, functions, etc. at one or more stages of compilation, for example, inserts calls / operations at the front end stage of compilation, and transactional In the memory conversion stage, the call / operation is converted into a lower code.

  However, regardless of the compiler's dynamic or static nature and execution environment, the compiler, according to one embodiment, compiles the program code to allow transactional execution. Thus, when referring to execution of program code, according to one embodiment, (1) a compiler for compiling the main program code, maintaining a transactional structure, or performing other transaction-related processing. Executing the program dynamically or statically; (2) executing main program code including transactional operations / calls; and (3) other program code such as a library associated with the main program code. Or (4) a combination of these.

  Compilers are often used in software transactional memory (STM) systems to insert some operations, calls, and other code according to the application code to be compiled. On the other hand, other operations, calls, functions, and code are provided separately within the library. With this configuration, it is possible to obtain the function of the library distribution unit that optimizes and updates the library without recompiling the application code. As a specific example, a call to a commit function may be inserted according to a transaction commit point in application code, and the commit function may be provided separately in an updatable library. Also, the choice of where to place certain operations and calls affects the efficiency of application code. For example, when a filtering process described later in more detail in association with an access barrier with reference to FIG. 6 is inserted according to a code, the filtering process is an inefficient way of performing the filtering process after guiding to the barrier Rather, it may be done before inducing execution towards the barrier.

  According to one embodiment, the processor 100 can perform transactions utilizing hardware / logic. That is, it can be executed in a hardware transactional memory (HTM) system. When implementing an HTM, there are many details regarding specific implementations from both an architectural and micro-architecture perspective, most of which are described herein to avoid unnecessarily obscuring the present invention. Then, explanation is omitted. However, some structures and examples are disclosed for illustrative purposes. However, it is noted that the structures and examples disclosed are not essential and other structures that differ in detail in implementation may be added and / or replaced with such other structures. I want to be.

  In combination, the processor 100 may be capable of executing transactions in an unlimited transactional memory (UTM) system that seeks to take advantage of both STM and HTM systems. For example, HTM is often suitable for executing small transactions at high speed and efficiency. This is because no software is used to perform all of access tracking, conflict detection, authentication and transaction commit. However, an HTM can usually only handle relatively small transactions. On the other hand, STM does not limit the size of transactions that can be processed. Thus, according to one embodiment, the UTM system utilizes hardware to perform relatively small transactions and software to perform transactions that are too large for the hardware. As can be seen from the following description, hardware may be utilized to assist and accelerate the software, even when the software is processing transactions. Furthermore, it is important to note that the hardware used to support and accelerate a pure STM system is the same.

  As described above, transactions include transactional memory access to data items by local processing elements and other processing elements within processor 100. If there is no safety mechanism in the transactional memory system, some of these accesses result in invalid data and execution. That is, writing to data that invalidates reading, reading of invalid data, or the like. To this end, the processor 100 includes logic to track or monitor memory accesses to data items to identify potential conflicts. For example, as will be described later, a read monitoring unit and a write monitoring unit are provided.

  A data item or data element may include any level of granularity defined by hardware, software, or a combination thereof. Examples of data, data elements, data items or references to them are not exhaustive but include memory addresses, data objects, classes, dynamic language code type fields, dynamic language codes There are indirect references to types, variables, operands, data structures, and memory addresses. However, any known data group may be referred to as a data element or data item. Some of the above examples, for example, dynamic language code type field and dynamic language code type, refer to the data structure of the dynamic language code. For example, a dynamic language code such as Java (registered trademark) manufactured by Sun Microsystems, Inc. is a highly typed language. Each variable has a type that becomes apparent at compile time. Types are divided into two categories: primitive types (boolean and numeric, eg, integer, floating point) and reference types (class, interface, and array). A reference type value is a reference to an object. In Java (registered trademark), an object consists of a plurality of fields, and may be a class instance or an array. For an object a of class A, a field x of type A is represented using the notation A :: x, and a. Usually, the field x of the object a of class A is represented by the notation method x. For example, the formula is a. x = a. y + a. It may be represented by z or the like. In this case, field y and field z are loaded and added, and the result is written in field x.

  Thus, monitoring / buffering of memory access to data items may be performed at any data level granularity. For example, according to one embodiment, memory access to data is monitored at the type level. Here, transactional writes to field A :: x and non-transactional loads of field A :: y may be monitored as accesses to the same data item, type A. According to another embodiment, memory access monitoring / buffering is performed at a field level granularity. In this case, transactional writes to A :: x and non-transactional loads of A :: y are not monitored as accesses to the same data item because they refer to different fields. It should be noted that other data structures or programming techniques may be taken into account for tracking memory accesses to data items. As an example, field x and field y of a class A object, ie A :: x and A :: y, specify a class B object and are initialized to a newly allocated object, Assume that writing is never done after initialization. According to one embodiment, a transactional write to the field B :: z of the object specified by A :: x is a non-transactional load of the field B :: z of the object specified by A :: y. Is not monitored for memory accesses to the same data item. From the above example, it can be inferred that the monitoring unit performs monitoring / buffering at an arbitrary data granularity level.

  According to one embodiment, the processor 100 comprises a monitoring unit that detects or tracks accesses associated with data items and conflicts that may occur thereafter. For example, the hardware of the processor 100 includes a read monitoring unit and a write monitoring unit that track loads and stores determined to be monitored. For example, the hardware read monitoring unit and the write monitoring unit monitor the data item at the granularity of the data item regardless of the granularity of the basic storage structure. According to one embodiment, the data items are defined by a tracking mechanism that is associated with granularity of the storage structure so that at least the entire data item is properly monitored.

  As a specific example for explanation, the read monitoring unit and the write monitoring unit associate an attribute associated with a cache position, for example, a position in the low-level data cache 150, with the position. Include to monitor load and store for addresses. In this case, the read attribute of the cache position of the data cache 150 is set to monitor a conflicting write for the same address in response to a read event for the address associated with the cache position. Here, the write attribute is similarly manipulated for the write event to monitor for read and write contention for the same address. To further explain based on this example, the hardware conflicts by snooping reads and writes to a cache location and setting the read and / or write attributes to indicate that the cache location is being monitored. Can be detected. Conversely, according to one embodiment, a snoop such as a read request or ownership read request is performed by setting a read monitor and a write monitor, or by updating the cache location to a buffered state. The As a result, it is possible to detect a conflict regarding the monitored address of another cache.

  For this reason, depending on the design, a conflict may occur depending on the combination of the monitoring target coherency state of the cache line and the cache coherency request. For example, a cache line that holds a data item that is shared and is subject to read monitoring, and a snoop that indicates a write request for the data item. Conversely, a cache line holding a data item in a buffered write state and an external snoop that indicates a read request for the data item may be considered as potentially causing a conflict. According to one embodiment, to detect a combination of access request and attribute state in this manner, the snoop logic includes conflict detection / reporting logic, eg, monitoring and / or logic for conflict detection / reporting, and , Coupled to a status register for conflict reporting.

  However, depending on the combination of conditions and scenarios, a transaction that may be defined by an instruction such as a commit instruction may be considered invalid. This will be described in detail later with reference to FIGS. 11 and 12. Examples of factors that do not consider a transaction to commit include detecting conflicts for memory locations where transactional access was performed, loss of monitoring information, loss of buffered data, and data items subjected to transactional access This includes detecting attached metadata loss and other invalid events such as interrupts, ring transitions, or explicit user instructions.

  According to one embodiment, the hardware of processor 100 holds transactional updates in a buffered state. As described above, transactional writes are not globally visible until the transaction is committed. However, local software threads associated with transactional writes can access transactional updates for subsequent transactional access. As a first example, the processor 100 is provided with a separate buffer structure that holds buffered updates, which can supply updates to local threads, but not to other external threads. Cannot supply. However, providing a separate buffer structure increases cost and complexity.

  In another example, in contrast, a cache memory, such as data cache 150, is used to buffer updates while also maintaining the functionality of transactional processing. Here, the cache 150 can hold data items in a buffered coherency state. In some cases, the newly buffered coherency state is added to a cache coherency protocol such as MESI (Modified, Exclusive, Shared Invalid) protocol to create a MESIB protocol. Cache 150 provides data items to local processing elements in response to local requests for buffered data items, i.e., data items held in buffered coherency state, so that internal transactions are sequential. Guarantee the order. However, for external access requests, a miss response is provided so that transactionally updated data items are not globally visible until commit. Further, if a line in the cache 150 is held in a buffered coherency state and selected for eviction, this buffered update is not written back to the higher level cache memory. This buffered update is not spread within the memory system. In other words, it will not be visible globally until the commit is complete. When the commit is complete, the buffered line transitions to the modified state, making the data item visible globally.

  Note that the terms “internal” and “external” are typically “internal” and “external” from the perspective of multiple processing elements sharing a thread or cache associated with the execution of a transaction. For example, a first processing element that executes a software thread associated with execution of a transaction is called a local thread. Thus, in the above description, when a store or load is received for an address previously written by the first thread and the corresponding cache line is held in a buffered coherency state, the first thread is the local thread. Provide a buffered version of the cache line. In contrast, a second thread executing in another processing element of the same processor is not associated with the execution of a transaction corresponding to a cache line held in a buffered state and becomes an external thread. . Thus, a load or store from the second thread to this address will miss the buffered version of this cache line, and will use normal cache replacement to take an unbuffered version of this cache line from higher level memory. To get.

  Here, the “internal / local” thread and the “external / remote” thread are running on the same processor, and in some embodiments, separate, sharing access to the cache in the same core of the processor. It may be executed by a processing element. However, the meaning of these terms is not limited to the above contents. As described above, “local” is not limited to one thread associated with execution of a transaction, but may mean a plurality of threads sharing access to the cache. On the other hand, “external” or “remote” may mean a plurality of threads that do not share access to the cache.

  As initially mentioned with respect to FIG. 1, the architecture of the processor 100 is merely illustrative for purposes of illustration. Similarly, a specific example of converting a data address for referring to metadata is merely an example, and any method may be used to associate data and metadata in separate entries of the same memory.

<Metaphysical address space for metadata>
<Metadata>
Referring to FIG. 2, an embodiment of maintaining data item metadata in a processor is illustrated. As shown in the figure, the metadata 217 of the data item 216 is held locally in the memory 215. The metadata includes any characteristic or attribute associated with the data item 216, for example, transactional information regarding the data item 216. For the sake of explanation, some examples of metadata will be described later. However, the disclosed metadata examples are merely illustrative and are not exhaustive. Further, the metadata position 217 may be held in combination with an example to be described later and other attributes of the data item 216 although not specifically described.

  As a first example, the metadata 217 is data written transactionally if the data item 216 was previously accessed, buffered, and / or backed up in a transaction. Contains a reference to the backup or buffer location of item 216. In this case, in some embodiments, the metadata 217 includes a reference, such as an address to this backup location, because the backup copy of the previous version of the data item 216 is kept at another location. Alternatively, the metadata 217 itself may function as a backup position or buffer position for the data item 216.

  As another example, metadata 217 includes filtering values to accelerate repeated transactional access to data item 216. In many cases, when executing a transaction using software, an access barrier is executed in transactional memory access to ensure consistency and data validity. For example, the read barrier process is executed by executing the read barrier before the transactional load process. For example, to test whether the data item 216 is locked, determine whether the current read setting of the transaction is still valid, update the filtering value, and verify the transaction so that it can be verified later Record the version value of the read setting. However, if the reading of this position has already been executed during the execution of the transaction, the same reading barrier process is not necessary.

  For this reason, one solution is to use a read filter and retain a first default value indicating that reading to the data item 216 or the address has not been performed during execution of the transaction, A second accessed value indicating that an access to the data item 216 or the address has already been made during the execution of the transaction is held. Basically, the second accessed value indicates whether the read barrier should be accelerated. In this example, if a transactional load process is received and the read filtering value at metadata location 217 indicates that data item 216 has already been read, in one embodiment, the read barrier is omitted and implemented. Without executing unnecessary and redundant read barrier processing, transactional execution is accelerated. Note that the write filtering value may have the same configuration for the writing process. However, each filtering value is exemplary only, and according to one embodiment, a single filtering value is used to determine whether an access has already been made, whether written or read for an address. Show. Here, such a filtering value is used in the metadata access process for confirming both the load and store processes of the metadata 217 of the data item 216. This is in contrast to the above example where the metadata 217 includes read and write filtering values separately. For illustrative purposes, the four bits of metadata 217 are used to indicate whether or not the read barrier should be accelerated for the associated data item, and for the associated data item. The writing filter indicating whether or not the writing barrier should be accelerated, the canceling filter indicating whether or not the cancellation processing should be accelerated, and the miscellaneous filter used as a filtering value by software in an arbitrary method.

  Some other examples of metadata include addressing, explaining or referring to an address for a handler or generic handler specific to the transaction associated with the data item 216, and a transaction associated with the data item 216. Irrevocability / strength of data, loss of data item 216, loss of monitoring information of data item 216, detection of conflict regarding data item 216, read entry of read setting or read setting address associated with data item 216 The previously recorded version of the data item 216, the current version of the data item 216, a lock that allows access to the data item 216, the version value of the data item 216, and the transaction associated with the data item 216. Transfection transaction descriptors, and, there is a description information related to other known transaction. Furthermore, as described above, the use of metadata is not limited to transaction information. Thus, the metadata 217 may further include information, characteristics, attributes, or states associated with the data item 216 that are not related to the transaction.

  Continuing with the description of metadata, the hardware monitoring and buffered coherency states described above are also considered metadata in some embodiments. The monitor indicates whether an external read request or external ownership read request for a location should be monitored, and the buffered coherency state indicates whether the corresponding data cache line holding the data item is buffered . However, in the above example, the monitoring unit is maintained as an attribute bit attached to the cache line or an attribute bit directly associated with the cache line, and the buffered coherency state is added to the cache line coherency state bit. The For this reason, in this case, the hardware monitor and buffered coherency state form part of the cache line structure and are maintained in metadata and another metaphysical address space as illustrated. Not. However, in other embodiments, the monitoring unit may be maintained as metadata 217 in a memory location separate from the data item 216, and similarly, the metadata 217 may be a data item that has been buffered by the data item 216. It may include a reference indicating that Conversely, instead of the in-situ update architecture described above where the data item 216 is updated and held in a buffered state, the metadata 217 holds the buffered data item and the globally visible version of the data item 216 is It may be maintained in its original position. In this case, when committed, the data item 216 is replaced with a buffered update held in the metadata 217.

<Lost metadata>
As described above with respect to buffered cache coherency states, according to one embodiment, metadata 217 is local information that is lossy and is not provided for external requests from outside the domain of memory 215. Assuming that memory 215 is a shared cache memory in one embodiment, misses to metadata access processing are not provided outside the domain of cache memory 215. Basically, the lossy metadata 217 is held only locally in the cache domain and does not exist as data that is valid for the entire memory subsystem. There is no reason to answer. Thus, mistakes for lossy metadata may be provided quickly and efficiently, and memory in the processor may be immediately allocated without waiting for external requests for metadata to be generated or provided.

<Metaphysical address space>
As shown in the illustrated embodiment, the metadata 217 is held at a different memory location than the data item 216, i.e., at a different address, and there will be a separate metaphysical address space for the metadata. . The metaphysical address space is a space orthogonal to the data address space, and the metadata access processing for the metaphysical address space does not hit or modify the physical data entry. However, in embodiments where the metadata is held in the same memory, such as the memory 215, the metaphysical address space may affect the data address space due to contention for allocation in the memory 215. In one example, the data item 216 is cached in an entry in the memory 215, and the metadata 217 of the data 216 is held in another entry in the cache. In this case, in subsequent metadata processing, the memory location of the data item 216 may be selected as an eviction target and the metadata of another data item may be retained instead. Therefore, the process associated with the address of the metadata 217 does not hit the data item 216, and the metadata address of the metadata element is held instead of the physical data such as the data item 216 in the memory 215. The

  In this example, metadata and data compete for the space in the cache memory. However, if the metadata can be held locally, the metadata can be used without the high cost of diffusing metadata that is valid in the entire memory hierarchy. Is efficiently supported. In another embodiment, the metadata 217 associated with / in the data item 216 is different from the data item 216, as estimated from this example assumption that the metadata is held in the same memory, ie, the memory 215. Retained in the memory structure. In this case, the metadata address and the data address are the same, but the metaphysical part of the metadata address leads to another metadata storage structure instead of the data storage structure.

  When the ratio of metadata to data is 1: 1, the metaphysical address space is shadowed in the data address space, but is orthogonal as described above. In contrast, as described below, metadata may be compressed against physical data. In this case, the size of the metaphysical address space for metadata does not shadow on the size of the data address space, but is still orthogonal.

<Metaphysical address conversion>
Continuing with the description of the metaphysical address space, the data address in the data address space, eg, the address of the data item 216, is converted into a metaphysical address in the metaphysical address space, eg, a metadata address for the metadata 217. In some cases, any method may be used. According to one embodiment, metaphysical conversion logic 210 is used to convert an address, such as data address 200, to a metadata address. As illustrated, the address 200 includes an address associated with the data item 216 or an address referring to the data item 216. The data item 216 may be indexed in the memory 215 using normal data translation, such as translation between a physical or linear address and a virtual address. Also, the association between the metadata 217 and the data item 216 includes a similar conversion from an address 200 referring to the data item 216 to another different address referring to the metadata 217, so that the address 200 is converted into data conversion logic. The conversion to a data address in 205 and the conversion to another metaphysical address in the metaphysical conversion logic 210 are separate accesses that do not interfere with each other, and the two address spaces are orthogonal. Become. As will be described in more detail below, the data conversion logic 205 or the metaphysical conversion logic 210 is used according to the type of access processing for the address 200 according to one embodiment, and is a normal data access processing for accessing the data item 216. In this case, the data conversion logic 205 is used, and in the metadata access processing for accessing the metadata 217, the metaphysical conversion logic 210 is used. This can be specified by a part of the instruction / processing operation code (opcode).

  In another embodiment, an instruction may access both metadata and data for a given metadata address, as specified by its opcode, so complex processing, for example, data based on metadata A conditional store to may be performed. In one example, the instruction is decoded into a metadata test and setting process to test the metadata and set it to a value, and set the data to a value if the metadata test is successful. Decoded for additional processing. According to another example, the data item may be moved to a matching metadata address based on the data read from the data memory.

  An example of converting the data address 200 to a metadata address for the metadata 217 will be described below. As a first example, converting a data address to a metadata address includes using a physical address or a virtual address after processing of the normal data conversion logic 205, and separating the data address from the metadata address. Adding a metaphysical value in the transformation logic 210. When the virtual address is used without performing the conversion, the metaphysical conversion logic 210 includes logic that combines the virtual address and the metaphysical value. However, when normal virtual-physical address conversion is used, the post-conversion address is acquired from the address 200 using the normal data conversion logic 205, and the logic provided in the metaphysical conversion logic 210 is A metadata address is generated by combining the address and the metaphysical value. As another example, the data address 200 may be converted utilizing a separate conversion structure, conversion table and / or conversion logic within the metaphysical conversion logic 210 to obtain a distinct metadata address. In this case, the metaphysical conversion logic 210 mirrors or has another logic, such as a logic that combines the address 200 with the metaphysical value, compared to the data conversion logic 205, but the metaphysical conversion The logic 210 includes page table information for translating the address 200 into another distinguishable metadata address. By adding information to the metadata address, expanding with information added to the metadata address, replacing information contained in the metadata address, or converting the data address to obtain the metadata address The resulting distinct metadata address can be used to add, extend, replace or transform data items while maintaining orthogonality for erroneously updating or reading data items. It can be seen that they are associated with.

  For the sake of explanation, some specific examples of processing for converting a data address into a metadata address, that is, processing for determining a metadata address based on the data address will be given below.

(1) The first data address is converted to the second data address using normal virtual-physical address conversion, and the metadata address is formed by adding, adding, or including the metaphysical value to the data address. .
(2) Virtual-physical address conversion is not performed on the data address, and a metaphysical value is added to, added to, or included in the data address to form a metadata address.
(3) The data address is converted into a post-conversion metadata address using the metaphysical conversion table logic. Although not necessarily required, a metadata address is formed by adding, adding, or including a metaphysical value to the converted metadata address. Further, any of the above-described conversion methods incorporates a data-to-metadata compression ratio, that is, is performed based on the compression ratio, and stores metadata separately for each compression ratio.

  In this case, the address may be modified for translation and / or compression. For example, you can ignore certain bits in the address, delete certain bits in the address, change which bit range is used in the address to select the granularity of data, or convert certain bits Or a specific bit may be added or replaced with metadata-related information. The compression will be described later in detail with reference to FIG.

<Multiple metaphysical address spaces>
FIG. 3 illustrates an embodiment that supports multiple metaphysical address spaces. According to one embodiment, each processing element is associated with one metaphysical address space, and each processing element can maintain independent metadata. Four processing elements 301-304 are illustrated. As described above, the processing elements may include any of the elements described above with reference to FIG. In the first example, the plurality of processing elements include a plurality of cores of one processor. However, as can be seen from the illustrative examples described below, the processing elements 301-304 are described in relation to multiple hardware threads (threads) in one processor. Each hardware thread executes one software thread and multiple software subsystems.

  For this reason, it is beneficial to have each thread of threads 301-304 maintain separate metadata. According to one embodiment, the metaphysical translation logic 310 maps accesses from multiple different threads 301-304 to the appropriate metaphysical address space. As an example, the correct metaphysical address space is guided by the thread identifier (ID) used together with the address referred to by the metadata access process.

  For purposes of explanation, assume that a metadata access process associated with thread 302 and referring to data address 300 of data item 316 has been received. As described above, an arbitrary conversion method may be used to convert the data address for the data item 316 into a metadata address. However, this conversion process further includes combining the thread ID 302. The thread ID 302 may be acquired from, for example, a control register for the thread 302, or may be received from an operation code of an instruction received from the thread 302. This combination processing may include adding the thread ID 302 to the address, replacing a bit included in the address, or executing another known method of associating the thread ID with the address. In this way, the metaphysical translation logic 310 can select / direct to the metaphysical address space for the processing element 302 that is associated with the data item 316.

  Inferring from this example, by using the thread ID for threads 301-304 as part of the conversion to a metaphysical address, each processing element 301-304 can maintain metadata independently for each data item 316. is there. However, the programmer does not need to manage multiple metaphysical address spaces separately. This is because the hardware can separate a plurality of metaphysical address spaces using thread IDs transparently to software. In addition, since each metadata access is associated with a separate address group including a reference to a unique thread ID, the plurality of metaphysical address spaces are orthogonal, and a certain metadata access from a thread Does not access metadata from another thread.

  However, as described below, with respect to instructions / processes that access metadata, a metadata access from one thread may be provided with access to another thread's metadata. That is, in some embodiments, access across multiple PEIDs and / or MDIDs (discussed below) may be beneficial. For example, to determine whether the hardware has detected a conflict, check for metadata monitoring from another thread and whether another thread is monitoring the associated data item To clear the other thread's metadata or to determine the commit condition that the thread needs to check to determine the other thread's metadata associated with the data item 316 Correct or clear

  In this case, since a specific opcode for the process for accessing the metadata of another thread is recognized, the metaphysical conversion logic 310 performs the conversion of the address 300 and all of the metadata to be accessed is converted. Get the metadata address. For illustrative purposes, 4 bits are added to the address 300, each bit represents one of the processing elements 301-304, and metadata access processing such as clear processing is a data item. Clearing all metadata for 316, the metaphysical conversion logic 310 sets each of the 4 bits to access all metadata 317. In this case, the look-up logic for the memory 315 is designed to access all metadata 317 with one access with all four bits set, or the metaphysical conversion logic 310 has four Different thread ID bits of each of the 4 bits may be set to generate separate accesses and access all metadata 317. To illustrate, for example, a mask may be applied to an address value to cause one thread to hit another thread's metadata.

  Further, as shown in the figure, each of the processing elements 301 to 304 is associated with a plurality of metaphysical address spaces, and a plurality of contexts or software subsystems in one thread are converted into a plurality of metadata address spaces. It may be interleaved. For example, it may be beneficial to have multiple software subsystems of a processing element maintain multiple independent metadata sets. Thus, by way of example, orthogonal metadata address spaces may be provided at various processing element levels. For example, it may be provided at the core level, the hardware thread level, and / or the software subsystem level. In the figure, each of the processing elements 301-304 is associated with two metaphysical address spaces, and each of these two metaphysical address spaces is a plurality of software executed by any one of the processing elements. Associated with a subsystem.

  The software subsystem includes any task or code that is to be executed on a processing element that utilizes a separate metaphysical address space. As an illustrative example, the four subsystems that are individually mapped to the metaphysical address space are a transactional runtime subsystem, a garbage collection runtime subsystem, a memory protection subsystem, And a software conversion subsystem. In this case, the software subsystems may have different timings for controlling the processing elements. As another example, a software subsystem includes multiple separate transactions that are executed on a processing element. In practice, it may be desirable for multiple nested transactions executed in the same thread to be associated with different metaphysical address spaces. To illustrate, the filtering test for access to data items in the outer transaction may fail, but provides a second separate filter for access to the same data item in the inner nested transaction Is beneficial. Apart from this second further filter, it may succeed in accelerating access in the inner transaction. In addition, when a nested inner transaction is aborted, each nested transaction, or subsystem, is associated with a different metadata space in order to maintain metadata for the outer transaction. And clearing the inner nested transaction's metadata does not affect the outer transaction's metadata. However, the software subsystem may be any task or code capable of managing metadata, and is not limited to this.

  According to one embodiment, in order to provide an orthogonal metaphysical address space at the level of the software subsystem, the address is combined with a processing element ID (PEID) as described above, and further a metadata ID (MDID) or context. Combine with ID. Thus, another metadata may be uniquely identified for the subsystem within the processing element. Using the above example, assume that processing elements 301-304 are hardware threads, and thread 302 is executing an outer transaction and an inner transaction nested inside of this outer transaction. For the outer transaction, the metadata 317c converts the data address 300 of the data item 316 into an address and thread ID (TID) and a metadata ID (MDID) for the outer transaction that references the metadata 317c. Corresponding to data item 316 by logic 310.

  For illustrative purposes only, metadata 317c may include four filtering values, a read filtering value, a writing filtering value, a cancellation filtering value, and a miscellaneous filtering value, a pointer to the backup location of data item 316, or other The reference includes a monitoring value indicating whether the monitoring unit for the data item 316 has been lost, a transaction descriptor value, and a version value of the data item 316. Similarly, the inner transaction is associated with metadata 317d for data item 316 that includes the same metadata fields as metadata 317c. As described above, the metaphysical conversion logic 310 converts the data address 300 for the data item 316 into an address that is combined with the metadata ID and thread ID of the inner transaction that references the metadata 317d.

  In this case, the only difference between the metadata address referring to the metadata 317c and the metadata address referring to the metadata 317d is the metadata ID for the outer transaction and the inner transaction. Because of this difference in address, the address spaces will be separate / orthogonal from each other, and the MDID of the access from the inner transaction is different from that of the access from the outer transaction, so the metadata from the inner transaction Access to does not affect metadata from outer transactions. As mentioned above, this may be useful for rolling back nested transactions or for maintaining different metadata values for each level of transaction. Specifically, when the inner transaction is aborted, the backup data of the data item 316 held in the metadata 317d is cleared, or the outer data held in the metadata 317c without being cleared. It may be used to roll back the data item 316 to the entry point before the inner transaction without affecting the backup data of the transaction.

  Note that the metadata ID (MDID) for separating the software subsystem metaphysical address spaces may be of any size and may be obtained from various sources. Taking a very simple example for illustration purposes, if there are four processing elements (PE) 301-304, the PEID may be a two-bit combination, 00, 01, 10, 11. Similarly, if four separate metaphysical address spaces are supported, the four subsystems can be similarly distinguished by a 2-bit MDID, 00, 01, 10, 11. To illustrate, the value representing the second subsystem in processing element 302 and PE 302 includes 0101 (the first two bits of 01 represent PE 302 and the subsequent two bits of 01 represent the second subsystem). In this example, the metaphysical conversion logic combines this value with the data address 300 or the converted value of the data address 300, and refers to 01 which is the MDID of the PE 302 including the metadata position 317d.

  However, both thread ID and MDID may be more complex. For example, assume that threads 301-302 share access to memory 315 and threads 303-304 are remote processing elements that do not share access to memory 315. Each of the threads 301-302 supports two software subsystems, and for the threads 301-302, a total of four orthogonal address spaces, PE301 MD0, PE301 MD1, PE302 MD0, and PE302 ME1, are supported. Assuming that In this case, the value obtained by combining the thread ID and the MDID used for acquiring the metadata address may be obtained from the operation code, the control register, or a combination thereof. To illustrate, the opcode provides one bit for context / MDID, the control register assumes one processing element ID (PEID), assuming only two processing elements, MDCR 320, etc. The metadata control register provides 4 bits to identify a particular software subsystem / context for fine graining. For this reason, when a metadata access process referring to the address 300 of the data item 316 is received from the second thread PE302, one bit from the opcode, that is, a first bit including 1 indicating the second context, And the second bit from the control register of the processing element 302, the second bit including 1 indicating the processing element 302, and the MDID from the metadata control register (MDCR) 320 associated with the second thread. Combine with. The MDCR has already been updated with the MDID of the current subsystem that is controlling the second thread “0010” to identify the appropriate subsystem associated with the received process. The metaphysical conversion logic acquires a combined value, for example, “110010”, and further acquires a metadata address by combining with the data address 300 or the converted value of the data address 300 that is referred to. However, since the “110010” portion of the metadata address is unique for the subsystem from which the access process originated, it is the metaphysical address space of the other subsystems in the second thread and other threads that are orthogonal to each other. Only the metadata address 317d in the memory 315 is hit or corrected without hitting or affecting the metadata addresses 317a, b, c, e, f, g, and h.

Specific examples of the MDCR will be described with specific examples for explanation. According to some embodiments, the ISA may be extended with a per-thread metadata identifier register (MDID register) that provides MDID to MDID-dependent metadata load / store / test / set instructions. In some embodiments, it is convenient to have a plurality of such registers. For example, the metadata control register (MDCR) is a 32-bit read / write register that holds the current metadata context ID (MDID). It may be updated with CR MOV. An example of bit field definition is shown below.

  MDID0 and MDID1 are metadata IDs that can be accessed simultaneously by an instruction group. Of these fields, the number of bits actually used is MDID_size. According to one embodiment, this field is read only at the permission level as specified in the processor design. However, according to other embodiments, this size may be modifiable at other levels of privilege. There may be no hardware confirmation mechanism to confirm that the MDID is within this allocated bit size. According to one embodiment, MDID0 and MDID1 can be read and written at any permission level. It is also possible to use a special MDID value that designates a special metadata space in which the read result is always 0 or 1. This may be used by software that forces all metadata tests in a block to be true or false, as well as registers that force metadata values as described with reference to FIGS.

  However, in another example, as described above, the metaphysical transformation logic 310, together with a decoder (not shown), from the thread 302 intended to access the metadata in the metadata address space of the thread 301. The metadata access process can be recognized, and the reading or modification of the metadata of the thread 301 is permitted for such a specific instruction / process access.

<Metadata compression for data>
In the above description, uncompressed metadata has been described when mapping data to metadata on a one-to-one basis. However, in some cases, it is more efficient to use metadata whose amount is reduced than that of data and to compress metadata so that the metadata size is smaller than the data size. The metaphysical address conversion logic 210 and 310 shown in FIGS. 2 and 3 may refer to the compressed metadata in consideration of compression when performing address conversion and correction. FIG. 4 illustrates an embodiment in which addresses are modified to achieve metadata compression. Specifically, an embodiment where the data to metadata compression ratio is 8 is shown. Control logic such as the metaphysical address translation logic 210 and 310 of FIGS. 2 and 3 receives the data address 400 referenced by the metadata access process. In one example, compression includes shifting log2 (N) bits at address 400 or deleting log2 (N) bits from address 400. N represents the compression ratio of data to metadata. In the illustrated example, when the compression ratio is 8, the metadata address 405 is deleted by shifting the lower 3 bits. Basically, an address 400 that contains 64 bits and refers to a particular data byte in memory is a metadata byte address 405 that is used to refer to metadata in memory with byte granularity by truncating 3 bits. Form. Of these, 1 bit of metadata is selected using 3 bits already deleted from the address to form a metadata byte address.

  According to one embodiment, other bits are used instead of the shifted / deleted bits. As shown, the high order bit after address 400 is shifted uses zero instead. However, other data or information may be used in place of the deleted / shifted bits. For example, a metadata ID (MDID), context identifier (ID), and / or processing element ID associated with the metadata access process may be used. In this example, the predetermined number of bits from the least significant bit have been deleted, but arbitrary, such as cache composition, cache circuit timing, locality of metadata for data, and minimizing conflicts between data and metadata The bit at any position may be deleted and replaced based on the number of factors.

  For example, the data address may not be shifted by log2 (N), but the address bits 0: 2 may be set to zero. For this reason, the bits of the same physical address and virtual address are not shifted as in the above example, and it becomes possible to select a set and a bank in advance with bits that are not modified, such as bits 11: 3.

  In addition, about the description regarding conversion, you may combine compression. In other words, the compression ratio may be input to the metaphysical address translation logic 210 and 310 of FIGS. 2 and 3, which translates the PEID, CID, MDID, metaphysical value, or data address into metadata. Use compression ratio along with other information to convert to address. The metadata address is then used to access the memory holding the metadata. As described above, since the metadata is generated locally, there is a lot of loss, and if a mistake occurs in the memory based on the metadata address, it can be dealt with immediately and efficiently, and the allocation of the memory location Is performed without generating an external error handling request and without waiting for an external request to be handled. Here, entries are allocated for metadata in the usual way. For example, based on the cache replacement algorithm such as the metadata address 405 and the least recently used (LRU) algorithm, an entry such as the entry 217 shown in FIG. 2 is selected, assigned, and initialized to a metadata default value. Thus, while metadata and regular data compete for space, the metadata remains compressed and remains separate from other software subsystems / processing elements.

  Note that setting the compression ratio to 8 is merely an example, and the compression ratio may be set to an arbitrary value. As another example, the compression ratio is 512: 1, where one bit of metadata represents 64 bytes of data. Similar to the above, the metadata address is formed by converting / modifying the data address and shifting the data address lower by log2 (512) bits, that is, 9 bits. In this case, instead of bits 0: 2, bits 6: 8 remain unchanged and are used to select one bit, and compression is performed efficiently by selecting with a granularity of 512 bits. Since the data address is shifted by 9 bits, 9 bit positions are empty in the high-order part of the data address, and information can be held. According to one embodiment, these 9 bits hold an identifier such as a context ID, thread ID, and / or MDID. Metaphysical space values may also be held in these bits. Alternatively, this address may be extended with a metaphysical value.

  According to one embodiment, multiple simultaneous compression ratios are supported in hardware. In this case, information representing the compression ratio is held as part of the metaphysical value combined with the data address to obtain the metadata address. For this reason, when the memory is searched with this data address, the compression ratio is taken into consideration and does not coincide with addresses of various compression ratios. Also, the software may be able to use hardware so that store information is not transferred to a load with a different compression ratio.

  According to one embodiment, a single compression ratio is used to implement the hardware, but the hardware includes other hardware support that presents multiple compression ratios to the software. As an example, assume that the cache hardware is implemented with an 8: 1 compression ratio, as shown in FIG. However, metadata access processing that accesses metadata at multiple different granularities is decoded to include microprocessing that reads the default amount of metadata and test microprocessing that tests the appropriate portion of metadata reading. Is done. As an example, the default amount for reading metadata is 32 bits. However, the test process for different granularity / compression of 8: 1 is based on a predetermined number of bits of the address, eg 32 bits for reading metadata based on a predetermined number of bits and / or context ID from the LSB of the metadata address. Test for the correct bit.

  As an explanation, in a method in which metadata is not aligned with 1 bit of metadata per 1 byte of data, based on the lower 3 bits of the metadata address, the lower 8 bits of the 32 read bits of the metadata 1 bit is selected. For one word of data, two consecutive metadata bits are selected from the lower 16 bits of the read 32 bits based on the lower 3 bits of the address, and 16 bits for a 128 bit metadata size. The same goes until it becomes a bit.

<Metadata access instruction / processing>
FIG. 5 is a flowchart for explaining a method of accessing metadata associated with data. Although the steps of the flowchart shown in FIG. 5 are illustrated as being executed substantially sequentially, at least some of the steps may be executed in parallel, or may be executed in a different order. Good.

  In step 505, a metadata process that references the data address of a given data item is found. In the above description, it has been described that metadata instructions / processing is supported by hardware that reads, modifies, and / or clears metadata. That is, since instructions are supported by the processor's instruction set architecture (ISA), the processor's decoder may recognize the operation code (opcode) of the instruction that accesses the data and the logic that performs the access. Note that using an instruction may also mean processing. Some processors make use of the concept of macroinstructions that can be decoded into multiple microprocessing that each perform a separate task. For example, metadata test and set macro instructions are decoded into a metadata test process / micro process to test the metadata, and if the correct Boolean value is obtained as a result of the test process, the metadata is specified in the set process Update to the value of.

  However, metadata access processing is not limited to explicit software instructions that access metadata, but is decoded as part of a larger, more complex instruction that includes access to the data item associated with the metadata. Implicit microprocessing may be included. Here, the data access instruction may be decoded into a plurality of processes, for example, a process of accessing a data item and a process of implicitly updating associated metadata.

  As previously noted, according to one embodiment, the physical mapping between hardware metadata and data is not directly visible to software. For this reason, in this example, the metadata access process refers to the data address and correctly converts using the hardware, that is, executes mapping and appropriately accesses the metadata. However, each metadata access process may have a different reference metaphysical address space depending on the source thread, context, and / or software subsystem. Thus, the memory may hold the metadata of the data item transparent to the software. When the hardware detects processing for accessing the metadata, the hardware accesses the metadata by an explicit operation code (instruction opcode) or by decoding the instruction into a metadata access microprocessing. Necessary conversion is executed for the data address referred to by the access process.

  As described in this example, the program may include a plurality of separate processes, such as a data access process or a metadata access process that refers to the same address of a data item such as data items 216 and 316 shown in FIGS. And the hardware may map these accesses to different address spaces, such as a physical address space and a metaphysical address space. According to 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 these parameters may be explicit instruction operands, may be encoded in the opcode, or may be obtained from a separate control register. In the instruction, the metadata load / store process may be combined with another process. For example, some data may be loaded, some of those bits may be tested, and a condition code for subsequent conditional jumps may be set. In the command, all metadata or only metadata of a specific MDID may be flushed. Examples of metadata access processing are listed below. Some of the instructions given as examples are specifically related to instructions with a compression ratio of 64X, but even if not specifically disclosed, the same instructions may be used for other compression ratios. Alternatively, uncompressed metadata may be used.

<Metadata bit test and setting (MDLT)>
The metadata load and test instruction (MDLT) includes two arguments. That is, it is a register (destination operand) in which metadata including metadata associated with metadata as a source operand and metadata including bytes of bytes, words, d words, q words, or other sizes is written. The value of the tested metadata bit is written to the register. The programmer should not assume any knowledge about the data stored in the destination register of the MDLT instruction and should not manipulate this register. This register is only used as a source operand for the metadata store and set instruction (MDSS) to the same address. According to one embodiment, the MDLT instruction combines the test process and the setting process, but discards the setting process if the test is successful.

<Metadata Store and Settings (MSS)>
The metadata store and setting instruction (MDSS) have two arguments. A register (source operand) that stores metadata including a data address with which the metadata is associated and a byte, word, d word, q word or other size bits to be stored in memory. The MDSS instruction sets the correct bit in the value from the source operand.

<Metadata store and reset instruction (MDSR)>
The MDSR instruction has two source arguments. A register (source operand) that stores metadata that contains metadata as source operands and metadata that includes bytes, words, d words, q words, or other size bits to be reset . The MDSR instruction resets the correct bit in the value from the source operand.

  The metadata address is determined from the referenced data address. An example of determining a metadata address is included in the above description describing metaphysical address translation and multiple metaphysical address spaces. However, it should be noted that in order to store metadata separately for each compression ratio, the conversion incorporates a data-to-metadata compression ratio, ie, the conversion is based on the data-to-metadata compression ratio.

  The CMDT instruction converts a memory data address into a memory metadata address using a processing-dependent compression mapping function, and tests whether a metadata bit corresponding to the memory metadata address is set. As an example, the compression ratio CR is 1 bit for 8 bytes. In the calculation of the metadata address, one of the MDCR register context IDs is incorporated to provide a unique MD group for each context ID, and MDBLK [CR] [MDCR. MDID [MDID number]]. Address META. The instruction is forcibly aligned by aligning the address “mem” to the specified data size. The instruction tests whether metadata is set.

The following is an example of pseudo code associated with CDMT (the ZF flag is set to represent a metadata value of zero. All other flags are cleared).

  The CMDS instruction converts a memory data address into a memory metadata address with a processing-dependent compression mapping function. The compression ratio is 1 bit for 8-byte data. The encoding of the imm8 value is as follows. 0 → MD_Value; value to be stored in MD and 7: 1 → reserved; unused

An example of pseudo code associated with CMDS is described below.

  The CMDCLR instruction includes all MDBLK [CR] [MDCR. MDID [MDID number]]. Reset META.

Examples of pseudo code related to CMDCLR are described below.

  Subsequently, in step 510, the metadata access processing is performed based on the compression ratio, processing element ID, context ID, MDID, metaphysical value, operand size, and / or other values related to the transformation of the metaphysical address space. The metadata address is determined based on the data address referred to in. Using one of the methods described above, for example, converting a data address as usual without converting the data address, or performing a separate metaphysical address conversion on the data address to combine a plurality of ID values Thus, an appropriate metadata address may be acquired.

  Further, as described above, in some examples, a version of a test instruction, a set instruction, a clear instruction, etc., tests the metadata of another thread or metadata context in one thread or metadata context, Set or clear. Thus, conversion to a metadata address may include address modification, such as applying 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. In a normal case, an independent position of the metadata associated with the requesting local thread or context ID is accessed, and appropriate processing such as testing, setting and clearing is executed. However, in other cases, as described above, this step may access metadata of another thread or context ID.

<Abstraction>
In the following, an embodiment of software abstraction will be described. A given CR is a power of 2 indicating the number of bits of data mapped to one bit of metadata. Which CR value to use is defined by the implementation system. CR> 1 means compressed metadata. CR = 1 means uncompressed metadata.

  MDBLK [CR] [*] is ceil (CR / 8) bytes in size and is naturally aligned. MDBLK is associated with physical data, not with its own linear virtual address. All valid physical addresses A having the same floor (A / MDBLK [CR] [*] _ SIZE) value specify the same MDBLK group.

  For a given CR, any number of identifiable MDIDs can be provided, each MDID specifying a unique metadata instance. The metadata for a given CR and MDID is distinguishable from any other CR or MDID metadata. For example, assuming that addr is aligned with QWORD for Thd # 0, the metadata block specified by MDBLK [CR = 64] [MDID = 3] (addr) is MDBLK [CR = 64] [MDID. = 3] (addr + 7), but distinguishable from MDBLK [CR = 64] [MDID = 4] (addr) and MDBLK [CR = 512] [MDID = 3] (addr).

  In a given embodiment, multiple contexts may be supported simultaneously. In this case, the number of contexts is determined according to predetermined setting information and CR regarding a specific system of which the processor is a part. In the case of uncompressed metadata, a metadata QWORD is provided for each physical data QWORD.

  Only software interprets the metadata. The software may set, reset or test the META for a specific MDBLK [CR] [MDID], or may reset the META of all Thd MDBLK [*] [*], or a given The META of MDBLK [CR] [MDID] of all Thd crossing MBLK (addr) may be reset.

  Regarding metadata loss, the META characteristic of Thd may be spontaneously reset to 0, in which case a metadata loss event occurs.

<Forced metadata value>
FIG. 6 is a diagram illustrating an embodiment that provides hardware support for enforced metadata values. The STM usually uses an access barrier to guarantee consistency between memory access processes. For example, prior to memory access to a data item, the metadata position or lock position associated with the data item is checked to determine whether the data item is available. Other barrier processes include a process of acquiring a lock such as a read lock and a write lock for a data item at a metadata position or a lock position, and a certain version of the data item is recorded / read in a transaction read setting or write setting. Processing to store, processing to determine whether the transaction read settings for that point are still valid, processing to buffer or back up the value of the data item, processing to set the monitoring unit, processing to update the filtering value, and Any other transactional processing may be included.

  However, in a transaction, subsequent accesses to the same data item often incur the overhead of executing the corresponding transactional barrier each time an access to the data item is discovered. To explain, if a write to address A is performed three times in a transaction, a write barrier for acquiring a write lock for address A is executed three times separately. However, the lock for address A has already been acquired by executing the write barrier on the first transactional write, and the write barrier is executed twice before the next two transactional writes. This is redundant and it is not necessary to acquire the lock for address A again.

  Thus, according to one embodiment, the hardware maintains filtering values that accelerate execution associated with these barriers. This filtering value may be included in the cache as an annotation bit, such as a read monitor and a write monitor, or may be held at a metadata location in the metaphysical address space as described above. Based on the above example, when the first write barrier is found, the write filtering value is updated from the unaccessed value to the accessed value, and the write barrier for address A is already found in the same transaction. Indicates that For this reason, when a transactional write process occurs twice in the same transaction, the write filtering value of the address A is confirmed before being guided to the write barrier. In this case, this filtering value does not need to execute the write barrier, that is, it contains an accessed value indicating that the write barrier has already been executed in the same transaction. For this reason, execution of the subsequent two write processes is not guided to the write barrier. That is, this filtering value accelerates transactional execution. That is, for the previous example that does not use filtering, the next two accesses do not delete or include the execution of the write barrier.

  Note that the read filter for loading / reading, the canceling filter for canceling processing, and the miscellaneous filter for general filtering processing are the same as those using the above writing filter for writing / store processing. May be used in a way.

  Furthermore, the transactional barrier is associated with the concept of strong atomicity and weak atomicity associated with separating transactional processing from non-transactional processing. In this case, a transactional write to a non-transactionally loaded memory location can also be a conflict, as a transactional write to a transactionally loaded memory location can be a conflict, Data used in non-transactional load processing becomes invalid data. In a weak atomic system, a barrier is not inserted in non-transactional processing, or the inserted barrier is minimized, so a weak atomic system has a risk of invalidation of execution. In contrast, in a strong atomic system, transactional barriers are also inserted into non-transactional processing, which isolates and protects between transactional and non-transactional processing, but transactional for all non-transactional processing. With the price of having to implement a dynamic barrier.

  Thus, according to one embodiment, the filter described above may be utilized with a strong atomicity barrier in non-transactional processing to support various modes of strong atomic processing and weak atomic processing. For purposes of explanation, a simplified example embodiment is shown in FIG. In this case, the metadata 610 is held in the hardware of the data 605 as described above. A metadata access 600 for accessing the metadata 610 is received. According to one embodiment, metadata access includes a test metadata process that tests a filter, such as a read filter, a write filter, a cancellation filter, or a miscellaneous filter.

  A test metadata process for testing the filter may be issued from a transactional or non-transactional access process. According to one embodiment, when compiling the application code, the compiler inserts test filtering according to the application code as a condition into the execution of the transactional barrier calls in transactional and non-transactional access. For this reason, in the transaction, filter processing is executed before calling the barrier, and if successful, the call to the transactional barrier is not executed, and acceleration is executed as described above.

  However, for non-transactional processing, in one embodiment, the hardware can operate in a weak atomicity mode where the transactional barrier in non-transactional processing is not executed, and in a strong atomicity mode where the transactional barrier is executed. is there.

  The mode of processing or control 625 may be set in the metadata control register (MDCR) 615. The MDCR 615 may be combined with the version of the MDCR that holds the MDID described above, or may be a separate control register. According to another embodiment, the operating mode control 625 may be maintained in a general transactional control register or status register. In this case, the first execution mode includes a strong atomicity mode in which a transactional barrier is executed in a non-transactional process. In this case, control 625 indicates a first value, such as “00”, representing strong atomicity and a non-transactional mode of operation. In response logic 620, which includes a multiplexer as an example, select a metadata value from metadata 610 maintained in hardware associated with data address A to be supplied to destination register 650 of metadata access 600 To do. Basically, in the strong atomicity mode, the barrier is accelerated based on metadata actually held in hardware. Instead, in the second execution mode, such as weak atomicity and non-transactional mode, depending on the metadata access 600 as specified by the control 625 indicating a second value such as “01”, Instead of the metadata 610 held in hardware, a fixed or forced value from the MDCR is provided to the destination register 650.

  Basically, in the weak atomic mode, a forced value is provided to the destination register 650 in response to the filter test process 600 so that the filter value test is always successful and a transactional barrier before non-transactional memory access. Prevent calls to to be executed. In this description, it is assumed that the filter test process returns a Boolean value to indicate whether the filter test was successful (barrier not executed) or failed (barrier executed). For this reason, using the same filtering software configuration that accelerates transactions by removing barriers based on filter values, a first mode of operation that removes all barriers in non-transaction processing, namely a weak atomic mode, And a second mode of operation, ie, a strong atomicity mode, that performs or accelerates a barrier in non-transactional processing based on metadata maintained in hardware. According to another embodiment, different forcing values may be provided for each mode. In this case, in the strong atomic mode, the filter test process always fails due to the forced value, so the barrier is always executed. In the weak atomic mode, the filter test process always succeeds because of the forced value, so the barrier is executed. Not.

  The provision of the forced value or the fixed value from the control register such as the MDCR 615 based on the control information such as the control 625 has been described in relation to the provision of the fixed value / forced value or the metadata value according to the processing mode. Providing mandatory or fixed values may also apply to general metadata usage. For example, the fact that data does not change may be used to perform debugging and general monitoring of memory access that can be enabled on demand.

  FIG. 7 shows a flowchart for describing an embodiment for accelerating non-transactional processing while maintaining atomicity in a transactional environment. In step 705, one specific example is given for explaining the discovery of the metadata (MD) access process referring to the data address. If the MD access process returns the first value as a result of the test, Depending on the application code, depending on the application code, the compiler should remove the transactional barrier in non-transactional memory access (if successful) and execute the barrier if the second value is returned as a result of the test (if it fails) Includes inserted test procedures. However, the MD test process is not limited to this, and any test process may be included as long as it is a test process that returns a success value or a failure value that is a Boolean value.

  In step 710, the operation mode is determined. In this case, an example of the operation mode includes an operation mode in which transactional or non-transactional and strong atomicity or weak atomicity are combined. Thus, one register or two separate registers have a first bit indicating a transactional mode or a non-transactional mode of operation and a second bit indicating a strong atomic mode of operation or a weak atomic mode of operation. May be held.

  When the operation mode is a transactional or non-transactional and strong atomic operation mode, a metadata value maintained in hardware is provided to the metadata access process. That is, the value maintained by the hardware is entered in the destination register specified by the MD access process. In contrast, when the operation mode is a non-transactional and weak atomic operation mode, the MDCR forced fixed value is used for the MD access process instead of the MD value maintained in hardware. provide. For this reason, in the strong atomic mode, the barrier is not accelerated based on the MD value maintained by the hardware, and in the weak atomic mode, the barrier is accelerated based on the forced MDCR value.

<Efficient transition to buffered and monitored state>
Subsequently, FIG. 8 is a flow chart illustrating an embodiment of a method for efficiently transitioning a data block to a buffered and monitored state before committing the transaction. As mentioned above, multiple blocks in memory, eg, cache lines holding data items or metadata, may be buffered and / or monitored. For example, a cache line coherency bit indicates a buffered state, and a cache line attribute bit indicates whether the cache line is being monitored, read monitored, or written monitored. Show.

  According to some embodiments, cache lines are buffered but not monitored. Since monitoring is not applied, it means that the data held in the cache line has a large loss, and no conflict with the cache line is detected. For example, data that is not committed locally to the transaction, eg, metadata, may be kept buffered but not monitored.

  If a conflict is detected between the buffered data and writing to the same address, read monitoring is applied to this data. Thereafter, the cache line shifts to a buffered and read-monitored state. To shift to this state, a read request for forcibly shifting all other copies to the shared state is performed by external processing. Sent to the element. Such an external read request may cause a conflict with another processing element that maintains a write monitoring unit for the same block / cache line.

  Similarly, when a conflict is detected between buffered data and reading to the same memory block, write monitoring is applied to the cache line. Thereafter, the cache line transitions to a state where it is buffered and monitored for writing. This transition is realized by sending an ownership read request to another processing element to forcibly shift all other copies to an invalid state. Similarly, a conflict is detected with a processing element that maintains read monitoring or write monitoring for the same memory block.

  However, to minimize transactional conflicts, memory blocks that need to be updated by a transaction but are not ultimately committed are kept buffered but not monitored, as described above. It's okay. However, if it is determined that a block that is buffered but held in an unmonitored state should be committed, in one embodiment, as shown in FIG. 8, buffered but not monitored. An efficient path for transitioning from state to commitable state is provided.

  As an example, in step 805, a buffered update for a memory block held by a cache line is received. Read monitoring is applied to the block before the buffered update or simultaneously with the buffered update. For example, the read attribute for the cache line is set to the read monitoring value to indicate that the block is being read monitored. However, to apply read monitoring, a read request is first sent to other processing elements in step 815. When the other processing element receives this read request, in step 820, since the cache line is already maintained in the write monitoring state, it detects a conflict or shifts the copy to the shared state. If there is no conflict at step 825, the cache line is buffered and transitions to a read-monitored state. That is, the read monitoring attribute is set by updating the coherency bit of the cache line to the buffered coherency value.

  In step 830, a conflicting write to the cache line is detected based on the read monitoring. According to one embodiment, the read attribute is coupled to the snoop logic, and an external ownership read request to the cache line detects a conflict with the read monitor set on the cache line.

  After this, if the block is to be committed as part of the state of the transaction at step 835, write monitoring is applied at step 840. In this case, an ownership read request is sent to another processing element in step 845, and the request detects a conflict in step 850 in response to holding the cache line in the read monitoring state or the write monitoring state. Or move the copy to an invalid state. Therefore, by detecting a conflict in the ownership read request, any conflict is detected at this time, so that the cache line can be committed.

  As a result, it is beneficial to transition the buffered but unmonitored blocks to a committable state in two stages, ie, step 810 and step 840. By extending the acquisition of ownership by performing the reading monitoring and the writing monitoring in stages, a plurality of simultaneous transactions can update the same block while reducing the occurrence rate of conflicts. If the transaction does not reach the commit stage for some reason, updating the block to a buffered and read-monitored state does not unnecessarily abort another transaction that reaches the commit stage. For this reason, extending the acquisition of the block's sole ownership to the commit stage is one way to increase concurrency among threads without sacrificing the validity of the data.

Table 8, described below, illustrates one embodiment of a conflict between the two processing elements P0 and P1. For example, a line buffered by P1 and held in a read-monitored state (indicated by the RB column) and an arbitrary state of P0 in which a cache line is maintained in the write monitoring unit (-W -, RW-, WB, and RWB) are conflicting as shown by crosses in the intersecting cells.

Table 9 shown below indicates that the characteristics associated with the processing element P1 are lost in accordance with the processing listed in the column of P0. For example, if P1 holds the line in a buffered and read-monitored state (indicated by the RB column), if a store process or a write monitor setting process occurs at P0, P1 / As indicated by xx where the set WM row intersects with the RB column, the read monitoring attribute and buffering attribute of the line are lost.

<Branch instruction for transactional data loss or conflict (JLOSS)>
FIG. 9 illustrates an embodiment of hardware that supports lost instructions jumping to a destination label based on the status value of the transaction status register. According to one embodiment, the hardware accelerates the procedure of checking transaction consistency. As an example, the hardware tracks the loss of monitored or buffered data from the cache, that is, a mechanism that tracks eviction of the buffered or monitored line, or a competitive access to such data. The consistency checking procedure may be supported by providing a monitoring mechanism that detects competing snoops, such as a mechanism to do this, ie, a read ownership request to the line being monitored.

  Also, according to one embodiment, the hardware provides an architectural interface for allowing software to access these mechanisms based on the status of the data being monitored or buffered. As such an interface, (1) an instruction to read and write the status register explicitly, causing the software to explicitly poll the register during execution, and (2) if the status register indicates a possible loss of consistency There are two interfaces that allow software to set a handler that is always read.

  According to another embodiment, the hardware supports a new instruction called JLOSS that performs conditional branches based on the status of HW monitoring or buffered data. The JLOSS instruction branches to a label when the hardware detects that the data being monitored or buffered has been lost from the cache, or when it detects a conflict with the data being monitored or buffered. The label includes any 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 illustrative embodiment, FIG. 9 shows a decoder 910 that recognizes JLOSS as part of the processor ISA and decodes instructions that cause the processor logic to perform conditional branches based on the status of the transaction. As an example, the status of the transaction is held in the transaction status register 915. The transaction status register may represent the status of the transaction, for example, that the hardware has detected a conflict or data loss, referred to herein as a loss event. To explain, the conflict flag of the TSR 915 is set when the monitoring unit indicates that the address is being monitored in combination with the snoop to the monitoring target address. The conflict flag of TSR 912 indicates that a conflict has been detected. Similarly, the loss flag is set in response to data loss such as eviction of lines containing transactional data or metadata.

  For this reason, in this document, JLOSS, when decoded and executed, examines the flags in the status register and if there is a loss event, ie loss and / or conflict, logic 925 refers to JLOSS. Is provided to the execution resource 930 as a jump destination address. Thus, with one instruction, the software can identify the status of the transaction, and based on this status, execution can be directed to the label specified by the instruction. JLOSS checks consistency, so reporting false conflicts is acceptable. JLOSS says, “You may report that a conflict has occurred in a conventional way.

  According to one embodiment, software such as a compiler inserts a JLOSS instruction in the program code to poll for consistency. However, JLOSS is used depending on the main application code, and the JLOSS instruction is often used on read barriers and write barriers provided in the library to determine consistency on demand. Thus, execution of program code may include the compiler inserting JLOSS into the code, or executing JLOSS from program code, and any other form of instruction insertion or execution. Polling with JLOSS is considered to be much faster than explicit reading of the status register. This is because the JLOSS instruction does not require an additional register, that is, the destination register does not need to receive explicit read status information. In this instruction embodiment, the conditions for checking consistency are either explicitly stated in the instruction or implicitly in another control register.

  In one example, the transaction status register 915 or other storage element holds specific conflict status information and loss status information. For example, a physical transaction is a read conflict if another agent writes to a location that is monitored for reading, and a write conflict if another agent reads or writes to a location that is monitored for writing. It holds information such as lost data or lost metadata. For this reason, various versions of the JLOSS instruction may be used. For example, JLOSS. The rm <label> instruction branches to a label when another agent writes to the location being monitored for reading. Hardware-accelerated STM (HASTM) is JLOSS. The consistency check can be accelerated using the rm instruction. Whenever checking the consistency of the read settings, for example, after each transactional load in the native code TM system, JLOSS. Use rm to check for conflicting updates to read settings in a short time. In this case, the read settings may be verified using JLOSS in the read barrier, so the JLOSS instruction is inserted into the read barrier in the library or after the load process depending on the main application code Is done. JLOSS. Detects the writing to the position being read. Similar to the rm instruction, JLOSS. The wm instruction may be used to detect a read or write to a location being monitored for writing. As yet another example, in a processor capable of buffering positions, JLOSS. A buf instruction may be used to determine whether or not to jump to a specific label because the buffered data has been lost.

  The pseudo code described below is pseudo code A, but shows a STM read barrier for native code that provides consistent read settings and utilizes JLOSS. The setrm (void * address) function sets the read monitor for a given address, and the jloss_rm () function returns a true when a competing access occurs for the position being read monitored. Is a built-in function. This pseudo code monitors the loaded data, but can alternatively monitor the transaction record (ownership record). It is possible to use an instruction that combines read monitoring settings and data loading, for example, a movxm instruction that both loads and monitors data. It is also possible to use this in a read barrier that performs filtering in addition to monitoring, and also in STM systems that use only hardware monitoring for verification of read settings, ie software read records and SW verification. It is also possible to use this in a non-executed STM system.

<Pseudocode A: STM for in-situ update, optimistic reading, and native code reading barrier>

  Similarly, STM systems that do not maintain read setting consistency, eg, STM for managed code, may avoid infinite loops or other inaccurate control flows. That is, at the loopback edge or other important control flow point, eg, JLOSS. Since consistency is lost by inserting the rm instruction, exceptions may be avoided.

  The pseudo code described below is designated as pseudo code B, but represents another native code read barrier that achieves consistency. This version of the TM system takes advantage of the write settings present in the cache using buffered updates for writes within a transaction. Since reading from a position that has been buffered and then deleted has no consistency, this read barrier avoids reading from a deleted buffered position in order to maintain consistency. The COMMIT_LOCKING flag is true if the STM uses a commit time lock for buffered locations. The confirmation of jloss_buf () is used for reading from a previously locked position when commit time lock is not used, but is used for all reads when not used.

<Pseudo code B: Update on the spot, STM read barrier of native code>

  The TM system may combine read monitoring with buffering and write monitoring, as described above, to check for conflicts with respect to monitored or buffered lines in order to maintain consistency. May further be included. In order to accommodate such a system, in a different embodiment, JLOSS. rm. buf (conflict with respect to read monitored position or buffered position), JLOSS. rm. wm (conflict with respect to read-monitored position or write-monitored position), or JLOSS. * Provides a JLOSS flavor that logically combines various monitoring events and buffering events, such as (conflicts to read monitored positions, write monitored positions, or buffered positions). You may do it.

  According to another embodiment, the architecture interface may cause the software to branch out of a condition by branching by having the software set a condition on another control register, i.e. a conflict for the line being read / written or buffered. Disconnect the JLOSS instruction. In this embodiment, the required JLOSS instruction is encoded only once, and it is possible to support future expansion of events to which JLOSS should branch.

  FIG. 10 is a flowchart illustrating an embodiment of a method for executing a loss instruction that jumps to a destination label based on a conflict or loss of specific information. According to one embodiment, at step 1005, a JLOSS instruction is received. As described above, the JLOSS instruction is inserted by the programmer or compiler into the main code, for example, to achieve read setting consistency after the load process, or within the barrier, for example, a read barrier or write. It may be inserted into the bayonet barrier. The JLOSS instruction and its variants described above, according to one embodiment, can be recognized as part of the processor's ISA. In this case, the decoder can decode the operation code of the JLOSS instruction.

  In step 1010, it is determined whether a conflict or loss of information has occurred. According to one embodiment, the type of conflict or loss depends on the version of the JLOSS instruction. For example, the received JLOSS command is JLOSS. In the case of the rm instruction, it is determined whether or not a conflict has occurred between the line monitored for reading and the external write access. However, as described above, any version of JLOSS may be received, including a JLOSS instruction that allows the user to specify a condition in the control register.

  Therefore, if the condition is established, it is determined whether the established condition is satisfied based on either the control register or the JLOSS instruction type. As a first example, it is determined whether or not a condition is satisfied using information in a transaction status register such as TSR 915. Here, the TSR 915 may be set to a non-conflict value by default, and may include a read monitoring status flag that is updated to a conflict value to indicate that a conflict has occurred. However, the method for determining whether or not a conflict has occurred is not limited to the method using the status register, and any known method may be used for determining loss or conflict.

  In response to no conflict being detected, for example, if the read monitoring conflict flag of the TSR 915 is still set to the default value, in step 1025, a value representing “false” is returned and execution continues normally. However, if a conflict or loss is detected, for example, if the read monitoring conflict flag is set, in step 1015 JLOSS returns a value representing “true” and in step 1020 the received JLOSS instruction defines. Jump to the label that is running.

<Hardware support for committing transactional memory>
As mentioned above, hardware supported transactions may accelerate software version control by buffering transactional writes in the cache without global visibility. In this case, a simple commit instruction that makes the buffered value visible to all processors may be used, but will fail if any of the buffered lines are lost. However, since hardware can hold metadata that software can use for acceleration, such as filters to remove / filter redundant barriers, if the hardware detects a conflict, the commit instruction It is desirable to fail. Also, once committed, it is desirable to clear various combinations of information held in hardware for the transaction, such as metadata, monitoring, or buffered lines.

  Thus, according to one embodiment, the hardware supports various forms of commit instructions, causing the commit instruction to specify both the conditions for committing and the information to clear upon commit. FIG. 11 illustrates a general case embodiment where the hardware supports definition of commit conditions and clear control with a commit instruction.

  As shown in the figure, the commit instruction 1105 includes an operation code 1110 that can be recognized as a part of the ISA of the processor, that is, can be decoded by the decoder 1115. In the illustrated example, the opcode 1110 includes two parts: a commit condition 1111 and a clear control 1112. The commit condition 1111 specifies the condition of the transaction to be committed, and the commit clear control 1112 specifies the information to be cleared when the transaction is committed.

  According to one embodiment, both parts include four values: read monitor (RM), write monitor (WM), buffering (Buf), and metadata (MD). Basically, if any of these four values is set in the portion 1111, that is, if the associated attribute / characteristic includes a value indicating that it is a commit condition, the corresponding characteristic is a commit It is a condition to do. In other words, when the first bit corresponding to the read monitoring information in the condition 1111 is set, the loss of the read monitoring data of the monitoring unit 1135 associated with the transaction is aborted. That is, since the specific condition of the commit instruction is not satisfied, the commit is not performed. Similarly, if a value of 1112 is set, the corresponding characteristic is cleared at commit time. Continuing with this example, when the RM of the portion 1112 is set, the read monitoring information of the transaction monitoring unit 1135 is cleared when the transaction is committed. For this reason, in this example, four settings can be made for the commit condition and the clear control, respectively, and 256 versions of the commit instruction can be made. According to one embodiment, the commit condition is specified by the opcode, so that the hardware can support all versions. In order to help you understand the various types of commit instructions, and to illustrate how commit instructions are used, a few versions are described below.

<TXCOMWM>
As a first example, a Txcomwm instruction will be described. This command terminates the transaction and globally visualizes all buffered and buffered data if no write-monitored data is lost (success). is there. If the data being monitored for writing is lost, a failure occurs. Txcomwm sets (or resets) a flag to indicate success (or failure). If successful, Txcomwm clears the buffered state of all data being monitored for writing. Since Txcomwm does not affect the read monitoring state or the write monitoring state, the software can reuse the read monitoring state or the write monitoring state in subsequent transactions. In addition, since it does not affect the state of the buffered position where the writing is not monitored, the software can maintain the information maintained at such a position. Although the pseudo code described below is indicated as pseudo code C, Txcomwm is described algorithmically. TSR. When LOSS_WM is 0, all BBLKs that are write-monitored and buffered have their BF characteristics cleared atomically and all this buffered data is also visible to other agents. TCR. IN_TX is cleared. Blocks that are buffered but not WM are not affected and remain buffered. The CF flag is set upon completion. TSR. If LOSS_WM is 1, the CF flag is cleared and TCR. IN_TX is cleared. The CF flag is set to 1 when the process is successful, and is set to 0 when the process is unsuccessful. The OF flag, SF flag, ZF flag, AF flag and PF flag are set to 0.

<Pseudo Code C: Embodiment of Txcomwm Processing Algorithm>

  The pseudo-code described below is shown as pseudo-code D, but how the HASTM system uses the Txcomwm instruction to use hardware write buffering to avoid undoing records in an in-situ update STM Explain whether to commit the transaction. The CACHE_RESIDENT_WRITES flag indicates this execution mode.

<Pseudo Code D: Pseudo Code Embodiment for Using the Txcomwm Instruction>

<TXCOMWMRM>
One modification, txcomwmrm, is an extension of the Txcomwm instruction and fails if the position being read is lost. This variation is useful for transactions that use only hardware when detecting read setting conflicts. Although the pseudo code described below is shown as pseudo code E, Txcomwrmm will be described algorithmically. TSR. LOSS_WM and TSR. When LOSS_RM is 0, all BBLKs that are write-monitored and buffered have their BF characteristics cleared atomically and all this buffered data is also visible to other agents. TCR. IN_TX is cleared. Blocks that are buffered but not WM are not affected and remain buffered. The CF flag is set upon completion. TSR. LOSS_WM or TSR. If LOSS_RM is 1, the CF flag is cleared and TCR. IN_TX is cleared. The CF flag is set to 1 when the process is successful, and cleared to 0 when the process is unsuccessful. The OF flag, SF flag, ZF flag, AF flag and PF flag are set to 0.

<Pseudo Code E: Embodiment of Description by Txcomwrmrm Algorithm>

  The following pseudo code, denoted as pseudo code F, represents a commit algorithm that utilizes the txcomwrmm instruction for an STM system that utilizes hardware for both transactional write buffering and read configuration conflict detection. The HW_READ_MONITORING flag indicates whether this algorithm uses only hardware for read setting conflict detection.

<Pseudo Code F: Pseudo Code Embodiment Using txcomwrmm Instruction>

<TXCOMMWIRMC>
A third modification will be described below using an algorithm as pseudo code F. TSR. LOSS_WM and TSR. When LOSS_IRM is 0, all BBLKs that are write-monitored and buffered have their BF characteristics cleared atomically, and all this buffered data is visible to other agents. RM, WM and IRM, and TCR. IN_TX is cleared. Blocks that are buffered but not WM are not affected and remain buffered. The CF flag is set upon completion. TSR. LOSS_WM or TSR. If LOSS_RM is 1, the CF flag is cleared and TCR. IN_TX is cleared. The CF flag is set to 1 when the process is successful, and cleared to 0 when the process is unsuccessful. The OF flag, SF flag, ZF flag, AF flag and PF flag are set to 0.

<Pseudo Code F: Embodiment of Explanation by Algorithm of Txcomwmirmc Instruction>

  FIG. 12 is a flowchart illustrating an embodiment of a method for executing a commit instruction defining a commit condition and clear control. In step 1205, a commit command is received. As described above, the compiler may insert a commit instruction into the program code. For illustration purposes, a commit function call is inserted into the main code, a commit function as provided in the pseudocode above is provided in the library, and the compiler further includes a commit in the library. A commit instruction may be inserted into the function.

  Upon receiving the commit instruction, the decoder can decode the commit instruction. In step 1210, based on the decoded information, the condition specified by the opcode of the commit instruction is determined. As described above, the opcode may indicate which condition is used during commit by setting some flags while resetting other flags. If the condition is not met, it returns “false” and the transaction may be aborted separately. However, if the condition for commit is satisfied, for example, if any combination of read monitoring, write monitoring, metadata and / or buffering is not lost, in step 1215, the clear condition / Judge the control. As an example, it is determined that any combination of transaction read monitoring, write monitoring, metadata, and / or buffering should be cleared. For this reason, in step 1225, information determined to be cleared is cleared.

<Optimization of UTM memory management>
As described above, the Unlimited Transactional Memory (UTM) architecture and its hardware implementation extend the processor architecture by introducing the characteristics of monitoring, buffering, and metadata. Such a configuration provides software with the means necessary to implement a variety of advanced algorithms, including a wide variety of transactional memory designs. Each characteristic may be implemented in hardware by extending an existing cache protocol when implementing the cache, or by assigning new independent hardware resources.

  When implementing UTM characteristics in HW, use software only for transactions if the UTM architecture and its hardware implementation can minimize UTM transaction abort and subsequent transaction retry processing. When compared with (STM), the performance may be improved. One of the main causes of hardware transaction aborts was the frequent occurrence of ring transitions due to external interrupts, system call events, and page faults.

  A suspension mechanism based on the currently executing privilege level (CPL) activates the hardware transaction (enables hardware accelerated transactions with UTM characteristics such as buffering and monitoring, and enables the release mechanism) The operation mode of the processor is privilege level 3 (user mode). A ring transition from ring 3 automatically suspends the currently active transaction (stops to generate UTM characteristics and disables the release mechanism). Similarly, a ring transition back to ring 3 automatically resumes a previously suspended hardware transaction if it was active. The disadvantage of this approach is that the use of hardware transactional memory resources at the ring level, excluding kernel code or ring 3, is largely eliminated.

  Another approach replicates TM control resources, such as the Ring 0 transaction control register (TxCR), to enable ring 0 code hardware transactions using this separately prepared TM resource. However, this method cannot efficiently handle nested interrupts and exceptions in ring 0 transaction processing.

  Thus, FIG. 13 shows an embodiment of hardware that supports privilege level transition processing during transaction execution. In this embodiment, a ring 0 transaction is enabled in addition to a user mode (ring 3) transaction, but a hypervisor such as a virtual machine monitor (VMM) and an OS are also provided, and a ring 0 transaction exists. In this state, it handles infinite hierarchy of nested interrupts and NMI.

  Storage elements such as the EFLAGS register 1310 include a transaction enable field (TEF) 1311. The TEF 1311 indicates that the transaction is currently active and enabled if it holds an active value, and indicates that the transaction is suspended if it holds an inactive value.

  According to one embodiment, the TEF field 1311 is set to an active value by a transaction start process or another process at the start of a transaction. When a ring level transition event such as an interrupt, exception, system call, virtual machine end, or virtual machine start occurs in step 1300, the state of the Eflags register 1310 of PE0 is pushed onto the kernel stack 1320 in step 1301. In step 302, the TEF field 1311 is cleared / updated to an inactive value to suspend the transaction. For ring level transition events, handle or respond appropriately while the transaction is suspended. When a return event is detected at step 1303, the state of the Eflags register 1310 pushed onto the stack at step 1301 is popped at step 1304 to return the previous state to the Eflags register 1310. By returning to the previous state, the active value is set again in the TEF 1311 and the transaction is resumed as being in the active and enabled state.

  A specific example of processing for a ring level transition event is described below. When interrupts and exceptions occur, the processor pushes the EFLAGS register onto the kernel stack, clears the “transaction enable” bit, if set, and suspends previously enabled transactions. When an IRET occurs, the processor restores all of the EFLAGS register state of the interrupted thread, including the “transaction enable” bit, based on the kernel stack, and suspends the transaction if previously enabled. To release.

  When SYSCALL occurs, the processor pushes the EFLAGS register, clears the “transaction enable” bit, if set, and suspends the previously enabled transaction. When a SYSRET occurs, the processor reverts the state of the EFLAGS register of the thread in which the interrupt occurred, including the “transaction enable” bit, based on the kernel stack and, if previously enabled, the transaction temporary Release the stop.

  When a VM-Exit occurs, the processor stores the guest's EFLAGS register, including the state of the “transaction enable” bit, in the virtual machine control structure (VMCS), and the host whose “transaction enable” bit is in the clear state. The EFLAGS register state is loaded, and previously enabled guest transactions are suspended, if enabled.

  When VM-Enter occurs, the processor reverts the guest's EFLAGS register containing the state of the "transaction enable" bit from VMCS, and if previously enabled guest transactions were enabled, Release the pause.

  With this configuration, in addition to the hardware-accelerated user mode (ring 3) UTM transaction, the hardware-accelerated kernel mode (ring 0) UTM transaction is enabled. And VMM will be able to handle an infinite hierarchy of nested interrupts and NMIs in the presence of ring 0 transactions. The prior art does not provide such a mechanism.

  “Module” as used herein means any hardware, software, firmware, or combination thereof. In many cases, the boundaries of modules shown as separate are usually changed and can overlap. For example, the first module and the second module may share some hardware, software, firmware, or a combination thereof, while having some hardware, software, or firmware separately. . According to one embodiment, the term “logic” includes hardware such as transistors, registers, or other hardware such as programmable logic devices. However, in another embodiment, “logic” further includes software or code integrated with hardware, eg, firmware or microcode.

  “Value”, as used herein, includes any known method of representing a number, state, logical state, or binary logical state. In many cases, a “logic level”, “logic value”, or “logic value” may be represented by 1 and 0, which simply represents a binary logic state. For example, “1” means a logical high level, and “0” means a logical low level. According to one embodiment, a storage cell such as a transistor or flash cell may be capable of holding one or more logical values. However, in a computer system, values may be expressed by other methods. For example, “10” in the decimal system is expressed as “1010” in the binary value, and the character “A” is expressed in the hexadecimal system. Therefore, the “value” includes any representation method as long as it is a representation method of information that can be held by the computer system.

  Further, the state may be expressed by a value or a part of the value. As an example, a first value such as a logical value “1” may represent a default or initial state, while a second value such as a logical value “0” may represent a non-default state. Also, the terms “reset” and “setting” respectively refer to a default value or default state, and an updated value or updated state, according to one embodiment. For example, the default value includes a logical high value, that is, a reset value, and the updated value includes a logical low value, that is, a set value. Any number of states may be expressed by arbitrarily combining values.

  The method, hardware, software, firmware, or code embodiments described above may be implemented with instructions or code stored on a machine-accessible or machine-readable medium that is executable on a processing element. A machine-accessible / readable medium includes any mechanism that provides (ie, stores and / or transmits) information in a state readable by a machine, such as a computer or electronic system. For example, the machine accessible medium is a RAM such as static random access memory (SRAM) or dynamic RAM (DRAM), ROM, magnetic storage medium or optical storage medium, flash memory device, electrical storage device, optical storage device, acoustic storage device Or other forms of propagated signal (eg, carrier wave, infrared signal, digital signal) storage devices and the like. For example, a machine may access a storage device by receiving a propagation signal, such as a carrier wave, from a medium capable of holding information transmitted with the propagation signal.

  In this specification, “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in association with the embodiment is included in at least one embodiment of the invention. To do. Thus, the expressions “in one embodiment” or “in an embodiment” are used repeatedly in this specification, but all do not necessarily mean the same embodiment. In addition, specific features, structures, or characteristics may be combined as appropriate in one or more embodiments.

  In the foregoing description, the invention has been described in detail with reference to specific exemplary embodiments. However, it will be apparent that various modifications and changes may be made in the specific embodiments described above without departing from the broader spirit and scope of the invention as set forth in the claims. Accordingly, the specification and drawings are to be construed as illustrative rather than limiting. Also, exemplary expressions such as “embodiments” as described above do not necessarily refer to the same embodiment or the same example, and may refer to the same embodiment but different separate implementations. It may also refer to a form.
  According to this embodiment, the following items are also disclosed.
(Item 1)
Multiple processing elements;
Metaphysical logic and
With
One processing element of the plurality of processing elements is associated with a plurality of software subsystems,
The metaphysical logic is associated with one current software subsystem of the plurality of software subsystems, and metadata access processing that refers to a data address is associated with the current software subsystem. An apparatus for associating with a metaphysical address space associated with the current software subsystem based at least on a data identifier (MDID) and the data address.
(Item 2)
The metaphysical address space associated with the current software subsystem is at least one other metaphysical address space associated with a second software subsystem of the plurality of software subsystems; and The apparatus of item 1, wherein the apparatus is orthogonal to a data address space containing the data address.
(Item 3)
Each of the plurality of software subsystems includes a transactional runtime subsystem, a garbage collection runtime subsystem, a memory protection subsystem, a software conversion subsystem, an outer transaction of a group of nested transactions, And the apparatus of item 2 selected from the group consisting of one inner transaction of the nested group of transactions.
(Item 4)
A decoding logic for decoding the metadata access process;
The apparatus according to item 1, wherein the metadata access process includes an operation code (opcode) recognized as one of a plurality of processes supported in the decoding logic.
(Item 5)
The metaphysical logic includes metaphysical conversion logic that converts the data address to a metadata address in the metaphysical address space associated with the current software subsystem based on at least the MDID. The device described in 1.
(Item 6)
The metaphysical conversion logic further includes the data address in the metaphysical address space associated with the current software subsystem based on a processing element identifier (PEID) associated with the processing element. 6. The device according to item 5, wherein the device converts the metadata address.
(Item 7)
The metaphysical conversion logic further converts the data address into a metadata address in the metaphysical address space associated with the current software subsystem based on a data-to-metadata compression ratio. The device described in 1.
(Item 8)
A register further modifiable by the current software subsystem;
The register holds the MDID in response to a write from the current software subsystem to indicate that the current software subsystem is currently being executed by the processing element;
The metaphysical conversion logic converts the data address to a metadata address in the metaphysical address space associated with the current software subsystem based on the PEID and the MDID. The apparatus according to item 6, wherein physical conversion logic includes combining information representing the data address, the PEID, and the MDID.
(Item 9)
The metaphysical conversion logic includes an algorithm for forming the metadata address by adding the PEID and the MDID to the data address when the information representing the data address is combined with the PEID and the MDID, normal data An algorithm for converting the data address to a converted data address using a conversion table, adding the PEID and the MDID to the converted data address to form the metadata address, and a normal data conversion table; Is an algorithm for converting the data address to a converted metadata address using another metaphysical conversion table, and adding the PEID and the MDID to the converted metadata address to form the metadata address. Apparatus according to claim 8 carried out based on a combination algorithm selected from the group consisting of.
(Item 10)
Discovering metadata processing that refers to a data address that is in a data address space and that is associated with a data item held in a data entry in a cache memory; and
A metadata address in a metaphysical address space separate from the data address space corresponds to the data address, a processing element identifier (PEID) of a processing element associated with the metadata processing, and the processing element Determining based on a metadata identifier (MDID) of the attached software subsystem;
Accessing a metadata entry in the cache memory based on the metadata address;
A method comprising:
(Item 11)
11. The method of item 10, wherein the metaphysical address space is also distinct from an additional metaphysical address space that is also associated with an additional software subsystem that is also associated with the processing element.
(Item 12)
The software subsystem includes a transactional runtime subsystem, a garbage collection runtime subsystem, a memory protection subsystem, a software conversion subsystem, an outer transaction of one of a group of nested transactions, and a nested 11. The method according to item 10, wherein the method is selected from the group consisting of one inner transaction of a group of transactions.
(Item 13)
Responsive to the software subsystem currently executing on the processing element in response to discovering a write operation from the software subsystem to a control register associated with the processing element Writing the MDID in
Determining the MDID based on the control register;
The method according to item 10, further comprising:
(Item 14)
14. The method of item 13, further comprising determining the PEID based on a portion of the metadata processing opcode.
(Item 15)
The step of determining the metadata address from the data address, the PEID, and the MDID includes an algorithm that forms the metadata address by adding the PEID and the MDID to the data address, and a normal data conversion table. An algorithm for converting the data address to a converted data address and adding the PEID and the MDID to the converted data address to form the metadata address, and a separate from a normal data conversion table Select from the group consisting of algorithms that convert the data address to a converted metadata address using a metaphysical conversion table and add the PEID and MDID to the converted metadata address to form the metadata address Is Algorithm and the data address The method of claim 13 including the step of combining the PEID and the MDID.
(Item 16)
Decoding logic for decoding a metadata access instruction that refers to the data address of the data item;
Transform the data address into a separate metadata address transparent to software and access the metadata referenced by the separate metadata address in response to the decode logic decoding the metadata access instruction Metadata logic to
With
The metadata access instruction includes an operation code that can be recognized as a part of an instruction group that can be appropriately decoded by the decoding logic.
(Item 17)
The metadata access instruction is selected from an instruction group 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). The device described in 1.
(Item 18)
17. The apparatus of item 16, wherein the metadata access instructions are selected from an instruction group consisting of a compressed metadata test (CMDT) instruction, a compressed metadata store (CMS) instruction, and a compressed metadata clear (CMDCLR) instruction.
(Item 19)
Translating the data address into a separate metadata address that is transparent to the software by the metadata logic is specified in a control register by a software subsystem associated with the metadata access instruction. The apparatus of item 16, comprising translating the data address based at least on a data identifier (MDID).
(Item 20)
The metadata access instruction further includes a reference to a destination register;
When the metadata logic accesses metadata referenced by the separate metadata address, the metadata logic places the metadata at the referenced separate metadata address into the destination register. Item 17. The device according to Item 16, comprising loading.
(Item 21)
21. The apparatus of item 20, wherein the opcode includes a thread identifier field that identifies a thread that issued the metadata access instruction.
(Item 22)
The metadata logic accessing metadata referenced by the separate metadata address depends on the metadata logic being loaded with the destination register being an unset value. 21. The apparatus of item 20, further comprising: setting the metadata at the referenced separate metadata address to a set value.
(Item 23)
The apparatus according to item 22, wherein the set value and the unset value are determined by the metadata access command.
(Item 24)
A machine-readable medium having program code, wherein when the program code is executed by a machine, the machine
According to the data access process that refers to the data address, generates a metadata access process that refers to the data address in the data access process,
When the metadata access process is executed by the machine, the machine
Converting the data address into a metadata address separate from the data address;
A machine-readable medium for accessing metadata of a data item at the data address based on the metadata address.
(Item 25)
The metadata access process is an item 24 selected from an instruction group 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). A machine-readable medium according to claim 1.
(Item 26)
25. The machine of item 24, wherein the metadata access process is selected from a group of compressed instructions consisting of a compressed metadata test (CMDT) instruction, a compressed metadata store (CMS) instruction, and a compressed metadata clear (CMDCLR) instruction. A readable medium.
(Item 27)
When the metadata access process is executed by the machine, the machine converts the data address into a metadata address when the metadata access process is executed by the machine. Based on the compression ratio of metadata, the data address, a processing element identifier (PEID) associated with the metadata access process, and a metadata data identifier associated with the metadata access process ( 27. The machine readable medium according to item 26, including combining with MDID).
(Item 28)
28. The machine readable medium of item 27, wherein the data address is translatable by virtual-physical address translation logic of the machine to refer to the data item.
(Item 29)
The metadata access process further refers to an operand register,
When the metadata access process is executed by the machine, the machine accesses the metadata of the data item. When the metadata access process is executed by the machine, the machine holds in the operand register. 25. The machine readable medium of item 24, comprising updating the metadata of the data item with a value being rendered.
(Item 30)
The program code includes compiler code,
The compiler code compiles application code including the data access process,
25. The machine readable medium of item 24, wherein generating the metadata access process in the data access process includes generating the metadata access process in a compiled version of the application code.
(Item 31)
A machine-readable medium having program code, wherein when the program code is executed on a machine, the machine
A metadata address (MDID) associated with a software subsystem that is currently active in a processing element associated with the metadata access instruction is a data address referred to by a metadata access instruction included in the program code. ) To a metadata address,
A machine-readable medium for accessing metadata based on the metadata address.
(Item 32)
The metadata access instruction is an item selected from an instruction group consisting of a metadata load instruction for loading the metadata, a metadata store instruction for storing in the metadata, and a metadata clear instruction for resetting the metadata. 31. The machine-readable medium according to 31.
(Item 33)
The software subsystem includes a transactional runtime subsystem, a garbage collection runtime subsystem, a memory protection subsystem, a software conversion subsystem, an outer transaction of one of a group of nested transactions, and a nested 32. The machine readable medium of item 31, wherein the machine readable medium is selected from the group consisting of one inner transaction of the grouped transactions.
(Item 34)
A metadata address (MDID) associated with a software subsystem that is currently active in a processing element associated with the metadata access instruction is a data address referred to by a metadata access instruction included in the program code. ) Is converted into a metadata address by adding the MDID to the data address to form the metadata address, and converting the data address into a converted data address using a normal data transaction table. An algorithm for converting and adding the MDID to the post-conversion address to form the metadata address, and a post-conversion meta-data using a metaphysical conversion table different from a normal data conversion table Combining the MDID and the data address based on a combination algorithm selected from the group consisting of algorithms that form the metadata address by adding the MDID to the converted metadata address. 32. The machine readable medium of item 31 comprising.
(Item 35)
Adding the MDID is an algorithm for adding the MDID selected from the group consisting of an algorithm for adding the MDID to the MSB position, an algorithm for adding the MDID to the LSB position, and an algorithm for replacing address bits with the MDID. 35. The machine readable medium of item 34, comprising:
(Item 36)
Item 35. When the program code is executed on the machine, the machine further determines the MDID based on a control register for the processing element indicating a current software subsystem currently active on the processing element. Machine-readable medium.
(Item 37)
A memory for holding program code including a metadata access instruction that refers to a data memory address associated with the data item;
A processor associated with the memory;
With
The processor is
One processing element of a plurality of processing elements associated with execution of the metadata access instruction;
Fetch logic for fetching the metadata access instruction from the memory;
Decoding logic for decoding the metadata access instruction into at least one metadata access process;
A control register holding a metadata identifier (MDID) associated with an active context in the processing element;
A data cache memory including a data entry for holding the data item;
Execution logic for executing the metadata access processing;
Have
When the execution logic executes the metadata access process, the metaphysical address conversion logic of the processor uses the data memory address as a metadata memory address based on the MDID held in the control register. Converting the cache control logic coupled to the data cache memory to perform the metadata access process on another entry in the data cache memory based on the metadata memory address. Including system.
(Item 38)
The metadata access instruction is an item selected from an instruction group consisting of a metadata load instruction for loading the metadata, a metadata store instruction for storing in the metadata, and a metadata clear instruction for resetting the metadata. 37. The system according to 37.
(Item 39)
The active context includes a transactional runtime subsystem, a garbage collection runtime subsystem, a memory protection subsystem, a software conversion subsystem, an outer transaction in a group of nested transactions, and a nesting 40. The system of item 37, wherein the system is selected from the group consisting of one inner transaction of the group of transactions made.
(Item 40)
The metaphysical address conversion logic of the processor further converts the data memory address into a metadata memory address based on a processing element identifier (PEID) for the processing element,
The metaphysical address conversion logic of the processor converts the data memory address into a metadata memory address based on the PEID and the MDID held in the control register. An algorithm for forming the metadata memory address in addition to the data memory address, converting the data memory address to a converted data memory address using a normal data transaction table, and converting the PEID and the MDID to the converted data memory address An algorithm for forming the metadata memory address in addition to the data memory address, and a metaphysical conversion table different from the normal data conversion table, and converting the data memory address to The PEID based on a combination algorithm selected from the group consisting of an algorithm for converting the data memory address and adding the PEID and the MDID to the converted metadata memory address to form the metadata memory address. 38. The system of item 37, comprising combining the MDID and the data memory address.
(Item 41)
A processor,
An execution module that executes a metadata loading process that refers to an address;
In response to the metadata loading process, if the processor is operating in the first mode, the metadata value associated with the address is provided, and the processor is operating in the second mode. In the case with a forced module that provides a fixed value
Processor.
(Item 42)
42. The processor of item 41, wherein the first mode includes a strong atomic mode, and the second mode includes a weak atomic mode.
(Item 43)
45. The processor of item 42, further comprising a first register that holds the fixed value.
(Item 44)
A second register for holding a mode value;
The mode value represents a first value when indicating that the processor is operating in the strong atomic mode;
44. A processor according to item 43, wherein the mode value represents a second value when the processor indicates that the processor is operating in the weak atomic mode.
(Item 45)
45. The processor of item 44, wherein the first register and the second register are the same metadata control register.
(Item 46)
The enforcement module provides a metadata value associated with an address when the processor is operating in the strong atomic mode, and when the processor is operating in the weak atomic mode. Providing a fixed value means that the enforcement module represents the first value indicating that the mode value held in the second register indicates that the processor is operating in the strong atomic mode. If the metadata value is loaded, the metadata value is loaded into the destination register defined by the metadata loading process, and the mode value held in the second register indicates that the processor operates in the weak atomic mode. The second value indicating that the first register is present, the first register is transferred to the destination register. The processor of claim 44 comprising loading the value.
(Item 47)
Discovering a metadata access process that references an address;
Determining the execution mode of the processor;
Providing the metadata value associated with the address to the metadata access process when it is determined that the execution mode of the processor is the first execution mode;
Providing a fixed value from a register for the metadata access process when it is determined that the execution mode of the processor is the second execution mode;
A method comprising:
(Item 48)
Determining the execution mode of the processor comprises reading a mode flag from a first control register;
The mode flag holds a first value indicating that the execution mode of the processor is the first execution mode, and a second value indicating that the execution mode of the processor is the second execution mode. 48. A method according to item 47 to be retained.
(Item 49)
The step of providing the metadata value associated with the address to the metadata access process includes the step of referencing the metadata access process from the memory location associated with the address. 48. The method of item 47, comprising loading the metadata value into a register.
(Item 50)
50. The method of item 49, wherein for the metadata access process, providing a fixed value from a register comprises loading the fixed value from the register to the destination register.
(Item 51)
A memory that holds a metadata load process that references an address and a destination register;
A processor associated with the memory;
With
The processor is
Execution logic for executing the metadata loading process;
A metadata register that holds the forced value,
A cache memory that holds a metadata value associated with the address;
When the execution logic executes the metadata loading process, when the processor operates in the first mode, the metadata value is provided to the destination register, and the processor operates in the second mode. Forcing logic to provide the forcing value from the metadata register to the destination register when
Having a system.
(Item 52)
52. The system of item 51, wherein the forcing logic further determines whether the processor is operating in the first mode or the second mode.
(Item 53)
53. The system of item 52, wherein the first mode includes a strong atomic mode, and the second mode includes a weak atomic mode.
(Item 54)
The metadata register further holds a mode value,
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;
The forcing logic further determining whether the processor is operating in the first mode or the second mode includes the forcing logic interpreting the mode value of the metadata register. 53. The system according to item 52.
(Item 55)
A control register for holding a mode value;
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;
The forcing logic further determining whether the processor is operating in the first mode or the second mode includes the forcing logic interpreting the mode value of the control register. 52. The system according to 52.
(Item 56)
52. The system of item 51, wherein the memory is selected from the group consisting of dynamic random access memory (DRAM), static random access memory (SRAM), and non-volatile memory.
(Item 57)
A data cache array that holds cache entries; and
Cache control logic coupled to the data cache array;
With
The cache control logic is
In response to a buffered update to the cache entry, the cache entry is transitioned from an unmonitored state to a buffered coherency state and a read monitoring state,
Thereafter, the apparatus transitions the cache entry to a buffered coherency state and a write monitoring state before transitioning the cache entry to a modified state to commit the buffered update.
(Item 58)
The buffered update for the cache entry includes a transactional memory access to a data address of a data item held in the cache entry, and a metadata access to a data address associated with the metadata held in the cache entry. 58. The apparatus of item 57, further comprising: an update selected from the group consisting of local updates to the cache entry.
(Item 59)
The cache control logic causes the cache entry to transition from an unmonitored state to a buffered coherency state and a read monitor state so that the cache control logic buffers coherency bits associated with the cache entry. 58. The apparatus of item 57, comprising updating to a completed value to represent the buffered coherency state, and updating a read monitoring attribute bit associated with the cache entry to a read monitoring value to represent the read monitoring state. .
(Item 60)
Transitioning the cache entry to a buffered coherency state and a write monitor state before the cache control logic transitions the cache entry to a modified state to commit the buffered update; Control logic maintains the buffered value of the coherency bit associated with the cache entry to represent the buffered coherency state and writes a write monitoring attribute bit associated with the cache entry 60. The apparatus of item 59, comprising updating to a monitoring value to represent the write monitoring state.
(Item 61)
The cache control logic transitioning the cache entry to the modified state means that the cache control logic updates the coherency bit associated with the cache entry to a modified value and the modified coherency state. 61. The apparatus according to item 60, comprising representing:
(Item 62)
Further comprising execution logic for performing commit processing after executing the buffered update;
Transitioning the cache entry to a buffered coherency state and a write monitoring state before the cache control logic transitions the cache entry to a modified state in order to commit the buffered update, the execution logic The device according to item 57, which is performed in response to executing the commit process.
(Item 63)
Discovering buffered updates to a block of cache memory;
Applying a read monitor to the block upon finding the buffered update for the block of the cache memory;
Applying write monitoring to the block after committing the read monitor and before committing the block;
A method comprising:
(Item 64)
64. The method of item 63, wherein the buffered update to the block of the cache memory comprises a transactional write to the block of the cache memory.
(Item 65)
Performing the buffered update on the block of the cache memory simultaneously with applying the read monitoring;
64. The method of item 63, wherein the block is held in a buffered coherency state after performing the buffered update.
(Item 66)
Performing the buffered update on the block of the cache memory after applying the read monitoring;
64. The method of item 63, wherein the block is held in a buffered coherency state after performing the buffered update.
(Item 67)
Upon finding the buffered update for the block of the cache memory, applying read monitoring to the block comprises:
Generating a read request for the block for a plurality of processing elements outside a cache domain of the cache memory;
When it is detected that there is no conflict from the plurality of processing elements outside the cache domain in response to the read request for the block, the read monitoring attribute associated with the block of the cache memory is updated to a read monitoring value. Applying read monitoring to the block;
64. A method according to item 63, comprising:
(Item 68)
After applying the read monitoring and before committing the block, applying write monitoring to the block comprises:
Generating an ownership read request for the block for the plurality of processing elements outside the cache domain of the cache memory;
Write monitoring associated with the block of the cache memory in response to detecting no conflict from the plurality of processing elements outside the cache domain in response to the ownership read request for the block Updating the attribute to a write monitoring value and applying write monitoring to the block;
68. The method according to item 67, comprising:
(Item 69)
69. The method of item 68, wherein committing the block includes transitioning the cache coherency state of the block from a buffered coherency state to a modified coherency state.
(Item 70)
A machine accessible medium holding program code,
When the machine executes the program code, the machine
When there is a buffered write to a block of cache memory, apply read monitoring to the block,
Performing the buffered write on the block;
A machine accessible medium that applies write monitoring to the block after applying the read monitoring and before committing the block.
(Item 71)
Applying read monitoring to the block when there is the buffered write to the block of the cache memory,
Generating a read request for the block for a plurality of processing elements outside a cache domain of the cache memory;
In response to detecting that there is no conflict from the plurality of processing elements outside the cache domain in response to the read request for the block, a read monitoring attribute associated with the block of the cache memory is Updating the read monitoring value to apply the read monitoring to the block;
including
Item 70. The machine accessible medium of item 70.
(Item 72)
Applying write monitoring to the block after applying the read monitoring and before committing the block;
Generating an ownership read request for the block for the plurality of processing elements outside the cache domain of the cache memory;
Write monitoring associated with the block of the cache memory in response to detecting no conflict from the plurality of processing elements outside the cache domain in response to the ownership read request for the block Updating the attribute to the write monitoring value and applying the write monitoring to the block;
72. The machine accessible medium according to item 71, comprising:
(Item 73)
71. The machine accessible medium of item 70, wherein write monitoring is applied to the block after applying the read monitoring and before committing the block in response to discovering a commit process.
(Item 74)
71. The machine accessible medium of item 70, wherein committing the block includes transitioning the cache coherency state of the block to a modified coherency state.
(Item 75)
System memory holding transactional writes referencing memory addresses and commit processing;
A processor having a cache memory and associated with the system memory;
With
The cache memory included in the processor is:
Generating a read request for the cache line associated with the memory address in response to receiving the transactional write;
Transitioning the cache line to a buffered and read-monitored state in response to no conflict being detected based on the read request;
An ownership read request is generated in response to receiving the commit process, and the cache line is buffered and monitored for writing in response to no conflict being detected based on the ownership read request. Transition
A system that transitions the cache line to a modified state in response to transitioning the cache line to the buffered and write-monitored state.
(Item 76)
Transitioning the cache line to a state where the cache memory is buffered and being monitored for reading means that the cache memory updates a coherency bit associated with the cache line to a buffered value, Represents a portion of the buffered and read-monitored state that is buffered, updates the read monitoring attribute bit associated with the cache line to a read monitoring value, and 76. A system according to item 75, comprising representing a portion of the read-monitored state that is being read-monitored.
(Item 77)
Transitioning the cache line to a state where the cache memory is buffered and monitored for writing means that the cache memory maintains the buffered value of the coherency bit associated with the cache line. Represents the buffered state of the buffered and write-monitored state, and updates the write monitoring attribute bit associated with the cache line to the write monitoring value. 77. The system of item 76, comprising representing a state of the buffered and write monitored state that is being write monitored.
(Item 78)
Transitioning the cache line to a modified state in response to the cache memory transitioning the cache line to the buffered and write-monitored state sets the coherency bit to a modified value. 78. A system according to item 77, comprising updating to represent the modified state.
(Item 79)
76. The system of item 75, wherein the memory is selected from the group consisting of dynamic random access memory (DRAM), static random access memory (SRAM), and non-volatile memory.
(Item 80)
Decode logic to decode the lost instructions and provide the decoded elements;
A status storage element having a loss field holding a loss value indicating that a loss event has been detected;
Jump logic coupled to the status storage element;
With
The lost instruction refers to a label, includes an operation code (opcode), and is part of an instruction group that can be recognized by the decode logic,
The apparatus wherein the jump logic passes control to the label based on the decoded element and the loss value indicating that the loss event has been detected.
(Item 81)
The label includes a jump destination address;
A loss event is a read monitoring conflict indicating that a write to a cache line being read has occurred, a write monitoring conflict indicating that an access to a cache line being written has occurred, and a buffered event. 81. The apparatus of item 80, wherein the apparatus is selected from the group consisting of:
(Item 82)
The status storage element comprises a register;
The loss field holding the loss value is buffered with a first bit set when a read monitoring conflict is detected, and a second bit set when a write monitoring conflict is detected. 81. The apparatus of item 80, comprising a third bit that is set when a loss of physical data is detected and a fourth bit that is set when a loss of buffered metadata is detected.
(Item 83)
The loss instruction includes a read monitoring loss instruction, the opcode defines a read monitoring loss event type,
The jump logic passes control to the label based on the decoded element and the loss value indicating that the loss event has been detected because the type of loss event that the jump logic has occurred , Causing the label to jump to execution in response to the loss field holding the loss value indicating the read monitor loss event type defined by the opcode of the read monitor loss instruction. The device of item 80 comprising:
(Item 84)
The loss instruction includes a write monitoring loss instruction, the opcode defines a write monitoring loss event type;
The jump logic has occurred that the jump logic has passed control to the label based on the decoded element and the loss field holding the loss value indicating that the loss event has been detected. In response to the loss field holding the loss value indicating that the type of the loss event is the write monitoring loss event type defined by the opcode of the write monitoring loss instruction, The apparatus of item 80, comprising causing the label to jump execution.
(Item 85)
The loss instruction includes a buffered loss instruction, the opcode defines a buffered loss event type;
The jump logic has occurred that the jump logic has passed control to the label based on the decoded element and the loss field holding the loss value indicating that the loss event has been detected. In response to the loss field holding the loss value indicating that the type of the loss event is the buffered loss event type defined by the opcode of the buffered loss instruction, the label 81. The apparatus of item 80, comprising causing the execution to jump to.
(Item 86)
A machine accessible medium holding program code,
When the machine executes the program code, the machine
Depending on the loss order,
Determine the status of the transaction defined by the loss instruction and held in the transaction status register provided in the machine,
A machine accessible medium that directs execution to a label defined by the loss instruction in response to the status of the transaction indicating that a loss event associated with the loss instruction has been detected.
(Item 87)
The label includes a jump destination address;
A loss event is a read monitoring conflict indicating that a write to a cache line being read has occurred, a write monitoring conflict indicating that an access to a cache line being written has occurred, and a buffered event. 87. The machine accessible medium of item 86, selected from the group consisting of a loss of cash lines.
(Item 88)
The loss command includes a read monitoring jump loss (JLOSS) command that defines the loss event as a read monitoring conflict,
Determining the status of a transaction held in the transaction status register includes determining a status of a read monitoring conflict bit held in the transaction status register;
Directing execution to a label defined by the loss instruction in response to the status indicating that the loss event associated with the loss instruction has been detected is a read monitor In response to the fact that the status of the read monitoring conflict bit held in the transaction status register indicates that a conflict has been detected, execution is directed to a label defined by the loss instruction. 90. The machine accessible medium of item 86 comprising.
(Item 89)
The loss instruction includes a write supervisor jump loss (JLOSS) instruction that defines the loss event as a write supervisor conflict;
Determining the status of the transaction held in the transaction status register includes determining the status of the write monitoring conflict bit held in the transaction status register;
In response to the status of the transaction indicating that a loss event associated with the loss instruction has been detected, directing execution to a label defined by the loss instruction is a write In response to the fact that the status of the write monitoring conflict bit held in the transaction status register indicates that a monitoring conflict has been detected, execution is directed to a label defined by the loss instruction. 89. The machine accessible medium of item 86, comprising:
(Item 90)
The loss instruction includes a buffered monitoring jump loss (JLOSS) instruction that defines the loss event as a buffered monitoring conflict;
Determining the status of a transaction held in the transaction status register includes determining a status of a buffered monitoring conflict bit held in the transaction status register;
Directing execution to the label defined by the loss instruction in response to the status indicating that the loss event associated with the loss instruction has been detected is buffered In response to the status of the buffered monitoring conflict bits held in the transaction status register indicating that a monitoring conflict has been detected, execution is directed to a label defined by the lost instruction 89. The machine accessible medium of item 86, comprising:
(Item 91)
Discovering lost instructions in the processor;
Determining whether a loss event associated with the loss instruction is detected in the processor in response to finding the loss instruction;
Branching to a label referenced by the loss instruction in response to finding the loss instruction and determining that the loss event associated with the loss instruction has been detected in the processor;
A method comprising:
(Item 92)
92. The method of item 91, wherein the label includes a jump address.
(Item 93)
The loss command includes a read monitoring loss command,
92. The method of item 91, wherein the loss event associated with the read monitoring loss instruction includes writing to a cache line being read monitored.
(Item 94)
The loss instruction includes a write monitoring loss instruction;
92. The method of item 91, wherein the loss event associated with the write monitoring loss instruction includes access to a cache line that is being write monitored.
(Item 95)
The loss instruction includes a buffered loss instruction;
92. The method of item 91, wherein the loss event associated with the buffered loss instruction includes eviction of a buffered cache line.
(Item 96)
Determining whether eviction of a buffered cache line is detected in the processor is by checking the buffered loss status bit in the transaction status register and setting the buffered loss status bit to a loss value. 96. The method of item 95, comprising determining, in response, that eviction of a buffered cache line has been detected.
(Item 97)
Decode logic to decode the transaction commit instructions and provide decoded elements;
Commit logic for determining whether a commit condition defined by the commit instruction is satisfied for the transaction according to the decoded element;
With
The commit instruction defines the commit condition, includes an operation code (opcode), and is a part of an instruction group that can be recognized by the decode logic.
(Item 98)
The commit condition includes any defined combination of no loss of read monitoring data, no loss of write monitoring data, no loss of buffer data, and no loss of metadata,
The determination that the commit logic satisfies the commit condition is that there is no loss of read monitoring data, no loss of write monitoring data, no loss of buffer data, and no loss of metadata. 98. The apparatus according to item 97, comprising determining that the specified combination has occurred.
(Item 99)
The commit instruction that defines the commit condition includes the commit instruction that holds 4 bits, and the first bit of the 4 bits is a condition that the loss of read monitoring data should be committed when set. The second bit, when set, indicates that the loss of write monitoring data is a condition to commit, and the third bit, when set, commits the loss of buffer data 98. The apparatus of item 97, indicating a condition to be performed and a fourth bit, when set, indicates that a metadata loss is a condition to commit.
(Item 100)
100. The apparatus of item 99, wherein the 4 bits are included in the opcode.
(Item 101)
When the commit logic determines whether the commit condition specified by the commit instruction is satisfied for the transaction, the commit logic determines whether the commit logic is a transaction status register And confirming that the commit condition is satisfied if none of the confirmed corresponding status bits of the transaction status register is set to indicate a corresponding loss. 100. Apparatus according to item 99.
(Item 102)
The commit instruction further defines a clear control indicating a combination to be cleared at the time of commit among read monitoring data, write monitoring data, buffered data, and metadata,
The commit logic, after committing the transaction in response to determining that the commit condition defined by the commit instruction is satisfied for the transaction, reads monitor data, write monitor data, buffer data, and 98. The apparatus according to item 97, wherein the specified combination of metadata is cleared.
(Item 103)
A machine-readable medium for holding program code,
When the machine executes the program code, the machine
For a transaction included in the program code, find a commit instruction that defines at least one commit failure condition;
Determining whether or not the at least one commit failure condition defined by the commit instruction is detected during execution of the transaction;
In response to determining that the at least one commit failure condition specified by the commit instruction is detected during the execution of the transaction, the at least one commit failure specified by the commit instruction during the execution of the transaction. Provides a value indicating that the condition has been detected
Machine-readable medium.
(Item 104)
104. The machine-readable medium of item 103, wherein the at least one commit failure condition is selected from the group consisting of loss of read monitoring data, loss of write monitoring data, loss of buffer data, and loss of metadata.
(Item 105)
Providing a value indicating that the at least one commit failure condition specified by the commit instruction has been detected during execution of the transaction means that the at least one specified by the commit instruction during execution of the transaction. 104. The machine-readable medium of item 103, comprising loading a value indicating that one commit failure condition has been detected into a destination register.
(Item 106)
Determining whether the at least one commit failure condition defined by the commit instruction is detected during execution of the transaction;
Checking a status bit of a transaction status register associated with the at least one commit failure condition;
In response to the status bit associated with the at least one commit failure condition being set to indicate that the at least one commit failure condition has been detected during execution of the transaction; Determining that the at least one commit failure condition defined by the commit instruction is detected during execution of a transaction;
In response to the status bit associated with the at least one commit failure condition being reset to indicate that the at least one commit failure condition was not detected during execution of the transaction, Determining that the at least one commit failure condition defined by the commit instruction was not detected during execution of the transaction;
104. The machine-readable medium of item 103, comprising:
(Item 107)
108. The machine-readable medium of item 106, further comprising committing the transaction in response to determining that the at least one commit failure condition defined by the commit instruction was not detected during execution of the transaction.
(Item 108)
In a transaction, finding a commit instruction including an operation code (opcode) defining a plurality of commit failure conditions for the transaction;
Determining that none of the plurality of commit failure conditions for the transaction defined in the opcode of the commit instruction was detected during execution of the transaction;
Committing the transaction in response to determining that none of the plurality of commit failure conditions for the transaction defined in the opcode of the commit instruction has been detected during execution of the transaction;
A method comprising:
(Item 109)
The opcode defining the plurality of commit failure conditions for the transaction is set with a first bit of the opcode that defines a loss of read monitoring data as a commit failure condition when set. A second bit of the opcode that defines a loss of write monitoring data as a commit failure condition; and a third bit of the opcode that defines a loss of buffer data as a commit failure condition when set; 109. The method of item 108, comprising: a fourth bit of the opcode that, when set, defines that the loss of metadata is a commit failure condition.
(Item 110)
Determining that none of the plurality of commit failure conditions for the transaction defined in the opcode of the commit instruction was detected during execution of the transaction;
Determining, in response to the first bit of the opcode being set, that the read monitoring bit of the transaction status register is not set, indicating no loss of read monitoring data;
Determining that the write monitoring bit of the transaction status register is not set and indicates no loss of write monitoring data in response to the second bit of the opcode being set;
Determining, in response to the third bit of the opcode being set, that the buffered bit of the transaction status register is not set, indicating no loss of buffer data;
Determining that the metadata bit of the transaction status register is not set and indicates no loss of metadata in response to the fourth bit of the opcode being set;
110. The method of item 109, comprising:
(Item 111)
The opcode further defines clear control,
The opcode that prescribes the clear control is set with a fifth bit of the opcode that prescribes clearing the read monitoring data when committed, and the write monitoring data when committed when set A sixth bit of the opcode that prescribes clearing, a seventh bit of the opcode that prescribes clearing the buffer data when committed, and a metadata when set. 110. The method of item 109, comprising: an eighth bit of the opcode specifying that it is cleared upon commit.
(Item 112)
Committing the transaction includes clearing read monitoring data when the fifth bit is set; clearing write monitoring data when the sixth bit is set; 119. The method of item 111, comprising: clearing buffer data when the seventh bit is set; and clearing metadata when the eighth bit is set.
(Item 113)
A memory for holding a program code including a commit instruction for a transaction, the clear control information and a commit instruction including an operation code (opcode) defining a plurality of commit failure conditions for the transaction;
Decoding logic for decoding the opcode of the commit instruction, and a processor having commit logic;
With
The commit logic determines whether none of the plurality of commit failure conditions specified by the opcode is detected during execution of the transaction, and the commit logic determines whether the plurality of commit commits during execution of the transaction. Committing the transaction in response to determining that none of the failure conditions were detected,
The system wherein the commit logic commits the transaction includes the commit logic clearing transaction information based on the clear control information defined by the opcode of the commit instruction.
(Item 114)
114. The system according to item 113, wherein the commit failure condition is determined by combining a loss of read monitoring data, a loss of write monitoring data, a loss of buffer data, and a loss of metadata.
(Item 115)
The commit failure condition includes: write monitoring data loss, read monitoring data loss or write monitoring data loss, write monitoring data loss or buffer data loss, write monitoring data loss or metadata loss, 119. The system of item 114, wherein the system is selected from the group consisting of loss of write monitoring data, loss of read monitoring data, loss of buffer data, or loss of metadata.
(Item 116)
The operation code defining the clear control information includes the operation code defining which of read monitoring, write monitoring, buffered coherency and metadata is cleared upon commit;
The commit logic clears transaction information based on the clear control information defined in the opcode of the commit instruction because the commit logic is the read monitor, the write monitor, the buffered coherency, and the 114. The system of item 113, comprising clearing metadata that is specified to be cleared by the opcode.
(Item 117)
A storage element having a transaction enable field (TEF);
Logic that stores at least the TEF state in a storage structure in response to a ring level transition event and returns at least the TEF state from the storage structure to the storage element in response to a return event;
With
If the TEF holds an active value, it indicates that the associated transaction is active and enabled, and if the TEF holds an inactive value, the associated transaction is temporary. A device that indicates that it has stopped.
(Item 118)
118. The apparatus of item 117, wherein the ring level transition event comprises an event selected from the group consisting of an interrupt, an exception, a system call, a virtual machine start, and a virtual machine end.
(Item 119)
118. The apparatus of item 117, wherein the return event includes an event selected from the group consisting of an interrupt return (IRET), a system return (SYSRET), a virtual machine (VM) start, and a virtual machine (VM) end.
(Item 120)
The storage element includes a flag register;
118. The apparatus of item 117, wherein the TEF includes a transaction enable flag.
(Item 121)
The storage structure includes a stack, and the logic storing at least the state of the TEF in the stack includes push logic pushing at least the state of the TEF into the stack, the logic from the stack 118. The apparatus of item 117, wherein returning at least the state of the TEF to a storage element comprises pop logic popping at least the state of the TEF from the stack and returning the TEF to the storage element.
(Item 122)
A memory that holds code that, when executed, generates a ring level transition event;
A processor having registers and stack logic;
With
The register includes a transaction enable field (TEF) for holding an active value indicating that the associated transaction is active;
The stack logic pushes the previous state of the register onto the stack in response to the ring level transition event, clears the TEF to an inactive value, and the associated transaction is suspended. And returning the previous state of the register from the stack to the register in response to a return event.
(Item 123)
123. The system of item 122, wherein the ring level transition event comprises an event selected from the group consisting of interrupt, exception, system call, virtual machine start, and virtual machine end.
(Item 124)
123. The system of item 122, wherein the return event includes an event selected from the group consisting of an interrupt return (IRET), a system return (SYSRET), a virtual machine (VM) start, and a virtual machine (VM) end.
(Item 125)
The register includes a flag register, the TEF includes a transaction enable flag, the active value includes a logic high value of the transaction enable flag, and the inactive value includes a logic low value of the transaction enable flag. The described system.
(Item 126)
Detecting a ring level transition event from the current ring level; and
Saving the previous state of the register containing the transaction enable field to a storage structure;
Clearing the transaction enable field to indicate that the associated transaction is suspended;
Detecting a return event to the current ring level;
Returning the previous state of the register from the storage structure in response to detecting the return event to the current ring level;
A method comprising:
(Item 127)
The storage structure includes a kernel stack, and saving the previous state of the register to the kernel stack comprises pushing the previous state of the register onto the kernel stack, from the kernel stack 127. The method of item 126, wherein returning the previous state of a register comprises popping the previous state of the register from the kernel stack and returning the previous state to the register.
(Item 128)
127. The method of item 126, wherein the current ring level includes a user ring level.
(Item 129)
129. The method of item 128, wherein the ring level transition event comprises an event selected from the group consisting of an interrupt, an exception, a system call, and a virtual machine start.
(Item 130)
131. The method of item 129, wherein the return event to the current privilege level includes an event selected from the group consisting of an interrupt return (IRET), a system return (SYSRET), and a virtual machine (VM) termination.

Claims (25)

Multiple processing elements;
With logic and
One processing element of the plurality of processing elements is associated with a plurality of software subsystems,
The logic is associated with a first software subsystem among the plurality of software subsystems, and a metadata access process that refers to a data address is associated with the first software subsystem. An apparatus for associating with a metaphysical address space associated with the first software subsystem based at least on a data identifier (MDID) and the data address. The metaphysical address space associated with the first software subsystem is at least one other metaphysical address space associated with a second software subsystem of the plurality of software subsystems; The apparatus of claim 1, wherein the apparatus is orthogonal to a data address space containing the data address. The logic includes conversion logic for converting the data address to a metadata address in the metaphysical address space associated with the first software subsystem based on at least the MDID. The device described. The translation logic further includes the data address in the metaphysical address space associated with the first software subsystem based on a processing element identifier (PEID) associated with the processing element. The apparatus of claim 3, wherein the apparatus converts to a metadata address. The conversion logic further converts the data address to a metadata address in the metaphysical address space associated with the first software subsystem based on a data-to-metadata compression ratio. 4. The apparatus according to 4. Further comprising a modifiable register by the first software sub-system,
Said register in response to a write from the first software sub-systems, while holding the MDID, shows the effect that the first software sub-system is running on the processing elements,
Said conversion logic, the data address, based on the PEID and the MDID, be converted to the meta data address of the first software the metaphysical address space associated with the subsystem, said conversion The apparatus of claim 4, wherein logic includes combining information representing the data address with the PEID and the MDID. The conversion logic, when said data address and information indicating the combining the PEID and the MDID, wherein forming the PEID and the metadata address by adding the MDID in the data address, the usual data conversion table by converting the data address to the converted data address using, to form the metadata address by adding the PEID and the MDID in the converted data address, and, separate from the normal data conversion table by converting the data address using the meta physical conversion table in the conversion after the metadata address, at least one of the by adding the PEID and the MDID in the converted metadata address to form the metadata address instrumentation of claim 6 for the . Discovering metadata processing that refers to a data address that is in a data address space and that is associated with a data item held in a data entry in a cache memory; and
A metadata address in a metaphysical address space separate from the data address space corresponds to the data address, a processing element identifier (PEID) of a processing element associated with the metadata processing, and the processing element Determining based on a metadata identifier (MDID) of the attached software subsystem;
Accessing a metadata entry in the cache memory based on the metadata address.   9. The method of claim 8, wherein the metaphysical address space is also distinct from an additional metaphysical address space that is also associated with an additional software subsystem that is also associated with the processing element. Responsive to the software subsystem currently executing on the processing element in response to discovering a write operation from the software subsystem to a control register associated with the processing element Writing the MDID in
The method of claim 8, further comprising: determining the MDID based on the control register.   The method of claim 10, further comprising determining the PEID based on a portion of the metadata processing opcode. It said data address to the metadata address, the PEID, and determining from the MDID is to form the metadata address by adding the PEID and the MDID in the data address, the usual data conversion table by converting the data address to the converted data address using, to form the PEID and the metadata address by adding the MDID in the converted data address, and, separate from the normal data conversion table Converting at least one of the data address into a converted metadata address using a metaphysical conversion table, and adding the PEID and the MDID to the converted metadata address to form the metadata address; go and said data address, Method of claim 10 including the step of combining the serial PEID and said MDID. Decoding logic for decoding a metadata access instruction that refers to the data address of the data item;
Transform the data address into a separate metadata address transparent to software and access the metadata referenced by the separate metadata address in response to the decode logic decoding the metadata access instruction With logic to
The metadata access instruction includes an operation code that can be recognized as a part of an instruction group that can be appropriately decoded by the decoding logic.   The metadata access instruction is selected from an instruction group 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). 13. The apparatus according to 13.   14. The apparatus of claim 13, wherein the metadata access instruction is selected from a group of instructions consisting of a compressed metadata test (CMDT) instruction, a compressed metadata store (CMS) instruction, and a compressed metadata clear (CMDCLR) instruction. . It is the metadata identifier specified in the control register by the software subsystem that is associated with the metadata access instruction that the logic converts the data address into a separate metadata address transparent to software. 14. The apparatus of claim 13, comprising translating the data address based at least on (MDID). The metadata access instruction further includes a reference to a destination register;
Access to metadata which the logic is referenced by the separate metadata address, said logic loads the metadata in the separate metadata address referenced in the destination register 14. The apparatus of claim 13, comprising.   The apparatus of claim 17, wherein the opcode includes a thread identifier field that identifies a thread that issued the metadata access instruction. To the machine,
A program for executing a step of generating a metadata access process that refers to the data address in the data access process according to a data access process that refers to a data address,
When the metadata access process is executed, the program converts the data address to a metadata address different from the data address, and the data address based on the metadata address. A program that causes access to metadata of data items in The metadata access process is selected from an instruction group 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). 19. The program according to 19 . The method of claim 19 , wherein the metadata access process is selected from a group of compressed instructions consisting of a compressed metadata test (CMDT) instruction, a compressed metadata store (CMS) instruction, and a compressed metadata clear (CMDCLR) instruction. program. The converting is associated with the data address, a processing element identifier (PEID) associated with the metadata access process, and the metadata access process based on a data-to-metadata compression ratio. 23. The program of claim 21 , comprising combining a metadata data identifier (MDID). The program according to claim 22 , wherein the data address can be converted by a virtual-physical address conversion logic of the machine so as to refer to the data item. The metadata access process further refers to an operand register,
The program according to claim 19 , wherein the accessing includes updating the metadata of the data item with a value held in the operand register. Including compiler code for compiling application code including the data access process;
The program according to claim 19 , wherein the step of generating the metadata access process in the data access process includes generating the metadata access process in a compiled version of the application code.

Images