Computer system

【0001】

[Technical field to which the invention belongs]

The present invention generally relates to superscalar RISC type microprocessors, and more specifically, alignment of microprocessor instructions from CISC type to RISC type so that compound instructions can be executed on RISC-based hardware. -Regarding units and decode units.

【0002】

[Problems to be solved by conventional techniques and inventions]<u style="single">Reference of related applications</u>The following are simultaneous pending applications for the same successor's application. US application number 07 / 802,816, filed December 6, 1992 (agent reference number SP024), title of invention "AROM with RAM Cell and Cyclic Redundancy check Circuit", US application No. 07 / 817,810, filed January 8, 1992 (agent reference number SP015), title of invention "High Performance RISC Microprocessor Architecture, US application number 07 / 817,809, 1992 1 Filed on May 8 (agent reference number SP021), title of invention "Extensible RISC Microprocessor Architecture".

【0003】

The disclosure of the above application is incorporated herein by reference.

【0004】<u style="single">Related technology</u>All compound instruction set computers (CISC type computers) that use variable-length instructions face the problem of determining the length of each instruction that occurs in the instruction stream. Instructions are packed into memory as data consisting of consecutive bytes. Therefore, given the address of an instruction, it is possible to determine the start address of the next instruction if the length of the first instruction is known.

【0005】

In a conventional processor, the determination of this length does not significantly affect the performance as compared with other stages in the processing of the instruction stream, such as the actual execution of each instruction. As a result, fairly simple circuits are typically used. Superscalar reduced instruction set computers (RISC computers), on the other hand, can process instructions much faster, but they must be extracted from memory much faster in order to execute multiple instructions in parallel. .. This limiting factor imposed by the speed at which instructions are extracted from memory is called the Flynn Bottleneck.

【0006】

The task of determining the length of each instruction and pulling that instruction out of the instruction stream is performed by a functional unit called the instruction alignment unit (IAU). This block must contain a decoder logic to determine the length of the instruction and a shifter to align the instruction data with the decoder logic.

【0007】

On Intel's 80386 microprocessors, the first byte of an instruction implies a lot about the overall instruction length, and it may be necessary to check for additional bytes before knowing the final length. In addition, it may be possible to identify other additional bytes from the additional bytes. Therefore, since the process is sequential in nature, it is extremely difficult to determine the length of x86 instructions immediately.

【0008】

Based on the information provided in the i486 Programmer's Reference Guide, some conclusions can be drawn regarding the alignment units used in the i486. The i486 IAU is designed to look only at the first few bytes of the instruction. If these bytes do not specify their length sufficiently, these initial bytes are extracted and the process is repeated for the remaining bytes. Each iteration of this process requires a full cycle. Therefore, in the worst case, it may take several cycles for the instructions to be fully aligned.

【0009】

The i486 IAU requires additional cycles, such as when prefix or dilated (2-byte) arithmetic codes are used. Both of these arithmetic codes are common to i486 programs. Moreover, compound instructions may also consist of displacement and immediate data. The i486 requires additional time to extract this data.

【0010】

A format example of the CISC type processor instruction is shown in FIG. This example represents the possible bytes of a variable length i486CISC type instruction. Instructions are stored in memory on a byte boundary. The minimum instruction length is 1 byte, and the maximum is 15 bytes including the prefix. The total length of the instruction is determined by the Prefixes Opcode, ModR / M and SIB bytes.

【0011】

[Means for solving problems]

The present invention comprises a complex instruction set computer (CISC) such as an Intel 80x86 microprocessor, or a superscalar reduced instruction set computer (RISC) processor designed to emulate other CISC type processors. A microprocessor subsystem and method.

【0012】

There are two basic steps in the translation process from CISC type to RISC type in the present invention. CISC-type instructions must first be extracted from the instruction stream and then decoded to produce nano-instructions that can be processed by a RISC-type processor. These steps are performed by the instruction alignment unit (IAU) and the instruction decoding unit (IDU), respectively.

【0013】

The IAU serves to extract individual CISC-type instructions from the instruction stream by examining the oldest to 23rd bytes on the instruction data. The IAU extracts 8 bytes starting and continuing from any of the bytes in the bottom line of the instruction FIFO. During each clock phase, the IAU determines the length of the current instruction and uses this information to control two shifters to shift out the current instruction, but the stream is next: There are still orders to come to. As a result, the IAU outputs instructions aligned between each clock phase at a peak rate of 2 instructions per cycle. This best-case performance exception is described in Sections 2.0 and 2.1 below.

【0014】

After the CISC type instructions are extracted from memory, the IDU serves to convert these aligned instructions into the same sequence as RISC type instructions called nanoinstructions. The IDU considers each aligned instruction to be output from the IAU, the number and type of nanoinstructions required, the size of the data operands, and whether memory access is required to complete the aligned instructions. The instruction is decoded to determine various factors such as. Simple instructions are converted directly into nanoinstructions by decoder hardware, while more complex CISC-type instructions are emulated by a special instruction set of subroutines called microcode routines, which are then nanoinstructions. Is decoded into. This information is collected in a complete cycle for each of the two instructions and then combined to form an instruction bucket, which contains nanoinstructions that correspond to both source instructions. .. This bucket is then transferred to the instruction execution unit (IEU) for execution by a RISC processor. Execution of nanoinstruction buckets is outside the scope of the present invention.

【0015】

The above and other features and advantages of the present invention will become apparent from the following more detailed description of preferred embodiments of the present invention, as shown in the accompanying drawings.

【0016】

BEST MODE FOR CARRYING OUT THE INVENTION

Hereinafter, embodiments of the present invention will be described with reference to the drawings. Contents 1.0 Instruction fetch unit 2.0 Outline of instruction alignment unit 2.1 Block of instruction alignment unit Figure 3.0 Outline of instruction decoding unit 3.1 Microcode dispatch logic 3.2 Mailbox 3.3 Nano instruction format 3.4 Special instruction 3.5 Instruction decoding unit Block Diagram 4.0 Decoded Instruction FIFO Detailed Description of Suitable Examples The basic concepts described in this section are described in detail in the following references: "Superscalar Microprocesser Design", by Mike Johnson, New Jersey. Published in 1991 by Prentice-Hall, located in Inglewood Cliff, State. "Computer architecture-A Quantitative Approach", by John L. Hennessy et al., Published in 1990 by Morgan Kaufmann Publishers in San Mateo, California. "I486 "Misroprocessor Programmer's Reference Manual" and "i486 Misroprocessor Hardware Reference Manual", published in 1990 by Intel Corporation in Santa Talala, California, with order numbers 240486 and 240552, respectively. Disclosures of these publications are incorporated herein by reference.

【0017】

1.0 <u style="single">Instruction fetch unit</u>The instruction fetch unit (IFU) of the present invention is used to fetch an instruction byte from an instruction stream stored in an instruction memory, an instruction cache, or the like, and further supply the instruction byte to a decoder unit for execution. Will be done. The instructions to be aligned by the instruction alignment unit are therefore supplied by the IFU. Figure 1 shows a block diagram of the three instruction prefetch buffers 200 in its IFU, from the main instruction buffer (MBUF) 204, the emulation instruction buffer (EBUF) 202, and the target instruction buffer (TBUF) 206. It is made up. The instruction prefetch buffer can load a 128-bit (16-byte) instruction stream from the instruction cache in a single cycle. This data is kept in one of the three buffers for use by the IAU.

【0018】

During normal program execution, MBUF202 is used to supply instruction bytes to the IAU. When a conditional control flow (ie, a conditional branch instruction) is encountered, the instruction corresponding to the target address of that branch is stored in TBUF206 while execution from MBUF202 continues. Once the branch is decided, either the TBUF206 is discarded if it does not branch, or the TBUF206 is transferred to the MBUF if it branches. In either case, execution from MBUF continues. The operation of EBUF204 is slightly different. Upon entering emulation mode, an emulation instruction or exception transfers instruction fetching and execution to the EBUF204. (Both emulation mode and exception handling are described in detail below.) Execution continues from EBUF204 as long as the processor is in emulation mode. At the end of the emulation routine, execution continues with the instruction data remaining in MBUF204. This eliminates the need to fetch the main instruction data again after executing the emulation routine.

【0019】

2.0 <u style="single">Outline of instruction alignment unit</u>In combination with the present invention, the instruction alignment unit uses a RISC strategy that speeds up ordinary cases by using the excellent instruction throughput per cycle of superscalar processors.

【0020】

In the present invention, the term "aligning" means positioning a byte of an instruction so that it can be distinguished from adjacent bytes in the instruction stream for later decoding. The IAU distinguishes the end of the current instruction from the beginning of the next instruction by determining the number of bytes in the current instruction. The IAU then aligns the current instruction so that the least significant byte put into the IDU is the first byte of the current instruction. Bytes can also be supplied to the IDU in a variety of different orders.

【0021】

The IAU subsystem of the present invention can align most common instructions at a rate of 2 instructions per cycle at any clock rate, and align most other instructions at a reduced clock rate at this same rate. be able to. Instructions containing a prefix require an extra half cycle for alignment. Immediate data and displacement fields are extracted in parallel, so no extra time is required.

【0022】

In addition, the IAU alignment time is only 2.0 cycles per instruction in the worst case, which is less than the time required to align many of the typical instructions of a traditional CISC processor. An instruction from a set that has one or more prefixes (half of the total number of cycles required for alignment), the instruction requires exactly one cycle to determine its length, and the instruction (without the prefix). The worst case occurs if the length is longer than 8 bytes (half a cycle extra is required, resulting in a total of 2 complete cycles).

【0023】

Some structural features provide these performances. First, the IAU is designed to perform a complete alignment operation for each phase of the clock by alternating between phase latches and multiplexers in the alignment circuit. Second, the decoding logic divides CISC-type instructions into two categories based on the number of bits that must be taken into account to determine the length of each instruction. That is, instructions of length specified by a small number of bits are aligned in a single phase (half cycle), while other instructions typically require an additional clock cycle. Finally, the IAU can extract up to 8 bytes from the instruction stream with a single shift. This makes it possible to align long instructions (up to 15 bytes on an i486) with a few shift instructions, and most instructions can be aligned with a single shift.

