+**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
* **ZftransAdv**: much more complex to implement in hardware
* **Zfrsqrt**: Reciprocal square-root.
-Minimum recommended requirements for 3D: Zftrans, Ztrigpi, Zarctrigpi,
-Zarctrignpi
+Minimum recommended requirements for 3D: Zftrans, Ztrignpi,
+Zarctrignpi, with Ztrigpi and Zarctrigpi as augmentations.
+
+Minimum recommended requirements for Mobile-Embedded 3D: Ztrignpi, Zftrans, with Ztrigpi as an augmentation.
# TODO:
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)**:
-* 3D Embedded Platform
+* 3D Embedded Platform (new)
* Embedded Platform
-* 3D UNIX Platform
+* 3D UNIX Platform (new)
* UNIX Platform
**The use-cases are**:
**The "contra"-requirements are**:
+* NOT for use with RVV (RISC-V Vector Extension). These are *scalar* opcodes.
+ Ultra Low Power Embedded platforms (smart watches) are sufficiently
+ resource constrained that Vectorisation (of any kind) is likely to be
+ unnecessary and inappropriate.
* The requirements are **not** for the purposes of developing a full custom
- proprietary GPU with proprietary firmware
- driven by *hardware* centric optimised design decisions as a priority over collaboration.
+ proprietary GPU with proprietary firmware driven by *hardware* centric
+ optimised design decisions as a priority over collaboration.
* A full custom proprietary GPU ASIC Manufacturer *may* benefit from
this proposal however the fact that they typically develop proprietary
software that is not shared with the rest of the community likely to
that are completely at odds with the other market at the other end of
the spectrum: Numerical Computation.
-Interoperability in Numerical Computation is absolutely critical: it implies
-IEEE754 compliance. However full IEEE754 compliance automatically and
-inherently penalises a GPU, where accuracy is simply just not necessary.
+Interoperability in Numerical Computation is absolutely critical: it
+implies (correlates directly with) IEEE754 compliance. However full
+IEEE754 compliance automatically and inherently penalises a GPU on
+performance and die area, where accuracy is simply just not necessary.
To meet the needs of both markets, the two new platforms have to be created,
and [[zfpacc_proposal]] is a critical dependency. Runtime selection of
opcodes were best suited to be added to RVV, and, further, that their
requirements conflict with the HPC world, due to the reduced accuracy.
This on the basis that the silicon die area required for IEEE754 is far
-greater than that needed for reduced-accuracy, and thus their product would
-be completely unacceptable in the market.
+greater than that needed for reduced-accuracy, and thus their product
+would be completely unacceptable in the market if it had to meet IEEE754,
+unnecessarily.
An "Embedded 3D" GPU has radically different performance, power
and die-area requirements (and may even target SoftCores in FPGA).
However given that 3D revolves around Standards - DirectX, Vulkan, OpenGL,
OpenCL - users have much more influence than first appears. Compliance
-with these standards is critical as the userbase (Games writers, scientific
-applications) expects not to have to rewrite large codebases to conform
-with non-standards-compliant hardware.
+with these standards is critical as the userbase (Games writers,
+scientific applications) expects not to have to rewrite extremely large
+and costly codebases to conform with *non-standards-compliant* hardware.
-Therefore, compliance with public APIs is paramount, and compliance with
-Trademarked Standards is critical. Any deviation from Trademarked Standards
-means that an implementation may not be sold and also make a claim of being,
-for example, "Vulkan compatible".
+Therefore, compliance with public APIs (Vulkan, OpenCL, OpenGL, DirectX)
+is paramount, and compliance with Trademarked Standards is critical.
+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.
compilers in both GPU and HPC Computer Science divisions. Collaboration
and shared public compliance with those standards brooks no argument.
-*Overall this proposal is categorically and wholly unsuited to
-relegation of "custom" status*.
+The combined requirements of collaboration and multi accuracy requirements
+mean that *overall this proposal is categorically and wholly unsuited
+to relegation of "custom" status*.
# Quantitative Analysis <a name="analysis"></a>
Fortunately, the subdivision by Platform, in combination with the
identification of only two primary markets (Numerical Computation and
3D), means that the logical reasoning applies *uniformly* and broadly
-across *groups* of instructions rather than individually.
+across *groups* of instructions rather than individually, making it a primarily
+hardware-centric and accuracy-centric decision-making process.
In addition, hardware algorithms such as CORDIC can cover such a wide
range of operations (simply by changing the input parameters) that the
above, and, again, one market would be penalised if SINPI was prioritised
over SIN, or vice-versa.
+In essence, then, even when only the two primary markets (3D and
+Numerical Computation) have been identified, this still leaves two
+(three) diametrically-opposed *accuracy* sub-markets as the prime
+conflict drivers:
+
+* Embedded Ultra Low Power
+* IEEE754 compliance
+* Khronos Vulkan compliance
+
Thus the best that can be done is to use Quantitative Analysis to work
-out which "subsets" - sub-Extensions - to include, and be as "inclusive"
-as possible, and thus allow implementors to decide what to add to their
-implementation, and how best to optimise them.
+out which "subsets" - sub-Extensions - to include, provide an additional
+"accuracy" extension, be as "inclusive" as possible, and thus allow
+implementors to decide what to add to their implementation, and how best
+to optimise them.
This approach *only* works due to the uniformity of the function space,
and is **not** an appropriate methodology for use in other Extensions
-with diverse markets and large numbers of potential opcodes.
-BitManip is the perfect counter-example.
+with huge (non-uniform) market diversity even with similarly large
+numbers of potential opcodes. BitManip is the perfect counter-example.
+
+# Proposed Opcodes vs Khronos OpenCL vs IEEE754-2019<a name="khronos_equiv"></a>
-# Proposed Opcodes vs Khronos OpenCL Opcodes <a name="khronos_equiv"></a>
+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.
-This list shows the (direct) equivalence between proposed opcodes and
-their Khronos OpenCL equivalents.
+For RISCV opcode encodings see
+[[rv_major_opcode_1010011]]
See
<https://www.khronos.org/registry/spir-v/specs/unified1/OpenCL.ExtendedInstructionSet.100.html>
+and <https://ieeexplore.ieee.org/document/8766229>
* Special FP16 opcodes are *not* being proposed, except by indirect / inherent
use of the "fmt" field that is already present in the RISC-V Specification.
results in non-compliance, and the vendor may not use the Trademarked words
"Vulkan" etc. in conjunction with their product.
+IEEE754-2019 Table 9.1 lists "additional mathematical operations".
+Interestingly the only functions missing when compared to OpenCL are
+compound, exp2m1, exp10m1, log2p1, log10p1, pown (integer power) and powr.
+
[[!table data="""
-Proposed opcode | OpenCL FP32 | OpenCL FP16 | OpenCL native | OpenCL fast |
-FSIN | sin | half\_sin | native\_sin | NONE |
-FCOS | cos | half\_cos | native\_cos | NONE |
-FTAN | tan | half\_tan | native\_tan | NONE |
-NONE (1) | sincos | NONE | NONE | NONE |
-FASIN | asin | NONE | NONE | NONE |
-FACOS | acos | NONE | NONE | NONE |
-FATAN | atan | NONE | NONE | NONE |
-FSINPI | sinpi | NONE | NONE | NONE |
-FCOSPI | cospi | NONE | NONE | NONE |
-FTANPI | tanpi | NONE | NONE | NONE |
-FASINPI | asinpi | NONE | NONE | NONE |
-FACOSPI | acospi | NONE | NONE | NONE |
-FATANPI | atanpi | NONE | NONE | NONE |
-FSINH | sinh | NONE | NONE | NONE |
-FCOSH | cosh | NONE | NONE | NONE |
-FTANH | tanh | NONE | NONE | NONE |
-FASINH | asinh | NONE | NONE | NONE |
-FACOSH | acosh | NONE | NONE | NONE |
-FATANH | atanh | NONE | NONE | NONE |
-FRSQRT | rsqrt | half\_rsqrt | native\_rsqrt | NONE |
-FCBRT | cbrt | NONE | NONE | NONE |
-FEXP2 | exp2 | half\_exp2 | native\_exp2 | NONE |
-FLOG2 | log2 | half\_log2 | native\_log2 | NONE |
-FEXPM1 | expm1 | NONE | NONE | NONE |
-FLOG1P | log1p | NONE | NONE | NONE |
-FEXP | exp | half\_exp | native\_exp | NONE |
-FLOG | log | half\_log | native\_log | NONE |
-FEXP10 | exp10 | half\_exp10 | native\_exp10 | NONE |
-FLOG10 | log10 | half\_log10 | native\_log10 | NONE |
-FATAN2 | atan2 | NONE | NONE | NONE |
-FATAN2PI | atan2pi | NONE | NONE | NONE |
-FPOW | pow | NONE | NONE | NONE |
-FROOT | rootn | NONE | NONE | NONE |
-FHYPOT | hypot | NONE | NONE | NONE |
-FRECIP | NONE | half\_recip | native\_recip | NONE |
+opcode | OpenCL FP32 | OpenCL FP16 | OpenCL native | OpenCL fast | IEEE754 |
+FSIN | sin | half\_sin | native\_sin | NONE | sin |
+FCOS | cos | half\_cos | native\_cos | NONE | cos |
+FTAN | tan | half\_tan | native\_tan | NONE | tan |
+NONE (1) | sincos | NONE | NONE | NONE | NONE |
+FASIN | asin | NONE | NONE | NONE | asin |
+FACOS | acos | NONE | NONE | NONE | acos |
+FATAN | atan | NONE | NONE | NONE | atan |
+FSINPI | sinpi | NONE | NONE | NONE | sinPi |
+FCOSPI | cospi | NONE | NONE | NONE | cosPi |
+FTANPI | tanpi | NONE | NONE | NONE | tanPi |
+FASINPI | asinpi | NONE | NONE | NONE | asinPi |
+FACOSPI | acospi | NONE | NONE | NONE | acosPi |
+FATANPI | atanpi | NONE | NONE | NONE | atanPi |
+FSINH | sinh | NONE | NONE | NONE | sinh |
+FCOSH | cosh | NONE | NONE | NONE | cosh |
+FTANH | tanh | NONE | NONE | NONE | tanh |
+FASINH | asinh | NONE | NONE | NONE | asinh |
+FACOSH | acosh | NONE | NONE | NONE | acosh |
+FATANH | atanh | NONE | NONE | NONE | atanh |
+FATAN2 | atan2 | NONE | NONE | NONE | atan2 |
+FATAN2PI | atan2pi | NONE | NONE | NONE | atan2pi |
+FRSQRT | rsqrt | half\_rsqrt | native\_rsqrt | NONE | rSqrt |
+FCBRT | cbrt | NONE | NONE | NONE | NONE (2) |
+FEXP2 | exp2 | half\_exp2 | native\_exp2 | NONE | exp2 |
+FLOG2 | log2 | half\_log2 | native\_log2 | NONE | log2 |
+FEXPM1 | expm1 | NONE | NONE | NONE | expm1 |
+FLOG1P | log1p | NONE | NONE | NONE | logp1 |
+FEXP | exp | half\_exp | native\_exp | NONE | exp |
+FLOG | log | half\_log | native\_log | NONE | log |
+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 | 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) |
+NONE | NONE | NONE | NONE | NONE | compound |
+NONE | NONE | NONE | NONE | NONE | exp2m1 |
+NONE | NONE | NONE | NONE | NONE | exp10m1 |
+NONE | NONE | NONE | NONE | NONE | log2p1 |
+NONE | NONE | NONE | NONE | NONE | log10p1 |
"""]]
Note (1) FSINCOS is macro-op fused (see below).
-# List of 2-arg opcodes
+Note (2) synthesised in IEEE754-2019 as "pown(x, 3)"
+
+Note (3) synthesised in IEEE754-2019 using "1.0 / x"
+
+## List of 2-arg opcodes
[[!table data="""
-opcode | Description | pseudo-code | Extension |
+opcode | Description | pseudocode | Extension |
FATAN2 | atan2 arc tangent | rd = atan2(rs2, rs1) | Zarctrignpi |
FATAN2PI | atan2 arc tangent / pi | rd = atan2(rs2, rs1) / pi | Zarctrigpi |
FPOW | x power of y | rd = pow(rs1, rs2) | ZftransAdv |
-FROOT | x power 1/y | rd = pow(rs1, 1/rs2) | ZftransAdv |
-FHYPOT | hypotenuse | rd = sqrt(rs1^2 + rs2^2) | Zftrans |
+FPOWN | x power of n (n int) | rd = pow(rs1, rs2) | ZftransAdv |
+FPOWR | x power of y (x +ve) | rd = exp(rs1 log(rs2)) | ZftransAdv |
+FROOTN | x power 1/n (n integer)| rd = pow(rs1, 1/rs2) | ZftransAdv |
+FHYPOT | hypotenuse | rd = sqrt(rs1^2 + rs2^2) | ZftransAdv |
"""]]
-# List of 1-arg transcendental opcodes
+## List of 1-arg transcendental opcodes
[[!table data="""
-opcode | Description | pseudo-code | Extension |
+opcode | Description | pseudocode | Extension |
FRSQRT | Reciprocal Square-root | rd = sqrt(rs1) | Zfrsqrt |
-FCBRT | Cube Root | rd = pow(rs1, 1.0 / 3) | Zftrans |
+FCBRT | Cube Root | rd = pow(rs1, 1.0 / 3) | ZftransAdv |
FRECIP | Reciprocal | rd = 1.0 / rs1 | Zftrans |
FEXP2 | power-of-2 | rd = pow(2, rs1) | Zftrans |
FLOG2 | log2 | rd = log(2. rs1) | Zftrans |
-FEXPM1 | exponential minus 1 | rd = pow(e, rs1) - 1.0 | Zftrans |
-FLOG1P | log plus 1 | rd = log(e, 1 + rs1) | Zftrans |
+FEXPM1 | exponential minus 1 | rd = pow(e, rs1) - 1.0 | ZftransExt |
+FLOG1P | log plus 1 | rd = log(e, 1 + rs1) | ZftransExt |
FEXP | exponential | rd = pow(e, rs1) | ZftransExt |
FLOG | natural log (base e) | rd = log(e, rs1) | ZftransExt |
FEXP10 | power-of-10 | rd = pow(10, rs1) | ZftransExt |
FLOG10 | log base 10 | rd = log(10, rs1) | ZftransExt |
"""]]
-# List of 1-arg trigonometric opcodes
+## List of 1-arg trigonometric opcodes
[[!table data="""
opcode | Description | pseudo-code | Extension |
FTAN | tan (radians) | rd = tan(rs1) | Ztrignpi |
FASIN | arcsin (radians) | rd = asin(rs1) | Zarctrignpi |
FACOS | arccos (radians) | rd = acos(rs1) | Zarctrignpi |
-FATAN (1) | arctan (radians) | rd = atan(rs1) | Zarctrignpi |
+FATAN | arctan (radians) | rd = atan(rs1) | Zarctrignpi |
FSINPI | sin times pi | rd = sin(pi * rs1) | Ztrigpi |
FCOSPI | cos times pi | rd = cos(pi * rs1) | Ztrigpi |
FTANPI | tan times pi | rd = tan(pi * rs1) | Ztrigpi |
FASINPI | arcsin / pi | rd = asin(rs1) / pi | Zarctrigpi |
FACOSPI | arccos / pi | rd = acos(rs1) / pi | Zarctrigpi |
-FATANPI (1) | arctan / pi | rd = atan(rs1) / pi | Zarctrigpi |
+FATANPI | arctan / pi | rd = atan(rs1) / pi | Zarctrigpi |
FSINH | hyperbolic sin (radians) | rd = sinh(rs1) | Zfhyp |
FCOSH | hyperbolic cos (radians) | rd = cosh(rs1) | Zfhyp |
FTANH | hyperbolic tan (radians) | rd = tanh(rs1) | Zfhyp |
FATANH | inverse hyperbolic tan | rd = atanh(rs1) | Zfhyp |
"""]]
-Note (1): FATAN/FATANPI is a pseudo-op expanding to FATAN2/FATAN2PI (needs deciding)
+# Subsets
+
+The full set is based on the Khronos OpenCL opcodes. If implemented
+entirely it would be too much for both Embedded and also 3D.
+
+The subsets are organised by hardware complexity, need (3D, HPC), however
+due to synthesis producing inaccurate results at the range limits,
+the less common subsets are still required for IEEE754 HPC.
+
+MALI Midgard, an embedded / mobile 3D GPU, for example only has the
+following opcodes:
+
+ E8 - fatan_pt2
+ F0 - frcp (reciprocal)
+ F2 - frsqrt (inverse square root, 1/sqrt(x))
+ F3 - fsqrt (square root)
+ F4 - fexp2 (2^x)
+ F5 - flog2
+ F6 - fsin1pi
+ F7 - fcos1pi
+ F9 - fatan_pt1
+
+These in FP32 and FP16 only: no FP32 hardware, at all.
+
+Vivante Embedded/Mobile 3D (etnaviv <https://github.com/laanwj/etna_viv/blob/master/rnndb/isa.xml>) only has the following:
+
+ sin, cos2pi
+ cos, sin2pi
+ log2, exp
+ sqrt and rsqrt
+ recip.
+
+It also has fast variants of some of these, as a CSR Mode.
+
+AMD's R600 GPU (R600\_Instruction\_Set\_Architecture.pdf) and the
+RDNA ISA (RDNA\_Shader\_ISA\_5August2019.pdf, Table 22, Section 6.3) have:
+
+ COS2PI (appx)
+ EXP2
+ LOG (IEEE754)
+ RECIP
+ RSQRT
+ SQRT
+ SIN2PI (appx)
+
+AMD RDNA has F16 and F32 variants of all the above, and also has F64
+variants of SQRT, RSQRT and RECIP. It is interesting that even the
+modern high-end AMD GPU does not have TAN or ATAN, where MALI Midgard
+does.
+
+Also a general point, that customised optimised hardware targetting
+FP32 3D with less accuracy simply can neither be used for IEEE754 nor
+for FP64 (except as a starting point for hardware or software driven
+Newton Raphson or other iterative method).
+
+Also in cost/area sensitive applications even the extra ROM lookup tables
+for certain algorithms may be too costly.
+
+These wildly differing and incompatible driving factors lead to the
+subset subdivisions, below.
+
+## Transcendental Subsets
+
+### Zftrans
+
+LOG2 EXP2 RECIP RSQRT
+
+Zftrans contains the minimum standard transcendentals best suited to
+3D. They are also the minimum subset for synthesising log10, exp10,
+exp1m, log1p, the hyperbolic trigonometric functions sinh and so on.
+
+They are therefore considered "base" (essential) transcendentals.
+
+### ZftransExt
+
+LOG, EXP, EXP10, LOG10, LOGP1, EXP1M
+
+These are extra transcendental functions that are useful, not generally
+needed for 3D, however for Numerical Computation they may be useful.
+
+Although they can be synthesised using Ztrans (LOG2 multiplied
+by a constant), there is both a performance penalty as well as an
+accuracy penalty towards the limits, which for IEEE754 compliance is
+unacceptable. In particular, LOG(1+rs1) in hardware may give much better
+accuracy at the lower end (very small rs1) than LOG(rs1).
+
+Their forced inclusion would be inappropriate as it would penalise
+embedded systems with tight power and area budgets. However if they
+were completely excluded the HPC applications would be penalised on
+performance and accuracy.
+
+Therefore they are their own subset extension.
+
+### Zfhyp
+
+SINH, COSH, TANH, ASINH, ACOSH, ATANH
+
+These are the hyperbolic/inverse-hyperbolic functions. Their use in 3D is limited.
+
+They can all be synthesised using LOG, SQRT and so on, so depend
+on Zftrans. However, once again, at the limits of the range, IEEE754
+compliance becomes impossible, and thus a hardware implementation may
+be required.
+
+HPC and high-end GPUs are likely markets for these.
+
+### ZftransAdv
+
+CBRT, POW, POWN, POWR, ROOTN
+
+These are simply much more complex to implement in hardware, and typically
+will only be put into HPC applications.
+
+* **Zfrsqrt**: Reciprocal square-root.
+
+## Trigonometric subsets
+
+### Ztrigpi vs Ztrignpi
+
+* **Ztrigpi**: SINPI COSPI TANPI
+* **Ztrignpi**: SIN COS TAN
+
+Ztrignpi are the basic trigonometric functions through which all others
+could be synthesised, and they are typically the base trigonometrics
+provided by GPUs for 3D, warranting their own subset.
+
+In the case of the Ztrigpi subset, these are commonly used in for loops
+with a power of two number of subdivisions, and the cost of multiplying
+by PI inside each loop (or cumulative addition, resulting in cumulative
+errors) is not acceptable.
+
+In for example CORDIC the multiplication by PI may be moved outside of
+the hardware algorithm as a loop invariant, with no power or area penalty.
+
+Again, therefore, if SINPI (etc.) were excluded, programmers would be penalised by being forced to divide by PI in some circumstances. Likewise if SIN were excluded, programmers would be penaslised by being forced to *multiply* by PI in some circumstances.
+
+Thus again, a slightly different application of the same general argument applies to give Ztrignpi and
+Ztrigpi as subsets. 3D GPUs will almost certainly provide both.
+
+### Zarctrigpi and Zarctrignpi
+
+* **Zarctrigpi**: ATAN2PI ASINPI ACOSPI
+* **Zarctrignpi**: ATAN2 ACOS ASIN
+
+These are extra trigonometric functions that are useful in some
+applications, but even for 3D GPUs, particularly embedded and mobile class
+GPUs, they are not so common and so are typically synthesised, there.
+
+Although they can be synthesised using Ztrigpi and Ztrignpi, there is,
+once again, both a performance penalty as well as an accuracy penalty
+towards the limits, which for IEEE754 compliance is unacceptable, yet
+is acceptable for 3D.
+
+Therefore they are their own subset extensions.
# Synthesis, Pseudo-code ops and macro-ops
ASINH( x ) = ln( x + SQRT(x**2+1))
-# Reciprocal
+# Evaluation and commentary
+
+This section will move later to discussion.
+
+## Reciprocal
+
+Used to be an alias. Some implementors may wish to implement divide as
+y times recip(x).
+
+Others may have shared hardware for recip and divide, others may not.
-Used to be an alias. Some imolementors may wish to implement divide as y times recip(x)
+To avoid penalising one implementor over another, recip stays.
-# To evaluate: should LOG be replaced with LOG1P (and EXP with EXPM1)?
+## To evaluate: should LOG be replaced with LOG1P (and EXP with EXPM1)?
RISC principle says "exclude LOG because it's covered by LOGP1 plus an ADD".
Research needed to ensure that implementors are not compromised by such
> ok, they stay in as real opcodes, then.
-# ATAN / ATAN2 commentary
+## ATAN / ATAN2 commentary
Discussion starts here:
<http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-August/002470.html>
(that is the hypothesis, to be evaluated for correctness. feedback requested).
-Thie because we cannot compromise or prioritise one platfrom's speed/accuracy over another. That is not reasonable or desirable, to penalise one implementor over another.
+This because we cannot compromise or prioritise one platfrom's
+speed/accuracy over another. That is not reasonable or desirable, to
+penalise one implementor over another.
-Thus, all implementors, to keep interoperability, must both have both opcodes and may choose, at the architectural and routing level, which one to implement in terms of the other.
+Thus, all implementors, to keep interoperability, must both have both
+opcodes and may choose, at the architectural and routing level, which
+one to implement in terms of the other.
-Allowing implementors to choose to add either opcode and let traps sort it out leaves an uncertainty in the software developer's mind: they cannot trust the hardware, available from many vendors, to be performant right across the board.
+Allowing implementors to choose to add either opcode and let traps sort it
+out leaves an uncertainty in the software developer's mind: they cannot
+trust the hardware, available from many vendors, to be performant right
+across the board.
Standards are a pig.
projects / libreriscv.git / blobdiff