HK1246441B - Bulk allocation of instruction blocks to a processor instruction window - Google Patents

Description

Batch allocation of instruction blocks to processor instruction windows

Background Art

The designers of instruction set architecture (ISA) and processor weigh power consumption and performance. For example, if the designer selects an ISA with instructions that deliver higher performance, the power consumption of the processor may also be higher. Alternatively, if the designer selects an ISA with instructions that have lower power consumption, the performance may be lower. Power consumption can be related to the quantity of hardware resources (such as arithmetic logic unit (ALU), cache lines or registers) of the processor used by the instruction during execution. Using a large amount of such hardware resources can deliver higher performance at the cost of higher power consumption. Alternatively, using a small amount of such hardware resources can produce lower power consumption at the cost of lower performance. A compiler can be used to compile high-level code into instructions compatible with ISA and processor architecture.

Summary of the Invention

The processor core in an instruction block-based microarchitecture includes a control unit that dispatches instructions into instruction windows in batches by simultaneously fetching the instruction block and associated resources, including control bits and operands. Such batch dispatch supports efficient operation of the processor core by enforcing consistent management and policy implementation across all instructions in a block during execution. For example, when an instruction block branches backward on itself, it can be reused during a flush instead of being re-fetched from the instruction cache. Since all resources for the instruction block are located in one place, the instructions can remain in place and only need to clear valid bits. Batched dispatch also supports operand sharing across instructions in a block and explicit message passing between instructions.

This Summary is provided to introduce in a simplified form some of the concepts that will be further described in the Detailed Description below. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 shows an illustrative computing environment in which a compiler provides coded instructions that execute on an architecture including multiple processor cores;

FIG2 is a block diagram of an illustrative microarchitecture for an exemplary processor core;

FIG3 shows an illustrative arrangement of a block header; and

4-15 are flow charts of illustrative methods.

Like reference numerals refer to like elements in the drawings. Unless otherwise noted, elements are not drawn to scale.

DETAILED DESCRIPTION

1 shows an illustrative computing environment 100 with which the current batch allocation of instruction blocks can be utilized. The environment includes a compiler 105 that can be used to generate encoded machine-executable instructions 110 from a program 115. The instructions 110 can be processed by a processor architecture 120 that is configured to process instruction blocks having variable-sized contents (e.g., between 4 and 128 instructions).

The processor architecture 120 typically includes a plurality of processor cores (representatively indicated by reference numeral 125) in a tiled configuration, interconnected by an on-chip network (not shown), and further interoperating with one or more level 2 (L2) caches (representatively indicated by reference numeral 130). Although the number and configuration of cores and caches may vary depending on the implementation, it should be noted that the physical cores can be merged together into one or more larger logical processors during the runtime of the program 115 in a process referred to as "composition", which can dedicate more processing power to program execution. Alternatively, when the program execution supports suitable thread-level parallelism, the cores 125 can be split up to operate independently and execute instructions from independent threads in a process referred to as "decomposition".

FIG2 is a simplified block diagram of a portion of an illustrative processor core 125. As shown, the processor core 125 may include a front-end control unit 202, an instruction cache 204, a branch predictor 206, an instruction decoder 208, an instruction window 210, a left operand buffer 212, a right operand buffer 214, an arithmetic logic unit (ALU) 216, another ALU 218, registers 220, and a load/store queue 222. In some cases, a bus (indicated by an arrow) may carry both data and instructions, while in other cases, a bus may carry data (e.g., operands) or control signals. For example, the front-end control unit 202 may communicate with other control networks via a bus that carries only control signals. Although FIG2 shows a number of illustrative components for the processor core 125 arranged in a particular arrangement, more or fewer components may be arranged differently depending on the needs of a particular implementation.

The front-end control unit 202 may include circuitry configured to control the flow of information through the processor core and circuitry for coordinating activities therein. The front-end control unit 202 may also include circuitry for implementing a finite state machine (FSM), in which a state enumerates each operational configuration that the processor core can adopt. Using opcodes (described below) and/or other inputs (e.g., hardware-level signals), the FSM circuitry in the front-end control unit 202 may determine the next state and control outputs.

Thus, the front-end control unit 202 can fetch instructions from the instruction cache 204 for processing by the instruction decoder 208. The front-end control unit 202 can exchange control information with other parts of the processor core 125 via a control network or bus. For example, the front-end control unit can exchange control information with the back-end control unit 224. In some embodiments, the front-end control unit and the back-end control unit can be integrated into a single control unit.

The front-end control unit 202 may also coordinate and manage control of the various cores and other portions of the processor architecture 120 ( FIG. 1 ). Thus, for example, an instruction block may be executed simultaneously on multiple cores, and the front-end control unit 202 may exchange control information with the other cores via a control network to ensure synchronization of the execution of the various instruction blocks as needed.

