1. Technical Field
The present invention relates to a system and method for executing instructions utilizing a preferred slot alignment mechanism. More particularly, the present invention relates to a processor architecture that includes a vector register file, a shared data path, and instruction execution logic to process source operands that correspond to both Single Instruction Multiple Data (SIMD) computations and scalar computations.
2. Description of the Related Art
A continuing importance of gaming applications and other numerically intensive workloads has generated an upsurge in novel computer architectures tailored for such functionality. Gaming applications feature highly parallel code for functions such as game physics, which have high computation and memory requirements. Gaming applications also include scalar code for functions such as game artificial intelligence that require fast response times and a full-featured programming environment.
A challenge found with these computer architectures is that they have overly complex designs, which results in area and power inefficiencies. For example, the computer architectures implement both Single Instruction Multiple Data (SIMD) execution units as well as scalar execution units. As a result, they include duplication logic for instruction decoding, instruction issue, register dependence tracking and resolution, register files, execution resources, and instruction commit.
What is needed, therefore, is a system and method that provides a power-efficient, area-efficient, low-complexity, and high performance computer architecture.
It has been discovered that the aforementioned challenges are resolved using a processor architecture that uses a vector register file, a shared data path, and instruction execution logic to process source operands that correspond to both Single Instruction Multiple Data (SIMD) computations and scalar computations. The processor architecture divides a vector into four “slots,” each including four bytes, and locates scalar data items in “preferred slots” to ensure proper positioning. As a result, the processor architecture eliminates a requirement for separate issue slots, separate pipelines, and the control complexity for separate scalar units.
A local storage area includes instructions that are fed into a buffer in 128-byte increments, which supplies the instructions to a fetch unit in 64 byte increments (representing a first and second half of a memory line). In turn, the instructions proceed through a shared datapath that includes instruction line buffers, issue/branch units, and a vector register file. The vector register file provides operands in data widths of 16 bytes, regardless of whether the instruction corresponds to a scalar computation or SIMD computation, to an appropriate execution unit for further processing, such as a vector floating point unit, a vector fixed point unit, a data formatting and permute unit, and a load/store unit.
In order to process the scalar instructions correctly, scalar data items are aligned using a “preferred slot” mechanism with respect to a vector word. Instructions using the preferred slot mechanism include 1) shift and rotate instructions operating across an entire quad-word that specify a shift amount, 2) memory load and store instructions that require an address, and 3) branch instructions that use the preferred slot for branch conditions (conditional branches) and branch addresses (register-indirect branches). Branch and link instructions also use the preferred slot mechanism to deposit a function return address in a return address register.
In one embodiment, the preferred slot is four bytes in length and starts at the leftmost word element slot that includes byte locations 0 through 3. As such, when a scalar data item is only one byte in length the byte resides in byte location 3. When a scalar data item is a half-word in length, the half-word resides in byte locations 2-3. When a vector includes a 32-bit address, the address resides in byte locations 0-3. When a scalar data item is one word in length, the word resides in byte locations 0-3. When a scalar data item is two words in length, the double word resides in byte locations 0-7. And, when a scalar data item is four words in length, the quad word resides in byte locations 0-15.
The foregoing is a summary and thus contains, by necessity, simplifications, generalizations, and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting.
The present invention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings.
The following is intended to provide a detailed description of an example of the invention and should not be taken to be limiting of the invention itself. Rather, any number of variations may fall within the scope of the invention, which is defined in the claims following the description.
The overall architecture for a computer system 101 is shown in
The computers and computing devices connected to network 104 (the network's “members” include, e.g., client computers 106, server computers 108, personal digital assistants (PDAs) 110, digital television (DTV) 112 and other wired or wireless computers and computing devices. The processors employed by the members of network 104 are constructed from the same common computing module. These processors also preferably all have the same ISA and perform processing in accordance with the same instruction set. The number of modules included within any particular processor depends upon the processing power required by that processor.
For example, since servers 108 of system 101 perform more processing of data and applications than clients 106, servers 108 contain more computing modules than clients 106. PDAs 110, on the other hand, perform the least amount of processing. PDAs 110, therefore, contain the smallest number of computing modules. DTV 112 performs a level of processing between that of clients 106 and servers 108. DTV 112, therefore, contains a number of computing modules between that of clients 106 and servers 108. As discussed below, each computing module contains a processing controller and a plurality of identical processing units for performing parallel processing of the data and applications transmitted over network 104.
This homogeneous configuration for system 101 facilitates adaptability, processing speed and processing efficiency. Because each member of system 101 performs processing using one or more (or some fraction) of the same computing module, the particular computer or computing device performing the actual processing of data and applications is unimportant. The processing of a particular application and data, moreover, can be shared among the network's members. By uniquely identifying the cells comprising the data and applications processed by system 101 throughout the system, the processing results can be transmitted to the computer or computing device requesting the processing regardless of where this processing occurred. Because the modules performing this processing have a common structure and employ a common ISA, the computational burdens of an added layer of software to achieve compatibility among the processors is avoided. This architecture and programming model facilitates the processing speed necessary to execute, e.g., real-time, multimedia applications.
To take further advantage of the processing speeds and efficiencies facilitated by system 101, the data and applications processed by this system are packaged into uniquely identified, uniformly formatted software cells 102. Each software cell 102 contains, or can contain, both applications and data. Each software cell also contains an ID to globally identify the cell throughout network 104 and system 101. This uniformity of structure for the software cells, and the software cells' unique identification throughout the network, facilitates the processing of applications and data on any computer or computing device of the network. For example, a client 106 may formulate a software cell 102 but, because of the limited processing capabilities of client 106, transmit this software cell to a server 108 for processing. Software cells can migrate, therefore, throughout network 104 for processing on the basis of the availability of processing resources on the network.
The homogeneous structure of processors and software cells of system 101 also avoids many of the problems of today's heterogeneous networks. For example, inefficient programming models, which seek to permit processing of applications on any ISA using any instruction set, e.g., virtual machines such as the Java virtual machine, are avoided. System 101, therefore, can implement broadband processing far more effectively and efficiently than today's networks.
The basic processing module for all members of network 104 is the processor element (PE).
PE 201 can be constructed using various methods for implementing digital logic. PE 201 preferably is constructed, however, as a single integrated circuit employing a complementary metal oxide semiconductor (CMOS) on a silicon substrate. Alternative materials for substrates include gallium arsinide, gallium aluminum arsinide and other so-called III-B compounds employing a wide variety of dopants. PE 201 also could be implemented using superconducting material, e.g., rapid single-flux-quantum (RSFQ) logic.
PE 201 is closely associated with a dynamic random access memory (DRAM) 225 through a high bandwidth memory connection 227. DRAM 225 functions as the main memory for PE 201. Although a DRAM 225 preferably is a dynamic random access memory, DRAM 225 could be implemented using other means, e.g., as a static random access memory (SRAM), a magnetic random access memory (MRAM), an optical memory or a holographic memory. DMAC 205 facilitates the transfer of data between DRAM 225 and the APUs and PU of PE 201. As further discussed below, DMAC 205 designates for each APU an exclusive area in DRAM 225 into which only the APU can write data and from which only the APU can read data. This exclusive area is designated a “sandbox.”
PU 203 can be, e.g., a standard processor capable of stand-alone processing of data and applications. In operation, PU 203 schedules and orchestrates the processing of data and applications by the APUs. The APUs preferably are single instruction, multiple data (SIMD) processors. Under the control of PU 203, the APUs perform the processing of these data and applications in a parallel and independent manner. DMAC 205 controls accesses by PU 203 and the APUs to the data and applications stored in the shared DRAM 225. Although PE 201 preferably includes eight APUs, a greater or lesser number of APUs can be employed in a PE depending upon the processing power required. Also, a number of PEs, such as PE 201, may be joined or packaged together to provide enhanced processing power.
For example, as shown in
Input/output (I/O) interface 317 and external bus 319 provide communications between broadband engine 301 and the other members of network 104. Each PE of BE 301 performs processing of data and applications in a parallel and independent manner analogous to the parallel and independent processing of applications and data performed by the APUs of a PE.
Local memory 402 is not a cache memory. Local memory 402 is preferably constructed as an SRAM. Cache coherency support for an APU is unnecessary. A PU may require cache coherency support for direct memory accesses initiated by the PU. Cache coherency support is not required, however, for direct memory accesses initiated by an APU or for accesses from and to external devices.
APU 402 further includes bus 404 for transmitting applications and data to and from the APU. In a preferred embodiment, this bus is 1,024 bits wide. APU 402 further includes internal busses 408, 420 and 418. In a preferred embodiment, bus 408 has a width of 256 bits and provides communications between local memory 406 and registers 410. Busses 420 and 418 provide communications between, respectively, registers 410 and floating point units 412, and registers 410 and integer units 414. In a preferred embodiment, the width of busses 418 and 420 from registers 410 to the floating point or integer units is 384 bits, and the width of busses 418 and 420 from the floating point or integer units to registers 410 is 128 bits. The larger width of these busses from registers 410 to the floating point or integer units than from these units to registers 410 accommodates the larger data flow from registers 410 during processing. A maximum of three words are needed for each calculation. The result of each calculation, however, normally is only one word.
Using this standardized, modular structure, numerous other variations of processors can be constructed easily and efficiently. For example, the processor shown in
The chip package of
A final configuration is shown in
A plurality of BEs can be connected together in various configurations using such optical wave guides and the four optical ports of each BE. For example, as shown in
A matrix configuration is illustrated in
Using either a serial configuration or a matrix configuration, a processor for network 104 can be constructed of any desired size and power. Of course, additional ports can be added to the optical interfaces of the BEs, or to processors having a greater or lesser number of PEs than a BE, to form other configurations.
BE 1201 also includes switch unit 1212. Switch unit 1212 enables other APUs on BEs closely coupled to BE 1201 to access DRAM 1204. A second BE, therefore, can be closely coupled to a first BE, and each APU of each BE can address twice the number of memory locations normally accessible to an APU. The direct reading or writing of data from or to the DRAM of a first BE from or to the DRAM of a second BE can occur through a switch unit such as switch unit 1212.
For example, as shown in
As discussed above, all of the multiple APUs of a PE can independently access data in the shared DRAM. As a result, a first APU could be operating upon particular data in its local storage at a time during which a second APU requests these data. If the data were provided to the second APU at that time from the shared DRAM, the data could be invalid because of the first APU's ongoing processing which could change the data's value. If the second processor received the data from the shared DRAM at that time, therefore, the second processor could generate an erroneous result. For example, the data could be a specific value for a global variable. If the first processor changed that value during its processing, the second processor would receive an outdated value. A scheme is necessary, therefore, to synchronize the APUs' reading and writing of data from and to memory locations within the shared DRAM. This scheme must prevent the reading of data from a memory location upon which another APU currently is operating in its local storage and, therefore, which are not current, and the writing of data into a memory location storing current data.
To overcome these problems, for each addressable memory location of the DRAM, an additional segment of memory is allocated in the DRAM for storing status information relating to the data stored in the memory location. This status information includes a full/empty (F/E) bit, the identification of an APU (APU ID) requesting data from the memory location and the address of the APU's local storage (LS address) to which the requested data should be read. An addressable memory location of the DRAM can be of any size. In a preferred embodiment, this size is 1024 bits.
The setting of the F/E bit to 1 indicates that the data stored in the associated memory location are current. The setting of the F/E bit to 0, on the other hand, indicates that the data stored in the associated memory location are not current. If an APU requests the data when this bit is set to 0, the APU is prevented from immediately reading the data. In this case, an APU ID identifying the APU requesting the data, and an LS address identifying the memory location within the local storage of this APU to which the data are to be read when the data become current, are entered into the additional memory segment.
An additional memory segment also is allocated for each memory location within the local storage of the APUs. This additional memory segment stores one bit, designated the “busy bit.” The busy bit is used to reserve the associated LS memory location for the storage of specific data to be retrieved from the DRAM. If the busy bit is set to 1 for a particular memory location in local storage, the APU can use this memory location only for the writing of these specific data. On the other hand, if the busy bit is set to 0 for a particular memory location in local storage, the APU can use this memory location for the writing of any data.
Examples of the manner in which the F/E bit, the APU ID, the LS address and the busy bit are used to synchronize the reading and writing of data from and to the shared DRAM of a PE are illustrated in
As shown in
An additional segment of memory is associated with each LS addressable memory location. For example, memory segments 1729 and 1734 are associated with, respectively, local memory locations 1731 and 1732, and memory segment 1752 is associated with local memory location 1750. A “busy bit,” as discussed above, is stored in each of these additional memory segments. Local memory location 1732 is shown with several Xs to indicate that this location contains data.
DRAM 1702 contains a plurality of addressable memory locations 1704, including memory locations 1706 and 1708. These memory locations preferably also are 1024 bits in size. An additional segment of memory also is associated with each of these memory locations. For example, additional memory segment 1760 is associated with memory location 1706, and additional memory segment 1762 is associated with memory location 1708. Status information relating to the data stored in each memory location is stored in the memory segment associated with the memory location. This status information includes, as discussed above, the F/E bit, the APU ID and the LS address. For example, for memory location 1708, this status information includes F/E bit 1712, APU ID 1714 and LS address 1716.
Using the status information and the busy bit, the synchronized reading and writing of data from and to the shared DRAM among the APUs of a PE, or a group of PEs, can be achieved.
The result of the successful synchronized writing of the data into memory location 1708 is shown in
As shown in
As shown in
As shown in
The data in memory location 1708 become valid and current when an APU writes data into this memory location. The synchronized writing of data into memory location 1708 from, e.g., memory location 1732 of APU 1722, is illustrated in
As shown in
As shown in this figure, in empty state 1880, a synchronized writing operation is permitted and results in a transition to full state 1882. A synchronized reading operation, however, results in a transition to the blocking state 1884 because the data in the memory location, when the memory location is in the empty state, are not current.
In full state 1882, a synchronized reading operation is permitted and results in a transition to empty state 1880. On the other hand, a synchronized writing operation in full state 1882 is prohibited to prevent overwriting of valid data. If such a writing operation is attempted in this state, no state change occurs and an error message is transmitted to the APU's corresponding control logic.
In blocking state 1884, the synchronized writing of data into the memory location is permitted and results in a transition to empty state 1880. On the other hand, a synchronized reading operation in blocking state 1884 is prohibited to prevent a conflict with the earlier synchronized reading operation which resulted in this state. If a synchronized reading operation is attempted in blocking state 1884, no state change occurs and an error message is transmitted to the APU's corresponding control logic.
The scheme described above for the synchronized reading and writing of data from and to the shared DRAM also can be used for eliminating the computational resources normally dedicated by a processor for reading data from, and writing data to, external devices. This input/output (I/O) function could be performed by a PU. However, using a modification of this synchronization scheme, an APU running an appropriate program can perform this function. For example, using this scheme, a PU receiving an interrupt request for the transmission of data from an I/O interface initiated by an external device can delegate the handling of this request to this APU. The APU then issues a synchronize write command to the I/O interface. This interface in turn signals the external device that data now can be written into the DRAM. The APU next issues a synchronize read command to the DRAM to set the DRAM's relevant memory space into a blocking state. The APU also sets to 1 the busy bits for the memory locations of the APU's local storage needed to receive the data. In the blocking state, the additional memory segments associated with the DRAM's relevant memory space contain the APU's ID and the address of the relevant memory locations of the APU's local storage. The external device next issues a synchronize write command to write the data directly to the DRAM's relevant memory space. Since this memory space is in the blocking state, the data are immediately read out of this space into the memory locations of the APU's local storage identified in the additional memory segments. The busy bits for these memory locations then are set to 0. When the external device completes writing of the data, the APU issues a signal to the PU that the transmission is complete.
Using this scheme, therefore, data transfers from external devices can be processed with minimal computational load on the PU. The APU delegated this function, however, should be able to issue an interrupt request to the PU, and the external device should have direct access to the DRAM.
The DRAM of each PE includes a plurality of “sandboxes.” A sandbox defines an area of the shared DRAM beyond which a particular APU, or set of APUs, cannot read or write data. These sandboxes provide security against the corruption of data being processed by one APU by data being processed by another APU. These sandboxes also permit the downloading of software cells from network 104 into a particular sandbox without the possibility of the software cell corrupting data throughout the DRAM. In the present invention, the sandboxes are implemented in the hardware of the DRAMs and DMACs. By implementing these sandboxes in this hardware rather than in software, advantages in speed and security are obtained.
The PU of a PE controls the sandboxes assigned to the APUs. Since the PU normally operates only trusted programs, such as an operating system, this scheme does not jeopardize security. In accordance with this scheme, the PU builds and maintains a key control table. This key control table is illustrated in
As shown in
In operation, an APU issues a DMA command to the DMAC. This command includes the address of a storage location 2006 of DRAM 2002. Before executing this command, the DMAC looks up the requesting APU's key 1906 in key control table 1902 using the APU's ID 1904. The DMAC then compares the APU key 1906 of the requesting APU to the memory access key 2012 stored in the dedicated memory segment 2010 associated with the storage location of the DRAM to which the APU seeks access. If the two keys do not match, the DMA command is not executed. On the other hand, if the two keys match, the DMA command proceeds and the requested memory access is executed.
An alternative embodiment is illustrated in
The key masks for the APU keys and the memory access keys provide greater flexibility to this system. A key mask for a key converts a masked bit into a wildcard. For example, if the key mask 1908 associated with an APU key 1906 has its last two bits set to “mask,” designated by, e.g., setting these bits in key mask 1908 to 1, the APU key can be either a 1 or a 0 and still match the memory access key. For example, the APU key might be 1010. This APU key normally allows access only to a sandbox having an access key of 1010. If the APU key mask for this APU key is set to 0001, however, then this APU key can be used to gain access to sandboxes having an access key of either 1010 or 1011. Similarly, an access key 1010 with a mask set to 0001 can be accessed by an APU with an APU key of either 1010 or 1011. Since both the APU key mask and the memory key mask can be used simultaneously, numerous variations of accessibility by the APUs to the sandboxes can be established.
The present invention also provides a new programming model for the processors of system 101. This programming model employs software cells 102. These cells can be transmitted to any processor on network 104 for processing. This new programming model also utilizes the unique modular architecture of system 101 and the processors of system 101.
Software cells are processed directly by the APUs from the APU's local storage. The APUs do not directly operate on any data or programs in the DRAM. Data and programs in the DRAM are read into the APU's local storage before the APU processes these data and programs. The APU's local storage, therefore, includes a program counter, stack and other software elements for executing these programs. The PU controls the APUs by issuing direct memory access (DMA) commands to the DMAC.
The structure of software cells 102 is illustrated in
Cell body 2306 contains information independent of the network's protocol. The exploded portion of
Global unique ID 2324 uniquely identifies software cell 2302 throughout network 104. Global unique ID 2324 is generated on the basis of source ID 2312, e.g. the unique identification of a PE or APU within source ID 2312, and the time and date of generation or transmission of software cell 2302. Required APUs 2326 provides the minimum number of APUs required to execute the cell. Sandbox size 2328 provides the amount of protected memory in the required APUs' associated DRAM necessary to execute the cell. Previous cell ID 2330 provides the identity of a previous cell in a group of cells requiring sequential execution, e.g., streaming data.
Implementation section 2332 contains the cell's core information. This information includes DMA command list 2334, programs 2336 and data 2338. Programs 2336 contain the programs to be run by the APUs (called “apulets”), e.g., APU programs 2360 and 2362, and data 2338 contain the data to be processed with these programs. DMA command list 2334 contains a series of DMA commands needed to start the programs. These DMA commands include DMA commands 2340, 2350, 2355 and 2358. The PU issues these DMA commands to the DMAC.
DMA command 2340 includes VID 2342. VID 2342 is the virtual ID of an APU which is mapped to a physical ID when the DMA commands are issued. DMA command 2340 also includes load command 2344 and address 2346. Load command 2344 directs the APU to read particular information from the DRAM into local storage. Address 2346 provides the virtual address in the DRAM containing this information. The information can be, e.g., programs from programs section 2336, data from data section 2338 or other data. Finally, DMA command 2340 includes local storage address 2348. This address identifies the address in local storage where the information should be loaded. DMA commands 2350 contain similar information. Other DMA commands are also possible.
DMA command list 2334 also includes a series of kick commands, e.g., kick commands 2355 and 2358. Kick commands are commands issued by a PU to an APU to initiate the processing of a cell. DMA kick command 2355 includes virtual APU ID 2352, kick command 2354 and program counter 2356. Virtual APU ID 2352 identifies the APU to be kicked, kick command 2354 provides the relevant kick command and program counter 2356 provides the address for the program counter for executing the program. DMA kick command 2358 provides similar information for the same APU or another APU.
As noted, the PUs treat the APUs as independent processors, not co-processors. To control processing by the APUs, therefore, the PU uses commands analogous to remote procedure calls. These commands are designated “APU Remote Procedure Calls” (ARPCs). A PU implements an ARPC by issuing a series of DMA commands to the DMAC. The DMAC loads the APU program and its associated stack frame into the local storage of an APU. The PU then issues an initial kick to the APU to execute the APU Program.
In step 2410, the PU evaluates the apulet and then designates an APU for processing the apulet. In step 2412, the PU allocates space in the DRAM for executing the apulet by issuing a DMA command to the DMAC to set memory access keys for the necessary sandbox or sandboxes. In step 2414, the PU enables an interrupt request for the designated APU to signal completion of the apulet. In step 2418, the PU issues a DMA command to the DMAC to load the apulet from the DRAM to the local storage of the APU. In step 2420, the DMA command is executed, and the apulet is read from the DRAM to the APU's local storage. In step 2422, the PU issues a DMA command to the DMAC to load the stack frame associated with the apulet from the DRAM to the APU's local storage. In step 2423, the DMA command is executed, and the stack frame is read from the DRAM to the APU's local storage. In step 2424, the PU issues a DMA command for the DMAC to assign a key to the APU to allow the APU to read and write data from and to the hardware sandbox or sandboxes designated in step 2412. In step 2426, the DMAC updates the key control table (KTAB) with the key assigned to the APU. In step 2428, the PU issues a DMA command “kick” to the APU to start processing of the program. Other DMA commands may be issued by the PU in the execution of a particular ARPC depending upon the particular apulet.
As indicated above, second portion 2404 of
The ability of APUs to perform tasks independently under the direction of a PU enables a PU to dedicate a group of APUs, and the memory resources associated with a group of APUs, to performing extended tasks. For example, a PU can dedicate one or more APUs, and a group of memory sandboxes associated with these one or more APUs, to receiving data transmitted over network 104 over an extended period and to directing the data received during this period to one or more other APUs and their associated memory sandboxes for further processing. This ability is particularly advantageous to processing streaming data transmitted over network 104, e.g., streaming MPEG or streaming ATRAC audio or video data. A PU can dedicate one or more APUs and their associated memory sandboxes to receiving these data and one or more other APUs and their associated memory sandboxes to decompressing and further processing these data. In other words, the PU can establish a dedicated pipeline relationship among a group of APUs and their associated memory sandboxes for processing such data.
In order for such processing to be performed efficiently, however, the pipeline's dedicated APUs and memory sandboxes should remain dedicated to the pipeline during periods in which processing of apulets comprising the data stream does not occur. In other words, the dedicated APUs and their associated sandboxes should be placed in a reserved state during these periods. The reservation of an APU and its associated memory sandbox or sandboxes upon completion of processing of an apulet is called a “resident termination.” A resident termination occurs in response to an instruction from a PU.
On the other hand, if a software cell contains MPEG data, then, in step 2638, APU 2508 examines previous cell ID 2330 (
Other dedicated structures can be established among a group of APUs and their associated sandboxes for processing other types of data. For example, as shown in
Coordinating APU 2720 is dedicated to receiving in its local storage the display lists from destination sandboxes 2706, 2712 and 2718. APU 2720 arbitrates among these display lists and sends them to other APUs for the rendering of pixel data.
The processors of system 101 also employ an absolute timer. The absolute timer provides a clock signal to the APUs and other elements of a PE which is both independent of, and faster than, the clock signal driving these elements. The use of this absolute timer is illustrated in
As shown in this figure, the absolute timer establishes a time budget for the performance of tasks by the APUs. This time budget provides a time for completing these tasks which is longer than that necessary for the APUs' processing of the tasks. As a result, for each task, there is, within the time budget, a busy period and a standby period. All apulets are writ en for processing on the basis of this time budget regardless of the APUs' actual processing time or speed.
For example, for a particular APU of a PE, a particular task may be performed during busy period 2802 of time budget 2804. Since busy period 2802 is less than time budget 2804, a standby period 2806 occurs during the time budget. During this standby period, the APU goes into a sleep mode during which less power is consumed by the APU.
The results of processing a task are not expected by other APUs, or other elements of a PE, until a time budget 2804 expires. Using the time budget established by the absolute timer, therefore, the results of the APUs' processing always are coordinated regardless of the APUs' actual processing speeds.
In the future, the speed of processing by the APUs will become faster. The time budget established by the absolute timer, however, will remain the same. For example, as shown in
In lieu of an absolute timer to establish coordination among the APUs, the PU, or one or more designated APUs, can analyze the particular instructions or microcode being executed by an APU in processing an apulet for problems in the coordination of the APUs' parallel processing created by enhanced or different operating speeds. “No operation” (“NOOP” instructions can be inserted into the instructions and executed by some of the APUs to maintain the proper sequential completion of processing by the APUs expected by the apulet. By inserting these NOOPs into the instructions, the correct timing for the APUs' execution of all instructions can be maintained.
Over the past decade, microprocessors have become powerful enough to tackle previously intractable tasks and cheap enough to use in a range of new applications. Meanwhile, the volumes of data to process have ballooned. This phenomenon is evident in everything from consumer entertainment, which is transitioning from analog to digital media, to supercomputing applications, which are starting to address previously unsolvable computing problems involving massive data volumes.
To address this shift from control function to data processing, APU 2900 exploits data-level parallelism through a SIMD architecture with the integration of scalar and SIMD execution. In addition to improving the efficiency of many vectorization transformations, this approach reduces the area and complexity overhead that scalar processing imposes. Any complexity reduction directly translates into increased performance because it enables additional cores per given chip area.
Local store 2910 includes instructions that are fed into buffer 2915 in 128-byte increments. Buffer 2915 separates the instructions out into 64 byte increments (representing a first and second portion of a memory line), which are supplied to fetch 2920. The instructions proceed through a datapath that includes instruction line buffers 2930, issue/branch 2940, and vector register file 2950.
Instruction issue logic 2940 issues instruction for execution in bundles of up two instructions. Each instruction is four bytes wide and specifies up to three source operands to be provided by the vector register file 2950 to execution units 2960, 2970, 2980, and 2990. In order to process scalar computations correctly, the scalar data values are aligned with respect to the vector words stored in vector register file 2950 using a “preferred slot” mechanism (see
Vector register file 2950 then provides source operands in 16 byte increments (regardless of whether the instruction is performing a computation corresponding to a scalar of SIMD computation in the source program), to an appropriate execution unit for further processing, such as vector floating point unit 2960, vector fixed point unit 2970, data formatting and permute unit 2980, and load/store unit 2990.
As a result, when execution unit 3060 adds vector 3040 to vector 3050, the resulting vector (vector 3070) does not include the correct data values. As can be seen, vector 3070 slot 1 equals x+n5 and vector 3070's slot 2 equals n2+y. Therefore, in order to add two vectors that include scalar operations, the invention described herein uses a “preferred slot” alignment mechanism (see
Instructions using the preferred slot mechanism include 1) shift and rotate instructions operating across an entire quad-word that specify a shift amount, 2) memory load and store instructions that require an address, and 3) branch instructions that use the preferred slot for branch conditions (conditional branches) and branch addresses (register-indirect branches). Branch and link instructions also use the preferred slot mechanism to deposit a function return address in a return address register, which the cell application binary interface (ABI) allocates to vector register 0.
As can be seen in
The preferred slot is an expected location for scalar parameters to APU instructions. In one embodiment, scalar computations may occur in any slot. The preferred slot also serves as a software abstraction in the ABI to identify the location of scalar parameters on function calls and as function return values. In addition, interprocedural register allocation may choose alternative locations to pass scalar values across function call boundaries.
Since the APU architecture uses only vector instruction forms, the scalar nature of an instruction can be inferred only from how the compiler uses that instruction. Meaning, the compiler selects a slot position in a vector in which to perform intermediate computations and from which to retrieve the result. The hardware is unaware of this use and always performs the specified operation across all slots. Removing explicit scalar indication allows the software to perform scalar operations in any element slots of a vector. The compiler may optimize alignment handling and eliminate previously compulsory scalar data alignment to the preferred slot. Unifying instruction encoding in this way to provide the same instruction forms for scalar and SIMD computations allows more opcode bits available to encode operations with up to four distinct operands from a 128-entry register file.
As can be seen, vector 3210 now includes data value x in its preferred slot (slot 0), and vector 3230 now includes data value y also in its preferred slot (slot 0). As such, vector 3210 may be added to vector 3230, which produces vector 3240. Vector 3240 includes data value z, which equals x+y. In one embodiment, when data value x and y are in the same slot before rotation (e.g., slot 2), the vectors may be added together, and the resultant vector may be rotated to place the summation of x+y in the preferred slot.
In accordance with a preferred code generation method, a compiler rotates or shifts scalar data items in a common slot position. In one embodiment, this is the preferred slot. In accordance with another embodiment, the preferred slot is chosen to be the leftmost word slot, allowing the ability to rotate words into the preferred slot with a single quadword rotate instruction using low-order address bits (stored in the preferred slot of a vector register) to specify the rotate count for word data. Those skilled in the art will appreciate the ability to adapt concepts of the preferred slot to other locations within a vector, and appropriate alignment rotate or shift sequences accordingly. Those skilled in the art will also understand the use of other instruction sequences, such as those including but not limited to a vector permute instruction.
To implement the read-modify-write sequence, the APU also supports a “generate controls for insertion” instruction, which generates a control word to steer the shuffle instruction to insert a byte, halfword or word element into a position the memory address specifies. As can be seen in
In accordance with a code preferred code generation method, the compiler generates 1) an instruction to insert a scalar data value in a vector, 2) a load instruction to load an aligned vector from memory, 3) a shuffle instruction to insert the scalar data item to be stored into the vector retrieved from memory under control of the control word, and 4) a store instruction to store the aligned vector to memory.
RT0:3←RA0:3+RB0:3
RT4:7←RA4:7+RB4:7
RT8:11←RA8:11+RB8:11
RT12:15←RA12:15+RB12:15
In accordance with the specification format for the APU architecture, the following notations, functions and symbols are used:
Those and other features of the APU specification will be further clarified by consulting an exemplary APU implementation as provided by the Cell SPU in accordance with the “Cell SPU specification V1.0” and incorporated herein by reference.
At step 3330, processing operates on the entire vector. Using the example shown in
LSA←(RepLeftBit(I10∥0b0000,32)+RA0:3)&LSLR&0xFFFFFFF0
RT←LocStor(LSA, 16)
In one embodiment, this address is further formatted by masking it with the contents specified by a local store limit register. The resultant address is used to access a local store (or other memory) and the sixteen bytes at the local store address are placed into register RT (see
Processing generates an address at step 3450 by adding the base address stored in the specified slot of register RA to the displacement I10, and formats the address under control of a local store limit register (LSLR), which identifies the local storage area's ending and specifies which address bits to use. At step 3470, processing accesses memory corresponding to the formatted address, selects data words (step 3480), and stores the data words in a register file (step 3490). Processing ends at 3495 (see
Those skilled in the art will appreciate that in one embodiment, different displacement sizes may be supported, and displacement formatting is performed under control of control logic 3510 to select a specific displacement format based on the instruction's opcode. Vector fields that are not required (such as slots 1, 2, 3 of vector registers 3540 and 3555) are labeled as “DC”, which means “don't care”. In parts of the logic flow, bits corresponding to DC values are not implemented.
Multiplexer 3557 selects an address base from one of a preferred slot of a specified vector register storing the base address for D-form loads (i.e., those using a register+displacement addressing format) and X-form loads (i.e., those using a register+register addressing format), 0 for A-form loads (i.e., those specifying an absolute address in their displacement field), and IAR 3556 for R-form loads (i.e., those using a instruction address+displacement addressing format). Vector 3555 includes a base address in the preferred slot (the vector operand is specified by
Adder 3559 adds the output of multiplexer 3550, which provides an address offset, to the output of multiplexer 3557, which provides an address base. Address formatting 3570 receives the generated address, and formats the address based upon local store limit register (LSLR) 3560. LSLR 3560 specifies which bits of the generated address to use as an actual address. The resulting address is stored in data address register 3575.
Once formatted, processing accesses local store 3580 through data address register 3575 and selects a quadword with selection logic 3590. In turn, processing stores the quadword to a vector register file entry that is specified by the RT field shown in
LSA←(RA0:3+RB0:3) & LSLR & 0xFFFFFFF0
LocStor(LSA,16)←RT
Instruction word register 3610 provides control information to control logic 3615, which instructs multiplexer 3640 to select an address offset based on an instruction form. Multiplexer 3640 selects either the formatted displacement generated by formatting logic 3620 for D-form memory instructions, or an address offset contained in the preferred slot of a specified index vector register (3630).
Multiplexer 3658 selects an address base from one of a preferred slot of a specified vector register 3650 storing the base address for D-form loads (i.e., those using a register+displacement addressing format) and X-form loads (i.e., those using a register+register addressing format), 0 for A-form loads (i.e., those specifying an absolute address in their displacement field), and IAR 3656 for R-form loads (i.e., those using a instruction address + displacement addressing format). Vector 3650 includes a base address in the preferred slot. The vector operand is specified by instruction 3600's RA field shown in
Adder 3665 adds multiplexer 3658's output, which provides an address base, to multiplexer 3640's output. Address formatting 3670 receives the generated address, and formats the address based upon local store limit register (LSLR) 3660, storing the result in data address register DAR 3680.
Once formatted, processing stores store value 3655 in memory at the address specified by DAR 3680 in one of a local store, a memory hierarchy, or store queue using data address register 3680. Store value 3655 is the value of a vector register file entry specified by instruction 3600's RT field shown in
RT0:3←(PC+4) & LSLR
RT4:15←0
PC←(PC+RepLeftBit(I16 ∥0b00,32)) & LSLR
In step 3726, processing formats and selects a displacement value (corresponding to instruction 3700's I16 value shown in
Instruction address register (IAR+4) 3760 includes a branch instruction address incremented by four to indicate the address of the next instruction following the branch instruction. This value may be derived from the output of the IAR incrementing logic 3865 (shown in
In yet another embodiment, all four slots receive a copy of the IAR+4 link value. In another embodiment, they correspond the prior value of these bits in the RT register. In accordance with another embodiment, they correspond to the value of bits 0 to 95 of the RT register prior to instruction execution (i.e., the leftmost 96b of the RT register), which allows the implementation of a history of the last four link addresses in a single vector register. In accordance with yet another embodiment, they have an undefined value. Those skilled in the art will be able to derive yet other values to define these bits within the scope of the present invention.
Instruction word register 3740 provides control information to control logic 3750, which instructs result multiplexer 3780 to select link address 3770. In turn, link address 3770 is stored in a vector register file, whereby the preferred slot of the register file entry specified by instruction 3600's RT field shown in
PC←RA0:3 & LSLR & 0xFFFFFFFC
if (E=0 and D=0) int. enable status is not modified
if (E=1 and D=0) enable interrupts at target
if (E=0 and D=1) disable interrupts at target
if (E=1 and D=1) reserved
Vector 3840, which is received from a vector register file, includes a base address in its preferred slot. The base address is a value corresponding to the vector register file entry specified by instruction 3800's RA field shown in
Instruction word register 3810 also provides control information to control logic 3820, which instructs multiplexer 3850 to select between multiple address forms, such as a register-indirect specified address (vector 3840) for indirect branches, or computed PC-relative branch address computed by adder 3835 for R-form branches. Multiplexer 3850 may select addresses corresponding to yet other addressing forms, such as an absolute address (not shown). Multiplexer 3850 may also select a sequential next instruction address computed by adder 3835 if no branch instruction is present.
Multiplexer 3850's selection feeds into instruction fetch address register (IFAR) 3860. When processing does not branch, processing proceeds through loop 3865 whereupon processing increments and processes the next instruction address. IFAR 3860's output feeds into address formatting 3880, which is formatted using LSLR 3870. Once formatted, the formatted address is passed to memory hierarchy. A number of memory hierarchies may be employed, including ones corresponding to a traditional cache-based main memory hierarchy or a novel local store based memory hierarchy using DMA engines to transfer instructions streams from and to main memory.
If RT0:3!=0 then
PC←(PC+RepLeftBit(I16∥0b00)) & LSLR & 0xFFFFFFFC
else
PC←(PC+4) & LSLR
End
If RT2:3!=0 then
PC←(PC+RepLeftBit(I16∥0b00)) & LSLR & 0xFFFFFFFC
else
PC←(PC+4) & LSLR
End
Processing, at step 3960, computes a target address, and at step 3970, processing transfers control if the decision indicates by updating the IFAR. Processing ends at 3980.
Vector 4030, which is received from a vector register file, includes the value corresponding to the vector register file entry specified by instruction 3900's or 3910's RT field shown in
Multiplexer 4060's output feeds into instruction fetch address register (IFAR) 4070. When processing does not branch, processing proceeds through loop 4075 whereupon processing increments and processes the next instruction address. When processing does branch, IFAR 4070's output feeds into address formatting 4090, which is formatted using LSLR 4080. Once formatted, the formatted address is passed to memory hierarchy.
In accordance with another aspect of the present embodiment, at least one compare instruction is implemented. In accordance with a preferred embodiment, at least one compare instruction operates on a plurality of slot values that generate a data mask in each slot that corresponds to “all 0” when the condition is not true, and corresponds to “all 1” when the condition is true.
In accordance with another embodiment, the data mask vector registered by the compare instruction feeds a select instruction. In another embodiment, the data mask provides a condition input to conditional branch instructions, such as those in accordance with the instructions shown in
In accordance with another embodiment, a minimal set of branch instructions are implemented, such as a first “compare for equality,” and a second “compare for ordering” (e.g., “compare greater than”). In this embodiment:
In at least one embodiment, two test for ordering, in accordance with comparison of signed and unsigned numbers, are provided.
While particular embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that, based upon the teachings herein, that changes and modifications may be made without departing from this invention and its broader aspects. Therefore, the appended claims are to encompass within their scope all such changes and modifications as are within the true spirit and scope of this invention. Furthermore, it is to be understood that the invention is solely defined by the appended claims. It will be understood by those with skill in the art that if a specific number of an introduced claim element is intended, such intent will be explicitly recited in the claim, and in the absence of such recitation no such limitation is present.
This application is a Continuation in Part (CIP) of U.S. Patent Application US 2002/0138637 A1, Ser. No. 09/816,004, filed on Mar. 22, 2001 titled “Computer Architecture and Software Cells for Broadband Networks,” and has at least one of the same inventors as the above referenced U.S. Patent Application.
Number | Date | Country | |
---|---|---|---|
Parent | 09816004 | Mar 2001 | US |
Child | 11461554 | Aug 2006 | US |