Condition Register SVP64 Operations

DRAFT STATUS

Links:

Condition Register Fields are only 4 bits wide: this presents some interesting conceptual challenges for SVP64, which was designed primarily for vectors of arithmetic and logical operations. However if predicates may be bits of CR Fields it makes sense to extend Simple-V to cover CR Operations, especially given that Vectorized Rc=1 may be processed by Vectorized CR Operations that usefully in turn may become Predicate Masks to yet more Vector operations, like so:

    sv.cmpi/ew=8 *B,*ra,0    # compare bytes against zero
    sv.cmpi/ew=8 *B2,*ra,13. # and against newline
    sv.cror PM.EQ,B.EQ,B2.EQ # OR compares to create mask
    sv.stb/sm=EQ    ...      # store only nonzero/newline

Element width however is clearly meaningless for a 4-bit collation of Conditions, EQ LT GE SO. Likewise, arithmetic saturation (an important part of Arithmetic SVP64) has no meaning. An alternative Mode Format is required, and given that elwidths are meaningless for CR Fields the bits in SVP64 RM may be used for other purposes.

This alternative mapping only applies to instructions that only reference a CR Field or CR bit as the sole exclusive result. This section does not apply to instructions which primarily produce arithmetic results that also, as an aside, produce a corresponding CR Field (such as when Rc=1). Instructions that involve Rc=1 are definitively arithmetic in nature, where the corresponding Condition Register Field can be considered to be a "co-result". Such CR Field "co-result" arithmeric operations are firmly out of scope for this section, being covered fully by normal.

  • Examples of Vectorizeable Defined Word-instructions to which this section does apply is
    • mfcr and cmpi (3 bit operands) and
    • crnor and crand (5 bit operands).
  • Examples to which this section does not apply include fadds. and subf. which both produce arithmetic results (and a CR Field co-result).
  • mtcr is considered normal because it refers to the entire 32-bit Condition Register rather than to CR Fields.

The CR Mode Format still applies to sv.cmpi because despite taking a GPR as input, the output from the Base Scalar v3.0B cmpi instruction is purely to a Condition Register Field.

Other modes are still applicable and include:

  • Data-dependent fail-first. useful to truncate VL based on analysis of a Condition Register result bit.
  • Reduction. Reduction is useful for analysing a Vector of Condition Register Fields and reducing it to one single Condition Register Field.

Special atrention should be paid on the difference between Data-Dependent Fail-First on CR operations and normal regarding the seemingly-contradictory behaviour of Rc=1,VLi=0. Explained below.

Format

SVP64 RM MODE (includes ELWIDTH_SRC bits) for CR-based operations:

6 7 19:20 21 22:23 description
/ / 0 0 RG dz sz simple mode
/ / 1 0 RG dz sz scalar reduce mode (mapreduce)
zz SNZ VLI 1 inv CR-bit Ffirst 3-bit mode
/ SNZ VLI 1 inv dz sz Ffirst 5-bit mode (implies CR-bit from result)

Fields:

  • sz / dz if predication is enabled will put zeros into the dest (or as src in the case of twin pred) when the predicate bit is zero. otherwise the element is ignored or skipped, depending on context.
  • zz set both sz and dz equal to this flag
  • SNZ In fail-first mode, on the bit being tested, when sz=1 and SNZ=1 a value "1" is put in place of "0".
  • inv CR-bit just as in branches (BO) these bits allow testing of a CR bit and whether it is set (inv=0) or unset (inv=1)
  • RG Reverse-Gear: inverts the Vector Loop order (VL-1 downto 0) rather than the normal 0 upto VL-1
  • VLi VL inclusive: in fail-first mode, the truncation of VL includes the current element at the failure point rather than excludes it from the count.

Data-dependent fail-first on CR operations

The principle of data-dependent fail-first is that if, during the course of sequentially evaluating an element's Condition Test, one such test is encountered which fails, then VL (Vector Length) is truncated (set) at that point. In the case of Arithmetic SVP64 Operations the Condition Register Field generated from Rc=1 is used as the basis for the truncation decision. However with CR-based operations that CR Field result to be tested is provided by the operation itself.

Data-dependent SVP64 Vectorized Operations involving the creation or modification of a CR can require an extra two bits, which are not available in the compact space of the SVP64 RM MODE Field. With the concept of element width overrides being meaningless for CR Fields it is possible to use the ELWIDTH field for alternative purposes.

Condition Register based operations such as sv.mfcr and sv.crand can thus be made more flexible. However the rules that apply in this section also apply to future CR-based instructions.

There are two primary different types of CR operations:

  • Those which have a 3-bit operand field (referring to a CR Field)
  • Those which have a 5-bit operand (referring to a bit within the whole 32-bit CR)

Examining these two types it is observed that the difference may be considered to be that the 5-bit variant already provides the prerequisite information about which CR Field bit (EQ, GE, LT, SO) is to be operated on by the instruction. Thus, logically, we may set the following rule:

  • When a 5-bit CR Result field is used in an instruction, the 5-bit variant of Data-Dependent Fail-First must be used. i.e. the bit of the CR field to be tested is the one that has just been modified (created) by the operation.
  • When a 3-bit CR Result field is used the 3-bit variant must be used, providing as it does the missing CRbit field in order to select which CR Field bit of the result shall be tested (EQ, LE, GE, SO)