The front-end control unit 202 may further process control information and meta-information about the instruction block executed in the atomic state. For example, the front-end control unit 202 may process a block header associated with the instruction block. As discussed in more detail below, the block header may include control information and/or meta-information about the instruction block. Accordingly, the front-end control unit 202 may include combinational logic, a state machine, and a transient storage unit (such as a flip-flop) to process various fields in the block header.

The front-end control unit 202 can fetch and decode a single instruction or multiple instructions per clock cycle. The decoded instructions can be stored in an instruction window 210, which is implemented as a buffer in the processor core hardware. The instruction window 210 can support an instruction scheduler 230, which, in some embodiments, can maintain the readiness of the inputs (such as predicates and operands) of each decoded instruction. For example, a given instruction can be woken up by the instruction scheduler 230 and ready to be issued when all of its inputs (if any) are ready.

Before issuing an instruction, any operands required by the instruction may be stored in the left operand buffer 212 and/or the right operand buffer 214, as needed. Depending on the opcode of the instruction, the ALU 216 and/or ALU 218 or other functional units may be used to perform operations on the operands. The output of the ALU may be stored in the operand buffer or in one or more registers 220. Store operations issued in data flow order may be queued in the load/store queue 222 until the instruction block is committed. When the instruction block is committed, the load/store queue 222 may write the committed block stores to memory. The branch predictor 206 may process block header information related to the branch exit type and factor this information into the branch prediction.

As described above, the processor architecture 120 typically utilizes instructions organized in blocks that are extracted, executed, and submitted atomically. Thus, the processor core can centrally extract instructions belonging to a single block, map them to execution resources within the processor core, execute the instructions, and submit their results atomically. The processor can submit the results of all instructions, or can cancel the execution of the entire block. The instructions within the block can be executed in data flow order. In addition, the processor can allow the instructions within the block to communicate directly with each other using messages or other suitable forms of communication. Therefore, an instruction that produces a result can transmit the result to another instruction in the block that utilizes the result, rather than writing the result to a register file. As an example, an instruction that accumulates the values stored in registers R1 and R2 can be represented as shown in Table 1 below:

Table 1

In this way, the source operand is not specified by the instruction, but by the instruction with the ADD instruction as the target. The compiler 105 (Figure 1) can explicitly encode the control and data dependencies during the compilation of the instruction 110, so that the processor core does not need to rediscover these dependencies at runtime. This can advantageously reduce the processor load and save energy during the execution of these instructions. As an example, the compiler can use assertions to convert all control dependencies into data flow instructions. By using these techniques, the number of accesses to the power-consuming register file can be reduced. Table 2 below shows an example of a general instruction format for such an instruction:

Table 2

OPCODE PR BID XOP TARGET1 TARGET2

Each instruction can have a suitable size, such as 32 bits, 64 bits, or another size. In the example shown in Table 2, each instruction can include an OPCODE field, a PR (prediction) field, a BID (broadcast ID) field, an XOP (extended OPCODE) field, a TARGET1 field, and a TARGET2 field. The OPCODE field can specify a unique opcode for an instruction or instruction block, such as addition, read, write, or multiplication. The PR (prediction) field can specify any predicates associated with the instruction. For example, a 2-bit PR field can be used as follows: 00 - not asserted, 01 - reserved, 10 - false assertion, 11 - true assertion. Thus, for example, if an instruction is only executed if a comparison result is true, the instruction can be asserted based on the result of another instruction that performs the comparison. The BID (broadcast ID) field can support sending operands to any number of consumer instructions in a block. The 2-bit BID field can be used to encode the broadcast channel on which the instruction receives one of its operands. The XOP (extended OPCODE) field can support expanding the type of opcode. The TARGET1 and TARGET2 fields may allow up to two target instructions to be encoded. The target field may specify a consumer instruction for the result of a producer instruction, thereby allowing direct communication between instructions.

Each instruction block may have specific information associated with it, such as control information and/or meta-information related to the block. This information may be generated by the compiler 105 during the process of compiling a program into instructions 110 for execution on the processor architecture 120. Some of this information may be extracted by the compiler during the compilation of the instruction block and then examined for instruction properties during runtime.

In addition, the information associated with the instruction block can be meta-information. As an example, such information can be provided to the processor core using a dedicated instruction or an instruction that provides a target encoding associated with a register or other memory, wherein the register or other memory may have the relevant information associated with the instruction block. In the case of a dedicated instruction, the opcode field of such an instruction can be used to transmit information related to the instruction block. In another example, such information can be maintained as part of a processor status word (PSW). For example, this information can advantageously help the processor to execute the instruction block more efficiently.

Various types of information can be provided to the processor core using a block header, a dedicated instruction, the location of a memory reference, a processor status word (PSW), or various combinations thereof. An illustrative instruction block header 300 is shown in FIG3 . In this illustrative example, the block header 300 is 128 bits and begins at offset 0 from the program counter of the block. The corresponding start and end of each field are also shown. These fields are described in Table 3 below:

