Central processing unit with integrated graphics functions

[0002] This application is a continuation of and claims the benefit of U.S. application Ser. No. 09/244,187, filed Feb. 4, 1999, which is a divisional of U.S. application Ser. No. 08/638,390, filed Apr. 26, 1996 now abandoned, which is a continuation-in-part of U.S. application Ser. No. 08/236,572, filed Apr, 29, 1994, now U.S. Pat. No. 5,734,874.

[0003] The present invention relates to a superscalar central processing unit (CPU) having integrated graphics capabilities.

[0004] The end result of most graphics applications is the generation of an image on a display or piece of paper. The basic elements of the image are the individual pixels and the location of each pixel. Thus, the basic values manipulated by a processing system are representations of the pixels and their locations, or addresses.

[0005] A typical representation of a pixel for a computer display uses RGB (red, green, blue) format. In this format, multiple bits for each of the R, G and B values indicates the intensity of the red, green and blue guns on the CRT. The combination of the different intensities gives the desired colors. In an alternate format, rather than specifying the intensity of each gun directly, the values could be used to index into a color look-up table (LUT) which then provides the desired intensity value for each gun of a CRT. One typical format uses 8 bits for each of the R, G and B values. In some formats, another field, called alpha (α) is used to represent either the transparency or relative coverage of an object over the pixel for 3-D applications. In 3-D applications, depending on the viewpoint, which pixel at of a particular X, Y location is to be displayed must be chosen amongst a number of planes of pixels in the Z plane. If a pixel in front is relatively transparent, the pixel behind might be allowed to show through, giving some combination of the colors of the two pixels.

[0006] Alternate types of pixel representations are used. For instance, CYM (cyan [light blue], magenta [purplish-red], and yellow) are typically used for printers, with a subtractive operation between the intensities, rather than additive as for RGB. Yet another representation, YUV, is used to give a luminance value and two values of chroma, and was developed for broadcast television to be compatible with black and white TVs which only have a luminance value. Black and white monitors use a grey scale, which is specified by the intensity of each pixel.

[0007] The display of an image in graphics processing requires producing the appropriate pixel values for each pixel at each address in a frame buffer, which stores information to be displayed on the screen. The pixel values at each location in the frame buffer may be created by various rendering techniques, which are the operations for creating the image in the frame buffer. Rendering will typically use a number of primitives, which are basic building blocks of the pictures, such as points, lines, polygons, circles, etc.

[0008] For 3-D images, additional factors include the particular viewpoint used, with appropriate lighting effects, such as shading and reflection. In addition, particular objects may be colored or textured to make them more realistic. The lighting and shading effects are accomplished by varying the intensities of the individual pixels in the area to be shaded or have a reflection. This typically involves, at the processing level, the multiplication of pixel values by a constant. This is one example of a graphics intensive operation in which many pixels may be required to be multiplied by the same or varying constants.

[0009] In 3-D graphics, an image is generated in three dimensions. This is stored in memory as an X, Y plane representing the first face of a cube, with a series of slices through the cube representing different Z positions, each having its own X, Y plane representation. When viewing the image on the display, the viewpoint must be selected to determine which X, Y plane is visible at any particular viewpoint. This typically involves a comparison operation in which the pixels' Z positions are compared to each other to determine which to put in the frame buffer for display. In addition, the pixel position may be compared to the viewpoint Z position. Thus, extensive comparison operations are another attribute of graphics manipulation.

[0010] In addition to determining which image is in front for 3-D applications, images may be clipped for a variety of reasons. For instance, if a triangle is partially behind a square, it may be most efficient to render the triangle, then render the square, and clip the triangle where it is hidden by the square. In addition, windows may be generated, or the edge of a screen may vary depending upon the scale of an images to be displayed, thus creating additional boundaries where an image must be cut off. Thus, it is often necessary to compare a particular pixel position, or address, to an edge boundary or clipping position.

[0011] In video graphics, there are additional complications for processing images. In particular, a large number of different images must be generated very rapidly, thus requiring fast throughput plus large amounts of memory. Compression techniques are thus very important in eliminating the amount of memory. One such compression technique involves motion estimation. In movement from one frame to another, often most of the image will not change, with only a portion moving. The portion moving, or the whole if it is moving, often will typically be shifted, and thus storage can be saved by indicating the amount of shift rather storing a whole new image. The amount of movement is typically determined by comparing a block of pixels in one image to those in another image frame, and moving the positions of the blocks around relative to each other until a best match is obtained.

[0012] Other considerations in video include the need to deal with images in multiple formats, and the need to convert one format into another to make it compatible with other images.

[0013] There are three major barriers to achieving high performance in graphics computer systems. The first barrier is in floating point processing throughput. Graphics applications typically perform large amount of figure manipulation operations such as transformations and clippings using floating point data. The second barrier is in integer or fixed point processing throughput. Graphics applications also typically perform large amount of display operations such as scan conversion and color interpolation using integer or fixed point data. The third barrier is in memory references. The above-described operations typically require large amount of memory references for reading from and writing into, for example, the frame and Z-buffers.

[0014] Historically, the CPU's in early prior art computer systems are responsible for both graphics as well as non-graphics functions. No special hardware are provided to assist these early CPUs in performing the large amount of floating and fixed point processing, nor memory references. While the designs of these early prior art computer systems are simple, their performance are typically slow.

[0015] Some later prior art computer systems provide auxiliary display processors. The auxiliary display processors would off load these later CPUs from some of the display related operations. However, these later CPUs would still be responsible for most of the graphics processing. Typically, the bandwidth of the system buses of these later prior art computer systems are increased correspondingly to accommodate the increased amount of communications between the processors over the buses. The auxiliary display processors may even be provided with their own memory to reduce the amount of memory contentions between the processors. While generally performance will increase, however, the approach is costly and complex.

[0016] Other later prior art computer systems would provide auxiliary graphics processors with even richer graphics processors would off load the CPUs of these later prior art computer systems from most of the graphics processing. Under this approach extensive dedicated hardware as well as sophisticated software interface between the CPUs and the auxiliary graphics processors will have to be provided. While performance will increase even more, however, the approach is even more costly and more complex than the display processor approach.

