Abstract:
A register file in which the physical row/column mapping is decoupled from the logical row/column mapping. The physical register file includes R*C N-bit storage elements arranged in R rows and C columns. Each physical row includes an N-bit bus, a log 2 (C)-bit storage element selection line, and a log 2 (C)-bit output column selection line. In either a logical row or logical column access, no more than one storage element is selected per physical row and coupled to that row&#39;s bus, and each column&#39;s vertical bit line is uniquely coupled to one row&#39;s bus. The values on the storage element selection lines and on the output column selection lines determines which storage elements are coupled to which vertical bit lines. The width C of the register file, the number of rows R of the register file, and the size N of the fundamental data storage element can be independently changed without affecting the others. The size X of the X*N-bit logical data elements can be changed without changing R, C, N, or the width of the buses. The same addressing logic is used, regardless of data size and regardless of whether the access is logically row-wise or column-wise. Horizontal wire count is minimized by an appropriate logical-to-physical mapping of the storage cells.

Description:
BACKGROUND OF THE INVENTION  
       [0001]     1. Technical Field of the Invention  
         [0002]     This invention relates generally to register files for storing data in a processor, and more particularly to register files adapted for use in conjunction with matrix arithmetic logic units.  
         [0003]     2. Background Art  
         [0004]      FIG. 1  illustrates a conventional digital logic system  10  including a register file  12 . The register file includes  64  storage locations organized in an 8-by-8 matrix including eight rows A through H and eight columns  7  through  0 . Each storage location may be identified by its row and column location, such as storage location A 7 , storage location F 4 , and so forth. Each storage location holds one byte of data.  
         [0005]     When data are read out of the register file, they are held in a latch before being provided as input to an arithmetic logic unit (ALU). Commonly, a register file has at least two read ports and can simultaneously provide at least two outputs which are used as operand inputs into one or more ALUs. For simplicity, only a single read port is shown. Commonly, the register file has one or more write ports into which the ALU&#39;s result is written back to the register file. For simplicity, no write port is shown.  
         [0006]     Within a data item stored within a physical row, the most significant byte (MSB) is toward column  7  and the least significant byte (LSB) is toward column  0 , in a “big-endian” configuration. Both the prior art and the present invention will be discussed in terms of big-endian configurations, although neither is thus limited.  
         [0007]     Although the storage locations have a “physical” size, such as one byte each, most digital logic systems include hardware for enabling the software to utilize data items of one or more different “logical” sizes. For purposes of illustration, the prior art and the present invention will be explained as being able to access logical data including single-byte data, word (2-byte) data, double-word (4-byte) data, and quad-word (8-byte) data.  
         [0008]     Some digital processing systems access and process vectors of these data types, in which two or more data items (of a particular size) are grouped and processed together. Some digital processing systems access and process scalar data (single data items of a particular size). Both types of systems can benefit from improved register file access performance, and from improved register file wiring and configuration.  
         [0009]     A word data item occupying e.g. storage locations C 7  and C 6  is referred to as C 7 : 6 , a double-word item occupying storage locations A 3 , A 2 , A 1 , and A 0  is referred to as A 3 : 0 , and a quad-word item occupying storage locations G 7 , G 6 , . . . G 0  is referred to as G 7 : 0 .  
         [0010]     Previously, the register file configuration as it appears to software, known as the “logical” configuration, has been identical with the way that the register file is actually constructed, known as the “physical” configuration. If the logical configuration is an 8-by-8 matrix of single-byte storage locations, then the register file has been physically constructed as an 8-by-8 matrix of single-byte storage locations.  
         [0011]     This is not a problem when the register file is being accessed row-wise, because each of the storage elements&#39; data can be directly, vertically driven onto its own, local set of bit lines. However, when the register file is accessed column-wise, the storage elements&#39; data must be driven both vertically and horizontally (so data from multiple data elements in a single column can be driven onto different vertical bit lines). This requires a substantial amount of additional, horizontal wiring and control logic in each row of the register file. Existing systems limit the vector element size that can be accessed column-wise, to avoid an explosion in the number and complexity of required wires and logic.  
         [0012]     One example of a recent attempt to deal with this problem is presented in a paper entitled “A Register File with Transposed Access Mode” by Yoochang Jung, Stefan G. Berg, Donglok Kim, and Yongmin Kim of the Image Computing Systems Laboratory at the University of Washington, Seattle, Wash., 98195. Although it does permit both row-wise and column-wise accesses, the Jung register file has several significant drawbacks. It requires separate address decoders for row-wise access and for column-wise access. For each data element size (byte, word, etc.) it requires a separate copy of each of the row-wise and column-wise address decoders. The number of rows useable in column-wise access is reduced by a factor of X, where X is the number of bytes in the data element size. And, as nearly as we can ascertain, the width of each row&#39;s bus is equal to the largest permissible data element size.  
         [0013]      FIG. 2  illustrates that when the digital logic system makes a vector access of Logical Row A with byte-sized data elements, physical locations A 7  through A 0  are accessed. When the digital logic system makes a similar vector access of Logical Row B, physical locations B 7  through B 0  are accessed; a similar vector access of Logical Row C accesses physical locations C 7  through C 0 ; and so forth.  
         [0014]      FIG. 3  illustrates that when the digital logic system makes a vector access of Logical Row A with word-sized data elements, physical locations A 7 : 6  through A 1 : 0  are accessed. When the digital logic system makes a similar vector access of Logical Row B, physical locations B 7 : 6  through B 1 : 0  are accessed; and so forth.  
         [0015]      FIG. 4  illustrates that when the digital logic system makes a vector access of Logical Row A with double-word-sized data elements, physical locations A 7 : 4  and A 3 : 0  are accessed. When the digital logic system makes a similar vector access of Logical Row B, physical locations B 7 : 4  and B 3 : 0  are accessed; and so forth.  
         [0016]      FIG. 5  illustrates that when the digital logic system makes a vector (or scalar) access of Logical Row A with quad-word-sized data elements, physical locations A 7 : 0  are accessed. When the digital logic system makes a similar access of Logical Row B, physical locations B 7 : 0  are accessed; and so forth.  
         [0017]      FIG. 6  illustrates that when the digital logic system makes a vector access of Logical Column  7  with byte-sized data elements, physical locations A 7  through H 7  are accessed. When the digital logic system makes a similar access of Logical Column  6 , physical locations A 6  through H 6  are accessed; and so forth.  
         [0018]     Thus, for all row-wise accesses and for byte-sized column-wise access, the existing systems do just fine. The problem manifests itself when word-sized and larger column-wise accesses are performed.  
         [0019]      FIG. 7  illustrates that when the digital logic system makes a vector access of Logical Column  7  with word-sized data elements, physical locations A 7 : 6  through D 7 : 6  are accessed. When the digital logic system makes a similar access of Logical Column  6 , physical locations A 5 : 4  through D 5 : 4  are accessed; Logical Column  5  accesses physical locations A 3 : 2  through D 3 : 2 ; Logical Column  4  accesses physical locations A 1 : 0  through D 1 : 0 ; Logical Column  3  accesses physical locations E 7 : 6  through H 7 : 6 ; and so forth.  
         [0020]      FIG. 8  illustrates that when the digital logic system makes a vector access of Logical Column  7  with double-word-sized data elements, physical locations A 7 : 4  and B 7 : 4  are accessed. When the digital logic system makes a similar access of Logical Column  6 , physical locations A 3 : 0  and B 3 : 0  are accessed; Logical Column  5  accesses physical locations C 7 : 4  and D 7 : 4 ; and so forth.  
         [0021]      FIG. 9  illustrates that when the digital logic system makes a vector (or scalar) access of Logical Column  7  with quad-word-sized data elements, physical locations A 7 : 0  are accessed. When the digital logic system makes a similar access of Logical Column  6 , physical locations B 7 : 0  are accessed, and so forth. (In the degenerate case when the data size matches the number of physical storage locations in a row and column, row-wise and column-wise accesses to the same index will access the same storage locations.)  
         [0022]     Referring to  FIG. 1  and  FIGS. 2-5 , it can be seen that row-wise access does not cause any read port or bit line problems, because each byte of each data item comes out on its own, unique set of bit lines from the register file to the latch.  
         [0023]     However, referring to  FIG. 1  and  FIGS. 6-9 , it can be seen that column-wise access of any size of data item smaller than the full register file width creates a problem of routing the accessed data horizontally to the appropriate bit lines. For example, in  FIG. 8 , bytes A 7  and B 7  are stored in physical storage locations which are both in the same physical column; somehow, the data from B 7  must be steered to the bit lines that are associated with column  6  not column  7 .  
         [0024]     Some existing systems have solved this problem by adding additional decoders which require vertical column select lines and additional horizontal routing associated with each data port and for each data size which the system is able to access. For example, to perform the read shown in  FIG. 6 , a decoder at the top of the register file causes a column select line to enable bytes A 7  through H 7  to be driven horizontally along 8-bit-wide buses. Additional switching logic then connects the horizontal data with the vertical bit lines to allow the desired data to be available in the proper output position. To perform the read shown in  FIG. 7 , data must be driven horizontally along 16-bit-wide buses. And to perform the read shown in  FIG. 8 , data must be driven horizontally along 32-bit-wide buses. One fundamental problem with this existing approach is that the buses must be as large as the largest vector element size which causes two or more bytes to be selected within any given column.  
         [0025]     What is needed, then, is an improved matrix register file which, with a minimal amount of additional wiring, allows logical rows and columns to be accessed using any of several elemental data sizes. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0026]      FIG. 1  shows a register file and arithmetic logic unit according to the prior art.  
         [0027]      FIGS. 2-5  show a conventional register file, highlighting storage locations which are accessed when performing reads of eight bytes, four words, two double-words, and one quad-word, respectively, from a row.  
         [0028]      FIGS. 6-9  show a conventional register file, highlighting storage locations which are accessed when performing reads of eight bytes, four words, two double-words, and one quad-word, respectively, from a column.  
         [0029]      FIG. 10  shows a digital logic system according to one embodiment of this invention.  
         [0030]      FIG. 11  shows one embodiment of register file control logic such as may be employed in the system of  FIG. 10 .  
         [0031]      FIGS. 12L and 12P  show the register file of this invention, in its logical and physical organization, respectively, highlighting storage locations which are accessed when performing a read of eight bytes from a row.  
         [0032]      FIGS. 13L and 13P  show the register file of this invention, in its logical and physical organization, respectively, highlighting storage locations which are accessed when performing a read of four words from a row.  
         [0033]      FIGS. 14L and 14P  show the register file of this invention, in its logical and physical organization, respectively, highlighting storage locations which are accessed when performing a read of two double-words from a row.  
         [0034]      FIGS. 15L and 15P  show the register file of this invention, in its logical and physical organization, respectively, highlighting storage locations which are accessed when performing a read of one quad-word from a row.  
         [0035]      FIGS. 16L and 16P  show the register file of this invention, in its logical and physical organization, respectively, highlighting storage locations which are accessed when performing a read of eight bytes from a column.  
         [0036]      FIGS. 17L and 17P  show the register file of this invention, in its logical and physical organization, respectively, highlighting storage locations which are accessed when performing a read of four words from a column.  
         [0037]      FIGS. 18L and 18P  show the register file of this invention, in its logical and physical organization, respectively, highlighting storage locations which are accessed when performing a read of two double-words from a column.  
         [0038]      FIGS. 19L and 19P  show the register file of this invention, in its logical and physical organization, respectively, highlighting storage locations which are accessed when performing a read of one quad-word from a column.  
         [0039]     FIGS.  20 A-D together show one embodiment of the contents of a lookup table, or of the output of logic, including the element selection line values and column output selection line values which result from each address combination of row-wise indicator, row/column index, and data element size indicator.  
         [0040]      FIG. 21  shows a register file with the lookup table which controls access to the register file&#39;s storage locations.  
         [0041]      FIGS. 22L and 22P  show another embodiment of a register file mapping and an access of a logical row of words.  
         [0042]      FIGS. 23L and 23P  show the register file mapping of  FIG. 22  and an access of a logical column of words.  
         [0043]      FIG. 24  shows another embodiment of a register file system according to this invention, in which only a portion of the register file uses the mapping feature of this invention and the remainder uses a conventional mapping. 
     
    
     DETAILED DESCRIPTION  
       [0044]     The invention will be understood more fully from the detailed description given below and from the accompanying drawings of embodiments of the invention which, however, should not be taken to limit the invention to the specific embodiments described, but are for explanation and understanding only.  
         [0045]      FIG. 10  illustrates one embodiment of an improved matrix register file system  20  according to this invention. Again, for simplicity, only a single read port is shown. The improvement in the register file includes both a reorganization of the logical-to-physical location mapping within any particular column, and a change in how the physical storage locations are accessed. The register file includes physical columns  7  through  0  shown organized left to right and storing Logical Rows A through H, respectively. The register file includes physical rows  7  through  0  shown organized top to bottom.  
         [0046]     In the prior art, logical rows and physical rows were the same thing. In the prior art, logical columns and physical columns were the same thing. In other words, a storage location&#39;s logical address e.g. “D4” precisely indicated its physical location within the register file. Row-wise access was performed simply by decoding the register address and activating a single “row select” line.  
         [0047]     According to the present invention, logical rows are organized in physical columns, and within each physical column, the storage locations have been reordered differently. The result is that logical rows and physical rows are not only not the same thing, but the physical locations that make up a logical row are not even stored in the same physical row.  
         [0048]     This reorganization can be done in a variety of manners.  FIG. 10  illustrates but one example. Logical Row A is stored in the physical column  7 , Logical Row B is stored in physical column  6 , and so forth.  
         [0049]     Within physical column  7 , the storage locations of Logical Row A are stored sequentially from physical row  7  to physical row  0 . Within physical column  6 , the storage locations of Logical Row B are stored sequentially from physical row  3  to physical row  0 , wrapping to physical row  7  and continuing to physical row  4 . Within physical column  5 , the storage locations of Logical Row C are stored sequentially from physical row  5  to physical row  0 , wrapping to physical row  7  and continuing to physical row  6 . Within physical column  4 , the storage locations of Logical Row D are stored sequentially from physical row  1  to physical row  0 , wrapping to physical row  7  and continuing to physical row  2 . Within physical column  3 , the storage locations of Logical Row E are stored sequentially from physical row  0 , wrapping to physical row  7  and continuing to physical row  1 . Within physical column  2 , the storage locations of Logical Row F are stored sequentially from physical row  4  to physical row  0 , wrapping to physical row  7  and continuing to physical row  5 . Within physical column  1 , the storage locations of Logical Row G are stored sequentially from physical row  6  to physical row  0 , wrapping to physical row  7 . Within physical column  0 , the storage locations of Logical Row H are stored sequentially from physical row  2  to physical row  0 , wrapping to physical row  7  and continuing to physical row  3 .  
         [0050]     No two Logical Rows have their storage starting in the same physical row, and, significantly, the physical storage locations which are accessed in any single logical column-wise access of any data size are all stored within different physical rows. Each physical row contains exactly one element from each logical row.  
         [0051]      FIG. 11  illustrates one embodiment of a register file  30  such as may be used in the system of  FIG. 10 , and includes an illustration of the register file storage locations. Rather than the entire register file being provided with a single, simple “row select” line as in the prior art, in the present invention each physical row is provided with a pair of dedicated controls. A multi-bit entry select line ESel N  selects one physical storage location  24  from the physical row; in the example shown, a given three-bit ESel N  line selects one of the eight storage locations in an associated row. A multi-bit column output selector line COut N  line selects a vertical bit line on which the selected storage location&#39;s data will be read out from the register file. Thus, the physical column position of the storage element does not dictate the register file output column position at which the storage element&#39;s data will be output. If physical row  7  is accessed with an ESel 7  value of 3 (binary 011) and a COut 7  value of 6 (binary 110), the contents of logical storage location E 6  will be provided at physical column  6 . If there are 2 N  physical columns, there will be N bits in the ESel line and N bits in the COut line.  
         [0052]     Each storage location has a dedicated selection logic element  32  and a dedicated column output control logic element  36 . In one embodiment, the selection logic element is a three-input AND gate with its inputs in positive or negative (inverted) state as indicated by the three-digit binary value, such that if that three-digit value is asserted on the ESel line, exactly that one selection logic element in the physical row will produce an active output enable signal to its storage cell. In the illustrated embodiment, the storage cell responds to this enable signal by outputting its stored value onto a common bus N  which is shared by the storage elements in that physical row. In one embodiment, the output control logic element operates similarly, such that if its corresponding three-digit value is asserted on the COut line, exactly that one output control element will pass onto its corresponding eight-bit column output bit line  26  the value on the bus.  FIG. 12L  illustrates a row-wise access of single-byte data, showing the register file in its logical organization.  FIG. 13P  illustrates the corresponding access of the physical register file of  FIG. 10 . The eight individual single-byte data items of Logical Row A are organized in physical column  7 . The eight ESel and COut values generated for this access are:  
                                                               ESel 7     111   COut 7     111           ESel 6     111   COut 6     110           ESel 5     111   COut 5     101           ESel 4     111   COut 4     100           ESel 3     111   COut 3     011           ESel 2     111   COut 2     010           ESel 1     111   COut 1     001           ESel 0     111   COut 0     000                      
 
         [0053]      FIG. 12P  illustrates the logical storage locations which are output at each of the physical columns—A 7  through A 0 .  
         [0054]      FIGS. 13L and 13P ,  14 L and  14 P, and  15 L and  15 P illustrate row-wise access of word, double-word, and quad-word data, respectively. In each case, the ESel and COut values are the same as given above regarding  FIG. 11 .  
         [0055]      FIGS. 16L and 16P  illustrate logical and physical column-wise access of byte data from Logical Column  7 . Logical Column  7  includes byte data at logical locations A 7 , B 7 , C 7 , D 7 , E 7 , F 7 , G 7 , and H 7 . As can be seen in  FIG. 16P , no two of these are in the same physical row. The ESel and COut values generated for this access are:  
                                                               ESel 7     111   COut 7     111           ESel 6     001   COut 6     001           ESel 5     101   COut 5     101           ESel 4     010   COut 4     010           ESel 3     110   COut 3     110           ESel 2     000   COut 2     000           ESel 1     100   COut 1     100           ESel 0     011   COut 0     011                        
         [0056]      FIGS. 17L and 17P  illustrate logical and physical column-wise access of word data from Logical Column  7 , which includes word data at logical locations A 7 : 6 , B 7 : 6 , C 7 : 6 , and D 7 : 6 . As can be seen in  FIG. 17P , no two bytes of these logical locations are stored in the same physical row. The ESel and COut values generated for this access are:  
                                                               ESel 7     111   COut 7     111           ESel 6     111   COut 6     110           ESel 5     101   COut 5     011           ESel 4     101   COut 4     010           ESel 3     110   COut 3     101           ESel 2     110   COut 2     100           ESel 1     100   COut 1     001           ESel 0     100   COut 0     000                        
         [0057]      FIGS. 18L and 18P  illustrate logical and physical column-wise access of double-word data from Logical Column  7 , which includes double-word data at logical locations A 7 : 4  and B 7 : 4 . As can be seen in  FIG. 18P , no two bytes of these logical locations are stored in the same physical row. The ESel and COut values generated for this access are:  
                                                               ESel 7     111   COut 7     111           ESel 6     111   COut 6     110           ESel 5     111   COut 5     101           ESel 4     111   COut 4     100           ESel 3     110   COut 3     011           ESel 2     110   COut 2     010           ESel 1     110   COut 1     001           ESel 0     110   COut 0     000                        
         [0058]      FIGS. 19L and 19P  illustrate logical and physical column-wise access of quad-word data from Logical Column  7 , which includes quad-word data at logical locations A 7 : 0 . As can be seen in  FIG. 19P , no two bytes of these logical locations are stored in the same physical row. The ESel and COut values generated for this access are:  
                                                               ESel 7     111   COut 7     111           ESel 6     111   COut 6     110           ESel 5     111   COut 5     101           ESel 4     111   COut 4     100           ESel 3     111   COut 3     001           ESel 2     111   COut 2     000           ESel 1     111   COut 1     001           ESel 0     111   COut 0     000                        
         [0059]     The ESel and COut values are, in one embodiment, driven from a lookup table. The lookup table is indexed by the logical row or logical column identifier, a data size indicator, and a column-wise/row-wise selector value.  
         [0060]     FIGS.  20 A-D together illustrate one example of a suitable lookup table for generating the ESel and COut values. For ease of understanding, the respective byte, word, double-word, and quad-word sections have been grouped vertically; however, the two-bit value which selects between these four addressing modes might typically be utilized in conjunction with the row-wise selector bit and the three-bit row or column selector value. In other words, the lookup table may be indexed by a 6-bit value comprising: 
 