Table 3

Although the block header shown in FIG. 3 and described in Table 3 includes multiple fields, this is intended to be illustrative, and other field arrangements may be used for particular implementations.

In an illustrative example, compiler 105 ( FIG. 1 ) may select information for inclusion in a block header, or for use in a dedicated instruction that may provide such information to a processor core based on the nature of the instruction and/or based on the nature of the processing requirements (such as high performance or low power consumption). This may advantageously allow for a better balance of tradeoffs between performance and power consumption. For certain types of processing applications (such as high performance computing with a large number of cores), a large amount of information may be an ideal choice. Alternatively, for other types of processing applications, such as embedded processors used in the Internet of Things, mobile devices, wearable devices, head mounted display (HMD) devices, or other embedded computing type applications, less information may be an ideal choice.

The scope of information conveyed using a block header or dedicated instructions can be tailored based on the nature of the instructions in the block. For example, if a block of instructions includes a loop that executes in a round-robin fashion, more extensive information may be required to encapsulate the control information associated with the block. The additional control information can allow the processor core to execute the loop more efficiently, thereby improving performance.

Alternatively, if there is an instruction block that will be executed infrequently, relatively less information may be sufficient. For example, if the instruction block includes several predicted control loops, more information may be required. Similarly, if the instruction block has a large amount of instruction-level parallelism, more information may be required as part of the block header or dedicated instructions.

Additional control information or dedicated instructions in the block header can, for example, be used to effectively exploit instruction-level parallelism within an instruction block. If the instruction block includes several branch predictions, more information may be needed. Additional control information about branch predictions generally makes code execution more efficient because it may result in fewer pipeline flushes.

Note that the functions corresponding to the fields in the block header can be combined or further separated. Similarly, a dedicated instruction can provide information related to any one of the fields shown in Figure 3 and Table 3, or can combine information from these fields. For example, although the illustrative block header of Figure 3 and Table 3 includes separate ID and SIZE fields, these two fields can be combined into a single field.

Similarly, when decoded, a single dedicated instruction can provide information about the size of the instruction block and the information in the ID field. Unless otherwise specified, a dedicated instruction can be included anywhere in the instruction block. For example, the BLOCK_SIZE#size (size) instruction can include an immediate field that contains the value of the size of the instruction block. The immediate field can contain an integer value that provides size information. Alternatively, the immediate field can include a coded value related to the size information so that the size information can be obtained by decoding the coded value, for example, by looking up the value in a size table that can be represented using one of logic, registers, memory, or code streams. In another example, the BLOCK_ID#id dedicated instruction can transmit a block ID number.

A separate mathematical function or a memory-based table may map a block ID to a memory address in a block header. The block ID transmitted as part of such an instruction may be unique to each instruction block. In another example, a BLOCK_HDR_ID#id instruction may transmit a block header ID number. A separate mathematical function or a memory-based table may map a block ID to a memory address in a block header. The block ID transmitted as part of such an instruction may be shared by several instruction blocks having the same header structure or fields.

In another example, the BLOCK_INFO#size, #exit types, #store mask, and #write mask instructions may provide information about the enumerated fields of the instruction. These fields may correspond to any of the fields discussed above with respect to Table 3. Other changes may be made to the block header structure and format, as well as to the specialized instructions, depending on the requirements of a given implementation. For example, additional fields may be provided that include information related to the characteristics of the instruction block. Specific fields may be included based on the frequency with which the instruction block is executed.

The fields included in the block header structure, or the information provided via the previously discussed dedicated instructions or other mechanisms, may be part of a publicly available standard instruction set architecture (ISA) for a particular processor or processor family. A subset of these fields may be a proprietary extension of the ISA. Certain bit values in the field may be part of the standard ISA of the processor, but certain other bit values in the field may provide proprietary functionality. This exemplary field may allow an ISA designer to add proprietary extensions to the ISA without fully disclosing the properties and functions associated with the proprietary extensions. Therefore, in this case, the compiler tools distributed by the ISA designer will support proprietary bit values in the field, completely independent proprietary fields, or dedicated instructions. The use of such fields may be particularly relevant to hardware accelerators that are proprietary to certain processor designs. Therefore, a program may include block header fields or unrecognizable dedicated instructions; however, a program may also include a recipe for decrypting fields or decoding instructions.