[0017] In the case of microprocessors, as the technology continues to allow more and more circuitry to be packaged in a small area, it is increasingly more desirable to integrate the general purpose CPU with built-in graphics capabilities instead. Some modern prior art computer systems have begun to do that. However, the amount and nature of graphics functions integrated in these modern prior art computer systems typically are still very limited. Particular graphics functions known to have been integrated include frame buffer checks, add with pixel merge, and add with Z-buffer merge. Much of the graphics processing on these modern prior art systems remain being processed by the general purpose CPU without additional built-in graphics capabilities, or by the auxiliary display/graphics processors.

[0018] The performance of a CPU in doing graphics operations may be affected by the structure of the CPU itself. For instance, most modern CPUs employ a cache memory and a TLB (translation look-aside buffer). The cache memory is a small memory storing frequently accessed instructions or data by a computer program. This is based on the realization that many applications programs do loops or repeatedly access data which is in proximity to each other. Thus a speed savings can be achieved by having a small amount of data and instructions on the microprocessor chip itself or an external, dedicated cache which is more quickly accessed than main memory. However, in graphics functions, the cache size may be overwhelmed in processing a large image. The TLB is a small cache of page translations from a virtual address used by a program to a physical address in memory, and misses may occur more often for graphics operations because of the amount of data that needs to be addressed.

[0019] In RISC (reduced instruction set computing) processors a superscalar approach is used in which multiple, relatively simple, instructions are executed in parallel. This requires a number of parallel execution units for performing these instructions. In addition, these processors are typically pipelined, with each instruction entering the pipeline to be followed by another instruction, and thus multiple instructions are being processed in the pipeline at the same time. Accordingly, the design of the processor requires that the execution units and pipelines be constructed so that it is unlikely that any two sequential instructions will require the same execution unit, thus not allowing them to be issued in parallel.

[0020] One implementation of a RISC microprocessor incorporating graphics capabilities is the Motorola MC88110. This microprocessor, in addition to its integer execution units, and multiply, divide and floating point add units, adds two special purpose graphics units. The added graphics units are a pixel add execution unit, and a pixel pack execution unit. The Motorola processor allows multiple pixels to be packed into a 64-bit data path used for other functions in the other execution units. Thus, multiple pixels can be operated on at one time. The packing operation in the packing execution unit packs the pixels into the 64-bit format. The pixel add operation allows the adding or subtracting of pixel values from each other, with multiple pixels being subtracted at one time in a 64-bit field. This requires disabling the carry normally generated in the adder on each 8-bit boundary. The Motorola processor also provides for pixel multiply operations which are done using a normal multiply unit, with the pixels being placed into a field with zeros in the high order bits, so that the multiplication result will not spill over into the next pixel value representation.

[0021] The Intel I860 microprocessor incorporated a graphics unit which allowed it to execute Z-buffer graphics instructions. These are basically the multiple operations required to determine which pixel should be in front of the others in a 3-D display.

[0022] The present invention provides an optimized, superscalar microprocessor architecture for supporting graphics operations in addition to the standard microprocessor integer and floating point operations. Independent execution paths are provided for different graphics instructions to allow parallel execution of instructions which commonly occur together. The invention also optimizes the use of register file accesses to avoid, as much as possible, interference between graphics instructions needing to access a register file and other instruction accesses which would occur in combination with graphics instructions, thereby avoiding pipeline stalls and allowing parallel execution.

[0023] In a preferred embodiment, a number of graphics instructions are provided, and corresponding logic is added, to the floating point units of a superscalar architecture. The floating point register file, which is separate from the integer register file, is used for most graphics accesses. In particular, additional circuitry and instructions are allocated between a floating point adder and a floating point multiply unit to maximize throughput.

[0024] In one embodiment, the floating point adder is modified to add logic units, which are already in the integer unit, but are added to the floating point unit to allow access of the FP register file for logical operations. The FP unit is also modified to add multiplexing circuitry which can perform expand/merge functions and alignment functions.

[0025] A floating point multiply unit is modified by adding circuitry specifically designed for performing pixel distance computations, packing operations, and compare operations for graphics. Additionally, the floating point paths are extended from 56 bits (53 plus GRS) to 64 bits to allow multiple pixels to be processed in parallel.

[0026] In another aspect of the present invention, modifications are made to the microprocessor, and instructions are provided, to limit the memory accesses required for graphics operations. A “partial store” instruction is provided, with appropriate circuitry in the load/store unit, to allow designated bytes in a 64-bit block to be stored at a destination. The bytes can be designated using a mask, which is created by a compare operation. This could be used, for example, in doing a Z compare to determine which pixel is in front in a 3-D rendering operation, and only storing the pixels which are not obscured. This one operation avoids the need for multiple pixel accesses and compare operations with subsequent writing into the destination, thus greatly reducing the number of memory accesses required.

[0027] Short load and store operations are provided to load or store less than an entire 64-bit register. One or more bytes could be loaded at a time into a 64-bit register until the register is full. Only then would be contents of the register be written to memory, thus minimizing the number of memory accesses.

[0028] In another aspect of the invention, array instructions are provided to remap the address space into a 3-D blocked address space. Addresses are arranged according to the XYZ coordinates in a series of small blocks, rather than describing an entire XY plane first, and then incrementing the Z amount. This addressing mode provides a greater likelihood of a hit in the on-chip cache and in the TLB, thus minimizing the need to go to an external cache or main memory when the data being processed is localized in three dimensions. This is useful, for instance, in 3-D medical imaging applications, such as CAT scans. In a preferred embodiment, additional logic is added to the integer execution unit to implement the necessary address transformations according to these instructions.

[0029] The present invention also provides a number of other unique instructions and associated circuitry for supporting graphics operations. Edge handling instructions are provided to generate masks used to indicate the edge (such as a window boundary) of an image. The floating point adder is modified in a preferred embodiment to support alignment instructions which realign graphics values on 64-bit boundaries.

[0030] For a fuller understanding of the present invention, reference should be made to following description taken in conjunction with the accompanying drawings.

[0031] FIG. 1 illustrates the CPU of an exemplary graphics computer system incorporating the teachings of the present invention.

[0032] FIG. 2 illustrates the two partitioned execution paths of one embodiment of the graphics circuitry added in FIG. 1.

[0033] FIG. 3 illustrates the Graphics Status Register (GSR).

[0034] FIG. 4 illustrates the first ALU partitioned execution path of FIG. 2 in further detail.

[0035] FIG. 5 illustrates the second multiply partitioned execution path of FIG. 2 in further detail.

[0036] FIGS. 6a-6cillustrate the graphics data formats, the graphics instruction formats, and the graphic instruction groups in further detail.