&lt;1-bit row-wise indicator&gt;&lt;3-bit row or column index&gt;&lt;2-bit size indicator&gt;
 
         [0061]     If the row-wise indicator value is 1, the register file is being accessed row-wise; if it is 0, the register file is being accessed column-wise. The row or column index is a value in the range 111 ( 7 ) through 000 ( 0 ). A size indicator of 00 may cause byte-sized data access, 01 may cause word-sized data access, 10 may cause double-word-sized data access, and 11 may cause quad-word-sized data access. If other sizes are permitted, the indicator will need to be encoded accordingly. Similarly, the size of the row or column index will need to be selected according to the size of the register file.  
         [0062]     Typically, the table will output forty-eight bits, comprised of the three-bit ESel value and the three-bit COut value for each of the eight physical rows in the register file. Within each cell of the following table, the eight three-bit values are organized top to bottom indicating the ESel or COut values provided to physical row  7  through physical row  0 . The number of bits output per table access will depend on the size of the register file.  
         [0063]     In other embodiments, rather than the ESel and COut values being stored in a table, they could be generated by decoder logic. This may offer some opportunity for die area savings. For example, in row-wise access mode, the ESel value is simply the same as the row/column index value, which can be passed straight through the decoder logic without the need for any storage cells. Similarly, in bite-size column-wise access mode, the ESel and COut values are identical, and in quad-word column-wise access mode, the ESel value is the same as the row/column index value. These and other embodiments and optimizations will be readily apparent to those skilled in the art, armed with the teachings of this disclosure.  
         [0064]      FIG. 21  illustrates the register matrix system  50  including the improved register file  22  of  FIG. 10 , and a lookup table  52  such as that given above.  
         [0065]      FIGS. 22L and 22P  illustrate one alternative logical-to-physical mapping of a register file according to another embodiment of this invention, in which corresponding bytes of the respective logical rows are organized into the same physical column (whereas, in  FIGS. 13L and 13P , for example, each physical column contained a single logical row). A word-size access of Logical Row C results in an access of one byte per physical row. The COut logic (not shown) moves the respective bytes onto their respective appropriate column bit lines.  
         [0066]      FIGS. 23L and 23P  illustrate the alternatively mapped register file performing a word-size access of Logical Column  2  (bytes  5 - 4  of Logical Rows E-H), which again results in one byte per physical row being accessed and moved onto appropriate column bit lines.  
         [0067]     There are a variety of such mappings which can be applied to the physical register file within the teachings of this invention. What matters is that, regardless of which logical row or column and which data element size is used in the access, no physical row contains two or more of the required storage locations.  
         [0068]      FIG. 24  illustrates another embodiment of a register file system utilizing the principles of this invention in only a first (upper) portion of its register file. The remaining (lower) portion of the register file uses a conventional addressing or mapping scheme.  
         [0069]     When the digital logic system (not shown) makes an access of a logical row or column whose address puts it within the first portion of the register file, the lookup table (or other suitable means such as a state machine or hard coded logic) uses the row-wise indicator, data size indicator, and row/column index to generate the appropriate ESel and COut values to access the required storage elements within the first portion of the register file. The ESel values select the correct storage element in each respective row of that portion of the register file, and the COut values steer them onto their correct bit lines. The first portion of the register file thus permits accessing both logical rows and logical columns.  
         [0070]     When the digital logic system makes an access of a logical row whose address puts it within the second portion of the register file, e.g. if the first portion contains 16 logical rows  0  through  15  and the access is to logical row  27 , decoder logic responds to the logical row index to generate a row select signal enabling access of a physical row within the second portion of the register file. Because the second portion does not use the COut logic, the bytes within the selected row cannot be steered and are simply output on the bit lines at their respective column positions. Thus, the second portion of the register file permits accessing only logical rows. The COut lines in the first portion of the register file are enhanced with an extra “enable” bit which, when deasserted, prevents that that row from being coupled to any of the bit lines. Alternatively, a single enable line could be added to decouple the first portion&#39;s bit lines from the second portion&#39;s bit lines.  
         [0071]     In other embodiments, the second portion of the register file could be modified to permit accessing logical columns as well. In one such embodiment, the technique of this invention could be used. In other embodiments, other techniques could be used.  
         [0072]     In one embodiment, two or more register files according to the teachings of this invention may be stacked vertically, to share bit lines. For example, if the physical row is 8 bytes wide, it may be convenient to include 8 physical rows in the register file so it is square. Then, if more than 8 rows are needed, it may be convenient to simply stack two such register files vertically, and use the most significant bit of the row/column index value to select between the two register files.  
       Conclusion  
       [0073]     When one component is said to be “adjacent” to another component, it should not be interpreted to mean that there is absolutely nothing between the two components, only that they are in the order indicated.  
         [0074]     The various features illustrated in the figures may be combined in many ways, and should not be interpreted as though limited to the specific embodiments in which they were explained and shown.  
         [0075]     Except where expressly indicated otherwise, the term “line” should not be interpreted as meaning exactly one single wire; rather, it generally indicates one or more wires carrying one or more related bits of data.  
         [0076]     Those skilled in the art having the benefit of this disclosure will appreciate that many other variations from the foregoing description and drawings may be made within the scope of the present invention. Indeed, the invention is not limited to the details described above. Rather, it is the following claims including any amendments thereto that define the scope of the invention.