The compiler 105 ( FIG. 1 ) may process blocks of instructions that are typically configured to be executed atomically by one or more processor cores to generate information about the blocks of instructions, including meta-information and control information. Some programs may be compiled for use with only one ISA, such as an ISA used with a processor for the Internet of Things, a mobile device, an HMD device, a wearable device, or other embedded computing environment. The compiler may employ techniques such as static code analysis or code profiling to generate information related to the blocks of instructions. In some cases, the compiler may consider factors such as the characteristics of the blocks of instructions and their execution frequency. Relevant characteristics of the blocks of instructions may include, for example, but are not limited to: (1) instruction-level parallelism, (2) the number of loops, (3) the number of control instructions that are asserted, and (4) the number of branch predictions.

Fig. 4 is a flow chart of an illustrative method 400 for managing instruction blocks in an instruction window disposed in a processor core. Unless otherwise specified, the method or steps in the flow chart of Fig. 4 and the methods or steps in other flow charts shown in the accompanying drawings and described below are not limited to a specific order or sequence. In addition, some of the methods or steps thereof may occur simultaneously or be performed simultaneously, and not all methods or steps must be performed in a given embodiment, depending on the requirements of such an embodiment, and some methods or steps may be optionally used. Similarly, some steps may be omitted in some embodiments to reduce overhead, but this may, for example, cause increased brittleness. The various features, costs, overhead, performance, and robustness trade-offs that may be implemented in any given application may be typically considered a design choice issue.

In step 405, the lifetime of the extracted instruction blocks is tracked explicitly using, for example, a lifetime vector. Thus, rather than using the instruction block order (i.e., position) in the instruction window (which is typically used to implicitly track lifetime), the control unit maintains explicit state. In step 410, a list of instruction blocks sorted by lifetime is maintained. In some embodiments, instruction block priority (which may in some cases be determined by the compiler) may also be tracked, and a list of instruction blocks sorted by priority may also be maintained.

In step 415, when the designated block is identified for processing, a list sorted by lifetime is searched to find a matching instruction block. In some embodiments, a list sorted by priority may also be searched to find a match. If a matching instruction block is found, it can be refreshed in step 420 without having to re-extract it from the instruction cache, which can improve processor core efficiency. Such refreshing makes it possible to reuse the instruction block when, for example, a program is executed in a tight loop and the instructions branch backward on their own. When multiple processor cores form a large-scale array, such efficiency increases may also be complicated. When refreshing the instruction block, the instruction is kept in place and only the valid bits in the operand buffer and load/store queue are cleared.

If no match is found for the instruction block, the list sorted by lifetime (or by priority) can be used again to find an instruction block that can be submitted to open a slot for the new instruction block in the instruction window. For example, the oldest instruction block or the lowest priority instruction block can be submitted (wherein high priority blocks may need to remain cached due to the possibility of future reuse). In step 425, the new instruction block is mapped to an available slot. A batch allocation process can be used to allocate instruction blocks, wherein the instructions in the block and all resources associated with the instructions are extracted simultaneously (i.e., centrally).

In step 430, the new instruction block is executed so that its instructions are committed atomically. In step 435, other instruction blocks may be executed sequentially by lifetime in a manner similar to a conventional reorder buffer so that their respective instructions are committed atomically.

FIG5 is a flow chart of an illustrative method 500 that can be performed by an instruction block based microarchitecture. In step 505, a control unit in a processor core causes the fetched instruction blocks to be cached using either continuous replacement or non-continuous replacement. In step 510, using continuous instruction block replacement, the operation buffer can be operated as a circular buffer. In step 515, using non-continuous instruction block replacement, the instruction blocks can be replaced out of order. For example, in step 520, explicit lifetime-based tracking can be performed such that instruction blocks are committed and replaced based on the tracked lifetime in a manner similar to that described above. In step 525, priorities can also be tracked, and the tracked priorities can be used to commit and replace instruction blocks.

Fig. 6 is a flow chart of an illustrative method 600 that can be performed by a control unit arranged in a processor core. In step 605, the state of the instruction blocks cached is tracked, and in step 610, the state tracked is used to maintain a list of instruction blocks. For example, depending on the specific implementation requirements, the state may include lifetime, priority, or other information or context. In step 615, when the instruction block is identified for mapping, the list is checked to find a match as shown in step 620. In step 625, the matching instruction blocks from the list are refreshed without re-extraction. When no matching instruction block is found in the list, then in step 630, in a manner similar to that described above, the instruction block is extracted from the instruction cache and mapped to an available slot in the instruction window.

FIG7 is a flow chart of an illustrative method 700 for managing instruction blocks arranged in an instruction window in a processor core. In step 705, a size table of instruction block sizes is maintained in the processor core. The size table can be represented in various ways, for example, using one of logic, registers, memory, code stream, or other suitable structures. In step 710, an index encoded in the header of the instruction block is read. The instruction block includes one or more decoded instructions. Therefore, instead of using the SIZE field shown in FIG3 and Table 3 to hard-code the instruction block size, this field can be used to encode or store an index to the size table. In other words, the index can be used as a pointer to an entry in the size window so that a specific size can be associated with the instruction block.