[0037] FIG. 6dillustrates a partitioned multiply with a controllable carry forward according to one embodiment of the multiplier of FIG. 5.

[0038] FIG. 6eillustrates a multiple pixel multiply operation according to one embodiment of the invention.

[0039] FIGS. 7a-7cillustrate the graphics data alignment instructions and circuitry in further detail.

[0040] FIGS. 8a-8gillustrate the graphics data packing instructions and circuitry in further detail.

[0041] FIGS. 9a-9billustrate the graphics data pixel distance computation instruction and circuitry in further detail.

[0042] FIGS. 10a-10billustrate the graphics data edge handling instructions in further detail.

[0043] FIGS. 11a-11iillustrate the graphics data 3-D array addressing instructions and circuitry in further detail.

[0044] In the following description, for purposes of explanation, specific numbers, materials and configurations are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without the specific details. In other instances, well-known systems are shown in diagrammatic or block diagram form in order not to obscure the present invention.

[0045] Overall CPU Architecture

[0046] Referring now to FIG. 1, a block diagram illustrating the CPU of an exemplary graphics computer system incorporating the teachings of the present invention is shown.

[0047] As illustrated, a CPU 10 includes a prefetch and dispatch unit (PDU) 46 connected to an instruction cache 40. Instructions are fetched by this unit from either the cache or main memory on a bus 12 with the help of an instruction memory management unit (IMMU) 44a. Data is fetched either from main memory or from a data cache 42 using a load storage unit (LSU) 48 working with a data memory management unit (DMMU) 44b.

[0048] PDU 46 issues up to four instructions in parallel to multiple pipelined execution units along a pipeline bus 14. Integer operations are sent to one of two integer execution units (IEU), an integer multiply or divide unit 30 and an integer ALU 31. These two units share access to an integer register file 36 for storing operands and results of integer operations.

[0049] Separately, three floating point operation units are included. A floating point divide and square root execution unit 25, a floating point/graphics ALU 26 and a floating point/graphics multiplier 28 are coupled to pipeline bus 14 and share a floating point register file 38. The floating point register file stores the operands and results of floating point and graphics operations.

[0050] The present invention uniquely modifies a floating point adder and floating point multiplier to include graphics capability. The choice of which hardware and functionality is added to the floating point adder vs. the floating point multiplier unit was optimized to improve pipeline throughput and limit memory bandwidth demands, as described in more detail below with respect to the individual execution units. In addition, many of the graphic operations and hardware are combined with the floating point units to share the floating point register file, thereby avoiding conflict with accesses to the integer register file by the integer execution units. Although graphics operations are typically fixed point type of operations, thus suggesting an integer unit might be more logical, the combination with a floating point unit not only eliminates conflicts with the integer register file, but also provides more precision by allowing the larger floating point data path to be used.

[0051] The graphics capability added to the floating point path allows integer operations to be issued at the same time along pipeline bus 14, thus processing in parallel. For example, for motion estimation, addition operations are required in conjunction with comparing operations for determining how much an image has shifted, as we will discuss below in connection with the pixel distance instruction. In another example, for a pixel packing operation, addition operations are also required. In another example, address computations may be done in the integer unit in combination with edge handling instructions for determining the edge of a window or other feature.

[0052] The data path through the floating point units 26 and 28 has been extended to 64 bits in order to be able to accommodate 8—8 bit pixel representations, (or 4-16 bit, or 2-32 bit representations) in parallel. Thus, the standard floating point path of 53 bits plus 3 extra bits (guard, round and sticky or GRS) has been expanded to accommodate the graphics instructions in accordance with the present invention.

[0053] Additionally, the IEU also performs a number of graphics operations, and appends address space identifiers (ASI) to the addresses of load/store instructions for the LSU 48, identifying the address spaces being accessed. LSU 48 generates addresses for all load and store operations. LSU 48 also supports a number of load and store operations, specifically designed for graphics data. Memory references are made in virtual addresses. The MMUs 44a-44binclude translation look-aside buffer (TLBs) to map virtual addresses to physical addresses.

[0054] Two Partitioned Graphics Execution Paths

[0055] FIG. 2 shows the floating point/graphics execution units 26 and 28 in more detail. FIG. 2 illustrates that these provide two partitioned execution paths for graphics instructions, a first partitioned execution path in unit 26 and a second partitioned execution path in unit 28. Both of these paths are connected to the pipeline bus 14 connected to the prefetch and dispatch unit 46. As will be described in more detail below, the division of hardware and instructions between two different execution paths allows two independent graphics instructions to be executed in parallel for each cycle of a pipeline. The partitioning of instructions and hardware between the two paths has been done to optimize throughput of typical graphics applications.

[0056] Also shown is a graphics status register (GSR) 50. This register is provided external to the two paths, since it stores the scale factor and alignment offset data used by graphics instructions in both execution paths. Each execution path is provided the information in the graphics status register along bus 18. The graphics status register is written to along a bus 20 by the IEU.

[0057] Graphics Status Register

[0058] Referring now to FIG. 3, a diagram illustrating the relevant portions of one embodiment of the graphics status register (GSR) is shown. In this embodiment, the GSR 50 is used to store an offset in bits 0-2, and a scale factor in bits 3-8, with the remaining bits reserved. The offset is the least significant three bits of a pixel address before alignment (alignaddr_offset) 54, and the scaling factor is used for pixel formatting (scale_factor) 52. The alignaddr_offset 54 is stored in bits GSR[2:0], and the scale_factor 52 is stored in bits GSR[6:3]. As will be described in more detail below, two special instructions RDASR and WRASR are provided for reading from and writing into the GSR 50. The RDASR and WRASR instructions and the usage of alignaddr_offset 54 and scale_factor 52 will be described in further detail below.

[0059] FP/Graphics ALU 26

[0060] Referring now to FIG. 4, a block diagram illustrating the relevant portions of one embodiment of the first partitioned execution path in unit 26 is shown.

[0061] Pipeline bus 14 provides the decoded instructions from PDU 46 to one of three functional circuits. The first two functional units, partitioned carry adder 37 and graphics logical circuit 39, contain the hardware typically contained in a floating point adder and an integer logic unit. The circuitry has been modified to support graphics operations as discussed in more detail below. An additional circuit 60 has been added to support both graphics expand and merge operations and graphics data alignment operations. Control signals on lines 21 select which circuitry will receive the decoded instruction, and also select which output will be provided through a multiplexer 43 to a destination register 35c. Destination register 35c, and operand register 35aand 35bare illustrations of particular registers in the floating point register file 38 of FIG. 1.