【0024】

The following tasks are performed by the IAU to decode CISC instructions quickly and accurately. Arithmetic code, ModR / M and SIB (scale, index, base) bytes that detect the existence and length of prefix bytes. Send the following information to the instruction decoding unit (IDU) to detect the length of the instruction (indicating the storage position of the next instruction) -the arithmetic code, that is, 8 bits plus any extended 3 bits. .. For 2-byte operations, the first byte is always OFhex, so the second byte is sent as the operation code-ModR / M bytes, SIB bytes, displacement and immediate data.

【0025】

--Information about the number and type of prefixes The operation code byte specifies the operation performed by the instruction. ModR / M bytes specify the address format used when an instruction references a memory operand. The ModR / M byte can also refer to a second addressing byte, the SIB (scale, index, base) byte, which may require the addressing format to be fully specified. ..

【0026】

2.1 <u style="single">Block diagram of the instruction alignment unit</u>The block diagram of IAU is as shown in Fig. 2. This figure is divided into two parts: the main data bus 302 (the part surrounded by the broken line) and the pre-decoder 304 (the part surrounded by the broken line). Instruction shifting and extraction occur on the main data bus 302, while length determination and data bus control are handled by the pre-decoder 304.

【0027】

The main data bus 302 consists of several shifters, latches and multiplexers. The extraction shifter 306 receives instruction data composed of bytes from the IFU. The two buses, the IFI0b_bus [127: 0] and the IFI1b_bus [55: 0] (generally indicated by 303), represent the IFU instruction data output. The IFU updates this instruction information on the advanced buffer request (ADVBUFREQ) line 308 in response to a request from the IAU. The generation of the ADVBUFREQ signal will be described below. The 8-byte data corresponding to the current instruction is output from the extraction shifter and sent to the alignment shifter 310 on the bus 307. The alignment shifter holds a total of 16 bytes of instruction data and can shift up to 8 bytes per phase. If the shift-out detects a prefix, an alignment shifter is used to separate the prefix from the instruction. Alignment shifters are also used to align an instruction to a lower bite and then shift out the entire instruction after alignment.

【0028】

The eight bytes are also sent via bus 309 to the Immediate Data Shifter (IMM Shifter 312) and the Displacement Shifter (DISP Shifter 314). The IMM shifter 312 extracts immediate data from the current instruction, and the DISP shifter 314 extracts displacement data. The data to these two shifters is delayed by the Ω cycle delay element 316 to maintain synchronization with the aligned instructions.

【0029】

The alignment shifter 310 outputs the next aligned instruction on bus 311 to the two alignment_IR latches 318 or 320. These latches operate on the opposite phase of the system clock. This will latch two instructions per cycle. Alignment_IR latches 318 and 320 output aligned instructions on two output buses 321. During the phase period when one of the latches receives a new value, the output of the other latch (currently aligned instruction) is selected by the multiplexer (MUX 322). The MUX322 outputs its aligned current instruction to the aligned instruction bus 323. Output 323 is the primary output of the IAU. This output is used by the pre-decoder 304 to determine the length of the current instruction and is fed back to the alignment shifter 310 as data from which the next instruction is extracted. The current aligned instruction is fed back to the alignment shifter 310 via bus 325, stack 334, and further bus 305. Bus 305 also sends information about the current aligned instruction to the Ω cycle data delay 316.

【0030】

The IMM shifter 312 and DISP shifter 314 can shift immediate and displacement data, respectively. Because they need a total of 16 bytes to shift. The Ω cycle data delay 316 outputs an instruction byte to the shifter on a single bus. The IMM shifter 312 outputs the immediate data corresponding to the current instruction on the immediate data bus 340. The DISP shifter 314 outputs the displacement data corresponding to the current instruction on the displacement data bus 342.

【0031】

The pre-decoder 304 consists of three decoder blocks: the next instruction detector (NID) 324, the immediate data and displacement detector (IDDD) 326, and the prefix detector (PD) 328. NID and PD control the alignment shifter and extraction shifter, and IDDD controls the IMM shifter 312 and DISP shifter 314.

【0032】

The PD328 is designed to detect the presence of a prefix in a single instruction. The PD328 supplies shift control signals to the alignment shifter 310 and countershifter 332 via lines 331, MUX330, and line 333 to determine the number of prefixes present and to extract the prefix from the instruction stream in the next half cycle. To do. In addition, the PD328 decodes the prefix itself and supplies this prefix information on the output line 329 to the IDU.

【0033】

The basic architecture of the PD328 consists of four identical detectors (to detect up to four prefixes) and a second block of logic to decode the prefix itself. The CISC format defines the order of prefix generation, but the present invention checks for the presence of all prefixes at each of the first 4 byte positions. Further, in order to utilize the deceleration request of the decoder, the function of detecting the existence of the prefix and the function of decoding the prefix are separate. The PD328 architecture is described in more detail below.

【0034】

IDDD326 is designed to extract immediate and displacement data from each instruction. IDDD326 always tries to extract these two fields regardless of their existence. IDDD326 controls the IMM shifter 312 and the DIS shifter 314 on a pair of lines 344 and 346, respectively. The IDU takes half a cycle to process the aligned instructions, but is useless for immediate and displacement data. Therefore, the immediate and displacement data are delayed by the Ω cycle data delay 316 to allow the IDDD326 to spend more time calculating the shift amount. This is because, unlike NID324, which performs decoding and shifting in the same phase, the shift occurs in the next phase.

【0035】

NID324 is the heart of the pre-decoder. Once the prefix is removed, NID324 determines the length of each instruction. The NID 324 controls the alignment shifter 310 and the counter shifter 332 via the control line 327, the MUX 330, and the line 333. The NID consists of two subblocks, a subset primary instruction detector (SNID702) and a residual secondary instruction detector (RNID704), and the RNID704 will be described in relation to FIGS. 6 and 7.

【0036】

As the name implies, SNI D702 determines the length of a subset of CISC-type instruction sets. The instructions in the subset are aligned by SNI D at a rate of 2 instructions per cycle.

【0037】

The RNID704 determines the length of all remaining instructions and requires an additional half cycle, which brings the total decoding time to one complete cycle. Determining whether an instruction is contained in a subset is made by the SNI D, and this signal is used within the NID to select either the SNI D or R NID output.

【0038】

If the new instruction is aligned, it is initially assumed to be in a subset, which selects the output of the SNI D. If the SNID determines that the instruction should be processed by the RNID (during this same half cycle), the signal is asserted and the IAU loops the current instruction and holds it for another half cycle. .. During this second half cycle, the output of the RNI D is selected and the instructions are properly aligned.

【0039】

This architecture of NID has several advantages. One of them, as already mentioned earlier, allows the selection between SNI D and RNID to be made in one half cycle if the cycle time is long enough so that all instructions are in a single phase (prefix or 8). It does not include the time to extract instructions longer than bytes). This allows improved performance per cycle at low cycle rates without the need for additional hardware.

【0040】

The second advantage is that the selection signal can be used as an alignment cancellation signal. This is because the selection signal causes the IAU to ignore the SNI D shift output and hold the current instruction for an additional half cycle. The SNI D can be designed to predict the combination or length of a particular instruction and then generate a cancel signal if the prediction is incorrect. For example, this method can be used to align multiple instructions in one half cycle, which further improves performance.

【0041】

The IAU also consists of the counter shifter 332. The counter shifter 332 is used to determine the shift amount of the extraction shifter 306 via the line 335 and to request an additional CISC type instruction byte from the IFU using the ADVBUFREQ line 308. The function of the counter shifter 332 will be better understood by examining the following examples of IAU operation flowcharts and timing diagrams.

【0042】

FIG. 3 is a schematic flow chart of instruction byte extraction and alignment performed by the IAU of the present invention. As shown in step 402, when new data is entered in the lowest line 205 of IFU's MBUF204 (called BUCKET_ # 0), the extract shifter 306 extracts 8 bytes starting with the first instruction. As shown in step 404, the 8 instruction bytes are passed to the alignment_IR latches 318 and 320, bypassing the alignment shifter 310. As shown in step 406, the IAU then waits for the next clock phase while holding the aligned instructions during the alignment_IR latch.

【0043】

During the next clock phase, the IAU outputs instructions aligned to IDU, STACK334, IDDD326, NID324, PD328 and Ω cycle data delay 316. Information about immediate data and displacement is then output to the respective IDUs on buses 340 and 342. This data, if present, corresponds to the instructions aligned in the previous phase. These operations are generally as shown in step 408 of FIG.

【0044】

The IAU then enters the conditional statement 409 to determine if the prefix exists. This determination is made by the PD (prefix decoder) 328. If the PD detects one or more prefixes, as indicated by the arrow "Yes" exiting conditional statement 409, the process proceeds to step 410, where the IAU selects the output of the PD on the MUX 330. As shown in step 412, the decoded prefix information is latched to be sent to the IDU in the next phase with the next corresponding aligned instruction. If no prefix instruction byte is detected, as indicated by the arrow "No" exiting conditional statement 409, MUX330 selects the output of NID324 as shown in step 414.

【0045】

Once step 412 or 414 is completed, as shown in block 416, the counter shifter controls the extraction shifter 306 to feed the alignment shifter 310 and the n-cycle data delay 316 with the next 8 bytes of instruction data. The current output of 332 is used. Next, IAU uses the output of MUX330 as a variable called shift_A. This variable is used to control the alignment shifter 310 to align the next instruction. The shift_A is also added to the current extract shifter shift amount (called the BUF_count) to calculate the shift amount to be used during the next phase. This addition is performed in the counter shifter 308 as shown in step 408.

【0046】

The next step of operation performed by the IAU is to run the output of the alignment shifter in the alignment_IR latch, as shown in step 420. As shown in step 422, the positions of the immediate and displacement data in IDDD326 are calculated, and this shift amount is delayed by Ω cycles. Next, as shown in step 424, the IAU uses the shift amount calculated during the previous half cycle to shift the data currently being input to the IMM shifter 312 and DISP shifter 314. Finally, this process is repeated for the first time from step 406, waiting for the next clock phase. Steps 408 to 424 are repeated for the remaining instruction bytes in the instruction stream.