The number of size entries included in the size table can vary according to implementation. A larger number of size entries can be used to achieve larger granularity, which may be beneficial when the distribution of the instruction block size associated with a given program is relatively wide, but at the expense of increased overhead in a typical implementation. In some cases, the number of sizes included in the table can be selected by the compiler to cover the specific distribution of instruction block sizes in a manner that can optimize the whole instruction packing density, and to minimize no-ops. For example, the size included in the size table can be selected to match the block instruction size commonly used in the program. In step 715, an index is used to search the instruction block size from the size table. In step 720, the instruction block is mapped to the available slot in the instruction window based on its size.

In some embodiments, as shown in step 725, the instruction window can be split into two or more sub-windows of two or more different sizes. Such changes in the split sub-windows can enable further adaptation to a given distribution of instruction block sizes and can further increase instruction packing density. Splitting can also be performed dynamically in some scenarios.

FIG8 is a flow chart of an illustrative method 800 that can be performed by an instruction block-based microarchitecture. In step 805, a size table is implemented. As described above, the size table can be implemented using one of logic, registers, memory, code flow, or other suitable structures and can include sizes corresponding to sizes commonly used in the distribution of instruction blocks used by a given program. In step 810, the instruction block header is checked for a pointer to an entry in the size table. In step 815, the size identified by the table entry is used to determine the placement of the instruction block in the instruction window.

In step 820, resources associated with the instruction blocks are allocated in batches. When mapping the instruction blocks in the instruction window in step 825, the restrictions specified in the instruction block header are used. These restrictions may include, for example, restrictions on alignment and the capacity of the instruction window to buffer instruction blocks. In step 830, the order of the instruction blocks in the instruction window is tracked by the control unit, and in some cases, the blocks may be submitted out of order. For example, instead of using a circular buffer of instruction blocks in which blocks are processed according to their position in the instruction window, the blocks may be prioritized so that highly used or particularly important instruction blocks are processed out of order, which may improve processing efficiency.

In step 835, in some cases, the lifetime of the instruction block may be explicitly tracked, and the instruction block may be committed based on such explicitly tracked lifetime. In step 840, the instruction block is flushed (i.e., reused without having to re-fetch the instruction block from the instruction cache).

FIG9 is a flow chart of an illustrative method 900 that may be performed by a control unit disposed in a processor core. In step 905, an instruction window is configured to have multiple segments having two or more different sizes in a manner similar to that described above. In step 910, the block instruction header is examined for an index encoded therein. In step 915, a lookup is performed in a size table using the index, and in step 920, the instruction block is placed into an instruction window segment appropriate for the particular size of the block based on the size lookup. In step 925, a batch allocation is used to extract resources associated with the instruction block.

FIG10 is a flow chart of an illustrative method 1000 for managing instruction blocks arranged in an instruction window within a processor core. In step 1005, an instruction block is mapped from an instruction cache into an instruction window. The instruction block includes one or more decoded instructions. In step 1010, resources associated with each instruction in the instruction block are allocated. Resources typically include control bits and operands, and allocation can be performed using a batch allocation process in which all resources are collectively acquired or extracted.

Instead of tightly coupling the resources and instructions, the instruction window and operand buffer are decoupled so that they can be operated independently by maintaining one or more pointers between the resources and the decoded instructions in the block, as shown in step 1015. When the instruction block is flushed (i.e., reused without having to re-fetch the instruction block from the instruction cache) in step 1020, then the resources can be reused by following the pointers back to the original control state in step 1025.

This decoupling can improve processor core efficiency, particularly when instruction blocks are flushed without the usual refetching, for example, when a program executes in a tight loop and instructions are reused. By establishing control state through pointers, resources are effectively pre-verified without the need for additional processing cycles and other overhead. Such efficiency gains can also be compounded when multiple processor cores are deployed in large arrays.

FIG11 is a flow chart of an illustrative method 1100 that can be performed by an instruction block-based microarchitecture. In step 1105, the instruction block is mapped into the instruction window in a manner such that the new instruction block replaces the submitted instruction block. As shown in step 1110, the mapping can be subject to various constraints specified in the instruction block header, such as alignment constraints and the capacity of the instruction window to buffer instruction blocks. In step 1115, resources are allocated for the new instruction block, which is typically implemented using a batch allocation process as described above.

In step 1120, the order of the instruction blocks in the instruction window is tracked by the control unit, and in some cases, the blocks may be submitted out of order. For example, rather than using a circular buffer of instruction blocks in which blocks are processed based on their position in the instruction window, the blocks may be prioritized so that highly used or particularly important instruction blocks are processed out of order, which may improve processing efficiency.

In step 1125, the instruction window is decoupled from the operand buffer so that, for example, instruction blocks and operand blocks are managed independently (i.e., a strict correspondence between instructions and operands is not used). As described above, decoupling increases efficiency by enabling pre-verification of resources when refreshing instruction blocks.