[0062] At each dispatch, the PDU 46 may dispatch either a graphics data partitioned add/subtract instruction, a graphics data alignment instruction, a graphics data expand/merge instruction or a graphics data logical operation to unit 26. The partitioned carry adder 37 executes the partitioned graphics data add/subtract instructions, and the expand and merge/graphics data alignment circuit 60 executes the graphics data alignment instruction using the alignaddr_offset stored in the GSR 50. The graphics data expand and merge/graphics data alignment circuit 60 also executes the graphics data merge/expand instructions. The graphics data logical operation circuit 39 executes the graphics data logical operations.

[0063] The functions and constitutions of the partitioned carry adder 37 are similar to simple carry adders found in many integer execution units known in the art, except the hardware are replicated multiple times to allow multiple additions/subtractions to be performed simultaneously on different partitioned portions of the operands. Additionally, the carry chain can be optionally broken into smaller chains as described in detail below with reference to a multiplier in FIG. 6d.

[0064] The functions and constitutions of the graphics data logical operation circuit 39 are similar to logical operation circuits found in many integer execution units known in the art, except the hardware are replicated multiple times to allow multiple logical operations to be performed simultaneously on different partitioned portions of the operands. Thus, the graphics data logical operation circuit 39 will also not be further described.

[0065] The graphics data alignment circuit 60 will be described in further detail below.

[0066] FP/Graphics Multiply Unit 28

[0067] Referring now to FIG. 5, a block diagram illustrating the relevant portion of one embodiment of the FP/graphics multiply unit 28 in further detail is shown. In this embodiment, multiply unit 28 comprises a pixel distance computation circuit 56, a partitioned multiplier 58, a graphics data packing circuit 59, and a graphics data compare circuit 64, coupled to each other as shown. Additionally, a number of registers 55a-55c(in floating point register file 38) and a 4:1 multiplexer 53 are coupled to each other and the previously-described elements as shown. At each dispatch, the PDU 46 may dispatch either a pixel distance computation instruction, a graphics data partitioned multiplication instruction, a graphics data packing instruction, or a graphics data compare instruction to unit 28. The pixel distance computation circuit 56 executes the pixel distance computation instruction. The partitioned multiplier 58 executes the graphics data partitioned multiplication instructions. The graphics data packing circuit 59 executes the graphics data packing instructions. The graphics data compare circuit 64 executes the graphics data compare instructions.

[0068] The functions and constitutions of the partitioned multiplier 58, and the graphics data compare circuit 64 are similar to simple multipliers and compare circuits found in many integer execution units known in the art, except the hardware are replicated multiple times to allow multiple multiplications and comparison operations to be performed simultaneously on different partitioned portions of the operands. Additionally, multiple multiplexers are provided to the partitioned multiplier for rounding, and comparison masks are generated by the comparison circuit 64. The partitioned multiplier 58 is described in more detail below, but the graphics data compare circuit 64 will not be further described.

[0069] The pixel distance circuit 56 and the graphics data pack circuit 59 will be described in further detail below.

[0070] The present invention is being described with an embodiment of the graphics circuitry having two independent partitioned execution paths, and a particular allocation of graphics instruction execution responsibilities among the execution paths. However, based on the descriptions to follow, it will be appreciated that certain aspects of the present invention may be practiced with one or more independent partitioned execution paths, and the graphics instruction execution responsibilities allocated in any number of manners.

[0071] Data Formats

[0072] Referring now to FIGS. 6a-6c, three diagrams illustrating the graphics data formats, the graphics instruction formats, and the graphics instructions are shown. As illustrated in FIG. 6a, the exemplary CPU 10 supports three graphics data formats, an eight bit format (Pixel) 66a, a 16 bit format (Fixed16) 66b, and a 32 bit format (Fixed32) 66c. Thus, four pixel formatted graphics data are stored in a 32-bit word, 66a, whereas either four Fixed16 or two Fixed32 formatted graphics data are stored in a 64-bit word 66bor 66c. Image components are stored in either the Pixel or the Fixed16 format 66aor 66b. Standard audio data formats are also supported. Intermediate results are stored in either the Fixed16 or the Fixed32 format 66bor 66c. Typically, the intensity values of a pixel of an image, e.g., the alpha, green, blue, and red values (α, G, B, R), are stored in the Pixel format 66a. These intensity values may be stored in a band interleaved format where the various color components of a point in the image are stored together, or in a band sequential format where all of the values for one component are stored together. The Fixed16 and Fixed32 formats 66b-66cprovide enough precision and dynamic range for storing intermediate data computed during filtering and other simple image manipulation operations performed on pixel data. Graphics data format conversions are performed using the graphics data pack, expand, merge, and multiply instructions described below.

[0073] Instruction Formats

[0074] As illustrated in FIG. 6b, the CPU 10 supports three graphics instruction formats 68a-68c. Regardless of the instruction format 68a-68c, the two most significant bits [31:30] 70a-70cprovide the primary instruction format identification, and bits [24:19] 74a-74cprovide the secondary instruction format identification for the graphics instructions. Additionally, bits [29:25] (rd) 72a-72cidentify the destination (third source) register of a graphics (block/partial conditional store) instruction, whereas, bits [18:14] (rs1) 76a-76cidentify the first source register of the graphics instruction. For the first graphics instruction format 68a, bits [13:5] (opf) 80 and bits [4:0] (rs2) 82aidentify the op codes and the second source registers for a graphics instruction of that format. For the second and third graphics instruction formats 68b-68c, bits[13:5] (imm_asi) and bits [13:0] (simm_13), respectively, may optionally identify the ASI (address space identifiers). Lastly, for the second graphics instruction format 68b, bits[4:0] (rs2) further provide the second source register for a graphics instruction of that format (or a mask for a partial conditional store).

[0075] Graphics Instructions

[0076] As illustrated in FIG. 6c, the CPU 10 supports a number of GSR related instructions 200, a number of partitioned add/subtract/multiplication instructions 202 and 208, a number of graphics data alignment instructions 204, a number of pixel distance computation instructions 206, a number of graphics data expand/merge instructions 210 and packing instructions 212, a number of graphics data logical and compare instructions 214 and 216, a number of edge handling and 3-D array access instructions 218 and 220, and a number of memory access instructions 222. The execution unit used for each instruction type is shown.

