(no commit message)

diff --git a/ztrans_proposal.mdwn b/ztrans_proposal.mdwn
index a402f70f9e4ff6d275b7f4bbd406fa17bf611d60..7e05e85106c4e65b6eb34a27390dfcf71883d718 100644 (file)
--- a/ztrans_proposal.mdwn
+++ b/ztrans_proposal.mdwn
@@ -6,6 +6,7 @@ See:
 * <https://www.khronos.org/registry/spir-v/specs/unified1/OpenCL.ExtendedInstructionSet.100.html>
 * Discussion: <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-August/002342.html>
 * [[rv_major_opcode_1010011]] for opcode listing.
+* [[zfpacc_proposal]] for accuracy settings proposal
 
 Extension subsets:
 
@@ -28,10 +29,10 @@ Zarctrignpi
 
 # TODO:
 
-* Decision on accuracy
+* Decision on accuracy, moved to [[zfpacc_proposal]]
 <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-August/002355.html>
 * Errors **MUST** be repeatable.
-* How about three Platform Specifications? 3D, UNIX and Embedded?
+* How about four Platform Specifications? 3DUNIX, UNIX, 3DEmbedded and Embedded?
 <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-August/002361.html>
   Accuracy requirements for dual (triple) purpose implementations must
   meet the higher standard.
@@ -124,39 +125,3 @@ Research needed to ensure that implementors are not compromised by such
 a decision
 <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-August/002358.html>
 
-# Dynamic accuracy CSR
-
-maybe a solution would be to add an extra field to the fp control csr
-to allow selecting one of several accurate or fast modes:
-
-- machine-learning-mode: fast as possible
-  (maybe need additional requirements such as monotonicity for atanh?)
-- GPU-mode: accurate to within a few ULP
-  (see Vulkan, OpenGL, and OpenCL specs for accuracy guidelines)
-- almost-accurate-mode: accurate to <1 ULP
-     (would 0.51 or some other value be better?)
-- fully-accurate-mode: correctly rounded in all cases
-- maybe more modes?
-
-Question: should better accuracy than is requested be permitted? Example:
-Ahmdahl-370 issues.
-
-Comments:
-
-    Yes, embedded systems typically can do with 12, 16 or 32 bit
-    accuracy. Rarely does it require 64 bits. But the idea of making
-    a low power 32 bit FPU/DSP that can accommodate 64 bits is already
-    being done in other designs such as PIC etc I believe. For embedded
-    graphics 16 bit is more than adequate. In fact, Cornell had a very
-    innovative 18-bit floating point format described here (useful for
-    FPGA designs with 18-bit DSPs):
-
-    <https://people.ece.cornell.edu/land/courses/ece5760/FloatingPoint/index.html>
-
-    A very interesting GPU using the 18-bit FPU is also described here:
-
-    <https://people.ece.cornell.edu/land/courses/ece5760/FinalProjects/f2008/ap328_sjp45/website/hardwaredesign.html>
-
-    There are also 8 and 9-bit floating point formats that could be useful
-
-    <https://en.wikipedia.org/wiki/Minifloat>