From 30847659f63a8c00382cf85bcc35ed393e0f26a1 Mon Sep 17 00:00:00 2001 From: lkcl Date: Tue, 16 Jul 2019 09:16:18 +0100 Subject: [PATCH] --- isa_conflict_resolution.mdwn | 48 +++++++++++++++++++++++++++++++++++- 1 file changed, 47 insertions(+), 1 deletion(-) diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn index 93c3081ef..847e59933 100644 --- a/isa_conflict_resolution.mdwn +++ b/isa_conflict_resolution.mdwn @@ -2,7 +2,8 @@ **Note: out-of-date as of review 31apr2018, requires updating to reflect "mvendorid-marchid-isamux" concept.** Recent discussion 10jun2019 - +. +Now updated with its own spec [[isamux_isans]]. ## Executive Summary @@ -350,6 +351,51 @@ invasive than the mvendor/march-id WARL concept. ==RB== +# Dynamic runtime hardware-adjustable custom opcode encodings + +Perhaps this is a misunderstanding, that what is being advocated +below (see link for full context): + +> The best that can be done is to allow each custom extension to have +> its opcodes easily re positioned depending on what other custom extensions +> the user wants available in the same program (without mode switches). + +It was suggested to use markers in the object files as a way to +identify opcodes that can be "re-encoded". Contrast this with Jacob +Bachmeyer's original idea where the *assembly code* (only) contains +such markers (on a global world-wide unique basis, using mvendorid-marchid-isamux +tuples to do so). + + + +There are two possible interpretations of this: + +* (1) the Hardware RTL is reconfigureable (parameterisable) to allow + easy selection of *static* moving (adjustment) of which opcodes a + particular instruction uses. This runs into the same difficulties + as outlined in other areas of this document. +* (2) the Hardware RTL contains DYNAMIC and RUN-TIME CONFIGUREABLE + opcodes (presumably using additional CSRs to move meanings) + +This would help any implementation to adjust to whatever future (official) +uses a particular encoding was selected. It would be particularly useful +if an implementation used certain brownfield encodings. + +The only downsides are: + +* (1) Compiler support for dynamic opcode reconfiguration would be... + complex. +* (2) The instruction decode phase is also made more complex, now + involving reconfigureable lookup tables. Whilst major opcodes + can be easily redirected, brownfield encodings are more involved. + +Compared to a stark choice of having to move (exclusively) to 48-bit +or 64-bit encodings, dynamic runtime opcode reconfiguration is +comparatively much more palatable. + +In effect, it is a much more advanced version of ISAMUX/NS +(see [[isamux_isans]]). + # Comments, Discussion and analysis TBD: placeholder as of 26apr2018 -- 2.30.2