INSTRUCTION DECODER INCLUDING TWO-WAY EMULATION CODE BRANCHING

Abstract: An instruction decoder (220) includes an emulation code sequencer (510) and emulation code ROM (520) for handling various instructions. The emulation code ROM includes a sequence of operations (Op) and an operation sequencing control code (OpSeq). Branch instructions such as conditional branch instructions may be encoded into the emulation code ROM so that a second branch, in combination with the branching operation controlled by the OpSeq code, is applied to an operation code sequence. Two-way branching permits flexible branching to locations within the emulation code ROM so that memory capacity is conserved. A superscalar microprocessor (120) includes an instruction decoder having an emulation code control circuit and an emulation ROM which emulates the function of a logic instruction decoder. The emulation code ROM is arranged as a matrix of multiple-operation (Op) units with each multiple-Op unit including a control field that points to a next location in the emulation code ROM. In one embodiment, the emulation code ROM is arranged to include a plurality of four-Op units, called Op quads, with each Op quad including a sequencing control field, called an OpSeq field.

Description: INSTRUCTION DECODER INCLUDING TWO-WAY EMULATION CODE BRANCHING TECHNICAL FIELD This invention relates to processors. More specifically, this invention relates to processors having an instruction decoder including an emulation ROM for emulating decoder logic. BACKGROUND ART Advanced microprocessors, such as P6-class 86 processors, are defined by a common set of features. These features mclude a superscalar architecture and performance, decoding of multiple x86 instructions per cycle and conversion of the multiple x86 instmctions mto RISC-like operations. The RISC-like operations are executed out-of-order in a RISC-type core that is decoupled from decoding. These advanced microprocessors support large instruction windows for reordering instructions and for reordering memory references. Performance of an advanced superscalar microprocessor is highly dependent upon decoding performance mcludmg decoding speed, the number of x86 mstructions decoded m a smgle cycle, and branch prediction performance and handling. Instruction decoders m advanced superscalar microprocessors often include one or more decoding pathways m which x86 instmctions are decoded by hardware logic translation and a separate decoding pathway which uses a ROM memory for fetching a RISC operation sequence that corresponds to an x86 instruction. Generally, x86 instructions that are translated by hardware logic are simple 86 instmctions. The lookup ROM is used to decode more complex x86 instmctions. One problem with usage of a lookup ROM for decoding instmctions is the overhead incurred m determimng a ROM vector or entry pomt address and retrieving operations (Ops) from ROM. This overhead typically causes a penalty in decoder throughput for mstructions that are decoded usmg the ROM. This throughput penalty lowers decoding performance. A second problem with the usage of a lookup ROM for decoding x86 mstmctions is the existence of a large number of different CISC-type mstmctions that are standard for an x86 processor. Since a substantial number of instmctions are implemented, a large ROM circuit on the processor chip is necessary. Furthermore, the lookup ROM typically has only a few defmed entry pomts and the vanous x86 mstmctions translate to Op sequences ROM havmg varying numbers of constituent Ops so that tbe sequences do not fit precisely between entry pomts without leavmg distributed unused ROM locations. The existence of unused lookup ROM locations further expands the large size of the lookup ROM, mcreasmg tbe size of the processor integrated circuit and thereby reducing manufacturing yields of the circuits and mcreasmg production costs. What is needed is a reduced-size and reduced-complexity ROM -based decoder m a superscalar instruction decoder. DISCLOSURE OF THE INVENTION In accordance with the present mvention, an instmction decoder mcludes an emulation code sequencer and emulation code ROM for handling various instructions. The emulation code ROM mcludes an a w ψψrικ of operations (Op) and an operation sequencing control code (OpSeq). Branch instmctions such as conditional branch instructions may be encoded mto the emulation code ROM so that a second branch, m combination with the branching operation controlled by the OpSeq code, is applied to an operation code sequence. Two-way branching permits flexible branching to locations withm the emulation code ROM so that memory capacity is conserved. In accordance with the present mvention, a superscalar microprocessor mcludes an instruction decoder havmg an emulation code control circuit and an emulation ROM which emulates the function of a logic instmction decoder. The emulation code ROM is arranged as a matnx of multiple-operation (multiple-Op) units with each multiple-Op unit mcludmg a control field that pomts to a next location in the emulation code ROM. In one embodiment, the emulation code ROM is arranged to mclude a plurality of four-Op units, called Op quads, with each Op quad mcludmg a sequencing control field, called an OpSeq field. In accordance with the present mvention, an mstruction decoder m a superscalar processor mcludes an emulation sequencer havmg a first mput terminal for receivmg an entry pomt signal, a second mput teπmnal and an output terminal for producmg an addressmg signal. The instmction decoder also mcludes an emulation ROM havmg an mput terminal connected to the emulation sequencer output terminal, a sequencing signal output terminal connected to the emulation sequencer second mput terminal for producmg a sequencmg signal, and an operation (Op) output terminal for generating one or many output Ops. The emulation ROM mcludes a plurality of Operation (Op) units, each Op unit mcludmg a fixed-number plurality of Ops and a sequencmg control information for designating a next Op or Op unit address withm the emulation ROM for subsequent execution. The emulation ROM is addressed terms of Op units, but branching is performed to a starting Op m a selected Op unit. The sequencmg control information is applied to the emulation sequencer second terminal to control sequencmg order by the emulation sequencer. Many advantages are gamed by the descnbed decoder The OpSeq field is used to efficiently fit Op sequences mto nonused locations in the emulation code ROM, substantially reducing the size of emulation code ROM and advantageously reducing the size and cost of a processor integrated circuit. The OpSeq field achieves unconditional branching to a target address without incurring a time or cycle penalty. Branching is performed to any designated Op unit so that holes in the emulation code ROM are readily filled. BRIEF DESCRIPTION OF THE DRAWINGS The features of the mvention believed to be novel are specifically set forth the appended claims. However, the mvention itself, both as to its structure and method of operation, may oest be understood by referring to the followmg descπption and accompanying drawmgs. Figure 1 is a block diagram which illustrates a computer system m accordance with one embodiment of the present mvention. Figure 2 is a block diagram illustrating one embodiment ot processor for usage in me computer svstem shown Figure 1. Figure 3 is a timing diagram which illustrates pipeline timing for an embodiment of the processor shown Figure 2. Figure 4 is a schematic block diagram showing an embodiment of an instmction decoder used m the processor shown Figure 2. Figure 5 is a schematic block diagram which depicts a structure of an emulation code sequencer and an emulation code memory of the instruction decoder shown in Figure 4. Figures 6A ---rough 6E are pictonal illustrations snowing a plurality of operation (Op) formats generated by the instmction decoder shown m Figure 4. Figure 7 is a pictonal depiction of an OpSeq field format employed the emulation code memory shown in Figure 5. Figure 8 is a block diagram of a personal computer incorporating a processor havmg an instmction decoder which implements two-way emulation code branciung accordance with an embodiment of the present mvention. MODEfS) FOR CARRYING OUT THE INVENTION Referring to Figure 1, a computer system 100 is used a vanety of applications, mcludmg a personal computer application. The computer system 100 mcludes a computer motherboard 110 contaimng a processor 120 accordance with an embodiment of the mvention. Processor 120 is a monolithic integrated circuit which executes a complex instruction set so that tbe processor 120 may be termed a complex instmction set computer (CISC). Examples of complex mstruction sets are the x86 instmcuon sets implemented on the well known 8086 family of microprocessors. The processor 120 is connected to a level 2 (L2) cache 122. a memory controller 124 and local bus controllers 126 and 128. The memory controller 124 is connected to a mam memory 130 so that the memory controller 124 forms an interface between the processor 120 and the mam memory 130. The local bus controllers 126 and 128 are connected to buses mcludmg a PCI bus 132 and an ISA bus 134 so that the local bus controllers 126 and 128 form interfaces between the PCI bus 132 and the ISA bus 134. Referring to Figure 2. a block diagram of an embodiment of processor 120 is shown. The core of the processor 120 is a RISC superscalar processmg engme. Common x86 mstmctions are converted by instmcuon decode hardware to operations an internal RISC86 instruction set. Other x86 mstmctions. exception processmg, and other miscellaneous functionality is implemented as RISC86 operation sequences stored on- chip ROM. Processor 120 bas interfaces mcludmg a system interface 210 and an L2 cache control logic 212. The system interface 210 connects the processor 120 to other blocks of the computer system 100. The processor 120 accesses the address space of the computer system 100, mcludmg the mam memory 130 and devices on local buses 132 and 134 by read and wnte accesses via the system interface 210. The L2 cache control logic 212 forms an interlace between an external cache, such as the L2 cache 122, and the processor 120. Specifically, the L2 cacne control logic 212 interlaces the L2 cache 122 ana to an instruction cache 214 and a data cache 216 m the processor 120. The instruction cache 214 and the data cache 216 are level 1 (Ll) caches which are connected through the L2 cache 122 to the address space of the computer system 100. Instructions from mam memory 130 are loaded mto instmcuon cache 214 via a predecoder 270 for anticipated execution. The predecoder 270 generates predecode bits that are stored m combinauon with instruction bits m the instmcuon cache 214. The predecode bits, for example 3 bits, are fetched along with an associated instrucuon byte (8 bits) and used to facilitate multiple instmction decodmg and reduce decode tune. Instruction bytes are loaded mto instrucuon cache 214 thirty-two bytes at a tune as a burst transfer of four eight- byte quantities. Logic of the predecoder 270 is replicated eight tunes for usage four times m a cache lme so that predecode bits for all eight instmction bytes are calculated simultaneously immediately before bemg wπtten mto the instruction cache 214. A predecode operation on a byte typically is based on information in one. two or three bytes so that predecode mformauon may extend beyond an eight-byte group. Accordmgly, the latter two bytes of an eight-byte group are saved for processmg with the next eight-byte group in case of predecode mformauon that overlaps two eight-byte groups. Instructions in instruction cache 214 are CISC instmctions, referred to as macroinstmctions. An instmction decoder 220 converts CISC lnstmcuons from instmction cache 214 mto operations of a reduced instmction set computmg (RISC) architecture instruction set for execution on an execution engme 222. A smgle macroinstniction from instruction cache 214 decodes mto one or multiple operations for execution engme 222. Instruction decoder 220 has interface connections to the instmcuon cache 214 and an instmction fetch control circuit 218 (as shown Figure 4). Instmction decoder 220 mcludes a macrou-stmction decoder 230 for decodmg most macroinstmctions, an instmcuon decoder emulation circuit 231 mcludmg an emulation ROM 232 for decodmg a subset of instmctions such as complex instmctions, and a branch unit 234 for branch predicUon and handling. Macroinstmctions are classified accordmg to the general type of operations mto which the macroinstmctions are converted. The general types of operations are register operations (RegOps), load-store operations (LdStOps), load immediate value operations (LIMMOps), special operations (SpecOps) and floating pomt operations (FpOps). Execution engme 222 has a scheduler 260 and six execution units mcludmg a load unit 240. a store unit 242, a first register unit 244, a second register unit 246, a floating pomt unit 248 and a multimedia unit 250. The scheduler 260 distnbutes operations to appropnate execution units and the execution units operate parallel. Each execution unit executes a particular type of operation, ln particular, the load unit 240 and the store unit 242 respectively load (read) data or store (wnte) data to the data cache 216 (Ll data cache), the L2 cache 122 and the mam memory 130 while executing a load/store operation (LdStOp). A store queue 262 temporaπly stores data rrom store unit 242 so that store unit 242 and load unit 240 operate parallel without conflicting accesses to data cache 216. Register units 244 and 246 execute register operations (RegOps) for accessing a register file 290. Floating pomt unit 248 executes floating pomt operations (FpOps). Multimedia unit 250 executes anthmetic operations for mulumedia apphcauons. Scheduler 260 is partitioned mto a plurality of, for example, 24 entnes where each entry contains storage and logic. The 24 entnes are grouped mto six groups of four entnes. called Op quads. Informauon in the storage ot an entrv descnoes an operation for execution, whether or not the execution is pending or completed. The scheduler monitors the entnes and dispatches informauon from the entnes to lnfoπnaUon- rie-πgnafcid execuuon units. Refemng to Figure 3, processor 120 employs five and six stage basic pipeline ming. Instmcuon decoder 220 decodes two u-stn-cuons a smgle clock cycle. Dunng a first stage 310, the instmcuon fetch control circuit 218 fetches CISC instructions mto instruction cache 214. Predecoding of the CISC -nstn-cuons dunng stage 310 reduces subsequent decode time. Duπng a second stage 320, instmction decoder 220 decodes instπicuo-is from instmcuon cache 214 and loads an Op quad mto scheduler 260. Duπng a third stage 330, scheduler 260 scans the entnes and issues operauons to correspondmg execuuon units 240 to 252 if an operation for the respective types of execution units is available. Operands for the operauons issued dunng stage 330 are forwarded to the execution units m a fourth stage 340. For a RegOp, the operation generally coπφletes m the next clock cycle which is stage 350. but LdStOps require more time for address calculation 352, data access and transfer of the results 362. For branch operations, instmcuon decoder 220 performs a branch prediction 324 dunng an initial decodmg of a branch operation. A branch unit 252 evaluates conditions for the branch at a later stage 364 to determine whether the branch predicUon 324 was correct. A two level branch prediction algonthm predicts a direction of conditional branciung. and fetching CISC instructions m stage 310 and decodmg the CISC instructions in stage 320 continues m the predicted branch direcuon. Scheduler 260 determines when all condiUon codes required for branch evaluation are valid, and directs the branch unit 252 to evaluate the branch instruction. If a branch was incorrectly predicted, operations m the scheduler 260 which should not be executed are flushed and decoder 220 begins loading new Op quads from the correct address after the branch. A time penalty is incurred as mstmctions for the correct branciung are fetched. Instmction decoder 220 either reads a previously-stored predicted address or calculates an address usmg a set of parallel adders. If a previously- predicted address is stored, the predicted address is fetched stage 326 and instmctions located at the predicted address are fetched stage 328 without a delay for adders. Otherwise, parallel adders calculate the predicted address. In branch evaluation stage 364, branch unit 252 determines whether the predicted branch direction is correct. If a predicted branch is correct, the fetching, decodmg, and instruction-executing steps continue without interruption. For an incorrect prediction, scheduler 260 is flushed and mstmction decoder 220 begins decodmg π-acroinstructions from the correct program counter subsequent to the branch. Referring to Figure 4, a schematic block diagram illustrates an embodiment of an instmction preparation circuit 400 which is connected to the mam memory 130. The instmction preparation circuit 400 includes the instrucuon cache 214 that is connected to the mam memory 130 via the predecoder 270 The instmction decoder 220 is connected to receive instrucuon bytes and predecode bits from three altemauve sources, tbe instruction cache 214, a branch target buffer (BTB) 456 and an instmction buffer 408. The instmction bytes and predecode bits are supphed to the instruction decoder 220 through a plurality of rotators 430, 432 and 434 via instmction registers 450, 452 and 454. The macro-ns-π-ction decoder 230 has mput connections to the instruction cache 214 ana instmc on fetch control circuit 218 for receivmg instmcuon bvtes and associated predecode mformauon. Toe macroinstrucuon decoder 230 buffers letcneα instmcuon bvtes in an instmcuon buffer 408 connected to the instruction fetch control circuit 218. The instmcuon buffer 408 is a sixteen byte buffer which receives and buffers up to 16 bytes or four aligned words from the instrucuon cache 214, loading as much dau as allowed by the amount of free space m the instmcuon buffer 408. The instmcuon buffer 408 holds the next instrucuon bytes to be decoded and continuously reloads with new instmction bytes as old ones are processed by the macromstmcuon decoder 230. Instmctions m both the instmcuon cache 214 and the instmction buffer 408 are held m "extended" bytes, contaimng both memory bits (8) and predecode bits (5), and are held m the same alignment. The predecode bits assist the macromstmcuon decoder 230 to perform multiple instmcuon decodes within a smgle clock cycle. Instmction bytes addressed usmg a decode program counter (PC) 420, 422, or 424 are transferred from the mstmcuon buffer 408 to the macroinstmction decoder 230. The instmction buffer 408 is accessed on a byte basis by decoders m the macroinstmction decoder 230. However on each decode cycle, the mstmction buffer 408 is managed on a word basis for tracking which of the bytes in the instmction buffer 408 are valid and which are to be reloaded with new bvtes from the instmcuon cache 214 The designation of whether an mstmction byte is valid is maintained as the instmction byte is decoded. For an invalid mstmcuon byte, decoder invalidation logic (not shown), which is connected to the macroinstmction decoder 230, sets a "byte invalid" signal. Control of updatmg of the current fetch PC 426 is synchronized closely with the validity of instmction bytes m the instmction buffer 408 and the consumption of the mstmction bytes by the mstmction decoder 220. The macromstmcuon decoder 230 receives up to sixteen bytes or four aligned words of instmcuon bytes fetched from the instmction fetch control circuit 218 at the end of a fetch cycle. Instmction bytes from the mstmction cache 214 are loaded mto a 16-byte instmction buffer 408. The mstmction buffer 408 buffers stmction bytes, plus predecode mformauon associated with each of the instmction bytes, as the instmction bytes are fetched and/or decoded. The instmction buffer 408 receives as many mstmcuon bytes as can be accommodated by the mstmcuon buffer 408 free space, holds the next mstmcuon bvtes to be decoded and contmuallv reloads with new instmction bvtes as previous instruction bytes are transferred to mdividual decoders withm the macromstmcuon decoder 230 The mstmcuon predecoder 270 adds predecode mformauon bits to the mstmction bytes as the mstmction bytes are transferred to the instmction cache 214. Therefore, the instmction bytes stored and transferred by the instmction cache 214 are called extended bytes. Each extended byte mcludes eight memory bits plus five predecode bits. The five predecode bits mclude three bits that encode instruction length, one D-bit that designates whether the instruction length is D-bit dependent, and a HasModRM bit that mdicates whether an instmction code mcludes a modπn field. The thirteen bits are stored in the instruction buffer 408 and passed on to the macroinstrucuon decoder 230 decoders. The instruction buffer 408 expands each set of five predecode bits mto six predecode bits. Predecode bits enable the decoders to quickly perform multiple instrucuon decodes withm one clock cycle. The instmcuon buffer 408 receives instmcuon bytes from the mstmcuon cache 214 the memory- aligned word basis of instrucuon cache 214 storage so that instructions are loaded and replaced with word granulaπtv Thus, the instmcuon buffer 408 bvte location 0 alwavs holds bvtes that are addressed memory at an address of 0 (mod 16) Inst cuon bytes are transferred from the instmcuon buffer 408 to the macroinstπiction decoder 230 with byte granularity. Duπng each decode cycle, the sixteen extended instruction bytes within the instruction buffer 408 , mcludmg associated implicit word valid bits, are transferred to the plurahty of decoders within the macroins-mcαon decoder 230. This method of transferring instrucuon bytes from the instruction cache 214 to the macroinstrucuon decoder 230 via the instrucuon buffer 408 is repeated with each decode cycle as long as instructions are sequentially decoded. When a control transfer occurs, for example due to a taken branch operation, the instmction buffer 408 is flushed and the method is restarted. The current decode PC has an arbitrary byte alignment m that the mstmction buffer 408 has a capacity of sixteen bytes but is managed on a four-byte word basis which all four bytes of a word are consumed before removal and replacement or the word with four new bytes m the instmction buffer 408. An instmction bas a length of one to eleven bytes and multiple bytes are decoded so that the alignment of an mstmction m the instruction buffer 408 is arbitrary. As instmcuon bytes are transferred from the instmcuon buffer 408 to the macroinstmction decoder 230. the mstmcuon buffer 408 is reloaded from the instmction cache 214. Instmcuon bytes are stored the instmcuon buffer 408 with memory alignment rather than a sequential byte alignment that is suitable for application of consecutive instruction bytes to the macromstmcuon decoder 230. Therefore, a set of byte rotators 430, 432 and 434 are interposed between the mstmction buffer 408 and each of the decoders of the macroinstmction decoder 230. Four instmcuon decoders, mcludmg three short decoders SDecO 410, SDecl 412 or SDec2 414, and one combmed long and vectoring decoder 418, share the byte rotators 430, 432 and 434. In particular, the short decoder SDecO 410 and the combmed long and vectormg decoder 418 share byte rotator 430. Short decoder SDecl 412 is associated with byte routor 432 and short decoder SDec2 414 is associated with byte routor 434. A plurality of pipeline registers, specifically instmction registers 450, 452 and 454, are interposed between the byte rotators 430. 432 and 434 and the instruction decoder 220 to temporanly hold the mstmcuon bytes, predecode bits and other mformauon. thereby shortening the decode timing cycle. The other mformauon held m the instmcuon registers 450, 452 and 454 mcludes vanous information for assistmg instmction decodmg, mcludmg prefix (e.g. OF) status, immediate size (8-bιt or 32-bιt), displacement and long decodable length designations. Although a circuit is shown utilizing three ro tors and three short decoders, in other embodiments, different numbers of circuit elements may be employed. For example, one circuit mcludes two routors and two short decoders. Instmctions are stored m memory alignment, not mstmction alignment, in the instruction cache 214, the branch rget buffer (BTB) 456 and the instruction buffer 408 so that the location of the first instmction byte is not known. The byte rotators 430. 432 and 434 find the first byte of an instruction. The macrou-stmction decoder 230 also performs vanous instrucuon decode and exception decode operations, mcludmg validation of decode operations and selection between different types of decode operations. Functions performed duπng decode operations mclude prefix byte handling, support for vectormg to the emulation code ROM 232 for emulation of instmctions. and for branch unit 234 operations, branch unit interfacing and retum address prediction. Based on the instruction bytes and associated information, the macroinstmction decoder 230 generates operation information in groups of four operations corresponding to Op quads. The macroinstruction decoder 230 also generates instmction vectoring control information and emulation code control informauon. The macro-nstmcuon decoder 230 also has output connections to the scheduler 260 and to the emulation ROM 232 for outputting the Op quad information, inst ction vectoring control information and emulation code control informauon. The macroinstmction decoder 230 does not decode instmctions when the scheduler 260 is unable to accept Op quads or is accepting Op quads from emulation code ROM 232. The macroinstmction decoder 230 has five distinct and separate decoders, including three "short" decoders SDecO 410, SDecl 412 and SDec2 414 that function in combination to decode up to three "short" decode operations of instructions that are defined within a subset of simple mstructions of the x86 instmction set. Generally, a simple mstmction is an instmction that translates to fewer than three operations. The short decoders SDecO 410, SDecl 412 and SDec2 414 each typically generate one or two operations, although zero operauons are generated m certam cases such as prefix decodes. Accordmgly for three short decode operauons, from two to six operations are generated m one decode cycle. The two to six operations from the three short decoders are subsequently packed together by operation packing logic 438 into an Op quad since a maximum of four of the six operations are valid. Specifically, the three short decoders SDecO 410. SDecl 412 and SDec2 414 each attempt to decode two operations, potentially generating six operations. Only four operations may be produced at one time so that if more than four operations are produced, the operations from the short decoder SDec2 414 are invalidated. The five decoders also include a single "long" decoder 416 and a smgle "vectoring" decoder 418. The long decoder 416 decodes instructions or forms of instmctions havmg a more complex address mode form so that more than two operations are generated and short decode handling is not available. The vectoring decoder 418 handles instmctions that cannot be handled by operation of the short decoders SDecO 410, SDecl 412 and SDec2 414 or by the long decoder 416. The vectormg decoder 418 does not actually decode an instmction, but rather vectors to a locauon of emulation ROM 232 for emulation of the mstruction. Vanous exception conditions that are detected by the macroinstmction decoder 230 are also handled as a special form of vectormg decode operation. When activated, the long decoder 416 and the vectoring decoder 418 each generates a full Op quad. An Op quad generated by short decoders SDecO 410. SDecl 412 and SDec2 414 has the same format as an Op quad generated by the long and vectoring decoders 416 and 418. Tbe short decoder and long decoder Op quads do not mclude an OpSeq field. The macroinstmction decoder 230 selects either the Op quad generated by the short decoders 410, 412 and 414 or the Op quad generated by the long decoder 416 or vectormg decoder 418 as an Op quad result of the macroinstmction decoder 230 are each decode cycle. Short decoder operation, long decoder operation and vectormg decoder operation function m parallel and independently of one another, although the results of only one decoder are used at one time. Each of the short decoders 410, 412 and 414 decodes up to seven instmcuon bytes, assuming the first byte to be an operation code (opcode) byte and the instruction to be a short decode instmcuon. Two operauons (Ops) are generated with corresponding valid bits. Appropriate values for effective address size, effective daU size, the current x86-s-andard B-bit, and any override operand segment register are supplied for the generation of operations dependent on these parameters. The logical address of the next "sequential" instmction to be decoded is supplied for use m generating me operations for a CALL lnstructior-. Note tnat the word sequential is placed m quotation marks to mdicate that, although the "sequential" address generally pomts to an instrucuon which immediately precedes the present instruction, the "sequential" address may be set to any addressed location. The current branch prediction is supphed for use in generating the operations for conditional transfer control instmctions. A short decode generates control signals mcludmg indications of a transfer control instruction (for example, Jcc, LOOP, JMP, CALL), an unconditional transfer control instruction (for example, JMP, CALL), a CALL instmction, a prefix byte, a cc-dependent RegOp, and a designation of whether the instmction length is address or daU size dependent. Typically one or both operations are valid, but prefix byte and JMP decodes do not generate a valid op. Invalid operations appear as valid NOOP operations to pad an Op quad. The first short decoder 410 generates operations based on more than decodmg of the instmction bytes. The first short decoder 410 also determines the presence of any prefix bytes decoded duπng preceding decode cycles. Vanous prefix bytes include OF, address size overπde, operand size override, six segment override bytes, REP REPE. REPNE and LOCK bvtes. Each prefix bvte affects a subsequent mstmcuon decode m a defined way. A count of prefix bytes and a count of consecutive prefix bytes are accumulated duπng decodmg and furnished to the first short decoder SDecO 410 and the long decoder 416. The consecutive prefix byte count is used to check whether an instmction bemg decoded is too long. Prefix byte count information is also used to control subsequent decode cycles, mcludmg checking for certam types of instruction-specific exception conditions. Prefix counts are reset or initialized at the end of each successful non-prefix decode cycle m preparation for decodmg the prefix and opcode bytes of a next instmction. Prefix counts are also reinitialized when the macroinstmction decoder 230 decodes branch condition and wnte mstmction pointer (WRIP) operations. Prefix bytes are processed by the first short decoder 410 the manner of one-byte short decode instmctions At most, one prefix byte is decoded a decode cycle, a condition that is enforced through invalidation of all short decodes followmg the decode of a prefix byte Effective address size, dau size, operand segment register values, and the current B-bit, are supplied to the first short decoder 410 but can decode along with preceding opcodes. The address size prefix affects a decode of a subsequent instruction both for decodmg of instmctions for which the generated operation depends on effective address size and for decodmg of the address mode and instruction length of modr/m instructions. The default address size is specified by a currently-specified D-bit, which is effectively toggled by the occurrence of one or more address size prefixes. The operand size prefix also affects the decode of a subsequent mstmction both for decodmg of instructions for which the generated operation depends on effective dau size and for decodmg of the instruction length. The default operand size is specified by a currently-specified x86-standard D-bit, which is effectively toggled by the occurrence of one or more operand size prefixes. The segment overnde prefixes affect the decode of a subsequent instruction only m a case when the generation of a load-store operation (LdStOps) is dependent on the effective operand segment of the instruction. The default segment is DS or SS, depending on the associated general address mode, and is replaced bv the segment specified by the last segment ovemαe prefix The REP/REPE and REPNE prefixes do not affect the decode of a subsequent instmction. If the instrucuon is decoded by the macro-nstmcuon decoder 230, rather than the emulation code ROM 232, then any precedmg REP prefixes are ignored. However, if the instmction is vectored, then the generation of the vector address is modified m some cases. Specifically, if a stπng instmcuon or particular neighboring opcode is vectored, then an mdication of the occurrence of one or more of the REP prefixes and designation of the last REP prefix encountered are mcluded the vector address. For all other instmctions the vector address is not modified and the REP prefix is ignored. A LOCK prefix inhibits all short and long decodmg except the decodmg of prefix bytes, forcing tbe subsequent instmcuon to be vectored. When the vector decode cycle of this subsequent instmction occurs, so long as the subsequent mstmction is not a prefix, the opcode byte is checked to ensure that the instruction is withm a "lockable" subset of the instmctions. If the stmction is not a lockable mstmcuon, an exception condition is recognized and the vector address generated by the vectoring decoder 418 is replaced by an exception entry pomt address. Instmctions decoded by die second and third short decoders 412 and 414 do not have prefix bytes so that decoders 412 and 414 assume fixed default values for address size, dau size, and operand segment register values Typically, the three short decoders generate four or fewer operations because three consecutive short decodes are not always performed and instmctions often short decode mto only a smgle operation. However, for the rare occurrence when more than four valid operations are generated, operation packing logic 438 inhibits or mvalidates the third short decoder 414 so that only two instructions are successfully decoded and at most four operauons are generated for packi g mto an Op quad. When the first short decoder 410 is unsuccessful, the action of the second and third short decoders 412 and 414 are invalidated. When the second short decoder 412 is unsuccessful, the action of the third short decoder 414 is invalidated. When even the first short decode is invalid, the decode cvcle becomes a long or vectoring decode cycle. In general, the macro-nstruction decoder 230 attempts one or more short decodes and, if such short decodes are unsuccessful, attempts one long decode. If the long decode is unsuccessful, the macroinstmction decoder 230 performs a vectormg decode. Multiple conditions cause the short decoders 410, 412 and 414 to be invalidated. Most generally, short decodes are invalidated when the instmction operation code (opcode) or the designated address mode of a π-odr/m instmction does not fall withm a defined short decode or "simple" subset of mstmctions. This condition typicallv restncts short decode instructions to those operations that generate two or fewer operations. Short decodes are also invalidated when not all of the bytes m the instmction buffer 408 for a decoded instruction are valid. Also, "cc -dependent" operauons, operations that are dependent on status flags, are only generated by the firet short decoder 410 to ensure that these operations are not preceded by and ".cc" RegOps. A short decode is invalidated for a second of two consecutive short decodes when the immediately precedmg short decode was a decode of a transfer control instruction, regardless of the direction taken. A short decode is invalidated for a second of two consecutive short decodes when the first short decode was a decode of a prefix bvte. in general, a prefix code or a transfer control code inhibits further decodes a cvcle. Furthermore, no more than sixteen instruction bytes are consumed by the macroinstrucuon decoder 230 since the instruction buffer 408 only holds sixteen bytes at one time. Also, at most four operations can be packed mto an Op quad. These constraints only affect the third short decoder 414 since the length of each short decoded instruction is at most seven bytes and operations in excess of four only arise in the third short decoder 414. In a related constraint, if the current D-bit value specifies a 16-bit address and daU size default, then an instmction having a length that is address and/or daU dependent can only be handled by the first short decoder 410 since the predecode information is probably incorrect. Also, when multiple instmction decoding is disabled, only the first short decoder 410 is allowed to successfully decode instmctions and prefix bytes. Validation tests are controlled by short decoder validation logic (not shown) in the macroinstmction decoder 230 and are independent of the operation of short decoders 410, 412 and 414. However, each of the short decoders 410, 412 and 414 does set zero, one or two valid bits depending on the number of operations decoded. These valid bits, a total of six for tbe three short decoders 410, 412 and 414. are used by the operation packing logic 438 to determine which operations to pack mto an Op quad and to force invalid operauons to appear as NOOP (no operation) operations. The operation packing logic 438 operates without short decoder validation information since valid short decodes and associated operations are preceded only by other valid short decodes and associated operations. The short decoders 410, 412 and 414 also generate a plurality of signals representing various special opcode or modr/m address mode decodes. These signals indicate whether a certain foπn of instmction is currently being decoded by the instruction decoder 220. These signals are used by short decode validation logic to handle short decode validation situations. The instmction bytes, which are stored unaligned in the mstmction buffer 408. are aligned by byte routors 430. 432 and 434 as the instruction bytes are transferred to the decoders 410-418. The first short decoder SDecO 410. the long decoder 416 and the vectormg decoder 418 share a first byte routor 430. The second and third short decoders SDecl 412 and SDec2 414 use respective second and third byte routors 432 and 434. Dunng each decode cycle, the three short decoders SDecO 410, SDecl 412 and SDec2 414 attempt to decode what are, most efficiently, three short decode operations usmg three independently-operating and parallel byte routors 430, 432 and 434. Although the multiplexing by the byte rotators 430, 432 and 434 of appropnate bytes in the instmcuon buffer 408 to each respective decoder SDecO 410, SDecl 412 and SDec2 414 is conceptually dependent on the preceding instmction decode operation, instmction length lookahead logic 436 uses the predecode bits to enable the decoders to operate substantially parallel. The long and vectoring decoders 416 and 418, in combmation, perform two parallel decodes of eleven instrucuon bytes, taking the first byte to be an opcode byte and generating either a long instmction decode Op quad or a vectoring decode Op quad. Information analyzed by the long and vectoring decoders 416 and 418 includes effective address size, effective daU size, the current B-bit and DF-bit, any override operand segment register, and logical addresses of the next "sequential" and target instmctions to be decoded. The long and vectormg decoders 416 and 418 generate decode signals including an instmcuon length excluding precedmg prefix bits, a designation of whether the instmcuon is withm the long decode subset ot instmctions. a RET instruction, and an effective operand segment register, based on a default implied by the modr/m address mode plus any segment override. During a decode cycle in which none of the short decoders SDecO 410, SDecl 412 and SDec2 414 successfully decodes a short instruction, the macroinstmction decoder 230 attempts to perform a long decode using the long decoder 416. If a long decode cannot be performed, a vectormg decode is performed. In some embodiments, the long and vectormg decoders 416 and 418 are conceptually separate and independent decoders, just as the long and vectoring decoders 416 and 418 are separate and independent of the short decoders 410, 412 and 414. Physically, however, the long and vectoring decoders 416 and 418 share much logic and generate similar Op quad outputs. Instmctions decoded by the long decoder 416 are generally included within the short decode subset of instmctions except for an address mode constraint such as that the mstmction cannot be decoded by a short decoder because the mstmction length is greater than seven bytes or because the address has a large displacement that would require generation of a third operation to handle to displacement. The long decoder 416 also decodes certain additional modr/m mstructions that are not m the short decode subset but are sufficiently common to warrant hardware decodmg. Instmction bytes for usage or decoding by the long decoder 416 are supplied from the instruction buffer 408 by the firet byte routor 430, the same instmction multiplexer that supplies instruction bytes to the first short decoder SDecO 410. However, while the first short decoder SDecO 410 receives only seven bytes, the long decoder 416 receives up to eleven consecutive instmction bytes, corresponding to the maximum length of a modr/m instruction excluding prefix bytes. Thus, the first byte rotator 430 is eleven bytes wide although only the first seven bytes are connected to the first short decoder SDecO 410. The long decoder 416 only decodes one mstmction at a time so that associated predecode information within the instrucuon buffer 408 is not used and is typically invalid. The first byte of the first byte routor 430 is fully decoded as an opcode byte and, in the case of a modr/m instmcuon, the second instmction byte and possibly the third are fully decoded as modr/m and sib bytes, respectively. The existence of a OF prefix is considered decodmg of the opcode byte. The OF prefix byte inhibit-: ail short decodmg smce all short decode instmctions are non-OF or "one-byte" opcodes. Because all prefix bytes are located within the "one-byte" opcode space, decodmg of a OF prefix forces the next decode cycle to be a two-byte opcode instruction, such as a long or vectoring decode instmction. In addition to generating operations based on the decoding of modr/m and sib bytes, the first byte routor 430 also determines the length of the mstmcuon for usage by vanous program counters, whether the instmction is a modr/m instmction for inhibiting or invalidating the long decoder, and whether the instmction is an instmcuon within the long decode subset of operation codes (opcodes). The long decoder 416 always generates four operations and, like the short decoders 410, 412 and 141, presents the operations in the form of an emulation code-like Op quad, excluding an OpSeq field. The long decoder 416 handles only relatively simple modr/m instructions. A long decode Op quad has two possible forms that differ only in whether the third operation is a load operation (LdOp) or a store operation (StOp) and whether the fourth operation is a RegOp or a NOOP. A first long decode Op quad has tbe form: LIMM t2. < ιmm32> LIMM tl , <dιsp32> LD.b/d t8L/t8,@( < gam>)OS.a < RegOp> . . . A second long decode Op quad has the form: I-IMM -2, < imm32> LIMM tl , <disp32> ST.b/d @( <gam> ),t--LΛ2,OS.a NOOP The @( < gam> ) address mode specification represents an address calculation correspondmg to that specified by the modr/m and/or sib bytes of the instmcuon, for example @(AX + BX*4 + LD). The < ι-nπ-32 > and < disp32 > values are four byte vaiues conuining the immediate and displacement instmction bytes when the decoded instmction conu-ns such values. The long decoder 416, like the first short decoder 410, generates operauons -along mto account the presence of any prefix bytes decoded by the short decoders dunng precedmg decode cycles. Effective address size, da size, operand segment register vaiues. and the current B-bit are supplied to the long decoder 416 and are used to generate operations. No indirect size or segment register specifiers are included within the final operations generated by the long decoder 416. Only a few conditions inhibit or invalidate an odierwise successful long decode. One such condition is an instmction operation code (opcode) that is not mcluded in the long decode subset of instmctions. A second condition is that not all of the instmction buffer 408 bytes for the decoded instmcuon are valid. The vectoring decoder 418 handles instructions that are not decoded by either the short decoders or the long decoder 416. Vectormg decodes are a default case when no short or long decoding is possible and sufficient valid bytes are available. Typically, the instructions handled by tbe vectoring decoder 418 are not included the short decode or long decode subsets but also result from other conditions such as decoding being disabled or the detection of an exception condition. Dunng normal operation, only non-short and non-long instmctions are vectored. However, all instmctions may be vectored. Undefined opcodes are always vectored. Only prefix bytes are always decoded. Prefix bytes are always decoded by the short decoders 410, 412 and 414. When an exception condition is detected duπng a decode cycle, a vectoring decode is forced, generally overriding any other form of decode without regard for instruction byte validity of the decoded instmction. When a detected exception condition forces a vectoring decode cycle, the generated Op quad is undefined and the Op quad valid bit for presenUtion to the scheduler 260 is forced to zero. The Op quad valid bit informs the scheduler 260 that no operations are to be loaded to the scheduler 260. As a result, no Op quad is loaded into the scheduler 260 dunng an exception vectormg decode cycle. Few conditions inhibit or invalidate a vectormg decode. One such condition is that not all of the bytes in the instrucuon buffer 408 are valid. When an instmcuon is vectored, control is transferred to an emulation code entry pomt. An emulation code entry pomt is either intemal emulation code ROM 232 or m extemal emulation code RAM 236. The emulation code suiting from the entry pomt address eidier emulates an mstmcuon or mitiates appropnate exception processmg. A vectoring decode cycle is properly considered a macroinstmction decoder 230 decode cycle. In the case of a vectoring decode, the macroinstniction decoder 230 generate the vectoring quad and generate the emulation code address mto the emulation code ROM 232. Following the initial vectormg decode cycle, the macroinstniction decoder 230 remains inactive while instmctions are generated by the emulation code ROM 232 or emulation code RAM 236 until a retum from emulation (ERET) OpSeq is encountered. The retum from emulation (ERET) sequencmg action transitions back to macroinstmction decoder 230 decoding. During the decode cycles followmg the initial vectoring decode cycle, the macroinstmction decoder 230 remains inactive, continually attempting to decode the next "sequential" instmction but havmg decode cycles repeatedly invalidated until after the ERET is encountered, thus waiting by default to decode the next "sequential" instmction. Instmcuon bytes for usage or decodmg by the vectormg decoder 418 are supplied from the instmction buffer 408 by the first byte rotator 430, the same instmcuon multiplexer that supplies instmcuon bytes to the first short decoder SDecO 410 and to the long decoder 416. The vectormg decoder 418 receives up to eleven consecutive instmction bytes, corresponding to the maximum length of a modr/m instruction excluding prefix bytes. Thus, the full eleven byte widdi of the first byte rotator 430 is distributed to both the long decoder 416 and the vectormg decoder 418. The predecode information within the instmcuon buffer 408 is not used by the vectormg decoder 418. As in the case of the long decoder 416, the first byte of the first byte routor 430 is fully decoded as an opcode byte and, in the case of a modr/m instmction, tbe second instmcuon byte and possibly the third are fully decoded as modr/m and sib bytes, respectively. The vectoring decoder 418 generates operations taking into account the presence of any prefix bytes decoded by the short decoders duπng preceding decode cycles. The existence of a OF prefix is considered in decodmg of the opcode byte. In addition to generating operations based on the decodmg of modr/m and sib bytes, the first byte routor 430 also determines the length of the instmction for usage by vanous program counters, whether the mstmction is a modr/m instmction for inhibiting or invalidating the long decoder, and whether the instmcuon is an mstmcuon within the long decode subset of operation codes (opcodes). If not, a vectormg decode is initiated. Effective address size, daU size and operand segment register values are supplied to the vectoring decoder 418 and are used to generate operations. No indirect size or segment register specifiers are included within the final operations generated by the vectormg decoder 418. Dunng a vectoring decode cycle, the vectoring decoder 418 generates a vectormg Op quad, generates an emulation code entry pomt or vector address, and initializes an emulation environment. The vectormg Op quad is specified to pass vanous information to initialize emulation environment scratch registers. The value of the emulation code entry point or vector address is based on a decode of the first and second instmction bytes, for example the opcode and modr/m bytes, plus other information such as the preaeoce of an OF prefix, a REP prefix or the like. In the case of vectormg caused by an exception condition, the entry pomt or vector address is based on a simple encoded exception identifier. The emulation environment is stored for resolving environment dependencies. All ot the short decoders 410, 412 and 414 and long decoder 416 directly resolve environmental dependencies, such as dependencies upon effective address and dau sizes, as operations are generated so that these operations never contain indirect size or register specifiers. However, emulation code operations do refer to such effective address and daU size values for a particular instance of the instruction being emulated. The emulation environment is used to store this additional information relating to the particular instmction that is vectored. This information includes general register numbers, effective address and daU sizes, an effective operand segment register number, the prefix byte count, and a record of the existence of a LOCK prefix. The emulation environment also loads a modr/m reg field and a modr/m regm field are loaded into Reg and Regm registers. The emulation environment is initialized at the end of a successful vectoring decode cycle and remains at the imtial sute for substantially the duration of the emulation of an mstmcuon by emulation code, until an ERET code is encountered. The vectormg decoder 418 generates four operations of an Op quad in one of four forms. All four forms mclude three LIMM operations. The four forms differ only m the immediate values of the LIMM operations and m whether the third operation is an LEA operation or a NOOP operation. A first vectormg decode Op quad has the form: LIMM -2. < ιmm32> LIMM tl , <dιsp32> LEA t6,@(<gam>),_.a LIMM t7.LogSeqDecPC[31..0] //logical seq. next //instr. PC A second vectoring decode Op quad has the foπn: LIMM t2. < ιmm32 > LIMM tl . <disp32> NOOP LIMM tT.LogSe Dec A third vectoring decode Op quad has the form: LIMM t2. < +/- l/2/4 > //equiv to "LDK(D)S t2. + 1/ + 2" LIMM tl , < + /- 2/4/8 > //equiv to "LDK(D)S tl , +2/+4" NOOP LIMM t7,LogSeqDecPC[31..0] A fourth vectoring decode Op quad has the form: LIMM t2, < +2/4 > //equiv to "LDKD t2, +2" LIMM tl , <disp32 > LD t6,@(SP),SS.s LIMM t7.LogSeqDecPC[31..0] //predicted RET target adr //from Return Address Stack The first two forms of vectormg Op quads apply for most opcodes. The first form is used for memory-referencing modr/m instmctions for which the LEA operation is used to compute and load a general address mode effective operand address mto a scratch register. The second form is used for non-modr/m and register-referencing modr/m mstmctions. For mstmctions havmg the second form no address is necessarily computed, although the < ιmm32> and <dιsρ32> values remam useful insofar as they contain instruction bytes followmg the opcode byte. The third foπn of vectoring Op quad is used for all string instructions plus some neighboring non-modr/m instructions. A fourth form of vectoring Op quad supports special vectoring and emulation requirements for near RET mstmctions. Tbe macroinstmction decoder 230 has four program counters, including three decode program counters 420, 422 and 424, and one fetch program counter 426. A first decode program counter, called an instmction PC 420, is the logical address of the first byte, including any prefix bytes, of either the current instmction being decoded or, if no instmction is currently decoding, the next instmcuon to be decoded. If tbe decode operation is a multiple instruction decode, instmcuon PC 420 points to the first instmction of the multiple instructions to be decoded. The instmction PC 420 corresponds to the architecmrai address of an instmction and is used to generate instmction fault program counters for handling of exceptions. The instmction PC 420 is passed down the scheduler 260 with correspondmg Op quads and is used by an operation commit unit (OCU) (not shown) of the scheduler 260 to produce instruction fault program counters to be saved duπng exception processmg. When an Op quad is generated by the macroinstrucuon decoder 230, the current instmction PC 420 value is Ugged to the Op quad and loaded into the Scheduler 260 Op quad entry along with the Op quad. A second decode program counter, called a logical decode PC 422, is the logical address of the next instmction byte to be decoded and addresses either an opcode byte or a prefix byte. A third decode program counter, called a linear decode PC 424, is the linear address of the next mstmction byte to be decoded and addresses eidier an opcode byte or a prefix byte. The logical decode PC 422 and the Imear decode PC 424 pomt to the same instmction byte. The linear decode PC 424 designates the address of the instruction byte currently at the first byte rotator 430. The vanous decoders in the macroinstrucuon decoder 230 function on the basis of decodmg or consuming either prefix bytes or whole instructions minus any prefix bytes so that prefixes are generally handled as one-byte mstmctions. Therefore, the address boundaπes between instmcuon and prefix byte decodes are more important than mstmction boundaπes alone. Consequently, at the beginning of each decode cycle, tbe next instmction byte to be decoded is not necessarily tbe tme beginning of an mstmction. At the beginning of a decode cycle the logical decode PC 422 and the Imear decode PC 424 contain tbe logical and Imear addresses of the next instmction to be decoded, eidier an instmction or a prefix byte. The linear decode PC 424 is a primary program counter value that is used during the decodmg process to access the instmction buffer 408. The linear decode PC 424 represents the suiting point for the decode of a cycle and specifically controls the byte routor feed g bytes from the instmcuon buffer 408 to the first short decoder 410 and to the long and vectormg decoders 416 and 418. The linear decode PC 424 also is the reference point for determimng the instrucuon addressee of any further short decode instmctions or prefix bytes, thus generating control signals for the byte rotators feeding the second and third short decoders 412 and 414. Tbe Imear decode PC 424 also acts secondarily to check for breakpoint matches during the firet decode cycles of new instructions, before prefix bytes are decoded, and to check for code segment overruns by the macroinstrucuon decoder 230 dunng successful instruction decode cycles. The logical decode PC 422 is used for program counter-related transfer control mstmctions. mcludmg CALL instructions. The logical decode PC 422 is supplied to the branch unit 234 to be summed wi the displacement value of a PC-relative transfer control instruction to calculate a branch target address. The logical decode PC 422 also supports emulation code emulation of instructions. The next sequential logical decode program counter (PC) 422 is available in emulation code from storage in a temporary register by the vectoring Op quad for general usage. For example, the next sequential logical decode PC 422 is used to supply a remm address that a CALL instruction pushes on a stack. A next logical decode PC 428 is set to tbe next sequential logical decode program counter value and has functional utility beyond that of the logical decode PC 422. The next logical decode PC 428 directly furnishes the remm address for CALL instructions decoded by the macroinstmction decoder 230. The next logical decode PC 428 also is passed to emulation code logic during vectoring decode cycles via one of the operations within the vectoring Op quad. During a decode cycle, die imear decode PC 424 pomts to the next mstmction bytes to be decoded. Tbe four least significant bits of imear decode PC 424 pomt to the first instmction byte within the mstmcuon buffer 408 and thereby directly indicate the amount of byte roution necessary to align tbe first and subsequent instruction bytes in tbe mstmction cache 214. The firet byte rotator 430 is an instmction multiplexer, specifically a 16: 1 byte multiplexer, for accessing bytes in the instmcuon buffer 408 that are offset by the linear decode PC 424 amount. The firet byte routor 430 is seven bytes wide for the first short decoder SDecO 410 and eleven bytes wide for the long decoder 416 and the vectoring decoder 418 in combination. Shared logic in the first short decoder SDecO 410, the long decoder 416 and the vectoring decoder 418 generate a first instmction length value ILenO for the first instruction. The second and third byte routore 432 and 434 are seven byte-wide instruction multiplexers, specifically 16: 1 byte multiplexers. The second byte routor 432 accesses bytes the instruction buffer 408 that are offset by the sum of the Imear decode PC 424 amount and the firet mstmction length ILenO. Logic m the second short decoder SDecO 412 generate a second instmction length value ILenl for the second instmction. The third byte routor 434 accesses bytes m tbe instmction buffer 408 that are offset by the sum of the Imear decode PC 424 amount and the firet and second mstmction lengths ILenO and ILenl. Tbe byte routore 430. 432 and 434 multiplex mstmcuon bytes but not predecode bits. The byte routors 430, 432 and 434 are controlled using predecode information in which the predecode bits associated with the first opcode byte or the first byte of the first instmction directly controls the second routor 432. The first byte of the second instmction directly controls the third routor 434. Each predecode code implies an instruction length but what is applied to the next routor is a pom ter. The pointer is derived by taking the four least significant bits of the program counter at the present instmcuon plus the iength to atuin the program counter to tbe next instruction. All program counters 420, 422, 424 and 428 in the macro-nstπiction decoder 230 are initialized during instruction and exception processing. A plurality of signal sources activate this initialization. First, the branch unit 234 supplies a target branch address when a PC-relative transfer control instmction is decoded and predicted taken. Second, a return address stack (not shown) supplies a predicted return target address when a near RET instruction is decoded. Third, the scheduler 260 generates a correct and alternate branch address when die macroinstrucuon decoder 230. along with the remaining circuits in the processor 120. is restarted by the scheduler 260 due to a mispredicted branch condition (BRCOND) operation. Fourth, register unit 244, the primary RegOp execution unit, supplies a new decode address when a WRJ-P RegOp is executed. The WRIP RegOp execution allows emulation code to explicitly redirect instmction decoding. In all four cases, a logical address is supplied and utilized to simultaneously reinitialize the three decode program counters 420, 422 and 424. For the linear decode PC 424, a linear address value is supplied by adding the supplied logical address to the current code segment base address to produce die corresponding linear address for loading mto linear decode PC 424. The logical address is loaded into the current instrucuon PC 420 and the logical decode PC 422. For each decode cycle until a next reinitialization, the macroinstmction decoder 230 sequentially and synchronously updates the current instruction PC 420, the logical decode PC 422 and die linear decode PC 424 as instmction bytes are successfully decoded and consumed by the individual decoders of macroinstniction decoder 230. Generation of the instmction lengths ILenO and ILenl occurs seπally. To hasten this serial process by emulating a parallel operation, instmcuon length lookahead logic 436 quickly determines the instmcuon lengths ILenO and ILenl usmg four predecode bits specifying the length ot each mstmction byte m the instmction buffer 408. The predecode bits associated with the opcode byte of the first instruction byte in the instruction buffer 408, the first instruction byte being multiplexed to the firet short decoder SDecO 410, directly specifies a byte index of the opcode byte of the second instruction byte in tbe instmction buffer 408. The predecode bits associated witb the opcode byte of tbe second instmction byte in the instmction buffer 408, the second instruction byte being multiplexed to the second short decoder SDecl 412, directly specifies a byte index of the opcode byte of the third instmction byte m the instmction buffer 408. The instmction length lookahead logic 436 includes two four-bit-wide 16: 1 multiplexers for generating the byte indices of the opcode bytes of the second and third instmcuon bytes in the instmction buffer 408. The instmction lookahead logic 436 also mcludes logic for determimng validity of the sets of predecode bits. Predecode bits are valid when the associated instruction byte is the sUrt of a valid short decode mstmction. Specifically, the mstmcuon lookahead logic 436 determines whether predecode bits for a given byte in the instruction buffer 408 pomt to the same byte, implying a zero length for an mstmction suiting at that byte. If so, that byte is not tbe sUrt of a short decode instmcuon and no further short decodmg is possible. Otherwise, a short decode operation is possible and predecode bits pomt to the beginning of the next mstmction. The predecoder 270 connected between the mam memory 130 and the instmcuon cache 214 has eight logic units, each of which examines its associated instmction byte plus, m some cases, the followmg one or two mstmction bytes. The first instmcuon byte is decoded as an opcode byte and the second and third instmction bytes, if the opcode byte is a modr/m opcode, are decoded as modr/m and sib bytes. Based on these three bytes, the length of an instruction and whether the instmction is classified as a "short" instruction are determmed. The length of the mstmction is added to a four-bit fixed value corresponding to the position of the logic unit with respect to the sixteen logic units to determine tbe byte index used by tbe instruction length lookahead logic 436. This byte index is set as the value of the predecode bits if the instruction falls within the criteπa of a short instruction. For instmction bytes not meeting the short instmction cπteria, the predecode bits are set to the four-bit fixed value correspondmg to the position of the logic unit with resσect to the sixteen logic units without increment to designate an instmcuon length of zero. An implied instmcuon length of zero is indicative that the instruction is not a short instrucuon. The predecode bits are truncated from four bits to three since short decode instructions are never longer than seven bytes and the most significant bit is easily reconstructed from the three predecode bits and tbe associated fixed byte address. The expansion from three to four predecode bits is performed by predecode expansion logic 440 havmg sixteen logic umts correspondmg to the sixteen instruction bytes of the instmction cache 214. The sixteen logic umts of predecode expansion logic 440 operate independently and simultaneously on predecode bits as the instmction bytes are fetched from the instruction cache 214 to the instruction buffer 408. The final two of the thirty-two instrucuon bytes that are predecoded and loaded to the instmction cache 214 have only one or two bytes for examination by the predecoder 270. For modr/m opcodes the full instruction length cannot be determmed. Thus logic umts for bytes 14 and 15 m the predecoder 270 are modified from logic umts for bytes 0 through 13. For mstmction byte 15, logic unit 15 of the predecoder 270 forces an instmcuon length of zero for all modr/m opcodes and for non-short decode instmctions. For mstmction byte 14. an effective mstmcuon length of zero is forced for modr/m opcodes with an address mode requiπng examination of a sib byte to reliably determine instmction length, as well as for non-short instmctions. Durmg each decode cycle, the macromstmcuon decoder 230 checks for several exception conditions, mcludmg an mstmction breakpoint, a pending nonmaskable interrupt (NMI), a pending interrupt (INTR), a code segment overrun, an instmction fetch page fault, an instruction length greater than sixteen bytes, a nonlockable instruction with a LOCK prefix, a floating pomt not available condition, and a pending floating pomt error condition. Some conditions are evaluated only duπng a successful decode cycle, other conditions are evaluated irrespective of any decodmg actions durmg the cycle. When an active exception condition is detected, all instmction decode cycles mcludmg short, long and vectormg decode cycles, are inhibited and an "exception" vectormg decode is forced in the decode cycle followmg exception detection. The recogmtion of an exception condition is only overridden or inhibited by inactivity of the macroinstmction decoder 230, for example, when emulation code Op quads are accepted by the scheduler 260, rather than short and long or vector decoder Op quads, ln effect, recogmtion and handling of any exception conditions are delayed until an ERET Op seq returns control to the macroinstrucuon decoder 230. Duπng the decode cycle that forces exception vectormg, a special emulation code vector address is generated m place of a normal mstmction vector address. The vectormg Op quad diat is generated by the long and vectormg decoders 416 and 418 is undefined. The exception vector address is a fixed value except for low-order bits for identifying the particular exception condition that is recogmzed and handled. When multiple exception conditions are detected simultaneously, the exceptions are ordered m a pnonty order and the highest pnonty exception is recogmzed. The instrucuon breakpoint exception, the highest pnonty exception condition, is recogmzed when the linear decode PC 424 pomts to the firet byte of an instrucuon mcludmg prefixes, the Imear decode PC 424 matches a breakpoint addreββ that is enabled as an instruction breakpoint, and none of die instmction breakpoint mask flags are clear. One mask flag (RF) specifically masks recogmtion of instruction breakpomts. Another mask flag (BNTF) temporarily masks NMI requests and instmction breakpomts. The pendmg NMI exception, the penultimate pnonty exception, is recogmzed when an NMI request is pending and none of the NMI mask flags are clear. One mask (NF) soecincaliv mast-s nonmaskaoie interrupts. Another mask flag (BNTF) temporarily masks NMI requests and instruction breakpoints. The pending INTR exception, the next exception in priority following the pending NMI exception, is recognized when an INTR request is pending and the interrupt flag (IF) and temporary interrupt flag (TTF) are clear. The code segment overrun exception, the next exception in pnonty following the pending INTR exception, is recognized when the macroinstruction decoder 230 attempts to successfully decode a set of instmctions beyond a current code segment limit. The instruction fetch page fault exception, havmg a priority immediately lower than the code segment overrun exception, is recognized when the macroinstrucuon decoder 230 requires additional valid instruction bytes from the instmction buffer 408 before decodmg of another instmction or prefix byte is possible and the instmction translation lookaside buffer (ITB) signals that a page fault has occurred on the current instruction fetch. A faultmg condition of the instmction fetch control circuit 218 is repeatedly retned so that the ITB contmuallv reports a page fault until the page fault is recognized by the macroinstmction decoder 230 and subsequent exception handling processmg stops and redirects instmcuon fetching to a new address. The fault indication from the ITB has the same timing as instructions loaded from tbe instmction cache 214 and, therefore, is registered in the subsequent decode cycle. The ITB does not necessarily signal a fault on consecutive instmction fetch attempts so that the macroinstmction decoder 230 holds the fault indication until fetching is redirected to a new instruction address. Upon recognition of a page fault, additional fault information is loaded into a special register field. The instrucuon length greater than sixteen bytes exception, which has a priority just below the instmction fetch page fault exception, is recognized when the macroinstruction decoder 230 attempts to successfully decode an instruction having a total length including prefix bytes of greater than fifteen bytes. The instruction length greater than sixteen bytes exception is detected by counting the number of prefix bytes before an acmal instmction is decoded and computmg the length of the rest of the mstmcuon when it is decoded. If the sum of the prefix bytes and the remaimng instmction length is greater than sixteen bytes, an error is recognized. The nonlockable instruction with a LOCK prefix excepuon. havmg a pnonty below the instmction length exception, is recognized when the macroinstmction decoder 230 attempts to successfully decode an instmction havmg a LOCK prefix, in which the instruction is not mcluded in the lockable instmction subset. The nonlockable LOCK instmction exception is detected based on decode of die opcode byte and existence of a OF prefix. Tbe nonlockable LOCK instmcuon exception only occurs during vectormg decode cycles smce the LOCK prefix inhibits short and long decodes. The floating point not available exception, having a next to lowest pnority, is recognized when the macroinstmction decoder 230 attempts to successfully decode a WATT mstmcuon or an ESC instruction that is not a processor control ESC, and the reportmg of a floating point error is pending. Macroinstniction decoder 230 detects the floating pomt not available excepuon based on decoding of an opcode and modr/m byte, in addition to the existence of a OF prefix. Dunng each decode cycle, the macroinstmction decoder 230 attemDts to perform some tυπn of instruction decode of one or more instmctions. Typically, the macroinstmction decoder 230 succeeds in performing either one or multiple short decodes, one long decode or an instruction vectoring decode. Occasionally no decode is successful for three types of conditions including detection of an active exception condition, lack of a sufficient number of valid bytes in the instruction buffer 408, or the macroinstruction decoder 230 does not advance due to an extemal reason. When an active exception condition is detected all forms of instruction decode are inhibited and, during the second decode cycle after detection of the exception condition, an exception vectoring decode cycle is forced, producing an invalid Op quad. When an insufficient number of valid bytes are available in the mstmction buffer 408 either no valid bytes are held in the instmction buffer 408 or at least the first opcode is valid and one of the decoders decodes the instmction but the decoded instmction length requires further valid bytes the instmction buffer 408, not all of which are currently available. When an external reason prevents macroinstmction decoder 230 advancement either the scheduler 260 is full and unable to accept an additional Op quad dunng a decode cycle or the scheduler 260 is currently accepting emulation code Op quads so that the macroinstniction decoder 230 is inactive awaitmg a retum to decoding. In the latter two cases, the decode sute of the macroinstmction decoder 230 is inhibited from advancing and the macroinstmction decoder 230 simply retπes the same decodes in the next decode cycle. Control of macroinstmction decoder 230 inhibition is based on die generation of a set of decode valid signals with a signai corresponding to each of the decoders. For each decoder there are multiple reasons which are combined into decoder valid signals to determme whether that decoder is able to successfully perform a decode. The decoder valid signals for all of the decoders are then mo to red. in combination, to determme the type of decode cycle to perform. The type of decode cycle is indicative of the particular decoder to perform the decode. The extemal considerations are also appraised to determme whether the selected decode cycle type is to succeed. Signals indicative of the selected type of decode cycle select between vanous signals internal to the macroinstrucuon decoder 230 generated by the different decodere, such as alternative next decode PC values, and also are applied to control an Op quad multiplexer 444 which selects the input Op quad applied to the scheduler 260 from the Op quads generated by the short decodere. the long decoder 416 and the vectormg decoder 418. In the case of vectormg decode cycles, the macroinstmction decoder 230 also generates signals that initiate vectoring to an entry pomt m either internal emulation code ROM 232 or external emulation code RAM 236. The macroinstruction decoder 230 then monitors the active duration of emulation code fetching and loading into the scheduler 260. The instmction decoder 220 includes me branch unit (not shown) for performing branch prediction so that operation-! are speculatively executed. Performance of an out-of-order processor is enhanced when branches are handled quickly and accurately so that pipeline-draining mispredictions are avoided. The processor 120 employs a two-level branch prediction algonthm that is disclosed deUii in U.S. Patent No. 5,454.117, entided CONFIGURABLE BRANCH PREDICTION FOR A PROCESSOR PERFORMING SPECULATIVE EXECUTION (Puziol et al., issued September 26, 1995), U.S. Patent No. 5,327,547, entitled TWO-LEVEL BRANCH PREDICTION CACHE (Stiles et al.. issued July 5, 1994), U.S. Patent No. 5,163,140, entided TWO-LEVEL BRANCH PREDICTION CACHE (Stiles et al., issued November 10, 1992), and U.S. Patent No. 5, 093,778, entitled INTEGRATED SINGLE STRUCTURE BRANCH PREDICTION CACHE (Favor et al., issued March 3, 1993). The processor 120 further utilizes an 8, 192-entry branch history Uble (BHT) (not shown) which is mdexed by combining four program counter bits with rune bits of global branch history. Each BHT entry contains two history bits. The BHT is a dual-port RAM allowmg both a read/lookup access and a wπte/update access. BHT lookups and updates do not conflict smce they take place m opposite half phases of a clock cycle. The large number of entnes of the BHT is supplied in a reasonable integrated circuit area because the BHT is only predicting conditional branch directions so that entnes are not gged and predicted branch Urget addresses are not stored, except for a 16-entry remm address stack (not shown) Accordmgly, an access to the BHT is similar to a direct mappmg mto a cache-like stmcture in which the BHT is mdexed to access an entry m the BHT and the accessed entry is presumed to be a branch instmcuon. For branches other than remms, the urget address is calculated duπng the decode cycle. The urget address is calculated with sufficient speed usmg a plurality of parallel adders (not shown) that calculate all possible Urget addresses before the location of a branch instruction is known. By the end of the decode cycle, the branch unit 234 determines which, if any, target address result is valid. If a branch is predicted taken, the target address is immediately known and the Urget instmctions are fetched on the followmg cycle, causing a one-cycle taken-branch penalty. The taken -branch penalty is avoided usmg a branch target buffer (BTB) 456. The BTB 456 mcludes sixteen entnes, each entry havmg sixteen instmction bytes with associated predecode bits. The BTB 456 is mdexed by the branch address and is accessed duπng the decode cycle. Instmctions from die BTB 456 are sent to the instmction decoder 220. eliminating the taken-branch penalty, for a cache hit of the BTB 456 when the BHT (not shown) predicts a taken branch. Duπng each decode cycle, die Imear decode PC 424 is used in a direct-mapped manner to address die BTB 456. If a hit, which is realized before the end of die decode cycle, occurs with a BTB entry, a PC-relative conditional transfer control mstmction is decoded by a short decoder and the control transfer is predicted taken, then two actions occur. First, the initial Urget Imear fetch address directed to the instruction cache 214 is changed from the actual Urget address to a value which pomts to an instrucuon byte immediately followmg tbe valid Urget bytes conuined m the BTB entry This modified fetch address is contained the BTB entry and directly accessed from the BTB entrv Second, die instmction byte and predecode information from the entry is loaded mto the mstmction buffer 408 at the end of the decode cycle. If a PC-relative conditional transfer control instruction is decoded by a short decoder and the control transfer is predicted taken, but a miss occurs, then a new BTB entry is created with the results of the target instruction fetch. Specifically, simultaneously with the first successful load of target instrucuon bytes mto tbe instruction buffer 408 from the instmction cache 214, the same mformauon is loaded mto a chosen BTB entry, replacing the previous contents. The target fetch and instmcuon buffer 408 load odierwise proceed normally Each entry mcludes a ug part and a dau pan. The dau nan holds sixteen extenαed instmcuon bytes mcludmg a memory byte and three associated predecode bits. Tbe correspondence of die memory byte is memory-aligned with the correspondmg instruction buffer 408 location. The Ug part of a BTB entry holds a 30-bit Ug mcludmg the 32-bit imear decode PC 424 associated with the transfer control instruction havmg a cached target, less bits [4: 1], an entry valid bit and the 30-bit modified imtial target Imear instmction fetch address. No explicit instruction word valid bits are used smce the distance between the tme target address and the modified target address directly implies the number and designation of valid instmction words withm the BTB 456. The purpose of the BTB 456 is to capmre branch Urgets withm small to medium sized loops for the time peπod a loop and nested loops are actively executed. In accordance with this purpose, at detection of a slightest possibility of an mconsistency, the entire BTB is mvalidated and flushed The BTB 456 is mvalidated and flushed upon a miss of the instruction cache 214, any form of invalidation of instmcuon cache 214, an ITB miss, or any form of ITB invalidation. Branch targets outside temporal or spatial locality are not effectively cached. Typically, die BTB 456 contains only a small number of entnes so mat complexity is reduced while the majonty of performance benefit of ideal branch Urget caching is achieved PC-relative branch Urget address calculation logic (not shown) performs the urget address calculation. Branch Urget address calculation logic is utilized only for PC-relative transfer control instmctions that are decoded by a short decoder SDecO 410, SDecl 414 or SDec2 416. Specifically, the branch target address calculation logic is utilized for the short decode branch instructions mcludmg Jcc dispβ, LOOP dispβ, JMP dispδ, JMP disp 16/32. and CALL dιspl6/32. Each short decoder SDecO 410, SDecl 412 and SDec2 414 mcludes logical and linear branch target address calculation logic (not shown). All three sets of logical and Imear branch target address calculation logic function parallel while the short decoders 410, 412 and 414 determme whether anv of the operations is a PC-relative short decode branch instmcuon The logical and Imear branch urget address calculation logic sum the logical program counter of the branch, the length of the branch instmction and die sign-extended displacement of the branch instmcuon and conditionally mask the high-order 16 bits of the sum, depending on calculation sizing, to produce a logical Urget address The logical and Imear branch Urget address calculation logic sum the logical Urget address with the current code segment base address to produce a Imear urget address. If die branch is taken, either unconditionally or predicted taken, then calculated addresses correspondmg to the decoded short decode branch instmction are used to reinitialize the logical decode PC 422 and Imear decode PC 424. If the branch is predicted not taken, the logical address is saved with tbe associated short decode branch mst cuon (BRCOND Op) a scheduler 260 Op quad entry. The logical urget address is compared to the current code segment limit value to momtor for a limit violation. If the logical and Imear branch target address calculation logic detects a limit violation, whether the branch is predicted taken or predicted not taken, then a special Ug bit indicative of the limit violation is set m the scheduler 260 Op quad entry hold g the operations generated from the branch instmction. Subsequently, when the operation commit unit (OCU) of the scheduler 260 attempts to commit this Op quad, tbe Op quad is handled as contaimng a fault and aborted. The macroinstmction decoder 230 generates signals that initiate vectormg to a fault handler m emulation code ROM 232. The fault handler temporaπiv innibits decodmg by the short and long decoders and jumps to the fault PC address of die violating instruction associated with the faulted Op quad. Ultimately, the branch instruction is redecoded and vectored to instmction emulation code. The emulation code recognizes the limit violation if the branch is actually taken and appropriately handles the violation. The processor 120 generally responds to a fault condition by vectoring to a specific fault handler in the emulation code ROM 232. The fault handler includes operations defined within the RISC instruction set which perform a routine that determines the source of the fault, an appropnate response to the fault and steps to initiate die appropriate response. As an alternative appropnate cases, the processor 120 also includes a special "load alternate fault handier" operation which initiates a special fault response. Exceptions that are detected during decode time direct execution to a fixed set of entry points, one entry point for each possible exception condition through operation of the vectoring decoder 418 which activates the alternate fault handler and designates a fault handler address. The alternate fault handler is advanugeous for allowmg modified full handling of special conditions. The load alternate fault handler stmction passes dirough the mstmction decoder 220 pipeline in the manner of all instmctions. but causes any subsequent excepuon condition to mvoke a different vector instruction ROM entry pomt. The alternate fault handler terminates upon completion of execution of the current macroinstrucuon. One example of the advanUge of the alternate fault handler anses with respect to a repeated move string instmction (REP MOVs). To perform multiple interactions very quickly, a capability to reorder the sequence of operations is important. The sequence of operations typically includes a load to a firet pointer- designated address, a store to a second pointer-designated address and, if both tbe load and store are successful, an increment of the firet and second pointers and a decrement of a counter. For additional efficiency, die pointers are incremented and the counter decremented before completing the store operation. However, if a fault or exception occurs duπng the sequence of operations, die sequence is aborted with the counters and pointers m the wrong sute. For example, the architecmrai x86 SI. Dl and CX registers do not have the correct value. The alternate fault handler is used by specifying, pπor to the sequence, an alternate fault handler that performs a cleanup after a repeated move fault. The sequence proceeds widiout die overhead of intermediate mstructions for tracking the pointers and counters. If no errors occur, the alternate fault handler terminates without effect. However, if an error occurs, the alternate fault handler is invoked. This alternate fault handler is specific to the particular sequence of operations and performs clean-up accordingly and jumps to tbe default fault handier. Advanugeously, highly efficient code improves speed performance without hmdrance from the alternate fault handler unul an error arises, at which time the error is addressed. The branch history uble (BHT) stores recent history information, particularly branch direction information, about conditional transfer control instructions that have been encountered in the past. When a branch is repeated, stored information relating to the branch is analyzed to predict the current direction of the branch. Subsequently, the stored informauon is updated based on the actual direction taken by the branch. The stored information is derived from the direction of a particular newly encountered branch, the recent direction history of the particular branch and the recent direction history of other branches. The stored information is based on a plurality of sets of two-bit sute machines and also on a direction historv of the last rune branch executions, whether the last nine branch executions pertained to tbe particular branch or other branches. The instruction address of die particular newly encountered branch is used to select one of the plurality of sets of two-bit state machines. The direction history of the last nine branch executions is used to select a particular two-bit state machine in the selected set of state machines. Each state machine is a two-bit saturating counter for counting the directions taken by the most recent few branches that accessed this particular sute machine. Typically a particular state machine is accessed by the same static branch, although other branches may access the same sute machine. A larger sute machine value is indicative of more taken instances of a branch. A smaller state machine value is indicative of more not taken instances of a branch. Upon selection of a state machine, the state machine is accessed. If die present overall count is "greater" then a branch is predicted taken. If the present overall count is "lesser" then a branch is predicted not taken. The direction history of the most recent rune branch executions is held a tune-bit shift register which is clocked or shifted each time a branch mstmction is successfully decoded. The immediate branch direction just predicted is the new direction history value that is shifted mto the shift register. A history bit value of one mdicates a branch taken. A history bit value of zero mdicates a branch not taken. Dunng a decode cycle, the linear decode PC 424 is used to perform a BHT Uble lookup. If a PC- relative branch instruction is decoded, dien tbe accessed sUte machine immediately predicts die branch direction, although the actual instruction subsequently fetched and decoded is determmed at the end of the decode cycle by die macroinstmction decoder 230. Subsequently, the branch condition (BRCOND) operation generated by decodmg of die conditional branch mstmction is resolved by logic in tbe scheduler 260, at which time the sute machine is updated. If the branch is actually taken, the sute machine is decremented unless already at the maximum value (3). If the branch is actually not taken, the sute machine is incremented unless already at a minimum value (0). Accordmgly, a state machine value of 0 and 1 respectively mdicate a strong and a mild prediction of a branch not taken. A state machine value of 2 and 3 respectively indicate a mild and a strong prediction of a branch taken. To support updatmg of BHT entnes. a copy of the branch address and direction history bits for accessmg the BHT and a copy of the sute machine value are passed to tbe scheduler 260 along with the branch condition (BRCOND) operation. Since a maximum of one BRCOND is included in an Op quad, the BHT support mformauon is Ugged to the Op quad applied to the scheduler 260. It is advanUgeous for reducing circuit size and complexity that the BHT does not coπuin entry ugs (addresses of imear decode PC 424 associated widi decoded conditional branches) that are typical in cache strucmres. It is further advanUgeous that the BHT has a large number of entnes so that tbe contention rate is low. The information saved in a scheduler 260 Op quad along with an associated BRCOND operation has a width of fifteen bits mcludmg four branch address bits, nine current history bits, and the immediately accessed two state machine bits, the upper bit of which is also the predicted direction for the immediate branch. The first thirteen bits are used, when necessary, to reaccess the BHT and to update a sute machine value. The final two bits are modified to create the new state machine value. When a branch is mispredicted, the set of history vaiues the nine-bit branch history shift register are corrected to reflect the actual direction taken by die branch. Furtheπnore. the shift register is "shifted back" to correspond to the mispredicted branch, then updated based on me acmal branch direction and which branch direction was predicted. A retum address stack (RAS) (not shown) is a target address cache for retum (RET) transfer control instructions. RAS is an eight entry, 32-bit wide, single-ported RAM that is managed as a circular buffer using a single three-bit pointer. During each cycle at most one access, either a read access for a RET decode or a write access for a CALL decode, is performed. RAS caches RET return addresses and predicts retum addresses which inherently specify a target address indirectly, in contrast to other transfer control instructions that contain a direct specification of target address. RAS is advanugeously utilized since a particular RET instruction often changes target address between different executions of the instmction. RAS discovers and anticipates the target address value for each RET instmction execuuon dirough momtonng of the return addresses that are saved - pushed on a suck - by CALL instmctions. Correspondmg CALL and RET instructions typically occur dynamically in pairs and in last-in-first-out LIFO order with respect to other CALL and RET instmction pairs. Each time a CALL instmction is successfully decoded, die logical remm address of die CALL instruction is saved (pushed) to a circular buffer managed as a LIFO stack. Each time a RET instmction is successfully decoded, the retum address value currently on die top of the RAS is employed as the predicted Urget address for the RET and die value is popped from the RAS. RAS achieves a high prediction rate although mispredictions do occur because CALLs and RETs do not always occur in nested pairs, only near CALLs and RETs and not far CALLs and RETs are supported, and mispredictions occur because of die finite depth of die RAS. When a conditional branch misprediction occurs, RAS attempts to restore the sute pnor to misprediction by setting the top of stack pomter to the previous condition because CALL and RET instmctions may have been speculatively decoded and the top-of-stack pomter thereby modified. The onginal pointer, before the misprediction, is to be restored. Restoration followmg a misprediction is supported by die scheduler 260. Each scheduler 260 Op quad is Ugged with a current initial top-of-stack pomter value m effect dunng the decode cycle in which the Op quad was generated. When the BRCOND Op generated for a conditional branch instrucuon is resolved and found to be mispredicted, die top-of-stack pomter ugged to the scheduler Op quad is supplied to the RAS dunng a restart cycle that is generated by the scheduler 260. RAS replaces the current top- of-stack vaiue with die scheduler Op quad top-of-stack pomter Ug. Referring to Figure 5, a schematic block diagram depicts an instmction decoder emulation circuit 231 mcludmg an instruction register 512, an entry pomt circuit 514, an emulation code sequencer 510, an emulation code memory 520 and an Op substimtion circuit 522. The instmction decoder emulation circuit 500 is a circuit within the instmction decoder 220. The instmction decoder emulation circuit 231 receives instmction bytes and associated predecode information from the instruction buffer 408 connected to the instruction fetch control circuit 218. the BTB 456 or die instmcuon cache 214. The mstmction buffer 408 is connected to and supphes die instruction register 512 with x86 lnstmcuons. The instmction register 512 is connected to the entry point circuit 514 to supply emulation code ROM entry pomts. The entry pomt circuit 514 receives the x86 instmction and, from die x86 instrucuon operation code (opcode), generates an entry pomt address, a beginning address pointing mto the emulation code memory 520. In this manner an address of an instruction in emulation code memory 520 is synthesized from the opcode of an x86 instmcuon. Tne address is denved oaseα on die x86 instruction byte, particularly the firet and second bytes of the x86 instruction as well as information such as the modem byte, prefixes REP and REPE, the protected mode bit and effective dau size bit DSz. Generally, closely related x86 instructions have similarly coded bit fields, for example a bit field indicative of instruction type is the same among related x86 instmctions, so that a single entry m the emulation code memory 520 corresponds to several x86 instructions. Entry pomts are generally synthesized by readmg die x86 instructions and assigning bits of the entry pomt address accordmg to the values of particular 86 instmction bit fields. The instruction register 512 is connected to the emulation code sequencer 510 which, m mm, is connected to the emulation code memory 520. The emulation code sequencer 510 applies the entry pomt to the emulation code memory 520 and receives sequencmg mformauon from the emulation code memory 520. The emulation code sequencer 510 either controls the sequencmg of instmctions or, when a new sequence is to be started, apphes an entry pomt to the emulation code memory 520. Operations (Ops) encoded m the emulation code memory 520 are output by the emulation code memory 520 to the Op substimtion circuit as Op quads or Op umts. The Ops correspond to a template for RISC-type x86 operation. This template mcludes a plurality of fields mto which codes are selectively substimted. The emulation code memory 520 is connected to the Op substimtion circmt 522 to supply Ops mto which the vanous Op fields are selectively substimted. Functionally, the entry pomt circuit 514 calculates an entry pomt mto the emulation code ROM 232 or emulation code RAM 236. The sequence m emulation code ROM 232 determines the functionality of an instmction. The emulation code memory 520 mcludes an on-chip emulation code ROM 232 and an external emulation code RAM 236. The emulation code memory 520 mcludes encoded operations that direct how the processor 120 functions and defines bow x86 instmctions are executed. Bodi die emulation code ROM 232 and RAM 236 mclude a plurality of operation (Op) instmction encodings havmg a Op coding format that is the same m ROM 232 and RAM 236. For example, m one embodiment die emulation code ROM 232 has a capacity of 4K 64-bιt words. The Op coding format is typically a format defined m 30 to 40-bιts for example. In one embodiment, a 38-bit format, shown in Figures 6A through 6E. is defined The emulation code ROM 232 base address locauon withm the emulation space is fixed. The external emulation code RAM 236 is resident standard memory address space withm cacheable memory. The emulation code RAM 236 base address location withm the emulation space is fixed. The 32-bιt emulation code RAM 236 address is formed by die fixed base address of die emulation code RAM 236 which supplies bits the most significant fifteen bits < 31: 17 > , and the Op address which furnishes fourteen bits < 16:3 > concatenated to the base address bits. The two least significant bits < 1:0 > of the emulation code RAM address are set to zero. The fourteen bit Op address m emulation code RAM 236 is the same as the Op address m emulation code ROM 232. Operauons (Ops) are stored m Op coding format, for example 38-bιts, the external emulation code RAM 236 in 64-bit words. Bits m excess of the Op coding format bits of the 64-bit words are used to store control transfer (OpSeq) information. The external emulation code RAM 236 is typically used for test and debug purposes, allowmg for patching of any instmction encoded in the emulation code ROM 232, and for implementing special functions such as system management mode (SMM). For example, if an instmction in emulation code ROM 232 is found to funcuon improperly, the extemal emulation code RAM 236 is accessed to temporanly or permanently substitute for the improperly-functioning fixed code m the emulation code ROM 232. Access to the external emulation code RAM 236 is typically gained using one of two techniques. In a firet technique, a one-bit field in an OpSeq field of an element of emulation code memory 520 designates that the next address for fetching instructions is located in external emulation code RAM 236. In diis firet technique, the on-chip emulation code ROM 232 initiates execuuon of die external emulation code RAM 236. In a second technique, a vector address is simply supplied for vectoring to an entry point in the emulation code RAM 236. The instmction cache 214, instmction fetch control circuit 218 and instmction decoder 220 function in three instmction fetch and decode modes. In a firet mode, the instmction decoder 220 fetches emulation code Op quads from the on-chip emulation code ROM 232. Each Op quad includes four operations (Ops) plus control transfer information (OpSeq) for determining the next cycle of fetch and decode function. In a second mode, die instmction fetch control circuit 218 controls fetching of x86 macroinstmction bytes from the instruction cache 214, which is part of the on-chip Ll instmction cache 214. The x86 macroinstmctions are decoded by die macroinstmction decoder 230, which generates four operations (Ops). Four Ops plus d e OpSeq field form a full Op quad. The instmction decoder 220 performs any coded control transfers usmg die branch unit 234 and vectormg functionality of the macroinstruction decoder 230. In a third mode, die instmction fetch control circuit 218 controls fetching of 64-bit words conuining emuiauon code in Op coding format from the instmction cache 214, one 64-bit word per cycle. Each 64-bit word corresponds to a smgle operation (Op). In other embodiments, a plurality of 64-bit words may be accessed per cycle. An embodiment which four 64- bit words are accessed, the emulation code RAM 236 supplies a full Op quad in the manner of the on-chip emulation code ROM 232 so that a fully-reprogrammable processor with full efficiency is achieved. A fully- reprogrammable processor advanugeously permits soft impiemenuuon of greatly differing processors, for example an x86 processor and a PowerPC" in a smgle hardware. In tbe first and third operating three modes, control transfer information is formatted into an operation sequencing (Opseq) field of the Op quad. Unconditional control transfers, such as branch (BR) and remm from emulation (ERET) operations, are controlled completely usmg d e Opseq control transfer mformauon. Conditional transfers, such as branch on condition (BRcc). are controlled usmg a combmation of the Opseq field and a branch condition (BRCOND) operation. An OpSeq field format graphic is shown m Figure 7. The 16- bit OpSeq field 700 mcludes a two-bit sequencmg action (ACT) field 710, a smgle-bit extemal emcode field 712 and a 13-bιt operation (Op) address field 714. Four sequencmg actions the ACT field 710 are encoded, as follows: ACT Operation Descπption 0 0 BR/BRcc uncond/cond branch to emcode address 0 1 BSR/BSRcc uncond/cond "call" to emcode address 1 0 ERET/ERETcc remm from emulation to inst decodmg 1 1 SRET/SRETcc retum from emulation call Whether a sequencmg action of an OpSeq is unconditional or conditional depends on die presence or absence, respectively, of a branch condition (BRCOND) Op elsewhere within the Op quad. The BRCOND Op within the Op quad specifies the condition to be tested and the alternate emulation code urget address. No explicit sutic branch direction prediction bit exists. Instead the predicted action and next address are always specified by die OpSeq field 700 and die "not predicted" next address is always specified by die BRCOND Op. A BRCOND Op is always paired with a BSR sequencmg action including unconditional calls. For unconditional and conditional "predicted-taken" calls, die BRCOND Op specifies the remm address to be saved. The external emcode field 712 is set to one if emulation code to be executed is located in extemal emulation code RAM 236. The external emcode field 712 is set to zero if emulation code to be executed is located in internal emulation code ROM 232. The Op address field 714 designates an address of a target Op within a non-entry point Op quad. The Opseq control transfer information controls unconditional control transfers when an Op quad or 64- bit memory word is fetched and arranged or "instantaneously decoded", designation of the next mstmcuon to be decoded is controlled by die Opseq field alone. The Opseq field specifies one of three alternative actions. First, the Opseq field directs fetching ot emulation code from emulation code ROM 232 at a specified 14-bit smgle operation word address so that an emulation code ROM 232 Op quad is fetched. Second, the Opseq field directs fetching of emulation code from emulation code RAM 236 at a specified 14-bιt smgle operation word address so that an emulation code RAM 232 64-bit memory word is fetched. Third, die Opseq field mcludes a remm from emulation (ERET) directive, which directs the instmction decoder 230 to remm to x86 microinstruction decoding. Emulation code fetched from die emulation code ROM 232 is fetched in the form of aligned Op quads. A branch to an intermediate location within an Op quad causes the preceding operations within the Op quad to be treated as mvalid by fetching NOOPs in place of the preceding operations. The byte memory addresses for fetching 64-bit memory words from emulation code RAM 236 are created by concatenating a specified 14-bit operation address with three least significant bits set to zero, thereby creating an aligned 8-bit address. Tbe byte memory addresses for fetching 64-bit memory words are 8 -bit aligned, thus rendering memory Op decodmg and fetch/decode advancement consistent and simple. Tbe Opseq control transfer informauon also controls designation of the immediate next mstmcuon to be decoded for conditional control transfers. The branch condition (BRCOND) operation specifies the condition code to be tested and evaluated and specifies an alternative 14-bιt emulation code fetch and decode address. Thus, Opseq control transfer mformauon for conditional control transfers effectively specifies the predicted padi of die conditional branch. The BRCOND address typically is either die 14-bit Urget Op word address or die 14-bit Op word address of the next "sequential" operation (Op). More generally, the BRCOND address may specify a fully general two-way conditional branch. Note that the word sequential is placed m quoUtion marks to mdicate that, although die "sequential " address generally pomts to an mstmction which immediately precedes the present instmction, the "sequential" address may be set to any addressed location. A conditional ERET operation is implemented by setting the Opseq field to specify an ERET operation so that the conditional ERET is predicted taken. If tbe ERET operation is subsequentiy found to be mispredicted, men the x86 macroinstmction stream directed by the ERET is aborted and the sequential macroinstmction stream specified by the BRCOND operation is restarted. BRCOND operations are loaded mto the scheduler 260 m an unissued sute. BRCOND operations are evaluated in-order by the brancn resolution unit of die scheduler 260. If the branch is properiy predicted, the branch is marked Completed. Odierwise, die BRCOND state is left unissued and triggers a branch abort signal when detected by die Op commit unit. The emulation code memory 520 supports a single-level (no nesting) subroutine functionality, in which an Opseq field is set to specify alternatives for fetching emulation code. The alternatives are structured as a typical two-way conditional branch, except that a 14-bit Op word address from the immediate field of a BRCOND Op within the Op quad or memory Op is loaded into a subroutine remm address register. The subroutine remm address register stores the 14-bit Op word address plus a single bit which designates whether the retum address is located in emulation code ROM 232 or RAM 236. The condition code specified by die BRCOND Op may be any alternative, mcludmg TRUE, so that both unconditional and conditional (predicted- taken) subroutines may be specified. However, die BRCOND Op must be specified to avoid loading an undefined value into tbe subroutine remm address register. All emulation code subroutine support and remm address register management is performed by the emulation code sequencer 510 at the front of the pipeime. Thus remm address register loading and usage is fully synchronous with standard decoder timi g so that no delays are introduced. Two-Waγ Emulation Code Branching The emulation code ROM 232 is storage for a plurality of sequences of operations (Ops). An operation sequence begins at a defined entry pomt that is hard-coded into the emulation code ROM 232 and extends to a remm from emulation (ERET) Opseq directive that ends the operation sequence. The number of operations m a sequence is typically variable as is appropnate for performing vanous different functions. Some simple x86 instmctions have only a single Op entry m the emulation code ROM 232, although diese instmctions are fetched widi Op quad granuiaπty. Other more complex x86 instmctions use many component operations. The emulation code ROM 232 storage is stmcmred as a plurality of Op quads, programmed mto a fixed ROM address space. Each Op quad includes tour RISC Op fields and one Opseq field. The operation sequences are typically not aligned within the Op quads so that, absent some techmque for branciung to mterspersed locations in emulation code ROM 232, many ROM umts die emulation code ROM 232 are unusable, wasting valuable integrated circuit space. Furthermore, because the entry pomt address of an instmcuon in emulation code ROM 732 is syndiesized from die opcode of an x86 instmction, the entry pomt addresses often are forced into fixed positions spread throughout the ROM address space with intervening gaps that lead to unused portions of ROM. ROM positions diat are left without access via an entry pomt are free for other usage but are not conveniently sequential to allow access. The OpSeq field provides a techmque for branching to these mterspersed locations, thereby substantially eliminating wasted space. Each of the four RISC Op fields of an Op quad stores a simple, RISC-like operation. The OpSeq field stores a control code diat is i y .mtnim.r-.ti-.. to the emulation code sequencer 510 and directs the emulation code sequencer 510 to branch to a next location in die emulation code ROM 232. Each of the four RISC Op fields in die emulation code ROM 232 may store a branch operation, either conditional or unconditional, and thereby specify a urget address so that a plurality of branches may be encoded a smgle Op quad. In some embodiments of the mstmction decoder emulation circuit 231, the Op quad is limited to havmg at most a smgle branch operation to direct Op order in comoination with the OpSeq field. The combination of a conditional branch Op in one of the four RISC Op fields and die OpSeq field in an Op quad yields an Op quad with two possible target or next addresses. For an Op quad having a plurality of target addresses, the emulation code sequencer 510 directs the sequence of operations by selecting a hard-coded, predicted target address. Thus, for an Op quad including an conditional branch, the emulation code sequencer 510 selects a hardcoded OpSeq target address in preference over the conditional branch. The unconditional branch is subsequently handled m accordance with die branch prediction functionality of die processor 120 so that no additional branch handling overhead is incurred by implementing two-way emulation code branching. Emulation microcode may be wπtten so that a BRCOND Op is positioned in one of the first three positions of the Op quad. Thus, the Ops following the BRCOND Op widiin die Op quad are executed based on the predicted direction rather than whether tbe branch is ultimately taken. If the branch is ultimately found to be correctly predicted, all of die Ops of die Op quad and die Ops of subsequent Op quads are committed to the scheduler 260. If the branch is ultimately found to be mispredicted, all of the Ops followmg the BRCOND Op plus all subsequent Op quads are aborted. The emulation code is supplied to mclude the branch conditions, a urget address, a "sequential * address, and also die prediction for the branch condition. For most mstmctions, the OpSeq field alone supplies die next fetch address, either a vector address or an ERET remm. This is advanUgeous for simplifying the control hardware, supplying a fast and simple control logic that controls operation fetching without analysis of conditional branching or branch prediction. For conditional branch mstmctions, the OpSeq field supplies a predicted branch address and a BRCOND operation in the quad specifies a condition code to be evaluated and specifies the alternate fetch address in case of misprediction. The emulation code handling advanugeously achieves the flexibility of nonsequential Op quad fetching in which die instruction control sequence is selected by die program with few constraints. Accordmgly, the OpSeq field is advanugeously used to efficiently fit Op sequences mto nonused locations the emulation code ROM 232. The emulation code handling also mcludes the flexibility ot optional two-way branciung m tbe case of conditional branches and also the case of a subroutme call which may be directed to remm to substantially any locauon rather than being constrained to remm to the mstmction followmg tbe calling mstmcuon. This usage of the OpSeq field to branch to a target address advanugeously achieves unconditional branciung without incurring a time or cycle penalty. Svstem Embodiments Superscalar processor 120 may be incorporated into a wide vanety of system configurations, illustratively mto standalone and networked personal computer systems, worksuuon systems, multimedia systems, network server systems, multiprocessor systems, embedded systems, integrated telephony systems, video conferencing systems, etc. Figure 8 depict an illustrative set of suiuble system configurations for a processor, such as superscalar processor 120, that has an instruction decoder which implements two-way emulation code branciung. in particular. Figure 8 depicts a suitable comomation of a suDerscalar processor having an instruction decoder that implements two-way emulation code branching with suiuble, bus configurations, memory hierarchies and cache configurations, I/O interfaces, controllere, devices, and peripheral components. While die invention has been described widi reference to various embodiments, it will be understood that these embodiments are illustrative and that the scope of the invention is not limited to them. Many variations, modifications, additions, and improvements of the embodiments described are possible. Additionally, structures and functionality presented as hardware in the exemplary embodiment may be implemented as software, firmware, or microcode in alternative embodiments. For example, the description depicts a macroinstmction decoder having short decode pathways including diree routors 430, 432 and 434, three instmction registere 450, 452 and 454 and diree short decodere SDecO 410, SDecl 412 and SDec2 414. In other embodiments, different numbers of short decoder pathways are employed. A decoder that employs two decoding pathways is highly suiuble. These and odier variations, modifications, additions, and improvements may fall within the scope of the mvention as defined in die ciaims which follow.