[0077] GSR Read and Write

[0078] The GSR related instructions 200 include a RDASR and a WRASR instruction for reading and writing the alignaddr_offset and the scale_factor from and into the GSR 50. The RDASR and WRASR instructions are executed by the IEU 30. Typically, once written to, the offset and scale factor stored in GSR 50 will not change for a particular graphics application. The RDASR and WRASR instructions are similar to other CPU control register read/write instructions, thus will not be further described.

[0079] Add/Subtract Instructions

[0080] The graphics data partitioned add/subtract instructions 202 include four partitioned graphics data addition instructions and four partitioned graphics data substraction instructions for simultaneously adding and subtracting four 16-bit, two 16-bit, two 32-bit, and one 32-bit graphics data, respectively. These instructions add or subtract the corresponding fixed point values in the rs1 and rs2 registers of the floating point register file, and correspondingly place the results in the rd register of the floating point register file. As described earlier, the graphics data partitioned add/subtract instructions 202 are executed by the partitioned carry adder 37 in execution unit 26.

[0081] Multiply Instructions

[0082] The partitioned multiplier 58 of FIG. 5 used for the multiplication instructions 208 is illustrated in more detail in FIG. 6d. As FIG. 6dshows, the multiplier is partitioned into four units 108a-108d. In-between the multiplier units are multiplexers 109a-109c. These multiplexers will either propagate the carry bit to the next multiplier unit, or will inhibit the propagating of the carry bit, providing a zero input instead. When the carry bit is propagated, the multiplier units act as a single 64-bit multiplier. Alternately, it can be broken into two 32-bit multipliers by inhibiting the carry bit with multiplexer 109bwith the control signal !GR (! being the C language NOT operator). Thus, when it is not a graphics operation, the carry is allowed to propagate, otherwise it is inhibited. The selection logic for multiplexers 109aand 109cwill inhibit the carry if it is a graphics operation and it is not a 32-bit operation.

[0083] The graphics data partitioned multiplication instructions 208 include seven partitioned graphics data multiplication instructions for simultaneously multiplying either two or four 8-bit graphics data with another two or four corresponding 16-bit graphics data. FIG. 6eshows an example where a FMUL8×16 instruction multiplies four 8-bit graphics data (A-D) in the rs1 register by four corresponding 16-bit graphics data (w-z) in the rs2 register. For each product, the upper 16 bits are stored in the corresponding positions of the rd register (the rs1, rs2 and rd registers are in the floating point register file). A FMUL8×16AU and a FMUL8×16AL instruction multiplies the four 8-bit graphics data in the rs1 register by the upper and the lower halves of the 32-bit graphics data in the rs2 register, respectively. Similarly, for each product, the upper 16 bits are stored in the corresponding positions of the rd register.

[0084] A FMUL8SU×16 instruction multiplies the four upper 8-bits of the four 16-bit graphics data in the rs1 register by the four corresponding 16-bit graphics data in the rs2 register. Likewise, for each product, the upper 16 bits are stored in the corresponding positions of the rd register. A FMUL8UL×16 instruction multiplies the four lower 8-bits of the four 16-bit graphics data in the rs1 register by the four corresponding 16-bit graphics data in the rs2 register. For each product, the sign extended upper 8 bits are stored in the corresponding positions of the rd register.

[0085] A FMULD8SU×16 instruction multiplies the two 16-bit graphics data in the rs1 register by the two corresponding 16-bit graphics data in the rs2 register. For each product, the 24 bits are appended with 8-bit of zeroes and stored in the corresponding positions of the rd register. A FMULD8UL×16 instruction multiplies the two lower 8-bits of the two 16-bit graphics data in the rs1 register by the two corresponding 16-bit graphics in the rs2 register. For each product, the 24-bits are sign extended and stored in the corresponding positions of the rd register.

[0086] As described earlier, the graphics data partitioned multiplication instructions 208 are executed by the partitioned multiplier 58 in execution unit 28.

[0087] Expand and Merge Instruction

[0088] The graphics data expand and merge instructions 210 include a graphics data expansion instruction, and a graphics data merge instruction, for simultaneously expanding four 8-bit graphics data into four 16-bit graphics data, and interleavingly merging eight 8-bit graphics data into four 16-bit graphics data, respectively. A FEXPAND instruction takes four 8-bit graphics data in the rs2 register, left shifts each 8-bit graphics data by 4 bits, and then zero-extend each left shifted graphics data to 16-bits. The results are correspondingly placed in the rd register. A FPMERGE instruction interleavingly merges four 8-bit graphics data from the rs1 register and four 8-bit graphics data from the rs2 register, into a 64 bit graphics datum in the rd register. As described earlier, the graphics data expand and merge instructions 210 are executed by the expand/merge portions of the graphics data expand/merge and alignment circuit 60 in execution unit 28. The circuitry is basically a number of controlled multiplexers.

[0089] Logical Operations

[0090] The graphics data logical operation instructions 214 include thirty-two logical operation instructions for performing logical operations on graphics data. Four logical operations are provided for zeroes filling or ones filling the rd register in either single or double precision. Four logical operation instructions are provided for copying the content of either the rs1 or rs2 register in the rd register in either single or double precision. Four logical operation instructions are provided for negating the content of either the rs1 or rs2 register and storing the result into the rd register in either single or double precision. Some logical operations are provided to perform a number of Boolean operations against the content of the rs1 and rs2 registers in either single or double precision, and storing the Boolean results into the rd register. Some of these Boolean operations are performed after having either the content of the rs1 or the rs2 register negated first. As described earlier, these graphics data logical operation instructions 214 are executed by the graphics data logical operation circuit 39 in execution unit 26.

[0091] Data Compare Instructions

[0092] The graphics data compare instructions 216 include eight graphics data compare instructions for simultaneously comparing four pairs of 16-bit graphics data or two pairs of 32-bit graphics data. The comparisons between the graphics data in the rs1 and rs2 registers include greater than, less than, not equal, and equal. Four or two result bits are stored in the least significant bits in the rd register. Each result bit is set if the corresponding comparison is true. Complimentary comparisons between the graphics data, i.e., less than or equal to, and greater than or equal to, are performed by swapping the graphics data in the rs1 and rs2 registers. As described earlier, these graphics data compare instructions 216 are executed by the graphics data compare circuit 64 in execution unit 28.

