162306a36Sopenharmony_ciTODO LIST
262306a36Sopenharmony_ci=========
362306a36Sopenharmony_ci
462306a36Sopenharmony_ci::
562306a36Sopenharmony_ci
662306a36Sopenharmony_ci  POW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - power
762306a36Sopenharmony_ci  RPW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - reverse power
862306a36Sopenharmony_ci  POL{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - polar angle (arctan2)
962306a36Sopenharmony_ci
1062306a36Sopenharmony_ci  LOG{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base 10
1162306a36Sopenharmony_ci  LGN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base e
1262306a36Sopenharmony_ci  EXP{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - exponent
1362306a36Sopenharmony_ci  SIN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - sine
1462306a36Sopenharmony_ci  COS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - cosine
1562306a36Sopenharmony_ci  TAN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - tangent
1662306a36Sopenharmony_ci  ASN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arcsine
1762306a36Sopenharmony_ci  ACS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arccosine
1862306a36Sopenharmony_ci  ATN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arctangent
1962306a36Sopenharmony_ci
2062306a36Sopenharmony_ciThese are not implemented.  They are not currently issued by the compiler,
2162306a36Sopenharmony_ciand are handled by routines in libc.  These are not implemented by the FPA11
2262306a36Sopenharmony_cihardware, but are handled by the floating point support code.  They should
2362306a36Sopenharmony_cibe implemented in future versions.
2462306a36Sopenharmony_ci
2562306a36Sopenharmony_ciThere are a couple of ways to approach the implementation of these.  One
2662306a36Sopenharmony_cimethod would be to use accurate table methods for these routines.  I have
2762306a36Sopenharmony_cia couple of papers by S. Gal from IBM's research labs in Haifa, Israel that
2862306a36Sopenharmony_ciseem to promise extreme accuracy (in the order of 99.8%) and reasonable speed.
2962306a36Sopenharmony_ciThese methods are used in GLIBC for some of the transcendental functions.
3062306a36Sopenharmony_ci
3162306a36Sopenharmony_ciAnother approach, which I know little about is CORDIC.  This stands for
3262306a36Sopenharmony_ciCoordinate Rotation Digital Computer, and is a method of computing
3362306a36Sopenharmony_citranscendental functions using mostly shifts and adds and a few
3462306a36Sopenharmony_cimultiplications and divisions.  The ARM excels at shifts and adds,
3562306a36Sopenharmony_ciso such a method could be promising, but requires more research to
3662306a36Sopenharmony_cidetermine if it is feasible.
3762306a36Sopenharmony_ci
3862306a36Sopenharmony_ciRounding Methods
3962306a36Sopenharmony_ci----------------
4062306a36Sopenharmony_ci
4162306a36Sopenharmony_ciThe IEEE standard defines 4 rounding modes.  Round to nearest is the
4262306a36Sopenharmony_cidefault, but rounding to + or - infinity or round to zero are also allowed.
4362306a36Sopenharmony_ciMany architectures allow the rounding mode to be specified by modifying bits
4462306a36Sopenharmony_ciin a control register.  Not so with the ARM FPA11 architecture.  To change
4562306a36Sopenharmony_cithe rounding mode one must specify it with each instruction.
4662306a36Sopenharmony_ci
4762306a36Sopenharmony_ciThis has made porting some benchmarks difficult.  It is possible to
4862306a36Sopenharmony_ciintroduce such a capability into the emulator.  The FPCR contains
4962306a36Sopenharmony_cibits describing the rounding mode.  The emulator could be altered to
5062306a36Sopenharmony_ciexamine a flag, which if set forced it to ignore the rounding mode in
5162306a36Sopenharmony_cithe instruction, and use the mode specified in the bits in the FPCR.
5262306a36Sopenharmony_ci
5362306a36Sopenharmony_ciThis would require a method of getting/setting the flag, and the bits
5462306a36Sopenharmony_ciin the FPCR.  This requires a kernel call in ArmLinux, as WFC/RFC are
5562306a36Sopenharmony_cisupervisor only instructions.  If anyone has any ideas or comments I
5662306a36Sopenharmony_ciwould like to hear them.
5762306a36Sopenharmony_ci
5862306a36Sopenharmony_ciNOTE:
5962306a36Sopenharmony_ci pulled out from some docs on ARM floating point, specifically
6062306a36Sopenharmony_ci for the Acorn FPE, but not limited to it:
6162306a36Sopenharmony_ci
6262306a36Sopenharmony_ci The floating point control register (FPCR) may only be present in some
6362306a36Sopenharmony_ci implementations: it is there to control the hardware in an implementation-
6462306a36Sopenharmony_ci specific manner, for example to disable the floating point system.  The user
6562306a36Sopenharmony_ci mode of the ARM is not permitted to use this register (since the right is
6662306a36Sopenharmony_ci reserved to alter it between implementations) and the WFC and RFC
6762306a36Sopenharmony_ci instructions will trap if tried in user mode.
6862306a36Sopenharmony_ci
6962306a36Sopenharmony_ci Hence, the answer is yes, you could do this, but then you will run a high
7062306a36Sopenharmony_ci risk of becoming isolated if and when hardware FP emulation comes out
7162306a36Sopenharmony_ci
7262306a36Sopenharmony_ci		-- Russell.
73