【0047】

Figure 4 shows the timing diagram related to the IAU in Figure 2. Two instruction buckets are displayed at the top of Figure 4. These two instruction buckets, labeled bucket_ # 0 and bucket_ # 1, each consist of 16 instruction bytes supplied by IFU (from instruction memory not shown) to the IAU shown in FIG. Instruction alignment is all done from the right side of bucket_ # 0 (ie the bottom bucket). In this embodiment, bucket # 0 and bucket_ # 1 are the bottom two buckets of IFU's MBUF204. Other sequences are possible.

【0048】

In this embodiment, the first three instructions sent to the IAU are OP0, OP1, and OP2, and their lengths are 5 bytes, 3 bytes, and 11 bytes, respectively. Note that only the first 8 bytes of instruction OP2 fit in bucket_ # 0. The remaining 3 bytes are latched at the beginning of bucket_ # 1. To simplify this embodiment, we assume that these three instructions do not have prefix bytes. If the prefix is detected, one phase needs to be added for one instruction alignment.

【0049】

Instructions can be initiated from any position in the bucket. Instructions start at any position in the bottom bucket and are extracted up to 8 bytes at a time. The IAU examines two buckets to deal with instructions that are in the second bucket, such as OP2 in this example.

【0050】

The trace "1" in this timing diagram is one of the two system clocks, CLK0. In this embodiment, the system clock has a half cycle of 6 nanoseconds. CLK0, which has the opposite phase to another system clock CLK1, rises at T6 and falls at T0. In that case, T0 is the rising edge of CLK1 and T6 is the rising edge of CLK0. For clarity, the three main clock phases in Figure 4 are labeled F1, F2, and F3.

【0051】

The traces "2" and "3" in this timing diagram represent the instruction data on the input buses IFI1B and IFI0B. As shown in 502, the new bucket_ # 0 will be available on IFI0B where F1 begins. Shortly afterwards, the first 8 bytes starting with OP0 (B # 0; 7-0) are extracted by the extract shifter 306 at 504. Bucket_ # 0 bytes 7-0 have been shown to be valid. The timing of the extraction shifter is as shown in trace "4".

【0052】

When decoding the instruction stream from CISC type to RISC type begins, the countershifter 332 controls the extraction shifter 306 to extract the first 8 bytes from bucket_ # 0. The counter shifter signals the extraction shifter to further shift and extract bytes from the bucket as the instruction alignment progresses. When the instruction byte is empty from bucket _ # 0, the contents of bucket _ # 1 are shifted into bucket _ # 0, and bucket _ # 1 is replenished from the instruction stream. After extracting the first 8 bytes, the extraction shifter extracts and shifts the bytes under the control of the counter shifter on line 335 based on the instruction length, prefix length, and previous shift information.

【0053】

However, in this embodiment, the counter shifter signals the extraction shifter to shift to zero to align the first instruction. Therefore, the extraction shifter shifts out the first 8 bytes of the first instruction to the alignment shifter 310. The timing of the signal of the alignment shifter is as shown in the trace "5" of the timing diagram. These 8 bytes are valid for the alignment shifter during the F1 time zone indicated by reference number 506.

【0054】

The first 8 bytes of bucket_ # 0 are stored in two alignment_IR latches 318 or 320 (as shown in traces "6" and "7" in Figure 4), bypassing the alignment shifter. Based on the timing of the clock signals CLK0 and CLK1, these alignment_IR latches alternately receive instruction bytes. Alignment_IR0318 is the latch of the clock signal CLK0, that is, it is latched when the clock signal CLK0 is high. Alignment_IR1320 is a latch of the clock signal CLK1 and latches when the clock signal CLK1 is high. The first 8 bytes are valid at alignment_IR0 before the end of the phase of the first clock signal CLK0, as indicated by reference number 508 near the end of F1.

【0055】

The MUX322 selects the latch that performed the latch in the previous phase. In this embodiment, therefore, MUX322 outputs the first 8 bytes of OP0 during the second full phase, F2.

【0056】

Then the first 8 bytes of OP0 flow to NID324 and stack 334. NID324 detects that the first instruction is 5 bytes long and sends this information back to the alignment shifter and counter shifter via lines 325, MUX330, and line 333. As mentioned above, the first 8 bytes flow through the stack at the same time and are fed back to the alignment shifter. As a result, the alignment shifter receives instruction bytes from the extraction shifter and indirectly from itself. This is because the alignment shifter requires 16 bytes of input to shift up to 8 bytes per cycle. When the alignment shifter shifts the X bytes to the right, it discards the least significant X bytes and passes the next 8 bytes of data to the latches 318 and 320. In this case, the stack 334 supplies bytes 0 to 7 to the alignment shifter 310.

【0057】

The bypass 336 surrounding the alignment shifter is used in the early cases where the extraction shifter extracts the first instruction from the instruction stream. With the exception of the prefix byte, the first instruction is aligned, so the alignment shifter does not need to shift in the early cases.

【0058】

During the period of F2 in the timing diagram, the extraction shifter shifts out 8 bytes of bytes 15 to 8 of bucket_ # 0. See 510 in Figure 4. These bytes are sent to the alignment shifter, which now has a total of 16 continuation bytes to process. The alignment shifter examines the output of the extraction shifter as well as the effective output of the latches 318 and 320 during the F2 period.

【0059】

Near the end of F2, the alignment shifter shifts bytes 12-5 of bucket_ # 0 to output based on the signal from the NID. The signal from that NID tells the alignment shifter to shift 5 bytes to the right. As a result, the lowest 5 bytes corresponding to instruction OP0 are discarded. See shift_5_byte signal 512 in trace "8" of the timing diagram. The remaining 8 bytes of instruction data, that is, bytes 12 to 5, then flow through the alignment shifter. Note that byte 5 is the first byte of the next instruction OP1.

【0060】

The counter shifter 332 then shifts 8 bytes of the extraction shifter 306. Because the first 8 bytes are now available from the Alignment_IR latch, so we need the next byte. When phase F3 begins, the counter shifter signals the extraction shifter to increase the shift amount by the number of bytes shifted out by the alignment shifter 310 in the previous phase. Therefore, the counter shifter must consist of logic for storing the shift amount of the previous extraction shifter and further adding the shift amount of the alignment shifter to this value.

【0061】

Each time a new value comes out for the alignment shifter, the counter shifter adds that amount to the old shift amount. In this embodiment, the counter shifter has shifted 8 bytes during the period of F2. Therefore, during F3, the counter shifter must instruct the extraction shifter to shift 8 + 5 or 13 bytes. The byte output by the extraction shifter is bytes 20 to 13. Alignment<u style="single"></u>Note that the IR latch outputs bytes 12-5 during F3, so bytes 20-5 are available in the alignment shifter.

【0062】

During F3, the extraction shifter outputs bytes 20-13. However, since bucket_ # 0 contains only bytes 15-0, bytes 20-16 must be fetched from bucket_ # 1. Bucket_ # 1 is enabled at the beginning of F3, as shown in timing diagram 514. As shown in 516, the extraction shifter subsequently shifts bytes 4 to 0 of bucket_ # 1 and further shifts bytes 15 to 13 of bucket_ # 0. If bucket_1 is not valid at this point, the IAU must wait for it to become valid.

【0063】

As mentioned above, a shift_5-byte signal was generated by NID during F2. Following this signal, bytes 12-5 of bucket_ # 0 are shifted out by the alignment shifter, as shown in 518, and then latched into alignment_IR1 shortly thereafter, as shown in 520.

【0064】

Bytes 12-5 are sent by MUX322 to stack 334 and NID324 at the beginning of F3. The stack feeds back bytes 12-5 to the alignment shifter as shown in 305, and as shown in trace "9" of 522, NID determines that OP1 is 3 bytes long and during F3. Outputs a shift_3_byte signal in the latter half of. The alignment shifter shifts 3 bytes (15-8), and this amount is added to the counter shifter.

【0065】

The above process is repeated. If one instruction crosses bucket _ # 0 (ie bucket _ # 0 is all used), bucket _ # 1 becomes bucket _ # 0, and the new bucket _ # 1 becomes valid thereafter. ..

【0066】

The trace "10" in the timing diagram shows the timing of byte extraction from the instruction stream. The Buf_count # 0 block represents the stored extraction shift amount. The shift amount aligned for each phase is added to the Buf_count # 0 and the result is the extraction shift amount in the next phase (see the block labeled Counter_Shift).

【0067】

The trace "11" in the timing diagram indicates the timing of instruction alignment. The blocks labeled IR_latch_ # 0 and IR_latch_ # 1 represent the duration of the instructions in the corresponding alignment_IR latch. A small block labeled MUX1 represents when the MUX322 begins to select its effective alignment latch. A small block labeled MUX2 represents when MUX330 begins to select a fixed shift amount for NID324. Finally, the block labeled Align_Shift represents when the align shifter begins to output instructions.

【0068】

The prefix is extracted using the same technique as the instruction is aligned, but the MUX330 chooses the output of PD328 over the output of NID324.

【0069】

The block diagram of a part of the stack 334 is as shown in FIG. This stack consists of 64 1-bit stacks arranged in parallel. The 1-bit stack 600 consists of two latches 602 and 604, respectively, and a three-input MUX606. Aligned instructions are input to the MUX on bus 607 labeled Latch and IN. The loading of these two latches is done separately in one of the clock phases. In addition, the MUX606 has three MUX control lines 608 to select which latch output to choose, or to bypass IN data and send directly to OUT-labeled output 610.

【0070】

The IAU can be transferred to separate instruction streams on a regular basis. The stack allows the IAU to store two 8-byte instruction data sets from MUX322. This feature is commonly used in CISC-type instruction emulation. When the IAU has to branch to process a microcode routine for embodying a complex CISC instruction, the IAU state is stored and restarted once the CISC instruction emulation is complete.

【0071】