[0093] The compare logic is placed in the same execution unit as the multiplier, rather than with the adder, in order to optimize instruction throughput. There are a number of operations where a compare and an add need to be done simultaneously. For example, in the rendering of a line, the color may be added using the adder while at the same time a comparison is done to determine which pixel is in front in the Z plane.

[0094] Data Alignment Instructions

[0095] Referring now to FIGS. 7a-7c, the graphics data alignment instructions, and the relevant portions of one embodiment of the graphics data alignment circuit are illustrated. As shown in FIG. 7a, there are two graphics data address calculation instructions 98a-98b, and one graphics data alignment instruction 100 for calculating addresses of misaligned graphics data, and aligning misaligned graphics data.

[0096] The ALIGNADDR instruction 98aadds the content of the rs1 and rs2 registers, and stores the result, except that the least significant 3 bits are forced to zeroes, in the rd register. The least significant 3 bits of the result are stored in the alignaddr_offset field of GSR 50. The ALIGNADDRL instruction 98bis the same as the alignaddr instruction 98a, except that the twos complement of the least significant 3 bits of the result is stored in the alignaddr_offset field of GSR 50.

[0097] The FALIGNDATA instruction 100 concatenates two 64-bit floating point values in the rs1 and rs2 registers to form a 16-byte value. The floating point value in the rs1 register is used as the upper half of the concatenated value, whereas the floating point value in the rs2 register is used as the lower half of the concatenated value. Bytes in the concatenated value are numbered from the most significant byte to the least significant byte, with the most significant byte being byte 0. Eight bytes are extracted from the concatenated value, where the most significant byte of the extracted value is the byte whose number is specified by the alignaddr_offset field of GSR 50. The result is stored as a 64 bit floating point value in the rd register.

[0098] Thus, as illustrated in FIG. 7b, by using the ALIGNADDRESS {_LITTLE} instruction to generate and store the alignaddr_offset in the GSR 50 (step a), copying the two portions of a misaligned graphics data block 99a-99bfrom memory into the rs1 and rs2 registers, aligning and storing the aligned graphics data block into the rd register using the FALIGNDATA instruction, and then copying the aligned graphics data block 101 from the rd register into a new memory location, a misaligned graphics data block 99a-99bcan be aligned in a quick and efficient manner.

[0099] As shown in FIG. 7c, in this embodiment, the graphics data alignment circuit 60 comprises a 64-bit multiplexer 51, coupled to each other and the floating point register file as shown. The multiplexer 51 aligns misaligned graphics data as described above. The same multiplexer, with different controls, can be used for the expand and merge operations.

[0100] Data Packing Instructions

[0101] Referring now to FIGS. 8a-8g, the graphics data packing instructions, and the relevant portions of the packing portion of the graphics data pack circuit 59 are illustrated. As illustrated in FIGS. 8a-8d, there are three graphics data packing instructions 106a-106c, for simultaneously packing four 16-bit graphics data into four 3-bit graphics data, two 32-bit graphics data into two 8-bit graphics data, and two 32-bit graphics data into two 16-bit graphics data.

[0102] The FPACK16 instruction 106atakes four 16-bit fixed values in the rs2 register, left shifts them in accordance to the scale_factor in GSR 50 (maintaining the clipping information), then extracts and clips 8-bit values starting at the corresponding immediate bits left of the implicit binary positions (between bit 7 and bit 6 of each 16-bit value). If the extracted value is negative (i.e., msb is set), zero is delivered as the clipped value. If the extracted value is greater than 255, 255 is delivered. Otherwise, the extracted value is the final result. The clipped values are correspondingly placed in the rd register.

[0103] The FPACK32 instruction 106btakes two 32-bit fixed values in the rs2 register, left shifts them in accordance to the scale_factor in GSR 50 (maintaining the clipping information), then extracts and clips 8-bit values starting at the immediate bits left of the implicit binary positions (i.e., between bit 23 and bit 22 of a 32-bit value). For each extracted value, clipping is performed in the same manner as described earlier. Additionally, the FPACK32 instruction 106bleft shifts each 32-bit value in the rs1 register by 8 bits. Finally, the FPACK32 instruction 106bcorrespondingly merges the clipped values from the rs2 register with the shifted values from the rs2 register, with the clipped values occupying the least significant byte positions. The resulting values are correspondingly placed in the rd register.

[0104] The FPACKFIX instruction 106atakes two 32-bit fixed values in the rs2 register, left shifts each 32-bit value in accordance to the scale_factor in GSR 50 (maintaining the clipping information), then extracts and clips 16-bit values starting at the immediate bits left of the implicit binary positions (i.e., between bit 16 and bit 15 of a 32-bit value). If the extracted value is less than −32768, −32768 is delivered as the clipped value. If the extracted value is greater than 32767, 32767 is delivered. Otherwise, the extracted value is the final result. The clipped values are correspondingly placed in the rd register.

[0105] As illustrated in FIGS. 8e-8g, in this embodiment, the graphics data packing circuit 59 comprises circuitry 248, 258 and 268 for executing the FPACK16, FPACK32, and FPACKFIX instructions respectively. The same actual circuitry may be used, with different controls. Three different drawings are used for ease of understanding the logic.

[0106] The circuitry 248 for executing the FPACK16 instruction comprises four identical portions 240a-240d, one for each of the four corresponding 16-bit fixed values in the rs2 register. Each portion 240a, . . . or 240dcomprises a shifter 242a, . . . or 242d, an OR gate 244a, . . . or 244d, and a multiplexer 246a, . . . or 246d, coupled to each other as shown. The shifter 242a, . . . or 242dshifts the corresponding 16-bit fixed value (excluding the sign bit) according to the scale factor stored in the GSR 50. The sign bit and the logical OR of bits [29:15] of each of the shift results are used to control the corresponding multiplexer 246a, . . . or 242d. Either bits [14:7] of the shift result, the value 0×FF or the value 0×00 are output.

[0107] The circuitry 258 for executing the FPACK32 instruction comprises two identical portions 250a-250b, one for each of the two corresponding 32-bit fixed values in the rs2 register. Each portion 250aor 250balso comprises a shifter 252aor 252d, an OR gate 254aor 254b, and a multiplexer 256aor 256b, coupled to each other as shown. The shifter 252aor 252dshifts the corresponding 32-bit fixed value (excluding the sign bit) according to the scale factor stored in the GSR 50. The sign bit and the logical OR of bits [45:31] of each of the shift results are used to control the corresponding multiplexer 256aor 256b. Either bits [30:23] of the shift result, the value 0×FF or the value 0×00 are output. The output is further combined with either bits [55:32] or bits [23:0] of the rs1 register.