FIG12 is a flow chart of an illustrative method 1200 that may be performed by a control unit disposed in a processor core. In step 1205, an instruction window is maintained for buffering one or more instruction blocks. In step 1210, one or more operand buffers are maintained for buffering resources associated with the instructions in the instruction blocks. As described above, resources typically include control bits and operands. In step 1215, pointers between instructions and resources are used to track status.

When the instruction block is flushed, the pointer can be followed back to the tracked state in block 1220. When the instruction block is committed, the control bit in the operand buffer is cleared and a new pointer is set in step 1225. As with the method discussed above, in step 1230, the instruction window is decoupled from the operand buffer, allowing the control unit to maintain the instruction block and operand block on a non-corresponding basis.

Figure 13 is a flow chart of an illustrative method 1300 for managing the instruction blocks in the instruction window arranged in the processor core. In step 1305, batch allocation process is used to allocate instruction blocks, wherein the instructions in the block and all resources associated with the instructions are extracted simultaneously (that is, centrally). Compared with the traditional architecture in which instructions and resources are repeatedly extracted with smaller blocks, the batch allocation here enables all instructions in the block to be managed simultaneously and in unison, which can improve the efficiency of the processor core operation. In the case where a given programming structure (for example, a structure that minimizes branches) enables a compiler to generate relatively large instruction blocks, this improvement can be more significant. For example, in some embodiments, an instruction block can comprise up to 128 instructions.

The batch allocation of instruction blocks also improves the efficiency of the processor core through a flush feature, in which instruction blocks are reused without having to be re-fetched as typically occurs, such as when a program executes in a tight loop and instructions branch backward on themselves. Such efficiency gains can also be compounded when multiple processor cores are arranged in large arrays. When an instruction block is flushed, the instructions are kept in place and only the valid bits in the operand buffer and load/store queues are cleared. This allows the fetch of the flushed instruction block to be bypassed entirely.

When a set of instructions and resources are in place, batch allocation of instruction blocks supports additional processing efficiency. For example, operands and explicit messages can be sent from one instruction in the block to another. Such functionality is not supported in traditional architectures because one instruction cannot send anything to another instruction that has not yet been allocated. Instructions that generate constants can also lock values in the operand buffer so that they remain valid after a flush, eliminating the need to regenerate these values each time the instruction block is executed.

In step 1310, when the instruction blocks are mapped into the instruction window, they are subject to constraints that can be applied in step 1315 by a mapping policy, restrictions specified in the block header, or both. In some cases, the policy can be set by the compiler based on the specific requirements of a given program. The specified restrictions can include, for example, restrictions on alignment and restrictions on the capacity of the instruction window to buffer instruction blocks.

In step 1320, in some embodiments, the instruction window may be segmented into sub-windows of equal or different sizes. Since instruction block sizes for a given program are typically randomly or unevenly distributed, this variation in the segmented sub-windows may more effectively accommodate a given instruction block size distribution, thereby increasing instruction packing density within the instruction window. In some cases, segmentation may also be performed dynamically, based on the distribution of block sizes currently being processed by the processor core.

In some embodiments, the instruction block header may encode an index or include a pointer to a size table of an embodiment in the usage logic, registers, memory, or code flow. The size table may include an instruction block size entry so that the instruction block size can be looked up from the table in step 1325. For example, when a block includes a relatively small number of instructions when an embodiment branches, using an encoded index and size table can increase the instruction packing density in the instruction block by providing more granularity in the available blocks to reduce the occurrence of no-ops.

FIG14 is a flow chart of an illustrative method 1400 that may be performed by an instruction block-based microarchitecture. In step 1405, a control unit in a processor core applies a policy for processing an instruction block. In step 1410, the instruction block is allocated using the batch allocation process described above, where the instructions and all associated resources are fetched simultaneously. In step 1415, the instruction block is mapped into an instruction window, where the mapping may be subject to various restrictions, such as alignment restrictions specified in the instruction block header and the capacity of the instruction window to buffer instruction blocks, as described above.

At step 1420, a strategy may be applied that includes the control unit tracking the order of instruction blocks in the instruction window. For example, in some cases, blocks may be submitted out of order, rather than using a circular buffer of instruction blocks where blocks are processed based on their position in the instruction window. At step 1425, a strategy may be applied that includes processing blocks based on priority (which may be specified by the compiler in some scenarios) so that highly used or particularly important blocks are processed out of order, which may further increase processing efficiency.

In some cases, a strategy may be applied that explicitly tracks the lifetime of instruction blocks and may commit instruction blocks based on such explicitly tracked lifetimes in step 1430. In step 1435, a strategy may be applied that maps instruction blocks based on the availability of appropriately sized slots in an instruction window (or a segment of a window). In step 1440, a strategy may be applied that uses a circular buffer to map instruction blocks into instruction windows.