The Ω cycle data delay 316 is used to send immediate data and displacement information. Instead of fixing the instruction length and shift during the same half-cycle period, immediate data and displacement logic are sent to make the shift in the next phase by delaying the IAU before the shifter. Since these actions are spread over the cycle, it is easy to match the timing requirements to the logic. The IDDD block 326 controls the IMM shifter 312 and the DISP shifter 314 to extract immediate data and displacement data from the instruction. For example, if the first 3-byte instruction is an arithmetic code followed by 4-byte displacement and 4-byte immediate data, the shifter will be able to shift out the appropriate bytes.

【0072】

The shifters 312 and 314 always output 32 bits regardless of whether the actual data size is 8, 16 or 32 bits, which is the properly aligned immediate data in the order of the lower bits of the 32-bit output. And displacement data is included. The IDU determines if the immediate and displacement data is valid, and if so, how much valid data is available.

【0073】

Determining the length of prefixes, immediate data, displacement data, and determining the actual length of an instruction is one of the functions of an actual CISC-type instruction set that is aligned and decoded. Those skilled in the art can obtain this information by examining the CISC type instruction set itself, the manufacturer's user manual, or other general reference materials. How to do this, how to transform information into random logic to achieve the IAU subsystem described above, how to implement the IDU subsystem described below, and more. You will easily understand the control logic used to control the flow of data and how to generate control signals. In addition, once such random logic is generated, you can use a commercially available engineering software application (for example, Verilog from Cadence Design Systems, San Jose, CA) to validate the logic and control such applications. Useful for defining the timing and generation of signals and associated random logic. Other off-the-shelf engineering software applications can be used to generate gate and cell layouts and optimize the implementation of such functional blocks and control logic.

【0074】

The i486 instruction set supports 11 prefixes whose order is defined when used together within an instruction. The format defines that a single instruction contains up to four prefixes. Therefore, the prefix detector 328 of the present invention includes four identical prefix detection circuits. Each circuit searches for one of its 11 prefix codes. The first 4 bytes passed to the prefix detector are evaluated, and the outputs of the 4 prefix detectors are combined to determine the total number of prefixes present. The result is used as the amount of shift passed to the MUX330.

【0075】

The block diagram of NID is shown in FIGS. 6 and 7. The following description of the NID is specific to the alignment of the i486 instruction. It is appropriate to use a different NID architecture for alignment of other CISC instructions. The techniques described below will therefore serve as a guide for those skilled in the art, but should not be considered to limit the scope of the invention.

【0076】

Only 4 bytes are required to determine the length of one instruction (as described above, the 4 bytes consist of two arithmetic code bytes, one arbitrary ModR / M byte, and one SIB byte. ).

【0077】

Figure 6 shows the 4-byte (32-bit) bus 701, which represents the first 4 bytes of the instruction received from MUX322. The first two bytes are sent to SNI D702 on bus 703. The SNID, by definition, determines the length of the first subset of instructions identified based on its first two bytes. The SNID can determine the length of this subset of instructions in half a cycle. The length of the subset instruction is output by the SNI D on bus 705. The width of the bus corresponds to the maximum number of instruction bytes detected by SNI D. The SNID also has a 1-bit MOD detection (MOD_DET) output line 707 to indicate if a Mod R / M byte is in the instruction. In addition, the SNI D has a 1-bit NID_wait line 709 (ie, uses the output of the RNID instead) to signal control logic where the instruction is not in subset form. Therefore, the IAU must wait half a cycle for the RNID to decode the instruction if the NID_wait is true.

【0078】

A subset of the instructions decoded by the SNID are CISC-type instructions that can be decoded in half a cycle using gates of at least 1, 2 and 3 inputs (sheffer fatigue, NOR and inventor), and their gate delay is The maximum is 5 based on a 16 × 16 Karnaugh map of 256 instructions. A block of Karnaugh maps, most of which contain 1-byte arithmetic code instructions, can be realized in this way. The remaining instructions are decoded by the RNID using a logic array with a longer gate delay.

【0079】

RNID704 receives the first 4 bytes on bus 701. RNID performs decoding to determine the length of the remaining instructions that require more than one phase to decode. The RNID has an output similar to the output of the SNI D.

【0080】

RNID detects the instruction length and outputs the result on bus 711. The 1-bit over 8 output 712 indicates that the instruction is at least 8 bytes in length. The RNID also has a 1-bit MOD_DET output 714 that indicates whether the instruction contains Mod R / M bytes.

【0081】

The length decoded by either SNID or RNID is selected by MUX706. The control line 708 for the MUX706, called the selection decoder for the current instruction (SELDECIR), switches the MUX706 between the two decoders to measure the actual length, which is 1 to 11 bytes. For example, an 11-byte long instruction causes the RNI D to output over 8 signals and 3 on bus 711. Its instruction length (1n) is sent to MUX330 on bus 716 and used by alignment shifter 310 and counter shifter 332. The 8-bit output by the top MUX706 is used as shift control (enable) for the alignment shifter and counter shifter.

【0082】

ModR / M bytes are selected as well. The SELDECIR signal 708 chooses the appropriate MOD line and controls the second MUX710 to indicate if the ModR / M bytes are present. MOD line output 718 is used by IDDD.

【0083】

The SELDE CIR signal 708 is generated based on the NID_wait signal 709. The output of the SNID is selected during the first clock phase because the result is complete. If the NID_wait signal 709 indicates that the instruction has not been decoded, the MUX706 and 710 are switched to select the output 711 of the RNID and become available at the beginning of the next clock phase.

【0084】

The RNID704 basically has two parallel decoders, one decoding the instruction as if it had a 1-byte math code and the other as if it had a 2-byte math code. Decode. Escape detection (ESC_DET) The input signal indicates whether the operation code is 1 byte or 2 bytes long. For example, in the i486 instruction set, the first byte of a total 2-byte arithmetic code (called an escape byte) has a value OFhex indicating that the instruction has a 2-byte arithmetic code. RNID outputs a valid instruction length based on the ESC_DET signal. This signal indicates that the first arithmetic code is escape (OFhex), that is, it is a two-byte arithmetic code, thereby enabling the second byte decoder. The decoding of the logic for generating the ESC_DET signal should be apparent to those skilled in the art.

【0085】

The block diagram of RNID is as shown in Fig. 7. RNID decodes ModR / M bytes to either the RNID_1OP decoder 752 that decodes the first arithmetic code byte, the RNID_2OP decoder 754 that decodes the second arithmetic code byte, or two positions determined by the number of arithmetic bytes that exist. It has two identical RNID_MOD decoders 756 and 758, and an RNID SUM adder 760. Based on the outputs of the four RNID decoders 752 to 758, the RNID_SUM adder 760 outputs the full length of the instruction on bus 762. The RNID_SUM adder 760 has another output line 764 labeled OVER8 to indicate whether the instruction length is 8 bytes or more.

【0086】

The 3 bits of the 1st operation code byte of the instruction and the ModR / M byte (bits called extension bits [5: 3]) are input to RNID_1OP752 on the bus 766. Yet another input line 768 to RNID_1OP, called data_SZ, indicates whether the operand size of the instruction is 16 bits or 32 bits. The data size is determined based on the memory protection configuration used and whether there is a prefix that invalidates the default data size. RNID_1OP assumes that the instruction has a 1-byte arithmetic code, and attempts to determine the length of the instruction based on that information and the extended 3 bits.

【0087】

The RNID_MOD decoder 756 decodes the Mod R / M byte instruction input on bus 770. The RNID_MOD decoder has another input bus 772 labeled ADD_SZ, which indicates whether the address size is 16 bits or 32 bits. The address size is independent of the data size.

【0088】

The ESC_DET signal 774 is also input to block 760. For example, if the ESC_DET signal is HIGH in logic, the RNID_SUM block knows that the arithmetic code is actually the second byte.

【0089】

The RNID_2OP decoder 754 assumes that the arithmetic code is 2 bytes and therefore decodes the 2nd byte of the arithmetic code (see Bus 776). The RNID_2OP decoder also has an input 768 that recognizes the data size.

【0090】

Since the decoder itself does not know the length of the operation code, that is, whether it is 1 byte or 2 bytes, and ModR / M bytes always follow the operation code, it is assumed that the operation code is 2 bytes, and the operation is 2 bytes. The second RNID_MOD decoder 758 is used to decode the bytes following the code (see Bus 778). The two RNID_MOD decoders are identical, but decode different bytes in the instruction stream.

【0091】

Furthermore, based on the ESC_DET signal 774, RNID_SUM760 selects the appropriate arithmetic code and ModR / Mbyte decoder output as well as the instruction length on bus 762. Output 764, labeled Over 8, indicates whether the instruction is at least 8 bytes. If the instruction length is 8 bytes or more, IR_NO [7: 0] bus 762 indicates the number of instruction bytes exceeding 8.

【0092】

The RNID_1OP decoder 752 has a 9-bit wide output bus 780. One line indicates whether the instruction is 1 byte long. The second line shows that the instruction is 1 byte long and there are ModR / M bytes, so the information from the ModR / M decoder should also be included to determine the length of the instruction. is there. Similarly, the remaining output lines on bus 780 indicate the number of bytes to: 2, 2 / MOD, 3, 3 / MOD, 4, 5, and 5 / MOD. If the instruction is 4 bytes long, then ModR / M bytes cannot exist. This is unique to the i486 instruction set. However, the present invention is not limited to a particular CISC type instruction set in any respect. One of ordinary skill in the art can apply the features of the present invention to align and decode any CISC type instruction set.

【0093】

The RNID_2OP decoder 754 has a 6-bit wide output bus 782. One line indicates whether the instruction is 1 byte long. The second line indicates whether the instruction is 1 byte long and contains ModR / M bytes, which should be included to determine the length of the instruction. Similarly, the remaining output lines of bus 782 indicate the presence of 2, 2 / MOD, 3, and 5 / MOD. If the arithmetic code is 2 bytes long, there is no other instruction length supported by the i486 instruction set.

【0094】

With the outputs 784 and 786 of the two decoders RNID_MOD756 and 758, RNID_SUM760 knows five possible additional lengths specified by ModR / M bytes. Each RNID_MOD decoder has a 5-bit wide output bus. The five possible additional lengths are 1, 2, 3, 5 and 6 bytes. The ModR / M bytes themselves are included to determine the overall length. The remaining bytes all consist of immediate or displacement data.

