+## List of 1-arg trigonometric opcodes
+
+[[!table data="""
+opcode | Description | pseudo-code | Extension |
+FSIN | sin (radians) | rd = sin(rs1) | Ztrignpi |
+FCOS | cos (radians) | rd = cos(rs1) | Ztrignpi |
+FTAN | tan (radians) | rd = tan(rs1) | Ztrignpi |
+FASIN | arcsin (radians) | rd = asin(rs1) | Zarctrignpi |
+FACOS | arccos (radians) | rd = acos(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 | 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 |
+FASINH | inverse hyperbolic sin | rd = asinh(rs1) | Zfhyp |
+FACOSH | inverse hyperbolic cos | rd = acosh(rs1) | Zfhyp |
+FATANH | inverse hyperbolic tan | rd = atanh(rs1) | Zfhyp |
+"""]]
+
+# 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
+
+The pseudo-ops are best left up to the compiler rather than being actual
+pseudo-ops, by allocating one scalar FP register for use as a constant
+(loop invariant) set to "1.0" at the beginning of a function or other
+suitable code block.
+
+* FSINCOS - fused macro-op between FSIN and FCOS (issued in that order).
+* FSINCOSPI - fused macro-op between FSINPI and FCOSPI (issued in that order).
+
+FATANPI example pseudo-code:
+
+ lui t0, 0x3F800 // upper bits of f32 1.0
+ fmv.x.s ft0, t0
+ fatan2pi.s rd, rs1, ft0
+
+Hyperbolic function example (obviates need for Zfhyp except for
+high-performance or correctly-rounding):
+
+ ASINH( x ) = ln( x + SQRT(x**2+1))
+
+# 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.
+
+To avoid penalising one implementor over another, recip stays.
+
+## 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
+a decision
+<http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-August/002358.html>
+
+> > correctly-rounded LOG will return different results than LOGP1 and ADD.
+> > Likewise for EXP and EXPM1
+
+> ok, they stay in as real opcodes, then.
+
+## ATAN / ATAN2 commentary
+
+Discussion starts here:
+<http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-August/002470.html>
+
+from Mitch Alsup:
+
+would like to point out that the general implementations of ATAN2 do a
+bunch of special case checks and then simply call ATAN.
+
+ double ATAN2( double y, double x )
+ { // IEEE 754-2008 quality ATAN2
+
+ // deal with NANs
+ if( ISNAN( x ) ) return x;
+ if( ISNAN( y ) ) return y;
+
+ // deal with infinities
+ if( x == +∞ && |y|== +∞ ) return copysign( π/4, y );
+ if( x == +∞ ) return copysign( 0.0, y );
+ if( x == -∞ && |y|== +∞ ) return copysign( 3π/4, y );
+ if( x == -∞ ) return copysign( π, y );
+ if( |y|== +∞ ) return copysign( π/2, y );
+
+ // deal with signed zeros
+ if( x == 0.0 && y != 0.0 ) return copysign( π/2, y );
+ if( x >=+0.0 && y == 0.0 ) return copysign( 0.0, y );
+ if( x <=-0.0 && y == 0.0 ) return copysign( π, y );
+
+ // calculate ATAN2 textbook style
+ if( x > 0.0 ) return ATAN( |y / x| );
+ if( x < 0.0 ) return π - ATAN( |y / x| );
+ }
+
+
+Yet the proposed encoding makes ATAN2 the primitive and has ATAN invent
+a constant and then call/use ATAN2.
+
+When one considers an implementation of ATAN, one must consider several
+ranges of evaluation::
+
+ x [ -∞, -1.0]:: ATAN( x ) = -π/2 + ATAN( 1/x );
+ x (-1.0, +1.0]:: ATAN( x ) = + ATAN( x );
+ x [ 1.0, +∞]:: ATAN( x ) = +π/2 - ATAN( 1/x );
+
+I should point out that the add/sub of π/2 can not lose significance
+since the result of ATAN(1/x) is bounded 0..π/2
+
+The bottom line is that I think you are choosing to make too many of
+these into OpCodes, making the hardware function/calculation unit (and
+sequencer) more complicated that necessary.
+
+--------------------------------------------------------
+
+We therefore I think have a case for bringing back ATAN and including ATAN2.
+
+The reason is that whilst a microcode-like GPU-centric platform would do ATAN2 in terms of ATAN, a UNIX-centric platform would do it the other way round.
+
+(that is the hypothesis, to be evaluated for correctness. feedback requested).
+
+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.
+
+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.
+
+---
+
+I might suggest that if there were a way for a calculation to be performed
+and the result of that calculation chained to a subsequent calculation
+such that the precision of the result-becomes-operand is wider than
+what will fit in a register, then you can dramatically reduce the count
+of instructions in this category while retaining
+
+acceptable accuracy:
+
+ z = x / y
+
+can be calculated as::
+
+ z = x * (1/y)
+
+Where 1/y has about 26-to-32 bits of fraction. No, it's not IEEE 754-2008
+accurate, but GPUs want speed and
+
+1/y is fully pipelined (F32) while x/y cannot be (at reasonable area). It
+is also not "that inaccurate" displaying 0.625-to-0.52 ULP.
+
+Given that one has the ability to carry (and process) more fraction bits,
+one can then do high precision multiplies of π or other transcendental
+radixes.
+
+And GPUs have been doing this almost since the dawn of 3D.