[0108] The circuitry 268 for executing the FPACKFIX instruction also comprises two identical portions 260a-260b, one for each of the two corresponding 32-bit fixed values in the rs2 register. Each portion 260aor 260balso comprises a shifter 262aor 262d, a NAND gate 263aor 263b, a NOR gate 264aor 264b, two AND gates 265a-265bor 265c-265d, and a multiplexer 266aor 266b, coupled to each other as shown. The shifter 262aor 262dshifts the corresponding 32-bit fixed value (excluding the sign bit) according to the scale factor stored in the GSR 50. The logical AND of the sign bit and the logical NAND of bits [45:32] of each of the shift results, and the logical AND of the inverted sign bit and the logical NOR of bits [45:32] of each of the shift results, are used to control the corresponding multiplexer 266aor 266b. Either bits [31:16] of the shift result, the value 0×EFFF or the value 0×8000 are output.

[0109] Pixel Distance Instruction

[0110] Referring now to FIGS. 9a-9b, the pixel distance computation instructions, and the pixel distance computation circuit are illustrated. As shown in FIG. 9a, there is one graphics data distance computation instruction 138 for simultaneously accumulating the absolute differences between graphics data, eight pairs at a time. The PDIST instruction 138 subtracts eight 8-bit graphics data in the rs1 register from eight corresponding 8-bit graphics data in the rs2 register. The sum of the absolute values of the differences is added to the content of the rd register. The PDIST instruction is typically used for motion estimation in video compression algorithms.

[0111] As shown in FIG. 9b, in this embodiment, the pixel distance computation circuit 56 comprises eight pairs of 8 bit subtractors 57a-57b. Additionally, the pixel distance computation circuit 56 further comprises three 4:2 carry save adders 61a-61c, a 3:2 carry save adder 62, two registers 63a-63b, and a 11-bit carry propagate adder 65, coupled to each other as shown. The eight pairs of 8 bit subtractors 57a-57h, the three 4:2 carry save adders 61a-61c, the 3:2 carry save adder 62, the two registers 63a-63b, and the 11-bit carry propagate adder 65, cooperate to compute the absolute differences between eight pairs of 8-bit values, and aggregate the absolute differences into a 64-bit sum.

[0112] The pair of 8-bit subtractors 57 generate the absolute value of the difference by first subtracting a first pixel from a second pixel, and then subtracting the second pixel from the first pixel. The value which is positive is chosen by multiplexer 59. Four pixel values are combined in adder 61b, and another four in adder 61a. The results are then combined in another carry/save adder 61cto give the final two result values to adder 62, which then combines them with the previous accumulated sum from the rd register.

[0113] The final result is stored in register 63bin the floating point register file. This register is a 64-bit register, and the results can eventually accumulate to use up a large number of bits. The upper 53-bit portions are provided back to the input through register 63a, with the lower bits being combined in carry save adder 62 into an 11-bit carry propagate adder 65. Thus, the data paths are minimized through the carry save adders to be 8 bits initially into carry save adder 61aand 61b, then 9 bits to adder 61c, 10 bits to adder 62 and eventually 11 bits for adder 65. The use of separate register 63aallows the upper order bits in the accumulated results to be separately combined with any carry from the adder 65.

[0114] Data Edge Handling Instructions

[0115] Referring now to FIGS. 10a-10b, the graphics data edge handling instructions are illustrated. The edge handling instructions are used to create a mask used to identify a start or stop address for an image, such as where an image is being written to a window on a display, and the edges of the window need to be identified. As illustrated, there are six graphics edge handling instructions 140a-140f, for simultaneously generating eight 8-bit edge masks, four 16-bit edge masks, and two 32-bit edge masks in big or little endian format.

[0116] The masks are generated in accordance to the graphics data addresses in the rs1 and rs2 registers, where the addresses of the next series of pixels to render and the addresses of the last pixels of the scan line are stored respectively. The generated masks are stored in the least significant bits of the rd register.

[0117] Each mask is computed from the left and right edge masks as follows:

[0118] a) The left edge mask is computed from the 3 least significant bits (LSBs) of the rs1 register, and the right edge mask is computed from the 3 (LSBS) of the rs2 register in accordance to FIG. 10b.

[0119] b) If 32-bit address masking is disabled, i.e., 64-bit addressing, and the upper 61 bits of the rs1 register are equal to the corresponding bits of the rs2 register, then rd is set equal to the right edge mask ANDed with the left edge mask.

[0120] d) Otherwise, rd is set to the left edge mask.

[0121] Additionally, a number of conditions codes are modified as follows:

[0122] a) a 32-bit overflow condition code is set if bit 31 (the sign) of rs1 and rs2 registers differ and bit 31 (the sign) of the difference differs from bit 31 (the sign) of rs1; a 64-bit overflow condition code is set if bit 63 (the sign) of rs1 and rs2 registers differ and bit 63 (the sign) of the difference differs from bit 63 (the sign) of rs1.

[0123] b) a 32-bit negative condition code is set if bit 31 (the sign) of the difference is set; a 64-bit negative condition code is set if bit 63 (the sign) of the difference is set.

[0124] c) a 32-bit zero condition code is set if the 32-bit difference is zero; a 64-bit zero condition code is set if the 64-bit difference is zero.

[0125] As described earlier, the graphics edge handling instructions 140a-140fare executed by the IEU 30. No additional hardware is required by IEU 30.

[0126] Memory Bandwidth Optimization Techniques

[0127] The present invention provides a number of instructions and corresponding logic for limiting the number of memory accesses required in a CPU superscalar environment including a cache memory.

[0128] The graphics data memory reference instructions 222 include a partial (conditional) store, a short load, a short store, a block load and a block store instruction. The graphics data load and store instructions are qualified by the imm_asi and asi values to determine whether the graphics data load and store instructions 144 and 146 are to be performed simultaneously on 8-bit graphics data, 16-bit graphics data, and whether the operations are directed towards the primary or secondary address spaces in big or little endian format. For the store operations, the imm_asi and asi values further serve to determine whether the graphics data store operations are conditional. These graphics data memory reference instructions 222 are executed by the LSU 48 of the CPU 10, and access the floating point register file.

