X-Git-Url: https://git.libre-soc.org/?a=blobdiff_plain;f=isa_conflict_resolution.mdwn;h=8125aa392c63c24b80d0768376037d794ade3966;hb=bbc68c99a8f0925a5c19e7a3186b4443df0ca973;hp=03aef29efbfe6eb2a79c1762ba0553136209ad4e;hpb=413f6903ae449e4cc624f9fe173e640a1a49d5cc;p=libreriscv.git diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn index 03aef29ef..8125aa392 100644 --- a/isa_conflict_resolution.mdwn +++ b/isa_conflict_resolution.mdwn @@ -558,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 *