In some embodiments, various combinations of strategies can be used to further enhance processor core efficiency. For example, the control unit can dynamically switch between strategies to apply a strategy that provides more optimized operation for a given instruction block or group of instruction blocks. For example, in some cases, it may be more efficient to use a circular buffer technique, in which instruction blocks are processed sequentially in a continuous manner. In other cases, out-of-order and lifetime-based processing can provide more optimized operation.

FIG15 is a flow chart of an illustrative method 1500 that may be performed by a control unit disposed in a processor core. In step 1505, an instruction window is configured to have multiple segments having two or more different sizes in a manner similar to that described above. In step 1510, an instruction block is extracted, and in step 1515, all of its associated resources are extracted.

In step 1520, the instruction block is placed in a suitable segmentation of the window that maximizes the instruction density in the window. For example, if the compiler generates a block size distribution that includes a relatively large number of blocks with lower instruction counts (e.g., to implement program branches, etc.), the instruction window can have a segmentation that is specifically sized for small instruction blocks. Similarly, if there are relatively large numbers of high instruction count blocks (e.g., for scientific and similar applications), the segmentation can be specifically sized for such larger instruction blocks. Therefore, the instruction window segmentation can be sized according to a specific size distribution, or dynamically sized in some cases when the distribution changes. In box 1525, as described above, the instruction block can be subject to the restrictions specified in the instruction block header.

Various exemplary embodiments of the current batch allocation of instruction blocks to a processor instruction window are now presented by way of illustration, not an exhaustive list of all embodiments. One example includes a method for managing instruction blocks arranged in an instruction window in a processor, comprising: batching the instruction blocks so that resources for one or more instructions in the instruction block are fetched simultaneously, wherein the resources include control bits and operands associated with the one or more instructions; mapping the instruction block including the one or more instructions from an instruction cache into the instruction window, wherein the instruction block includes a header; and applying one or more constraints when performing the mapping, wherein the constraints are imposed by one of a mapping policy or restrictions specified in the header. In another example, the mapping policy is implemented using a control unit that processes the instruction blocks based on one of lifetime, size, location, or priority. In another example, the method further includes segmenting the instruction window into sub-windows, wherein the segmented sub-windows share a common size or have different sizes. In another example, the sizes of the segmented sub-windows are dynamically determined based on the distribution of instruction block sizes. In another example, the specified restrictions include one of an alignment restriction or an instruction block capacity restriction for the instruction window. In another example, the instruction block size is indicated in the header using a pointer to a size table, where the size table is expressed in one of the following: logic, registers, memory, or code flow.

Another example includes an instruction block-based microarchitecture comprising: a control unit; one or more operand buffers; and an instruction window configured to store decoded instruction blocks to be controlled by the control unit, wherein the control includes applying one or more of a plurality of policies for processing instruction blocks; and batching instruction blocks, including fetching resources into the one or more operand buffers for all instructions in the instruction block to allow instructions in the instruction block to send messages or operands to other instructions in the instruction block. In another example, the resources include one of control bits or operands buffered in the operand buffers. In another example, the policy includes a configuration for mapping instruction blocks based on constraints specified in the instruction block header, wherein the specified constraints include one of alignment constraints or instruction block capacity constraints for the instruction window. In another example, the policy includes a configuration for tracking the order of instruction blocks in the instruction window and for committing instruction blocks out of order. In another example, the policy includes a configuration for explicitly tracking the lifetime of instruction blocks currently mapped in the instruction window and for committing instruction blocks based on the explicitly tracked lifetime. In another example, the policy includes a configuration to map an instruction block to an instruction window when a slot in the instruction window that fits the instruction block is available. In another example, the policy includes a configuration to map the instruction block to the instruction window using a circular buffer. In another example, the policy includes a configuration to map the instruction block to the instruction window or to submit the instruction block based on priority.

Another example includes a control unit disposed in a processor, the processor being configured to perform a method for instruction block management, the method comprising: configuring an instruction window having a plurality of segments, wherein the segments have two or more different sizes; extracting an instruction block comprising one or more instructions from an instruction cache; extracting all resources associated with the instructions in the instruction block; and placing the instruction block into the segments of the instruction window such that instruction density in the instruction window is maximized. In another example, the control unit further comprises inspecting a header of the instruction block to obtain specified constraints on placement within the instruction window, and performing the placement according to the specified constraints, wherein the specified constraints comprise one of: an alignment constraint or an instruction block capacity constraint. In another example, the control unit further comprises configuring the segmented instruction window into logically segmented instruction windows distributed across a plurality of processor cores. In another example, the control unit further comprises maintaining state across the logically segmented instruction windows using communications carried over an intra-chip network. In another example, the control unit further comprises performing the extraction of instruction blocks and resources as a batch allocation. In another example, the control unit further comprises selecting a segment for the placed instruction block based on an instruction block size encoded in the header or based on an instruction block size indicated by a pointer in the header to a size table, wherein the size table is represented using one of the following: logic, registers, memory, or code flow.