【0095】

Figure 8 shows a block diagram of IDDD326. IDDD326 determines the shift amount of IMM shifter 312 and DISP shifter 314. The shift amount is determined by the ModR / M bytes of the instruction.

【0096】

The i486 instruction set contains two special instructions: the enter_detect instruction and the jump_call_detect instruction. Therefore, IDDD326 has a block called Immediate Special Detector (ISD) 802 to decode these instructions. Input 803 to the ISD is the first byte of the instruction. The two output lines EN_DET and JMP_CL_DET (820 and 822) indicate that one of the corresponding instructions has been detected.

【0097】

The MOD_DEC decoders 804 and 806 are identical and decode the immediate and displacement data. Based on ADD_SZ772, the decoder 804 looks at ModR / M bytes assuming it is a 1-byte arithmetic code, and the decoder 806 looks at ModR / M bytes assuming it is 2 bytes. The instruction byte inputs to MOD_DEC804 and 805 are 805 and 807, respectively. These decoders determine the position of the displacement of the instruction stream and the position of the immediate data. Two 7-line outputs 824 and 826 indicate the starting position of displacement and immediate data. That is, the displacement starts at position 2 or 3, and the immediate data starts at position 2, 3, 4, 6 or 7.

【0098】

MOD_DET lines 707 and 714 are also input to selection block 812.

【0099】

The selection block 812 combines the EN_DET signal and the JMP_CL_DET signal, the MOD_DET result and the MOD_DEC result, and the ADD_SZ, and outputs the result on four buses 832 to 838. The displacement (DISP_1) bus 832 outputs the result of the displacement shift assuming that it is a 1-byte arithmetic code. The displacement 2 (DISP_2) bus 834 outputs the displacement shift result assuming that it is a 2-byte arithmetic code. Immediate 1 and 2 (IMM_1 and IMM_2) buses 836 and 838 output immediate data shift information assuming 1-byte and 2-byte arithmetic codes, respectively.

【0100】

The final block 814, labeled MOD_SEL / DLY, actually selects the appropriate shift amount and delays the result by half a cycle. The half-cycle delay performed by MOD_SEL / DLY816 represents the delay 316 shown in Figure 2. The ESC_DET signal 774 described above is used by the MOD_SEL / DLY block to make shift selection. The result is clocked from MOD_SEL / DLY814 by the clock signals CLK0 and CLK1 with a delay of half a cycle. Immediate data shift control signals and displacement shift control signals are sent to the DISP shifter and IMM shifter via shift_D [3: 0] bus 840 and shift_I [7: 0] bus 842, respectively. The number of possible positions of the immediate data and the displacement data in the CISC type instruction defines the number of bits required to specify the shift amount.

【0101】

The block diagram of the prefix detector 328 is as shown in FIG. The prefix detector 328 includes a prefix_number decoder (PRFX_NO) 902, four prefix_detector decoders (PRFX_DEC904 to 910) and a prefix_decoder (PRFX_SEL) 912.

【0102】

For example, the i486 instruction set contains 11 possible prefixes. Since there are several invalid prefix combinations, a total of four prefixes can be included per instruction. The order of the four prefixes is also defined by the instruction set. However, the prefix detector uses four prefix detectors 904-910 not only to detect only the correct prefix permutation, but rather to decode each of the first 4 bytes of the instruction. The first 4 bytes of the instruction are input to the prefix detector on bus 901. The detectors 904 to 910 each have a 12-bit wide output bus (905, 907, 909 and 911). If the prefix is actually decoded, you can tell which prefix exists from the 12 outputs. The twelfth prefix, called unlock, is a functional complement of the i486 lock prefix, but is only available for microcode routines in emulation mode.

【0103】

The alignment_RUN control signal 920 may be built in to enable / disable the prefix decoder and is used to mask out all prefixes. The HOLD_PRFX control signal 922 is used to latch and hold the prefix information. In general, for instruction alignment when the prefix detector 328 indicates the presence of a prefix, the control logic must latch the prefix information. The prefix information is then used by the alignment shifter 310 to shift out the prefix. In the next cycle, the IAU determines and aligns the instruction length and hands it over to the IDU.

【0104】

The PRFX_NO decoder 902 shows where and how much the prefix is by decoding the first 4 bytes of the arithmetic code. The logical diagram of the PRFX_NO decoder 902 is as shown in FIG. The PRFX_NO decoder has four identical decoders 1002-1008 and a set of logic gates 1010. Each of the four decoders 1002-1008 examines one of the first 4 bytes (1010-1013) to determine if the prefix is present. Since the prefix byte can follow the operation code byte, the logic gate 1010 is used to output the result indicating the total number of prefixes before the first operation code byte. This is because the prefix following the arithmetic code can only be applied to the arithmetic code of the next instruction.

【0105】

If the first byte (position) is a prefix and there is no prefix at the second position, the total number of prefixes is 1. As another example, if the prefix is not in the first 3 positions, the prefix in the 4th position is irrelevant. Logic HIGH (1) output from the bottom NAND gate 1014 indicates the existence of 4 prefixes, and HIGH output from the second NAND gate 1015 from the bottom indicates the existence of 3 prefixes. And so on. The outputs of the four NAND gates are combined to form the PREFIX_NO bus 1018, which represents the total number of valid prefixes that precede the first arithmetic code, that is, the shift amount output of the prefix detector 328.

【0106】

The PRFX_NO decoder 902 also includes the Prefix_Present (PRFX_P) output bus 1020 (also 4-bit wide). The four PRFX_P output lines 1020-1023 indicate whether or not there is a prefix at a particular position, regardless of what the output at other positions is. The PRFX_P output is taken directly from the outputs of the four decoders (1002-1008).

【0107】

The results of the PRFX_NO decoder (discussed in relation to FIG. 10) and the information from the PRFX_DEC detectors 904-910 are combined by the PRFX_SEL decoder 912. The prefix information is combined to form one 13-bit output bus 924, which indicates whether there is a prefix signal and which prefix is present.

【0108】

3.0 <u style="single">Outline of instruction decoding unit</u>All instructions are passed from the IAU to the instruction decoding unit (IDU) and converted directly into RISC-type instructions. Instructions executed by the IEU are first processed by the IDU. The IDU determines whether each instruction is an emulated instruction or a basic instruction. If emulated, a microcode emulation routine consisting entirely of basic instructions is processed. If it is a basic instruction, it is directly converted by hardware into 1 to 4 nanoinstructions and sent to the IEU. It is these and nano-instructions that the IEU actually executes, not the original CISC-type or microcode instructions.

【0109】

There are two main advantages to splitting instructions. The first is that the hardware is small because it only needs to support simple operations. The second is a complex microcode routine that is easy to change and is prone to bugs, so bugs are less of an annoyance.

【0110】

IDU's microcode routine-enabled hardware related to the present invention has some unique features. Microcode instructions consist of control bits for various data buses present in the processor, typically barely or completely unencoded. In contrast, the microcodes of the present invention are relatively high-level machine languages designed to emulate a particular set of complex instructions. Typical microcode is sent directly to the functional unit of the processor, whereas the microcode of the invention is processed by the same decoder logic used for the target CISC type (eg, 80x86) instruction. This makes the code density of the microcodes of the present invention much better than would be achieved with typical microcodes, and is similar to the target CISC type instruction set, making microcode development easier. become. Further, the present invention will be hardware-enabled for revision of microcode. That is, on-chip ROM-based microcode can be partially or entirely replaced by external RAM-based microcode by software control. (Simultaneous pending application for the same successor's application filed on December 6, 1991, US Application No. 07/802, 816, Refer to the title of the invention "ROM with RAM cell and cyclic redundancy check circuit", agent reference number SP024. The disclosure of the application is incorporated herein by reference. The microcode routine language is a set of instructions executed by the RISC core to perform various control and maintenance functions related to exception handling, in addition to the functions required for any emulated compound instruction. It is designed to be. Emulated instructions typically do not affect performance, such as unemulated (basic) instructions, and exceptions (handled by microcode routines) rarely occur, but nevertheless both. Efficient processing is very important to the overall system throughput. This goal is achieved by using hardware that supports various forms of microcode routines. The present invention comprises four areas of microcode-enabled hardware: dispatch logic, mailbox, nanoinstruction format, and special instructions.

【0111】

Microcode dispatch logic controls the efficient transfer of program control from the target CISC instruction stream to the microcode routine and back to the target instruction stream. It uses a small amount of hardware and is processed in a way that is invisible to the RISC-type core instruction execution unit (IEU). (IEU executes RISC-type instructions. The "RISC core" mentioned above is synonymous with IEU. Details about IEU are not necessary for those skilled in the art to carry out the present invention. The features of the present invention are RISC-type. Applicable to processors in general.) Mailboxes include a system of registers used to systematically transfer information from instruction decoding hardware to microcode routines. This allows the hardware to pass instruction operands and similar data to microcode routines, thus eliminating the task of extracting this data from instructions.

【0112】

The nanoinstruction format describes the information passed from IDU to IEU. This format has been chosen to ensure efficient extraction from the source CISC type instructions, but it provides the IEU with sufficient information for dependency checking and functional unit control.

【0113】

Finally, special instructions are an additional instruction set provided to give full control over RISC hardware and to handle hardware-specific emulation tasks, and are dedicated to CISC instruction sets.

【0114】

3.1 <u style="single">Microcode dispatch logic</u>The first step in dispatching to microcode is to determine the address of the microcode routine. There are two important requirements for this step. That is, each microcode routine has its own starting address, and those addresses must be generated at high speed. Is small caseload because hardly be selected between to and them can be stored if there is no hardware address as a constant, it can be realized routines fairly easily exception handling in this way. However, addressing an emulated instruction is more difficult because there are too many to store all the executable addresses.

【0115】