Claims: WHAT IS CLAIMED IS: I. An instmction decoder m a superscalar processor, compnsmg: an emulation sequencer havmg a first mput terminal for receivmg an entry pomt signal, a second mput terminal and an output terminal for producmg an addressmg signal; an emulation ROM havmg an mput terminal coupled to the emulation sequencer output terminal, a sequencmg signal output terminal coupled to the emulation sequencer second mput terminal for producmg a sequencmg signal, and an operation (Op) output terminal for generating an output Op, the emulation ROM mcludmg a plurality of Operation (Op) umts, each Op umt mcludmg: a fixed-number plurality of Ops; and a sequencmg control mformauon for designating a sequential next Op within the emulation ROM for subsequent execution, the sequencmg control mformauon bemg applied to the emulation sequencer second terminal for controlling sequencmg order by the emulation sequencer. 2. An mstmcuon decoder according to Claim 1 , further compnsmg. an mstmcuon register for temporaπly hold g an instmction for decodmg, an entry pomt circuit coupled to die instmcuon register for receivmg the mstmcuon. the entry pomt circuit generating an entry pomt signai denved from the mstmction and bemg coupled to the emulation sequencer for supplying the entry pomt signal. 3. An mstmction decoder accordmg to Claim 1 , wherem each Op umt mcludes a plurality of four Ops and the sequencmg control mformation is held m an operation sequence field. 4. An instruction decoder accordmg to Claim 1, wherem vanous Ops of die fixed-number plurahty of Ops are conditional sequencmg control Ops so that an Op umt mcludmg a conditional sequencmg control Op m combination with die sequencmg control information mcludes a plurality of sequencmg control options, the sequencmg of the sequencmg mformation bemg controlled by the instruction decoder and die sequencmg of die conditional sequencmg control Op bemg controlled bv a branch circuit of the superscalar processor. 5 An mstmcuon decoder according to Claim 1. wherem the seauencine control mformauon is held m an operation sequence field and is selected from control mformation mcludmg unconditional branch sequence information and return from emulation sequence information. 6. An mstmction decoder in a superscalar processor, compnsmg: a plurahty of first type macromstmcuon decoders for simultaneously decodmg a plurality of instmctions m a predetermined group of firet type instmctions; and an emulation ROM decoder mcludmg: an emulation sequencer havmg a first mput terminal for receivmg an entry pomt signal, a second mput terminal and an output terminal for producmg an addressmg signal; an emulation ROM havmg an mput terminal coupled lo the emulation sequencer output terminal, a sequencmg signal output terminal coupled to die emulation sequencer second mput terminal for producmg a sequencmg signal, and an operation (Op) output terminal for generating an output Op, die emulation ROM mcludmg a plurality of Operation (Op) umts, each Op umt mcludmg. a fixed-number plurality of Ops; and a sequencmg control mformation for designating a sequential next Op withm the emulation ROM for execution, the sequencmg control mformation bemg applied to die emulation sequencer second terminal for controlling sequencmg order bv the emulation sequencer 7. An instmction decoder accordance with Claim 6 wherem the predetermined group of firet type mstmctions decoded m parallel by the first type macromstmcuon decoders substantially mcludes mstmctions that translate to fewer than three operations. 8. An instmction decoder accordance with Claim 7, further compnsmg: a second type instmction decoder for decodmg instructions m a predeteπmned group of second type instmctions, the second type instructions substantially mcludmg mstmctions havmg a more complex address form dian die first type instmctions. 9. An instmction decoder accordance with Claim 8 wherem the emulation ROM decoder decodes instmctions a predetermined group of third type instructions, the third type instmctions bemg generally more complex than die firet type and second type instructions. 10. An instmction decoder accordmg to Claim 6, further compnsmg: an instruction register for temporarily hold g an instruction for decodmg; an entry pomt circuit coupled to tbe instrucuon register for receivmg the mstmcuon, die entry pomt circuit generating an entry pomt signal denved from die instmction and bemg coupled to the emulation sequencer for supplying die entry pomt signal. 11. An mstmcuon decoder according to Claim 6, wherem each Op umt mcludes a plurality of four Ops and the sequencmg control mformauon is held m an operation sequence field. 12. An mstmction decoder accordmg to Claim 6, wherem vanous Ops of the fixed-number plurality of Ops are conditional sequencmg control Ops so that an Op umt mcludmg a conditional sequencmg control Op m combmation with the sequencmg control mformation mcludes a plurality of sequencmg control options, the sequencmg of the sequencmg mformation bemg controlled by die instruction decoder and the sequencmg of die conditional sequencmg control Op bemg controlled by a branch circuit of the superscalar processor. 13. An instmction decoder accordmg to Claim 6, wherem the sequencmg control mformauon is held m an operation sequence field and is selected from control mformation mcludmg unconditional branch sequence mformauon and remm from emulation sequence mformation. 14. An mstmction decoder a superscalar processor, compnsmg: an emulation sequencer for generating an addressmg signai; an emulation ROM coupled to the emulation sequencer to receive the addressmg signal, the emulation ROM mcludmg a memory stoπng a plurality of Op quads and producmg a sequencmg signal and an output operation (Op) m response to the addressmg signal, each Op quad mcludmg: a four Ops; and a sequencing control ---formation for designating a sequential next Op within die emulation ROM for subsequent execution, die sequencing control information being applied to the emulation sequencer second terminal for controlling sequencing order by die emulation sequencer. 15. An instmction decoder according to Claim 14, further compnsmg: an instmction register for temporarily holding an instruction for decodmg; an entry point circuit coupled to the instmction register for receiving the instmction, the entry point circuit generating an entry pomt signal denved from the stmction and bemg coupled to the emulation sequencer for supplying the entry pomt signal. 16. An instruction decoder accordmg to Claim 14, wherem vanous Ops of the Op quad are conditional sequencing control Ops so that an Op quad includmg a conditional sequencmg control Op in combination widi die sequencing control information includes a plurality of sequencing control options, the sequencmg of the sequencing information being controlled by the instmction decoder and die sequencing of the conditional sequencing control Op bemg controlled by a branch circuit of the superscalar processor. 17. An instmction decoder accordmg to Claim 14, wherem the sequencmg control information is held in an operation sequence field and is selected from control information mciuding unconditional branch sequence information and remm from emulation sequence information. 18. An mstmction decoder in a superscalar processor for convening CISC-type instmctions to RISC- type operations (Ops), compnsmg: a plurality of first type macroinstniction decoders for simultaneously decoding a plurality of CISC-type instructions in a predetermined group of first CISC-type instructions mto RISC-type operations (Ops); and an emulation ROM decoder including: an emulation sequencer for generating an addressmg signal, an emulation ROM coupled to the emulation sequencer to receive the addressing signal, the emulation ROM including a memory stoπng a plurality of Op quads and producing a sequencing signal and an output operation (Op) in response to the addressmg signal, each Op quad including: a four Ops; and a sequencmg control information for designating a sequential next Op within the emulation ROM for subsequent execution, die sequencing control information being applied to die emulation sequencer second terminal for controlling sequencmg order by die emulation sequencer. 19. An instmction decoder in accordance with Claim 18 wherem the predetermined group of firet CISC-type instructions decoded in parallel by the first type macroinstmction decodere substantially includes instructions that translate to fewer than three RISC-type Ops. 20. An instmction decoder in accordance widi Claim 19, further comprising: a second CISC-type instruction decoder for decoding instmctions in a predeteπmned group of second CISC-type instructions, the second type instructions substantially including instructions having a more complex address form than die first CISC-type instmctions. 21. An mstmction decoder in accordance widi Claim 20 wherem the emulation ROM decoder decodes CISC-type instmctions a predetermined group of third CISC-type instmctions, the third CISC-type instmctions being generally more complex than the first CISC-type and second CISC-type instmctions. 22. A computer system compnsing: a memory subsystem which stores daU and instructions; and a processor operably coupled to access the dau and instructions stored in the memory subsystem, wherem the processor includes an instruction decoder further including: an emulation sequencer having a firet mput terminal for receiving an entry pomt signal, a second mput terminal and an output terminal for producmg an addressmg signal an emulation ROM having an mput terminal coupled to the emulation sequencer output terminal, a sequencing signal output terminal coupled to the emulation sequencer second input terminal for producing a sequencing signal, and an operation (Op) output terminal for generating an output Op, the emulation ROM including a plurality of Operation (Op) units, each Op unit including: a fixed-number plurality of Ops; and a sequencing control information for designating a sequential next Op within the emulation ROM for subsequent execuuon, the sequencing control information being applied to the emulation sequencer second terminal for controlling sequencmg order by die emulation sequencer. 23. In a computer system havmg a memory subsystem for stoπng daU and instmctions and a processor operably coupled to access the dau and instmctions stored in the memory subsystem, an instmction decoder for decoding die instmctions for execution on the processor, tbe instmction decoder bemg further characterized as comprising: an emulation sequencer havmg a first mput terminal for receiving an entry point signai, a second input terminal and an output terminal for producing an addressmg signal; an emulation ROM having an mput terminal coupled to die emulation sequencer output terminal, a sequencing signal output terminal coupled to the emulation sequencer second mput terminal for producmg a sequencmg signal, and an operation (Op) output terminal for generating an output Op, the emulation ROM mciuding a plurality of Operation (Op) umts, each Op umt mcludmg: a fixed-number plurality of Ops; and a sequencing control information for designating a sequential next Op within the emulation ROM for subsequent execution, die sequencmg control information being applied to the emulation sequencer second terminal for controlling sequencmg order by die emulation sequencer.

Inventors: FAVOR JOHN G, FAVOR, JOHN, G.
Applicants: ADVANCED MICRO DEVICES INC, ADVANCED MICRO DEVICES, INC.
Application year: 1996
Main classification: G06F9
IPC codes: G06F9