From: rogier.brussee@b90d8f15ea9cc02d3617789f77a64c35bcd838d8 Date: Fri, 4 May 2018 08:09:46 +0000 (+0100) Subject: add the crucial motivation for the extension X-Git-Tag: convert-csv-opcode-to-binary~5383 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=0bd557468e94f0cfe558b36aeb1c4e11cc68f7a7;p=libreriscv.git add the crucial motivation for the extension --- diff --git a/overloadable_opcodes.mdwn b/overloadable_opcodes.mdwn index 7fc272951..ed05873e2 100644 --- a/overloadable_opcodes.mdwn +++ b/overloadable_opcodes.mdwn @@ -1,7 +1,11 @@ # Overloadable opcodes. -The xext proposal defines a small number N (e.g. N= 8) standardised R-type instructions -xcmd0, xcmd1, ...xcmd[N-1], preferably in the brownfield opcode space. +The overloadable opcode (or xext) proposal allows a non standard extension to use a documented 20 + 3 bit (or 52 + 3 bit on RV64) UUID identifier for an instruction for _software_ to use. At runtime, a cpu translates the UUID to a small implementation defined 12 + 3 bit bit identifier for _hardware_ to use. It also defines a fallback mechanism for the UUID's of instructions the cpu does not recognise. + +Tl;DR see below for a C description of how this is supposed to work. + +It defines a small number N standardised R-type instructions +xcmd0, xcmd1, ...xcmd[N-1], preferably in the brownfield opcode space. We usually assume N = 8 (aka log2(8) = 3 in the + 3 above). Each xcmd takes (in rs1) a 12 bit "logical unit" (lun) identifying a (sub)device on the cpu that implements some "extension interface" (xintf) together with some additional data. Extension devices may be implemented in any convenient form, e.g. non standard extensions @@ -36,7 +40,6 @@ arbitrary number of commands. Organising related commands in xintfs, helps avoid pollution, and allows to amortise the (small) cost of UUID to lun translation if related commands are used in combination. -Tl;DR see below for a C description of how this is supposed to work. == Description of the instructions ==