Microcode. Dispatch logic meets the requirement by directly base its arithmetic code on the dispatch address of each instruction. For example, a 1-byte arithmetic code is mapped from OH to the 1FFFH address space. In that case, the upper 3 bits of the 16-bit dispatch address must be zero. The entry points in these microcodes are 64 bytes apart, and the least significant 6 bits of each entry point address must be zero. This leaves 7 bits undecided, but can be taken directly from the 7 bits of the arithmetic code. As will be clear to those skilled in the art, address generation by this method requires little logic. For example, only multiplexers are used to select the proper bits from the arithmetic code.

【0116】

Once the dispatch address of the microcode routine is determined, the microcode must be fetched from memory. Typically, the microcode resides in on-chip ROM, but this is not always the case. As detailed in US Application No. 07 / 802,816 cited above, each entry point corresponds to a ROM invalid bit that indicates whether the ROM routine is correct or not. This bit is fetched in parallel with the ROM access and works like a traditional cache hit indicator. If this bit indicates that the ROM entry is valid, the microcode routine is fetched sequentially from ROM and executed normally. However, if the bit indicates that the ROM is invalid, the microcode will be fetched from an external memory such as RAM.

【0117】

The addressing of the on-chip microcode routine is done by the IDU itself. IDU generates a 16-bit address to access the microcode ROM. If the ROM invalid bit corresponding to the addressed ROM entry indicates that the microcode is invalid, the address of the external microcode that exists off-chip in main memory is calculated. The U_base register holds the upper 16 address bits (called the start address) of the external microcode existing in the main memory. The 16-bit address decoded by the IDU is concatenated with the upper 16 bits of the U_Base register to access the external microcode residing in main memory. If the storage location of the external microcode existing in the main memory is changed, the contents of the U_Base register can be modified to reflect the new storage location of the main memory.

【0118】

This feature allows microcode updates by replacing one routine with another in external memory without forcing all microcode to degrade external memory access. It will also be possible to reduce the area requirement of RISC chips and to remove all ROM from RISC chips and put the entire microcode in external RAM to assist in microcode development.

【0119】

It is also this dispatch logic that provides a means for the microcode routine to return to the main stream of instructions when the task is completed. A separate program counter (PC's) and instruction buffer are maintained for this process. During normal operation, the main PC determines the address of each CISC type instruction in the external memory. The section of memory containing these instructions is fetched by the IFU and stored in the MBUF.

【0120】

When an emulated instruction or exception is detected, the PC value and length of the current instruction is stored in a temporary buffer. On the other hand, the microcode dispatch address is calculated as described above, and the instruction is fetched from this address to EBUF. The microcode is executed from the EBUF until a microcode "return" instruction is detected. When the return instruction is detected, the spare PC value is reloaded, and execution is continued from MBUF. Since the MBUF and all other related registers are stored during the transfer of control to the microcode routine, the transfer of the return to the CISC type program occurs very fast.

【0121】

There are two return instructions used by microcode routines to address the differences between instruction emulation routines and exception handling routines. When a microcode routine is entered for exception handling, it is important that the processor returns to the very interrupted state after the routine finishes. However, when a microcode routine is entered to emulate an instruction, the routine wants to return to the instruction that follows the emulated instruction. Otherwise, the emulation routine will run a second time. These two functions are processed using two return instructions, namely aret and eret. The aret instruction returns the processor to that state if microcode has been input, while the eret instruction updates and controls the primary PC to return to the next instruction in the target stream.

【0122】

3.2 <u style="single">Mailbox</u>In order for the emulation routine to successfully function as a complex CISC instruction, the microcode needs to have easy access to the operands referenced by the emulated instruction. In the present invention, this is done by using four mailbox registers. These registers are unique in their use. That is, it is defined as the first four of the 16 temporary register sets in the integer register file that can be used in microcode. Each emulation routine that requires operands from the original instruction or other information should find these values stored in one or more mailbox registers as it enters the routine. When the IDU detects the emulated instruction, it generates the instruction used by the IEU to load the register with the value that the microcode expects, before the microcode routine itself starts executing.

【0123】

For example, consider the emulation of a Load Machine Status Word (lmsw) instruction that specifies one of the general purpose registers as an operand. Suppose the specific instruction to be emulated is lmswax, which loads a 16-bit state word from the "ax" register. The same microcode routine is used regardless of the register actually specified in the instruction, so the state word is loaded into mailbox # 0 before the microcode entry for this instruction. When the IDU detects this instruction, the IEU generates a moveu0 / ax instruction to move the state word from the "ax" register to the "u0" register, which is defined as mailbox # 0. After this mov instruction is sent to the IEU, the microcode routine is fetched and sent. Therefore, the microcode is written as if the emulated instruction was lmswu0 and handles all possible operands specified in the original CISC type instruction exactly.

【0124】

3.3 <u style="single">Nano instruction format</u>As mentioned above, CISC type instructions are decoded into nanoinstructions by IDU, and the processing is performed by a RISC type processor core called IEU. Nanoinstructions are passed from IDU to IEU in four groups called "buckets". One of the buckets is shown in Figure 11. Each bucket consists of two packets and general information about the entire bucket. Packet # 0 contains three nanoinstructions that are always executed in order. The three nanoinstructions are the load instruction 1102, the ALU type instruction 1104, and the storage instruction 1106. Packet # 1 consists of a single ALU type instruction 1108.

【0125】

The IEU can accept buckets from the IDU at one peak rate per cycle. The IDU processes basic instructions at two peak rates per cycle. Since most of the basic instructions are translated into a single packet, the two basic instructions are usually put together in a bucket and passed to the IEU. The biggest constraint on this rate is that the basic instructions must meet the requirements of the bucket. The requirements are as follows.

【0126】

Only one of the two basic instructions can reference a memory operand (only one load / store operation per bucket), and both instructions have a single ALU type operation (two ALU type operations). Must consist of (in contrast to one command required).

【0127】

If one or both of these constraints are not met, a bucket containing nanoinstructions that correspond to only one of the basic instructions will be sent to the IEU, and the remaining instructions will be sent later in another bucket. These constraints accurately reflect the capabilities of the IEU. That is, since the IEU has two ALUs and one load / storage unit, these requirements do not actually limit the performance. For an example of this type of IEU, US Patent Application No. 07 / 817.810, title of invention "High Performance RISC Microprocessor Architecture", pending applications of the same successor. Filed January 8, 1992 (agent reference number SPO15 / 1397.0280001), as well as US patent application number 07 / 817.809, invention title "Extensible RISC Microprocessor" Architecture) , filed January 8, 1992 (agent reference number SPO21 / 1397.0300001). These disclosures are incorporated herein by reference.

【0128】

3.4 <u style="single">Special command</u>There are many functions that must be performed by microcode routines that are difficult or inadequate to perform with general instructions. Furthermore, since the architecture of this RISC type processor is expanded compared to the conventional CISC type processor, specific functions are effective. However, such functions have no meaning to CISC-type processors and therefore cannot be executed using any combination of CISC-type instructions. At the same time, "special orders" were born from this situation.

【0129】

An example of the first category of special instructions is the extract_desc_base instruction. This instruction extracts various bit fields from the two microcode general purpose registers, concatenates them, and puts the result in a third general purpose register for use by the microcode. To perform the same operation without using this instruction, the microcode must perform some masking and shift operations, and it requires the use of additional registers to hold temporary values. .. Special instructions allow one instruction in a single cycle to perform the same function as it would be executed without the use of scratch registers.

【0130】

We have already mentioned two examples of the second category of special instructions. That is, two return instructions, aret and eret, used to terminate the microcode routine. These instructions are meaningful only in a microcode environment, so there is no equivalent instruction or instruction order in a CISC-type architecture. In this case, the special instruction was necessary not only for performance reasons but also for functional correction.

【0131】

Since special instructions can only be used in microcode routines, and the emulated instructions only occur in the target CISC-type instruction stream, the arithmetic code of the emulated instructions is in the microcode mode of the special instruction. Will be reused. Therefore, when one of these arithmetic codes occurs in the target CISC instruction stream, it only indicates that the microcode emulation routine for that instruction should be executed. However, when the same arithmetic code occurs in the microcode instruction stream, it has a completely different function as one of the special instructions. To accommodate this reuse of arithmetic codes, the IDU records the current state of the processor and decodes the instructions appropriately. This arithmetic code reuse is invisible to the IEU.

【0132】

The IDU decodes each CISC type instruction (eg, of the i486 instruction set) and converts each instruction into several RISC type processor nanoinstructions. As mentioned above, each instruction is converted from 0 to 4 nanoinstructions, depending on complexity and functionality. IDU decodes and converts two CISC type instructions at a rate of up to one cycle. The basic functions of IDU are summarized below. * Decode one CISC type instruction per half cycle. * Decode the 1st CISC type instruction in the 1st phase. * The decoded result of the 1st CISC type instruction is held as valid until the end of the 2nd phase. * Decode the 2nd CISC type instruction in the 2nd phase. * Combine the outputs of the two instructions, if possible in the third phase. * Output one bucket consisting of four nanoinstructions per cycle.

【0133】

3.5 <u style="single">Block diagram of the instruction decoding unit</u>The block diagram of IDU is as shown in FIG. Aligned instructions from the IAU reach the IDU on bus 1201 which is 32 bits wide ([31: 0] or 4 bytes). The aligned instructions are received by the instruction decoder 1202. IDU1202 only looks at the first 4 bytes of the aligned instruction to make a CISC to RISC conversion.

【0134】

The instruction decoder 1202 operates in one clock phase (half cycle). Aligned instructions pass through the decoder, and the decoded information exiting it is multiplexed and fetched into the half-cycle delay latch 1204 via bus 1203. Therefore, the decoded information will experience the same as a one-phase pipeline delay.

【0135】

After a half cycle delay, the decoded information is sent to MUX1206 over bus 1205 to determine the actual register code used. At this stage of decoding, the decoded information is formatted into nanoinstructions. The nanoinstruction is then latticed. Two complete nanoinstruction buckets are latched on a cycle-by-cycle basis. The latches of the two nanocommand buckets are shown graphically in the 1st IR bucket 1208 and the 2nd IR bucket 1210, respectively.

【0136】