[0129] Partial Store Instruction

[0130] A partial (conditional) store operation allows only certain pixel values within a 64-bit group to be stored in a register or to memory. This instruction may be used, for instance, when writing to the frame buffer for displaying on a display. A mask is previously generated with a compare operation to determine which pixels are in front in the Z plane. Only the pixels which are in front (visible) are written, with the mask blocking out the rest. Thus, rather than the need to compare and write on a pixel-by-pixel basis, an entire 64-bit block of pixels can be written at one time, greatly reducing the number of memory accesses required.

[0131] The partial store is a read-modify-write operation for use with cached memory, not main memory. A partial (conditional) store operation stores the appropriate number of values from the rd register to the addresses specified by the rs1 register using the mask specified (in the rs2 bit location). The mask has the same format as the results generated by the pixel compare instructions. The most significant bit of the mask corresponds to the most significant part of the rs1 register.

[0132] Short Load/Store Instructions

[0133] Load and store operations are typically performed for the integer unit, and stored in the integer register file. Accordingly, circuitry is added to the load/store unit to modify the control of the same logic so that a floating point load is treated like an integer load, except that the destination is the floating point register file. The store operation is the reverse of the load, with the control logic in the load/store unit being modified in the same manner.

[0134] A short 8-bit load operation may be performed against arbitrary byte addresses. For a short 16-bit load operation, the least significant bit of the address must be zero. Short loads are zero extended to fill the entire floating point destination register. Short loads are zero extended to fill the entire floating point destination register. Short stores access either the low order 8 or 16 bits of the floating point source register. A block load/store operation transfers data between 8 contiguous 64-bit floating point registers and an aligned 64-byte block in memory.

[0135] 3-D Array Addressing Instructions

[0136] Referring now to FIGS. 11a-11b, the 3-D array addressing instructions and circuitry are illustrated.

[0137] FIG. 11aillustrates a 3-D address space as a cube. In a typical addressing scheme for a frame buffer, the pixels are specified starting with the first row in the Y direction, with the position in the row in the X direction being indicated by increasing addresses. When the end of the row is reached, the next row in the Y direction is started, and the X positions are stepped through again. When an entire XY plane has been addressed, the next XY plane in the Z direction is then addressed. Such an addressing scheme is problematic for a CPU using a cache and a TLB, since references to separate Z planes will result in cache or TLB misses. Accordingly, the array instructions of the present invention remap the pixels into a format which provides a greater likelihood of cache and TLB hits for certain applications, such as medical imaging. Using the array instructions, the pixels in the memory space are mapped into a new memory space using the revised addressing scheme. The addressing scheme breaks up the memory space into a number of blocks, with a smaller block 120 in FIG. 11abeing indicated as the “lower” portion of an address. The middle-size block 122 is made up of a series of lower blocks 120. Finally, the upper block 124 is made up of a number of middle blocks 122.

[0138] Because the total image volume may vary, the size of the upper block can vary as well. As illustrated in FIG. 11c, six different values of rs2 can specify the number of elements (upper blocks) included within the address space. The particular value will vary the split between the XY and Z coordinates for the upper block as indicated in FIGS. 11e-11g. FIGS. 11e-11galso indicate the different pixel formats of 8, 16 and 32 bits, with the larger formats including a single zero or double zero being shifted in the least significant bits as illustrated.

[0139] For example, using the format of FIG. 11e, if the rs2 value is zero, the upper block has one bit for the X position, and no bits for the Y or Z position. If the rs2 value is 1, there is one bit for X, 17, one bit for Y, 18 (17 plus rs2=18) and 3 bits for Z, extending from bit 19 (17 plus 2 rs2) to 22 (20 plus 2rs2). Once the pixels have been converted into a new address space, that new address space can be used for the other operations for rendering or otherwise manipulating an image.

[0140] As illustrated in FIG. 11a, there are three 3-D array addressing instructions 142a-142cfor converting 8-bit, 16-bit, and 32-bit 3-D addresses to blocked byte addresses. Each of these instructions 142a-142cconverts 3-D fixed point addresses in the rs1 register to a blocked byte address, and store the resulting blocked byte address in the rd register. These registers are in the integer register file. These instructions 142a-142care typically used for address interpolation for planar reformatting operations. Blocking is performed at the 64-byte level to maximize external cache block reuse, and at the 64k-byte level to maximize external cache block reuse, and at the 64k-byte level to maximize the data cache's translation lookaside buffer (TLB) entry reuse, regardless of the orientation of the address interpolation. The element size, i.e., 8-bits, 16-bits, or 32-bit, is implied by the instruction. The value of the rs2 register specifies the power of two sizes of the X and Y dimension of a 3d image array. In the embodiment illustrated, the legal values are from zero to five. A value of zero specifies 64 elements, a value of one specifies 128 elements, and so on up to 2048 elements for the external cache block size specified through the value of five. The integer parts of X, Y, and Z (rs1) are converted to either the 8-bit, the 16-bit, or the 32-bit format. The bits above Z upper are set to zero. The number of zeros in the least significant bits is determined by the element size. An element size of eight bits has no zero, an element size of 16-bits has one zero, and an element size of 32-bits has two zeros. Bits in X and Y above the size specified by the rs2 register are ignored.

[0141] As described earlier, the 3-D array addressing instructions 142a-140aare also executed by the IEU 30. FIG. 11billustrates one embodiment of the additional circuitry provided to the IEU 30. The additional circuitry 300 comprises two shift registers 308 and 310, and concatenation logic 304, coupled to each other as shown. The appropriate bits from the lower and middle integer portions of X, Y, and Z (i.e., bits <12:11>, <34:33>, <55>, <16:13>, <38:35>, and <59:56>) are first stored into shift register A 308. Similarly, the appropriate bits of the upper integer portion of Z (i.e., <63:60>) and the upper integer portions of Y and X are loaded into shift register B 310 from concatenation logic 304, depending on the value of rs2. Finally, zero, one, or two zero bits are shifted into shift register A 308, with the shift out bits shifted into shift register B 310, depending on the array element size (i.e., 8, 16, or 32 bits).

[0142] While the present invention has been described in terms of presently preferred and alternate embodiments, those skilled in the art will recognize the invention is not limited to the embodiments described. The method and apparatus of the present invention can be practiced with modification and alteration within the spirit and scope of the appended claims. The description is thus to be regarded as illustrative of, and not limiting the scope of the present invention.