The reason why the 3-bit CR variant needs the additional CR-bit field should be obvious from the fact that the 3-bit CR Field from the base Power ISA v3.0B operation clearly does not contain and is missing the two CR Field Selector bits. Thus, these two bits (to select EQ, LE, GE or SO) must be provided in another way.

Examples of the former type:

  • crand, cror, crnor. These all are 5-bit destination (BT). The bit to be tested against inv is the one selected by BT
  • mcrf. This has only 3-bit destiation (BF). In order to select the bit to be tested, the alternative encoding must be used. With CRbit coming from the SVP64 RM bits 22-23 the bit of BF to be tested is identified.

Just as with SVP64 branches there is the option to truncate VL to include the element being tested (VLi=1) and to exclude it (VLi=0).

Also exactly as with normal fail-first, VL cannot, unlike ldst, be set to an arbitrary value. Deterministic behaviour is required.

Important also to note is that reduce mode is implied by Data-Dependent Fail-First. In other words where normally if the destination is Scalar, the looping terminates at the first result, Data-Dependent Fail-First continues just as it does in reduce mode. This allows effectively conditional reduction (one register is both a source and destination) where testing of each result gives an option to exit.

Apparent contradictory behaviour compared to Rc=1,VLi=0

In normal mode when Rc=1 and VLi=0 the Vector of co-results appears to ignore VLi=0 because the last CR Field co-result element tested is written out regardless of the setting of VLi. This is because when Rc=1 the CR Fields are co-results not actual results.

When looking at the actual number of results written (arithmetic results on arithmetic operations vs CR-Field results on CR-Field operations), and ignoring the Rc=1 co-results entirely, the totals (the behaviours) are consistent whether VLi=0 or VLi=1.

*Programmer's Note: Data-dependent fail-first stores an updated VL in the SVSTATE SPR, not in any GPR. If needed VL may be obtained by using the alias getvl.

Reduction and Iteration

Bearing in mind as described in the appendix SVP64 Horizontal Reduction is a deterministic schedule on top of base Scalar v3.0 operations, the same rules apply to CR Operations, i.e. that programmers must follow certain conventions in order for an end result of a reduction to be achieved. Unlike other Vector ISAs there are no explicit reduction opcodes in SVP64: Schedules however achieve the same effect.

Due to these conventions only reduction on operations such as crand and cror are meaningful because these have Condition Register Fields as both input and output. Meaningless operations are not prohibited because the cost in hardware of doing so is prohibitive, but neither are they UNDEFINED. Implementations are still required to execute them but are at liberty to optimise out any operations that would ultimately be overwritten, as long as Strict Program Order is still obvservable by the programmer.

Also bear in mind that 'Reverse Gear' may be enabled, which can be used in combination with overlapping CR operations to iteratively accumulate results. Issuing a sv.crand operation for example with BA differing from BB by one Condition Register Field would result in a cascade effect, where the first-encountered CR Field would set the result to zero, and also all subsequent CR Field elements thereafter:

    # sv.crand/mr/rg CR4.ge.v, CR5.ge.v, CR4.ge.v
    for i in VL-1 downto 0 # reverse gear
         CR.field[4+i].ge &= CR.field[5+i].ge

sv.crxor with reduction would be particularly useful for parity calculation for example, although there are many ways in which the same calculation could be carried out (parityw) after transferring a vector of CR Fields to a GPR using crweird operations.

Implementations are free and clear to optimise these reductions in any way they see fit, as long as the end-result is compatible with Strict Program Order being observed, and Interrupt latency is not adversely impacted. Good examples include sv.cror/mr which is a cumulative ORing of a Vector of CR Field bits, and consequently an easy target for parallelising.

Unusual and quirky CR operations

cmp and other compare ops

cmp and cmpi etc take GPRs as sources and create a CR Field as a result.

    cmpli BF,L,RA,UI
    cmpeqb BF,RA,RB

With ELWIDTH applying to the source GPR operands this is perfectly fine.

crweird operations

There are 4 weird CR-GPR operations and one reasonable one in the cr int predication set:

  • crrweird
  • mtcrweird
  • crweirder
  • crweird
  • mcrfm - reasonably normal and referring to CR Fields for src and dest.

The "weird" operations have a non-standard behaviour, being able to treat individual bits of a GPR effectively as elements. They are expected to be Micro-coded by most Hardware implementations.

Effectively-separate Vector and Scalar Condition Register file

As mentioned in the introduction on svp64 some prohibitions are made on instructions involving Condition Registers that allow implementors to actually consider the Scalar CR (fields CR0-CR7) as a completely separate register file from the Vector CRs (fields CR8-CR127).

The complications arise for existing Hardware implementations due to Power ISA not having had "Conditional Execution" added. Adding entirely new pipelines and a new Vector CR Register file is a much easier proposition to consider.

The prohibitions utilise the CR Field numbers implicitly to split out Vectorized CR operations to be considered completely separare and distinct from Scalar CR operations even though they both use the same binary encoding. This does in turn mean that at the Decode Phase it becomes necessary to examine not only the operation (sv.crand, sv.cmp) but also the CR Field numbers as well as whether, in the EXTRA2/3 Mode bits, the operands are Vectorized.

A future version of Power ISA, where SVP64Single is proposed, would in fact introduce "Conditional Execution", including for VSX. At which point this prohibition becomes moot as Predication would be required to be added into the existing Scalar (and PackedSIMD VSX) side of existing Power ISA implementations.

\newpage{}