IDU attempts to combine buckets 1208 and 1210 into a single bucket 1212. The control gate type 1214 performs the collective work. The IDU first examines the type of each nanoinstruction to determine if it is a connectable type. Either of the two latched instruction load (LD) operations can enter the LD storage location 1216 of the single bucket 1212, and which of the latched instruction store (ST) operations is in the single bucket ST storage location. Note that either A0 operation can enter A0 storage location 1220, and either A0 or A1 operation can enter A1 storage location 1222.

【0137】

IDU handles instructions as a whole. If IDU cannot pack two instructions into one bucket, it leaves one complete instruction behind. For example, if the 1st IR latch has only A0 operation and the 2nd IR latch contains all 4 operations, the IFU does not take A1 from the 2nd IR latch and merges with the A0 operation. The A0 operation is sent alone, and the set of operations of the 2nd IR latch is transferred to the 1st IR latch and sent on the next phase. During that period the 2nd IR latch will be reloaded. In other words, the actions stored in the 1st IR latch are always sent, and the actions stored in the 2nd IR latch are combined with the actions of the 1st IR latch if possible. In the unlikely event that the 1st and 2nd IRs cannot be combined, the previous IDU and IAU pipeline stages must wait. IDUs can merge the first and second IR latch operations in the following situations:

【0138】

1. Both use only A0, or 2. one uses only A0 and the other uses only A0, LD and ST. Combination logic can be easily designed to generate the control signals required for the control gate to merge the contents of the first and second IR latches.

【0139】

When the IDU identifies an instruction that belongs to a subset of instructions that require emulation, it enters emulation mode. When in embroidery mode, an embroidery mode control signal (EMUL_MODE) is sent to the IDU decoder. Direct decoding of CISC-type instructions is interrupted and the microcode routine corresponding to the identified instruction is sent to the IDU for decoding. When the microcode routine finishes emulating the subset instruction, the IDU decoder returns to basic mode to continue decoding CISC-type instructions. Basically, IDU treats basic CISC type instructions and microcode instructions in the same way. Only the interpretation of the arithmetic code changes.

【0140】

The Karnaugh maps of the default (basic) mode of the 1-byte and 2-byte arithmetic code instructions are shown in FIGS. 13 to 17. The numbers on the left and top of the Karnaugh map are arithmetic code bits. For example, a 1-byte arithmetic code with a hexOF code corresponds to the 1st row and 11th column, which is a "2-byte escape" instruction.

【0141】

The gray instruction box shaded in the Karnaugh maps of FIGS. 13 to 17 is the basic instruction, and the white box is the instruction that must be emulated.

【0142】

A block diagram of the IDU instruction decoder 1202 is shown in FIG. The instruction decoder 1202 contains multiple decoders used to decode CISC-type instructions and microcode routines.

【0143】

The Type Generator (TYPE_GEN) decoder 1402 receives the first fully aligned instruction on the aligned_IR bus and decodes the instructions one by one to identify the type field of the instruction.

【0144】

The identified type fields correspond to the nanoinstruction behavior described above in relation to the IDU. The type is represented by a 4-bit field that represents each action (load, ALU0, store, ALU1) in the bucket. The TYPE_GEN decoder 1402 specifies which of these four actions is required for instruction execution. Depending on the instruction received, any number from 1 to 4 of the instruction is required to satisfy the CISC type instruction.

【0145】

For example, the addition operation, which sums the contents of one register with the contents of another register, only needs to execute the ALU nanoinstruction once. On the other hand, for an instruction that requires the contents of a register and the contents of a storage location to be added, three nanoinstruction operations are required, including a load and ALU operation and then a storage operation. (Data must be read from memory, added to registers, and stored in memory.) More complex CISC-type instructions require all four nanoinstructions.

【0146】

The TYPE_GEN decoder 1402 has three type decoders. The first decoder type 1 assumes that the instruction has a 1-byte arithmetic code before ModR / M bytes, and calculates the type based on that assumption. The second decoder type 2 assumes that the instruction has a 2-byte arithmetic code. The first byte is the escape byte, which comes before the second byte, which is the arithmetic code, and the third byte, which is the ModR / M byte. The third decoder type F assumes that the instruction is a floating point instruction and decodes the instruction based on that assumption.

【0147】

The TYPE_GEN decoder has three 4-bit wide type instruction output buses (type 1, type 2, type F). Each bit corresponds to one of the four nanoinstructive actions in the bucket. A particular type field specifies which nanoinstructions are needed to execute a CISC type instruction. For example, if all 4 bits are HIGH for logic, a CISC type instruction requires one load and one store operation and two ALU operations.

【0148】

The rest of the decoders in Figure 18, which include sections labeled 1, 2, and F, decode by assuming they are 1-byte math code, 2-byte math code, and floating-point instructions, respectively. Invalid results are rarely selected. The multiplexer selects the correct decoder output.

【0149】

Each of the two ALU operations (ALU0 and ALU1) has an 11-bit long arithmetic code field. The 11 bits consist of 8 bits of arithmetic code and 3 arithmetic code extension bits from adjacent ModR / M bytes. In most CISC-type instructions processed by IDU, the arithmetic code bits are copied directly to the nanoinstruction operation. However, some CISC-type instructions require replacement of arithmetic codes. In this case, IDU devices rarely filter CISC-type arithmetic code into instruction execution units (IEUs). This will be apparent to those skilled in the art as the type and number of functional units within the IEU will determine whether replacement of the arithmetic code within the IDU is necessary for a particular CISC type instruction.

【0150】

In order for the IEU to process an ALU operation, it must receive information about which functional unit is required to process the specified ALU operation. Therefore, the IDU includes a functional zero unit (F 0 UNIT) decoder 1410 consisting of three decoders, F_0UNIT1, F_0UNIT2, and F_0UNITF. The output of the decoder is a multi-byte field that represents which functional unit is needed to handle the A0 ALU operation. The functional units that decode for the ALU operation of the A1 are the same, but are handled by a separate decoder, the F_1 unit 1412.

【0151】

CISC-type instructions often perform operations using registers implied by arithmetic codes. For example, many instructions imply that AX registers should be used as accumulators. Therefore, a constant generator (CST_GEN) decoder 1414 is included to generate a register index based on the arithmetic code of the CISC instruction. The CST_GEN decoder reveals which registers are implied based on a particular arithmetic code. The multiplexing to generate the correct source of nanoinstructions and the destination register index will be described below in the context of FIG.

【0152】

An additional 2-bit control signal, TempCount (TC), is input to the CST_GEN decoder. The TC control signal is a 2-bit counter that represents four temporary registers that are circulated for use by the IEU as dummy registers. The temporary (or dummy) register indicates, in addition to the implied register, another value of the register inherited from the CST GEN decoder. Since there are two ALU operations with two registers for each operation, the constant generator / decoder passes four constant fields. Since each constant register bus is 20 bits wide and each constant is 5 bits in total, one of the 32 registers in the IEU can be selected.

【0153】

Next, the selection generator (SEL) roughly shown in block 1416.<u style="single"></u>GEN) The decoder will be described. The SEL_GEN decoder includes a flag request change (FG_NM) decoder 1418. The FG_NM decoder decodes for 1-byte arithmetic code, 2-byte arithmetic code, and floating-point instructions. For example, the i486 instruction set has a total of 6 flags. Flags may be changed by the instruction, but these flags must be in effect before the instruction starts executing. The FG_NM decoder outputs two signals for each flag. One bit indicates whether a flag is needed to execute this instruction, and the other bit indicates whether this instruction actually changes the flag.

【0154】

Register invalid information about the operation of ALU0 and ALU1 is decoded by the INVD1 and INVD2 decoders represented by 1420 and 1422, respectively. The INVD1 and INVD2 decoders are also part of the SEL_GEN decoder 1416. The INVD1 and INVD2 decoders generate control signals for the IEU. These signals indicate whether the ALU register should be used. Three possible register indexes are specified by each ALU operation. One is used as a source and / or destination register, and the other two are limited to source register specifications only. A 4-bit field is used to specify which registers are required for operation.

【0155】

The SEL_GEN decoder 1416 also includes an FLD_CNT decoder 1424 that indicates which of the register fields is required for CISC instructions. The FLD_CNT decoder specifies which of the two fields is the source register and which is the destination register.

【0156】

The nanoinstruction generator (NIR_GEN) decoder is roughly as shown as block 1426. The data size (DATA_SZ) and address size (ADDR_SZ) input control signals correspond to the default state in which the system is operating. In order to decode the final address as well as the size of the operands, the default mode must be known, and the existence of the prefix (discussed earlier in relation to the IAU) must also be known. The EMUL_MODE control signal is input to the NIR_GEN decoder, but is also used by other decoders.

【0157】

The escape detection (ESC_DET) input control signal is sent to the NIR_GEN decoder to indicate whether the instruction has a 2-byte arithmetic code. In addition, the Selective Code Extension (SEL_OP_EXT) input control signal is used to cause mailbox register loading when an emulation instruction is detected.

【0158】

Floating-point register (FP_REG) The input control signal passes the converted floating-point register index to the IDU. For example, the i486 floating point format has eight registers for floating point numbers, which are accessed like a stack. You can access these registers using the stack access method, that is, register 0 is at the top of the stack, register 1 is second from the top, and so on. This register stack is emulated by using eight linear registers with fixed indexes. If the input instruction specifies register 0, the conversion block (not shown) converts the stack-related register index to a register index for linear registers in a well-known manner. This allows the IDU to record which registers are at the top of the stack.

【0159】

When the system branches into emulation mode, the IDU stores information about the emulated instructions. The IDU stores the instruction data size (EM_DSIZE) and address size (EM_ASIZE) in addition to the destination register index (EM_RDEST), source (EM_RDEST2), and base index information (EM_BSIDX). This stored information is used by microcode routines to properly emulate instructions. For example, consider the emulation of an addition instruction. Microcode routines may check EM_ASIZE to determine the address size of the add instruction to know which address size to emulate.

【0160】

The NIR_GEN decoder 1426 includes a size decoder 1428. The fields generated by the SIZE decoder (ie, SIZE1, SIZE2, SIZEF) represent the instruction address size, operand size, and immediate data size. A 16-bit or 32-bit address size, an 8-bit, 16-bit, or 32-bit operand size, and an 8-bit, 16-bit, or 32-bit immediate data field size are extracted for each instruction.

