remove retro-fit branch section

diff --git a/simple_v_extension/specification.mdwn b/simple_v_extension/specification.mdwn
index 1d0a173bc23ad23bbb84182046b4747b9f084e17..10c4333daeaae8b5542f726de22636247c4d980c 100644 (file)
--- a/simple_v_extension/specification.mdwn
+++ b/simple_v_extension/specification.mdwn
@@ -793,76 +793,4 @@ No specific hints are yet defined in Simple-V
 
 # Under consideration <a name="issues"></a>
 
-## Retro-fitting Predication into branch-explicit ISA <a name="predication_retrofit"></a>
-
-One of the goals of this parallelism proposal is to avoid instruction
-duplication.  However, with the base ISA having been designed explictly
-to *avoid* condition-codes entirely, shoe-horning predication into it
-bcomes quite challenging.
-
-However what if all branch instructions, if referencing a vectorised
-register, were instead given *completely new analogous meanings* that
-resulted in a parallel bit-wise predication register being set?  This
-would have to be done for both C.BEQZ and C.BNEZ, as well as BEQ, BNE,
-BLT and BGE.
-
-We might imagine that FEQ, FLT and FLT would also need to be converted,
-however these are effectively *already* in the precise form needed and
-do not need to be converted *at all*!  The difference is that FEQ, FLT
-and FLE *specifically* write a 1 to an integer register if the condition
-holds, and 0 if not.  All that needs to be done here is to say, "if
-the integer register is tagged with a bit that says it is a predication
-register, the **bit** in the integer register is set based on the
-current vector index" instead.
-
-There is, in the standard Conditional Branch instruction, more than
-adequate space to interpret it in a similar fashion:
-
-[[!table  data="""
-31      |30 ..... 25 |24..20|19..15| 14...12| 11.....8 | 7       | 6....0 |
-imm[12] | imm[10:5]  |rs2   | rs1  | funct3 | imm[4:1] | imm[11] | opcode |
- 1      | 6          | 5    | 5    | 3      | 4        | 1       |   7    |
-   offset[12,10:5]  || src2 | src1 | BEQ    | offset[11,4:1]    || BRANCH |
-"""]]
-
-This would become:
-
-[[!table  data="""
-31      | 30 .. 25 |24 ... 20 | 19 15 | 14  12 | 11 ..  8 | 7       | 6 ... 0 |
-imm[12] | imm[10:5]| rs2      | rs1   | funct3 | imm[4:1] | imm[11] | opcode  |
-1       | 6        | 5        | 5     | 3      | 4             | 1  | 7       |
-reserved          || src2     | src1  | BEQ    | predicate rs3     || BRANCH  |
-"""]]
-
-Similarly the C.BEQZ and C.BNEZ instruction format may be retro-fitted,
-with the interesting side-effect that there is space within what is presently
-the "immediate offset" field to reinterpret that to add in not only a bit
-field to distinguish between floating-point compare and integer compare,
-not only to add in a second source register, but also use some of the bits as
-a predication target as well.
-
-[[!table  data="""
-15..13 | 12 ....... 10 | 9...7 | 6 ......... 2     | 1 .. 0 |
-funct3 | imm           | rs10  | imm               | op     |
-3      | 3             | 3     | 5                 | 2      |
-C.BEQZ | offset[8,4:3] | src   | offset[7:6,2:1,5] | C1     |
-"""]]
-
-Now uses the CS format:
-
-[[!table  data="""
-15..13 | 12 .  10 | 9 .. 7 | 6 .. 5 | 4..2 | 1 .. 0 |
-funct3 | imm      | rs10   | imm    |      | op     |
-3      | 3        | 3      | 2      | 3    | 2      |
-C.BEQZ | pred rs3 | src1   | I/F B  | src2 | C1     |
-"""]]
-
-Bit 6 would be decoded as "operation refers to Integer or Float" including
-interpreting src1 and src2 accordingly as outlined in Table 12.2 of the
-"C" Standard, version 2.0,
-whilst Bit 5 would allow the operation to be extended, in combination with
-funct3 = 110 or 111: a combination of four distinct (predicated) comparison
-operators.  In both floating-point and integer cases those could be
-EQ/NEQ/LT/LE (with GT and GE being synthesised by inverting src1 and src2).
-
-
+placeholder