X-Git-Url: https://git.libre-soc.org/?a=blobdiff_plain;f=isa_conflict_resolution.mdwn;h=8125aa392c63c24b80d0768376037d794ade3966;hb=ea40cb5f22cbcf88ce152fa5d162e7e4746b8f7e;hp=dd253a40df04a191893473e7270ef9af444042f3;hpb=c7696ef2a9d028f10adb3ceef36ba0ff3e5a467c;p=libreriscv.git diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn index dd253a40d..8125aa392 100644 --- a/isa_conflict_resolution.mdwn +++ b/isa_conflict_resolution.mdwn @@ -322,6 +322,8 @@ NOTE: under discussion. ==RB 2018-5-1 dropped IOCTL proposal for the much simpler overloadable opcodes proposal== +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. + The overloadable opcodes proposal defines 8 standardised R-type instructions xcmd0, xcmd1, ...xcmd7 preferably in the brownfield opcode space. Each xcmd takes in rs1 a 12 bit "logical unit" (lun) identifying a device on the cpu that implements some "extension interface" (xintf) together with some additional data. An xintf is a set of up to 8 commands with 2 input and 1 output port (i.e. like an R-type instruction), together with a description of the semantics of the commands. Calling e.g. xcmd3 routes its two inputs and one output ports to command 3 on the device determined by the lun bits in rs1. Thus, the 8 standard xcmd instructions are standard-designated overloadable opcodes, with the non standard semantics of the opcode determined by the lun. @@ -556,6 +558,27 @@ The following conversation exerpts are taken from the ISA-dev discussion > instruction decode must be unambiguous, it merely expands every opcode with > extra bits from a "select" CSR. +## (5) Krste Asanovic on clarification of use of opcode space + +> A CPU is even free to reuse some standard extension encoding space for +> non-standard extensions provided it does not claim to implement that +> standard extension. + +## (6) Clarification of difference between assembler and encodings + +> > The extensible assembler database I proposed assumes that each processor +> > will have *one* and *only* one set of recognized instructions.  (The "hidden +> > prefix" is the immutable vendor/arch/impl tuple in my proposals.)  +> +>  ah this is an extremely important thing to clarify, the difference +> between the recognised instruction assembly mnemonic (which must be +> globally world-wide accepted as canonical) and the binary-level encodings +> of that mnemonic used different vendor implementations which will most +> definitely *not* be unique but require "registration" in the form of +> atomic acceptance as a patch by the FSF to gcc and binutils [and other +> compiler tools]. + + # References *