bug 1244: separate frame for linked list image

[libreriscv.git] / ztrans_proposal.mdwn

diff --git a/ztrans_proposal.mdwn b/ztrans_proposal.mdwn
index 996fd203a3ab5139e54d75664aa799fecf6b15d1..ca73c4220a0faf66a30917a4b688fe32d0a6a657 100644 (file)
--- a/ztrans_proposal.mdwn
+++ b/ztrans_proposal.mdwn
@@ -1,7 +1,14 @@
+**OBSOLETE**, superceded by [[openpower/transcendentals]]
+
 # Zftrans - transcendental operations
 
-With thanks to:
+Summary:
+
+*This proposal extends RISC-V scalar floating point operations to add IEEE754 transcendental functions (pow, log etc) and trigonometric functions (sin, cos etc). These functions are also 98% shared with the Khronos Group OpenCL Extended Instruction Set.*
 
+Authors/Contributors:
+
+* Luke Kenneth Casson Leighton
 * Jacob Lifshay
 * Dan Petroski
 * Mitch Alsup
@@ -54,7 +61,7 @@ Minimum recommended requirements for Mobile-Embedded 3D: Ztrignpi, Zftrans, with
 
 This proposal is designed to meet a wide range of extremely diverse needs,
 allowing implementors from all of them to benefit from the tools and hardware
-cost reductions associated with common standards adoption.
+cost reductions associated with common standards adoption in RISC-V (primarily IEEE754 and Vulkan).
 
 **There are *four* different, disparate platform's needs (two new)**:
 
@@ -210,11 +217,14 @@ Any deviation from Trademarked Standards means that an implementation
 may not be sold and also make a claim of being, for example, "Vulkan
 compatible".
 
-This in turn reinforces and makes a hard requirement a need for public
+For 3D, this in turn reinforces and makes a hard requirement a need for public
 compliance with such standards, over-and-above what would otherwise be
 set by a RISC-V Standards Development Process, including both the
 software compliance and the knock-on implications that has for hardware.
 
+For libraries such as libm and numpy, accuracy is paramount, for software  interoperability across multiple platforms. Some algorithms critically rely on correct IEEE754, for example.
+The conflicting accuracy requirements can be met through the zfpacc extension.
+
 **Collaboration**:
 
 The case for collaboration on any Extension is already well-known.
@@ -312,8 +322,11 @@ numbers of potential opcodes.  BitManip is the perfect counter-example.
 
 # Proposed Opcodes vs Khronos OpenCL vs IEEE754-2019<a name="khronos_equiv"></a>
 
-This list shows the (direct) equivalence between proposed opcodes and
-their Khronos OpenCL equivalents.
+This list shows the (direct) equivalence between proposed opcodes,
+their Khronos OpenCL equivalents, and their IEEE754-2019 equivalents.
+98% of the opcodes in this proposal that are in the IEEE754-2019 standard
+are present in the Khronos Extended Instruction Set.
+
 For RISCV opcode encodings see 
 [[rv_major_opcode_1010011]]
 
@@ -374,7 +387,7 @@ FEXP10   | exp10       | half\_exp10 | native\_exp10 | NONE        | exp10    |
 FLOG10   | log10       | half\_log10 | native\_log10 | NONE        | log10    |
 FPOW     | pow         | NONE        | NONE          | NONE        | pow      |
 FPOWN    | pown        | NONE        | NONE          | NONE        | pown     |
-FPOWR    | powr        | NONE        | NONE          | NONE        | powr     |
+FPOWR    | powr        | half\_powr  | native\_powr  | NONE        | powr     |
 FROOTN   | rootn       | NONE        | NONE          | NONE        | rootn    |
 FHYPOT   | hypot       | NONE        | NONE          | NONE        | hypot    |
 FRECIP   | NONE        | half\_recip | native\_recip | NONE        | NONE (3) |
@@ -387,10 +400,6 @@ NONE     | NONE        | NONE        | NONE          | NONE        | log10p1  |
 
 Note (1) FSINCOS is macro-op fused (see below).
 
-Note (2) IEEE754-2019 pown(x, n) - n is an integer
-
-Note (3) IEEE754-2019 powr(x, y) is defined as "exp(y log (x))"
-
 Note (2) synthesised in IEEE754-2019 as "pown(x, 3)"
 
 Note (3) synthesised in IEEE754-2019 using "1.0 / x"