isa_conflict_resolution/isamux_isans.mdwn

   1 # Note-form on ISAMUX (aka "ISANS")
   2
   3 A fixed number of additional (hidden) bits that go directly and non-optionally
   4 into the instruction decode phase, extending (in each implementation) the
   5 opcode length to 16+N, 32+N, 48+N, where N is a hard fixed quantity on
   6 a per-implementor basis.
   7
   8 Where the opcode is normally loaded from the location at the PC, the extra
   9 bits are instead set via a CSR: hence why they are described as "hidden".
  10
  11 # Hypothetical Format
  12
  13 ```
  14   3                   2
  15   1
  16 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
  17      reserved                      |          |      | foreignarch |1|
  18        reserved                    |          |        |B| rvcpage |0|
  19
  20 ```
  21
  22 RV Mode
  23
  24 * when bit 0 is 0, "RV" mode is selected.
  25 * in RV mode, bits 1 thru 5 provide up to 16 possible alternative meanings (namespaces) for 16 Bit opcodes. "pages" if you will. The top bit indicates custom meanings. When set to 0, the top bit is for official usage.
  26 * Bits 15 thru 31 are reserved.
  27 * bit 6 ("B") is LE/BE
  28
  29 16 bit page examples:
  30
  31 * 0b0000 STANDARD (2019) RVC
  32 * 0b0001 RVCv2
  33 * 0b0010 RV16
  34 * 0b0011 RVCv3
  35 * ...
  36 * 0b1000 custom 16 bit opcode meanings 1
  37 * .....
  38
  39 Foreign Arch Mode
  40
  41 * when bit 0 is 1, "Foreign arch" mode is selected.
  42 * Bits 1 thru 7 are a table of foreign arches.
  43 * when the MSB is 1, this is for custom use.
  44 * when the MSB is 0, bits 1 thru 6 are reserved for 64 possible official foreign archs.
  45
  46
  47 Foreign archs could be (examples):
  48
  49 * 0b000000 x86_32
  50 * 0b000001 x86_64
  51 * 0b000010 MIPS32
  52 * 0b000011 MIPS64
  53 * ....
  54 * 0b010000 Java Bytecode
  55 * ....
  56 * 0b1000000 custom foreign arch 1
  57 * ....
  58
  59
  60
  61 # Privileged Modes / Traps
  62
  63 i remembered how priv-mode (and interrupts) are
  64 done.  just as the idea you suggested of having separate MISAs per
  65 ISAMUX/ISANS permutation, so are separate utvec / stvec / htvec
  66 required.
  67
  68 whilst these tables would under some circumstances point to exactly
  69 the same trap vectors, many would not.
  70
  71 or, at least, the very first thing that each would do is: push the
  72 current ISAMUX/ISANS value onto the stack, set it to a "known-good"
  73 value, and call the "common" trap vector as a function.  when that
  74 function exits, the ISAMUX/ISANS is popped off the stack, returned to
  75 its former value, and the trap allowed to exit.
  76
  77 each trap in each ISAMUX/ISANS is written in the opcodes that that
  78 ISAMUX/ISANS uses.  the RVCv2 use-case should be pretty obvious that
  79 if you use RVCv1 opcodes within the RVCv2 ISAMUX/ISANS trap, it's not
  80 going to work.
  81
  82 thus, the need for having a per-privilege per-permutation utvec/stvec/htvec.
  83
  84 # Why ISAMUX / ISANS has to be WLRL and mandatory trap on illegal writes
  85
  86 The namespaces, set by bits in the CSR, are functionally directly equivalent to c++ nanespaces, even down to the use of braces.
  87
  88 WARL, by allowing implementors to choose the value, prevents and prohibits the critical and necessary raising of an exception that would begin the JIT process in the case of ongoing standards evolution.
  89
  90 Without this opportunity, an implementation has no way of knowing how to JIT emulate any given conflicting opcode. It is as if the c++ standard was given the similar opportunity to completely ignore the "using namespace" prefix!
  91
  92 --
  93
  94 Ok so I trust it's now clear why WLRL (thanks Allen) is needed.
  95
  96 When Dan raised the WARL concern initially a situation was masked by the conflict, that if gone unnoticed would jeapordise ISAMUX/ISANS entirely. Actually, two separate errors. So thank you for raising the question.
  97
  98 The situation arises when foreign archs are to be given their own NS bit. MIPS is allocated bit 8, x86 bit 9, whilst LE/BE is given bit 0, RVCv2 bit 1 andso on. All of this potential rather than actual, clearly.
  99
 100 Imagine then that software tries to write and set not just bit 8 and bit 9, it also tries to set bit 0 and 1 as well.
 101
 102 This *IS* on the face of it a legitimate reason to make ISAMUX/ISANS WARL.
 103
 104 However it masks a fundamental flaw that has to be addressed, which brings us back much closer to the original design of 18 months ago, and it's highlighted thus:
 105
 106 x86 and simultaneous RVCv2 modes are total nonsense in the first place!
 107
 108 The solution instead is to have a NS bit (bit0) that SPECIFICALLY determines if the arch is RV or not.  If 0, the rest of the ISAMUX/ISANS is very specifically RV *only*, and if 1, the ISAMUX/ISANS is a *binary* table of foreign architectures and foreign architectures only.
 109
 110 Exactly how many bits are used for the foreign arch table, is to be determined. 7 bits, one of which is reserved for custom usage, leaving a whopping 64 possible "official" foreign instruction sets to be hardware-supported/JIT-emulated seems to be sufficiently gratuitous, to me.
 111
 112 One of those could even be Java Bytecode!
 113
 114 Now, it could *hypothetically* be argued that the permutation of setting LE/BE and MIPS for example is desirable. A simple analysis shows this not to be the case: once in the MIPS foreign NS, it is the MIPS hardware implementation that should have its own way of setting and managing its LE/BE mode, because to do otherwise drastically interferes with MIPS binary compatibility.
 115
 116 Thus, it is officially Not Our Problem: only flipping into one foreign arch at a time makes sense, thus this has to be reflected in the ISAMUX/ISANS CSR itself, completely side-stepping the (apparent) need to make the NS CSR WARL (which would not work anyway, as previously mentioned).
 117
 118 So, thank you, again, Dan, for raising this. It would have completely jeapordised ISAMUX/NS if not spotted.
 119
 120 The second issue is: how does any hardware system, whether it support ISANS or not, and whether any future hardware supports some Namespaces and, in a transitive fashion, has to support *more* future namespaces, through JIT emulation, if this is not planned properly in advance?
 121
 122 Let us take the simple case first: a current 2019 RISCV fully compliant RV64GC UNIX capable system (with mandatory traps on all unsupported CSRs).
 123
 124 Fast forward 20 years, there are now 5 ISAMUX/NS unary bits, and 3 foreign arch binary table entries.
 125
 126 Such a system is perfectly possible of software JIT emulating ALL of these options because the write to the (illegal, for that system) ISAMUX/NS CSR generates the trap that is needed for that system ti begin JIT mode.
 127
 128 (This again emphasises exactly why the trap is mandatory).
 129
 130 Now let us take the case of a hypothetical system from say 2021 that implements RVCv2 at the hardware level.
 131
 132 Fast forward 20 years: if the CSR were made WARL, that system would be absolutely screwed. The implementor would be under the false impression that ignoring setting of "illegal" bits was acceptable, making the transition to JIT mode flat-out impossible to detect.
 133
 134 When this is considered transitively, considering all future additions to the NS, and all permutations, it can be logically deduced that there is a need to reserve a *full* set of bits in the ISAMUX/NS CSR *in advance*.
 135
 136 i.e. that *right now*, in the year 2019, the entire ISAMUX/NS CSR cannot be added to piecemeal, the full 32 (or 64) bits *has* to be reserved, and reserved bits set at zero.
 137
 138 Furthermore, if any software attempts to write to those reserved bits, it *must* be treated just as if those bits were distinct and nonexistent CSRs, and a trap raised.
 139
 140 It makes more sense to consider each NS as having its own completely separate CSR, which, if it does not exist, clearly it should be obvious that, as an unsupported CSR, a trap should be raised (and JIT emulation activated).
 141
 142 However given that only the one bit is needed (in RV NS Mode, not Foreign NS Mode), it would be terribly wasteful of the CSRs to do this, despite it being technically correct and much easier to understand why trap raising is so essential (mandatory).
 143
 144 This again should emphasise how to mentally get one's head round this mind-bendingly complex problem space: think of each NS bit as its own totally separate CSR that every implementor is free and clear to implement (or leave to JIT Emulation) as they see fit.
 145
 146 Only then does the mandatory need to trap on write really start to hit home, as does the need to preallocate a full set of reserved zero values in the RV ISAMUX/NS.
 147
 148 Lastly, I *think* it's ok to only reserve say 32 bits, and, in 50 years time if that genuinely is not enough, start the process all over again with a new CSR.  ISAMUX2/NS2.
 149
 150 Subdivision of the RV NS (support for RVCv3/4/5/RV16 without wasting precious CSR bits) best left for discussion another time, the above is a heck of a lot to absorb, already.
 151
 152 # Alternative RVC 16 Bit Opcode meanings
 153
 154 Ok, here is appropriate to raise an idea how to cover RVC and future variants, including RV16.
 155
 156 Just as with foreign archs, and you quite rightly highlight above, it makes absolutely no sense to try to select both RVCv1, v2, v3 and so on, all simultaneously. An unary bit vector for RVC modes, changing the 16 BIT opcode space meaning, is wasteful and again has us believe that WARL is the "solution".
 157
 158 The correct thing to do is, again, just like with foreign archs, to treat RVCs as a *binary* namespace selector. Bits 1 thru 3 would give 8 possible completely new alternative meanings, just like how the Z80 and the 286 and 386 used to do bank switching.
 159
 160 All zeros is clearly reserved for the present RVC. 0b001 for RVCv2. 0b010 for RV16 (look it up) and there should definitely be room reserved here for custom reencodings of the 16 bit opcode space.
 161