The above-described subject matter is provided for illustration only and should not be construed as limiting. Various modifications and changes may be made to the subject matter described herein without following the example embodiments and applications shown and described, and without departing from the true spirit and scope of the present disclosure as set forth in the following claims.

Claims (19)

1. A method for managing instruction blocks in an instruction window, the instruction window being arranged in a processor, the method comprising: The instruction block is allocated in batches such that resources for one or more instructions in the instruction block are simultaneously extracted, wherein the resources include control bits and operands associated with the one or more instructions; Mapping an instruction block comprising one or more instructions from the instruction cache into the instruction window, wherein the instruction block includes a header; and When performing the mapping, one or more constraints are applied, wherein the constraints are imposed by one of the mapping strategies or restrictions specified in the header; and The instruction block size is indicated in the header using a pointer to a size table, which is expressed using one of the following: logic, register, memory, or code stream. 2. The method of claim 1, wherein the mapping strategy is implemented using a control unit that processes instruction blocks based on one of lifetime, size, position, or priority. 3. The method of claim 1 further includes dividing the instruction window into sub-windows, wherein the divided sub-windows share a common size or have different sizes. 4. The method of claim 3, wherein the size of the segmented sub-window is dynamically determined based on the distribution of instruction block sizes. 5. The method of claim 1, wherein the specified limitation includes one of the following: an alignment limitation or a limit on the instruction block capacity of the instruction window. 6. An instruction block-based processor, comprising: Control unit; One or more operand buffers; and A command window, configured to store blocks of decoded commands to be controlled by the control unit, wherein the control includes performing the following operations: One or more of a plurality of strategies for processing an instruction block are applied, wherein the strategies include mapping the configuration of the instruction block based on constraints specified in the header of the instruction block, and wherein the size of the instruction block is indicated in the header using a pointer to a size table, the size table being expressed using one of the following: logic, registers, memory, or code stream; and The batch allocation instruction block includes: for all instructions in the instruction block, extracting resources into one or more operand buffers to allow instructions in the instruction block to send messages or operands to another instruction in the instruction block. 7. The instruction block-based processor of claim 6, wherein the resource includes a control bit or an operand buffered in the operand buffer. 8. The instruction block-based processor of claim 6, wherein the specified limitation includes one of the following: an alignment limitation or an instruction block capacity limitation of the instruction window. 9. The instruction block-based processor of claim 6, wherein the strategy includes a configuration for tracking the order of the instruction blocks in the instruction window and for submitting instruction blocks out of order. 10. The instruction block-based processor of claim 6, wherein the strategy includes explicitly tracking the lifetime of instruction blocks currently mapped in the instruction window and configuring instruction blocks to be committed based on the explicitly tracked lifetime. 11. The instruction block-based processor of claim 6, wherein the strategy includes a configuration for mapping the instruction block to the instruction window when a slot suitable for the instruction block is available in the instruction window. 12. The instruction block-based processor of claim 6, wherein the strategy includes a configuration for mapping instruction blocks to the instruction window using a circular buffer. 13. The instruction block-based processor of claim 6, wherein the strategy includes a configuration for mapping instruction blocks to the instruction window or a configuration for submitting instruction blocks based on priority. 14. A control unit disposed in a processor, the control unit being configured to perform a method for instruction block management, comprising: Configure a command window with multiple segments, where each segment has two or more different sizes; Retrieve a block of instructions, including one or more instructions, from the instruction cache; Retrieve all resources associated with the instruction in the instruction block; The instruction blocks are placed into segments of the instruction window to maximize the instruction density within the instruction window; and The header of the instruction block is examined to obtain specified constraints on its placement within the instruction window, wherein the size of the instruction block is indicated in the header using a pointer to a size table, which is expressed using one of the following: logic, register, memory, or code stream. 15. The control unit of claim 14, further comprising performing the placement according to a specified constraint, wherein the specified constraint includes one of an alignment constraint or an instruction block capacity constraint. 16. The control unit of claim 14, further comprising an instruction window that configures the segmented instruction window as logically segmented instructions distributed across a plurality of processor cores. 17. The control unit of claim 16 further includes using communication carried on an on-chip network to maintain state across logical segmentation instruction windows. 18. The control unit of claim 14, further comprising the retrieval of instruction blocks and resources as a batch allocation. 19. The control unit of claim 15, further comprising selecting segments based on instruction block sizes encoded in the header or based on instruction block sizes indicated by a pointer in the header to a size table, the segments being selected for placement of the instruction block, wherein the size table is represented using one of: logic, registers, memory, or code stream.