comments and references

[libreriscv.git] / isa_conflict_resolution.mdwn

diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn
index 6de6852cc3d79a9e0b75652ba9eab6df8e5e741e..d80b7efb328d75ca3d3dcde58dd15c0e5c7a824e 100644 (file)
--- a/isa_conflict_resolution.mdwn
+++ b/isa_conflict_resolution.mdwn
@@ -89,7 +89,7 @@ Each of these will be discussed below in their own sections.
 
 # Do nothing (no problem exists)
 
-TBD (basically not an option).
+(Summary: not an option)
 
 There were several solutions offered that fell into this category.
 A few of them are listed in the introduction; more are listed below,
@@ -138,7 +138,7 @@ field.
 
 # Do nothing (out of scope)
 
-TBD (basically, may not be RV Foundation's "scope", still results in
+(Summary: may not be RV Foundation's "scope", still results in
 problem, so not an option)
 
 This was one of the first arguments presented: The RISC-V Foundation
@@ -156,7 +156,7 @@ be hardest hit by the resultant chaos, and that will just be the more
 
 # Do nothing (Compliance too complex, therefore out of scope)
 
-TBD (basically, may not be RV Foundation's "scope", still results in
+(Summary: may not be RV Foundation's "scope", still results in
 problem, so not an option)
 
 The summary here was that Compliance testing of Custom Extensions is
@@ -183,7 +183,7 @@ solution be very, very simple.
 
 # MISA
 
-TBD, basically MISA not suitable
+(Summary: MISA not suitable, leads to better idea)
 
 MISA permits extensions to be disabled by masking out the relevant bit.
 Hypothetically it could be used to disable one extension, then enable
@@ -206,8 +206,8 @@ a hundred percent unsuitable for solving the problem.
 
 # MISA-like
 
-TBD, basically same as mvend/march WARL except needs an extra CSR where
-mv/ma doesn't.
+(Summary: basically same as mvend/march WARL except needs an extra CSR where
+mv/ma doesn't. Along right lines, doesn't meet full requirements)
 
 Out of the MISA discussion came a "MISA-like" proposal, which would
 take into account the flaws pointed out by trying to use "MISA":
@@ -224,7 +224,7 @@ take into account the flaws pointed out by trying to use "MISA":
 Whilst it was the first "workable" solution it was also noted that the
 scheme is invasive: it requires an entirely new CSR to be added
 to the privileged spec (thus making existing implementations redundant).
-This does not completely fulfil the "minimum impact" requirement.
+This does not fulfil the "minimum impact" requirement.
 
 Also interesting around the same time an additional discussion was
 raised that covered the *compiler* side of the same equation.  This
@@ -237,15 +237,18 @@ separate page?  review this para?**)
 
 # mvendorid/marchid WARL
 
-TBD paraphrase and clarify
+(Summary: the only idea that meets the full requirements.  Needs
+ toolchain backup, but only when the first chip is released)
 
-Coming out of the software-related proposal by Jacob, which hinged on
-the idea of a global gcc / binutils database that kept and coordinated
-architectural encodings, was to quite simply make the mvendorid and
-marchid CSRs have WARL (writeable) characteristics.  For instances
-where mvendorid and marchid are readable, that would be taken to be
-a Standards-mandatory "declaration" that the architecture has *no*
-Custom Extensions.
+Coming out of the software-related proposal by Jacob Bachmeyer, which
+hinged on the idea of a globally-maintained gcc / binutils database
+that kept and coordinated architectural encodings (curated by the Free
+Software Foundation), was to quite simply make the mvendorid and marchid
+CSRs have WARL (writeable) characteristics.  For instances where mvendorid
+and marchid are readable, that would be taken to be a Standards-mandatory
+"declaration" that the architecture has *no* Custom Extensions (and that
+it conforms precisely to one and only one specific variant of the
+RISC-V Specification).
 
 This incredibly simple non-invasive idea has some unique and distinct
 advantages over other proposals:
@@ -300,7 +303,7 @@ during the switching phase, if needed.
 
 # ioctl-like
 
-TBD - [[ioctl]] for full details, summary kept here
+(Summary: good solid orthogonal idea.  See [[ioctl]] for full details)
 
 This proposal basically mirrors the concept of POSIX ioctls, providing
 (arbitrarily) 8 functions (opcodes) whose meaning may be over-ridden
@@ -324,16 +327,19 @@ being worthwhile in its own right, and standing on its own merits and
 thus definitely worthwhile pursuing, it is non-trivial and much more
 invasive than the mvendor/march-id WARL concept.
 
-# Discussion and analysis
+# Comments, Discussion and analysis
 
-TBD
+TBD: placeholder as of 26apr2018
 
-# Conclusion
+# Summary and Conclusion
 
 In the early sections (those in the category "no action") it was established
 in each case that the problem is not solved.  Avoidance of responsibility,
 or conflation of "not our problem" with "no problem" does not make "problem"
-go away.
+go away.  Even "making it the Fabless Semiconductor's design problem" resulted
+in a chip being *more costly to engineer as hardware **and** more costly
+from a software-support perspective to maintain*... without actually
+fixing the problem.
 
 The first idea considered which could fix the problem was to just use
 the pre-existing MISA CSR, however this was determined not to have
@@ -437,3 +443,8 @@ The following conversation exerpts are taken from the ISA-dev discussion
 > it is implementing. It will test nothing in the custom extension space,
 > and doesn't monitor or care what is in that space.
 
+# References
+
+* <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/7bbwSIW5aqM>
+* <https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/InzQ1wr_3Ak%5B1-25%5D>
+