【0161】

Another NIR_GEN decoder is called the load information (LD_INF) decoder 1430. The LD_INF decoder decodes the information corresponding to the load and store operations. Load information is used to perform effective address calculations. Since CISC instruction sets usually support many different addressing modes, the load information fields (LD_INF1, LD_INF2, LD_INFF) are used to specify which addressing mode is used by the CISC instruction. ..

【0162】

The i486's basic addressing mode includes segment fields and offsets that are added together to determine the address. In addition to the scale of the index register (for example, if the index register is an element in the array), the index register can be specified, and the element can be specified as 1, 2, 4, or 8 bytes in length. Therefore, the index register can be standardized by 1, 2, 4, or 8 before the index register is added to determine the address. The base and index can also be specified in the LD_INF field.

【0163】

The nanoinstruction arithmetic code (NIR_OPC) decoder 1432 transfers the arithmetic code for A1 operation (packet 1). The decoded fields (NIR_OPC1, NIR_OPC2, NIR_OPCF) consist of the first instruction byte (8 bits) and three extension bits from the second byte.

【0164】

Miscellaneous Code (MISC_OPC) Decoder 1434 indicates whether the instruction is floating point and whether the load instruction actually exists. The fields generated by the MISC_OPC decoder will indicate if the floating data needs to be converted. This decoder does not need to be multiplexed because this information is easily extracted regardless of the instruction format.

【0165】

The arithmetic code for A0 operation of packet 0 is specified by the arithmetic code decoder 1436. The A0 math code is usually copied directly from the i486's input math code, but some instructions may replace the math code with another math code. (As mentioned above, the functionality of the signal generated by the NIR_GEN decoder is specific to the CISC type instruction set being decoded, so it will be apparent to those skilled in the art to consider the CISC type instruction set and the nanoinstruction format of the present invention. The EXT_CODE decoder 1440 extracts a 3-bit optocode extension from ModR / M bytes.

【0166】

The IN_ORDER decoder 1442 decodes an instruction to determine if the instruction must be executed "in order". This instructs the IEU to do nothing to this instruction until the end of execution of all preceding instructions. Once the instruction execution is complete, the subsequent instruction execution begins.

【0167】

The control flow jump size decoder 1444 represents the displacement size of the addressing jump. Labeled CF_JV_SIZE, this field specifies the address size of the jump. This is specific to the type of addressing scheme used for CISC instruction sets.

【0168】

A 1-bit decoder labeled DEC_MDEST1446 indicates whether the instruction destination is a memory address or not.

【0169】

Finally, the instruction decoder includes three register code decoders 1438 for register code (index) selection. The i486 instruction format encodes the index of register fields at various locations within the instruction. The indexes of these fields are extracted by the RC decoder. ModR / M bytes also have two register indexes, which are used as the destination / source specified by the arithmetic code itself. The register code decoder 1438 generates three RC fields, RC1, RC2, and RC3. If the processor is not in emulation mode, RC1 and RC2 are extracted from the ModR / M bytes as follows, and the instruction is not a floating point instruction. That is, RC1 = ModR / M-byte bits [2: 0], RC2 = ModR / M-byte bits [5: 3], and RC3 = arithmetic code bits [2: 0]. For floating-point instructions in basic (non-embroidery) mode, RC1, RC2, and RC3 are assigned as follows:

【0170】

RC1: ST (0) = top of the stack RC2: ST (1) = second item on the stack = second from the top of the stack RC3: ST (i) = i-th item from the stack, where i is specified in the operation code. In emulation mode, RC1, RC2, and RC3 are assigned as follows:

【0171】

RC1: Byte 3 bit [4: 0] RC2: Byte 2 bit [1: 0] and Byte 3 bit [7: 5] RC3: Byte 2 bit [6: 1] Figure 19 shows CST_GEN, NIR_GEN, It represents a typical block and logic gate diagram of each decoder (1414, 1438, 1424) of SEL_GEN. Figure 19 shows 1-byte math code, 2-byte math code, and floating to generate the source and destination register indexes for nanoinstruction operations A0 and A1, as well as the destination register index for load instructions. It should be understood as an example showing how the decoded results of the decimal points are selected, delayed, and further combined. Selection, delay, and multiplexing techniques apply to all signals generated by the instruction decoder 1202, except signals that do not produce 1-byte arithmetic code, 2-byte arithmetic code, and floating-point results individually. .. Further, in other words, the results produced by this embodiment are application-specific and apply to decoding i486 instructions into the nanoinstruction format of the present invention. However, the principles described so far through these examples are generally applicable to CISC-to-RISC instruction alignment and decoding.

【0172】

As explained earlier, the CST_GEN decoder 1414 produces three outputs, CST1, CST2 and CSTF, each of which consists of four constant 5-bit register fields (20 bits in total). SEL_GEN generates register field control signals (FLD1, FLD2, FLD3) for the selection of the multiplexer in the further part MUX1512. The selection of CST1, CST2 or CSTF results and FLD1, FLD2, and FLDF results is largely as shown in multiplexer block 1502. The 3-bit MUX select line 1504 is used to select the result depending on whether the instruction has a 1-byte math code, a 2-byte math code, or a floating point instruction.

【0173】

The Ω cycle pipeline delay latch 1506 is used to delay the results selected by the multiplexer 1502 and RC1, RC2, RC3 in the three register control fields. Each input to the Ω pipeline delay latch 1504 is sent to a pair of opposed clocked latches 1508. The contents of this latch are selected by the multiplexer 1510. This sequence is similar to the Ω cycle data delay 316 described earlier in relation to the IAU.

【0174】

Further multiplexing stages are as shown in block 1512. The constant register fields selected by the multiplexer 1502 are input to the multiplexer 1512 as four separate fields labeled individually from repc1 to repc4, as shown roughly in 1514. Also shown as inputs to block 1512 are the arithmetic code and the register fields extracted from ModR / M bytes, RC1, RC2 and RC3. FLD to generate the source and destination register indexes a1_rd and a1_rs for operation A1 generally shown in 1518, as well as the source and destination register indexes a0_rd and a0_rs for operation A0 shown in approximately 1516. The register and RC fields are combined by the logic of block 1512 under the control of the control signal 1520. Index 1d_rd, the destination register index of the load instruction, is also selected in block 1512.

【0175】

4.0 <u style="single">Decoded instruction FIFO</u>The block diagram of the decode FIFO (DFIFO) in the present invention is as shown in FIG. 20A. The DFIFO holds four complete buckets, each containing one nanoinstruction, two immediate data fields, and one displacement field. Each bucket corresponds to a DFIFO one-level pipeline register. These buckets are generated by IDU and pushed to DFIFO during each cycle when the IEU requests a new bucket. The nanoinstructions in the bucket are divided into two groups called packet 0 and packet 1. Packet 0 consists of load, ALU, and / or store operations, which correspond to 1, 2, or 3 nanoinstructions. Packet 1 has only ALU operation equivalent to 1 nanoinstruction. As a result of this split, one bucket contains only two ALU operations, only one of which can reference memory. If subsequent instructions both require memory operands, they must be placed in separate buckets.

【0176】

As can be seen from Figure 20B, there is only a fair amount of general information about each packet and the entire bucket. This information is stored in the general information FIFO. By default, four nanoinstructions in a bucket are executed in the order NIR0 to NIR3. NIR3 can be set to one of the general information bits of the bucket to indicate that it must be executed before NIR0 ~ NIR2. This feature makes it easy to combine consecutive instructions into a single bucket. This is because the order no longer affects the ability to meet bucket requirements.

【0177】

Figure 20C shows the immediate data and displacement FIFO of buckets 0 through 4. IMM0 represents the immediate data corresponding to packet 0, and IMM1 represents the immediate data corresponding to packet 1. DISP represents the displacement corresponding to packet 0. Packet 1 does not use DISP information because the DISP field is only used as part of the address calculation.

【0178】

Specific examples of the above three types of nanoinstructions are shown in FIG. These tables provide information about the contents of each bucket.

【0179】

Although various examples based on the present invention have been described above, it should be understood that they are presented as examples only and are not limited thereto. Therefore, the scope and scope of the present invention should not be limited by the above examples, but should be defined only according to the claims and their equivalents.

[Simple explanation of drawings]

FIG. 1 is a block diagram of an instruction prefetch buffer of the present invention.

FIG. 2 is a block diagram of the instruction alignment unit of the present invention.

FIG. 3 is a typical flowchart showing an IAU instruction extraction and alignment method of the present invention.

4 is a simplified timing diagram related to the block diagram of FIG. 2 and the flowchart of FIG.

FIG. 5 is a block diagram of STACK of the present invention.

FIG. 6 is a block diagram of the next command detector (NID) of the present invention.

FIG. 7 is a block diagram of the residual next command detector (RNID) of the present invention.

FIG. 8 is a block diagram of the immediate data and displacement detector (IDDD) of the present invention.

FIG. 9 is a block diagram of the prefix detector (PD) of the present invention.

FIG. 10 is a block diagram of the number of prefixes (PRFX_NO) decoder of the present invention.

FIG. 11 is a block diagram of the nanocommand bucket of the present invention.

FIG. 12 is a typical block diagram of the instruction decoding unit (IDU) of the present invention.

FIG. 13 is a diagram showing an instruction bitmap of the present invention.

FIG. 14 is a diagram showing an instruction bitmap of the present invention.

FIG. 15 is a diagram showing an instruction bitmap of the present invention.

FIG. 16 is a diagram showing an instruction bitmap of the present invention.

FIG. 17 is a diagram showing an instruction bitmap of the present invention.

FIG. 18 is a block diagram showing an example of a section of the IDDD instruction decoder of the present invention.

FIG. 19 is a typical block and logic diagram of the decoder type of the instruction decoder shown in FIG.

FIG. 20 is a conceptual block diagram of the decoding FIFO of the present invention.

FIG. 21 shows an example of a field format for nanoinstructions of the present invention.

FIG. 22 is a diagram showing a data structure format of a conventional CISC type instruction.