The `CR{n}` notation is designed to give *linear sequential
numbering* in the Vector domain on a straight sequential Vector Loop.
-Without it, there is the risk of massive confusion as CR Fields
-could be accessed in order `CR7 CR6 ... CR0 CR15 CR14 .. CR8 CR23..`
-in Vector Loops.
In OpenPOWER v3.0/1, BF/BT/BA/BB are all 5 bits. The top 3 bits (0:2)
select one of the 8 CRs; the bottom 2 bits (3:4) select one of 4 bits
*in* that CR (EQ/LT/GT/SO). The numbering was determined (after 4 months of
analysis and research) to be as follows:
- CR_index = 7-(BA>>2) # top 3 bits but de-MSB0'd
- bit_index = 3-(BA & 0b11) # low 2 bits but de-MSB0'd
+ CR_index = (BA>>2) # top 3 bits
+ bit_index = (BA & 0b11) # low 2 bits
CR_reg = CR{CR_index} # get the CR
# finally get the bit from the CR.
CR_bit = (CR_reg & (1<<bit_index)) != 0
Thus, for example, to access a given bit for a CR in SV mode, the v3.0B
algorithm to determine CR\_reg is modified to as follows:
- CR_index = 7-(BA>>2) # top 3 bits but BE
+ CR_index = (BA>>2) # top 3 bits
if spec[0]:
# vector mode, 0-124 increments of 4
CR_index = (CR_index<<4) | (spec[1:2] << 2)
# scalar mode, 0-32 increments of 1
CR_index = (spec[1:2]<<3) | CR_index
# same as for v3.0/v3.1 from this point onwards
- bit_index = 3-(BA & 0b11) # low 2 bits but BE
+ bit_index = (BA & 0b11) # low 2 bits
CR_reg = CR{CR_index} # get the CR
# finally get the bit from the CR.
CR_bit = (CR_reg & (1<<bit_index)) != 0