18c2ecf20Sopenharmony_ciTODO LIST
28c2ecf20Sopenharmony_ci=========
38c2ecf20Sopenharmony_ci
48c2ecf20Sopenharmony_ci::
58c2ecf20Sopenharmony_ci
68c2ecf20Sopenharmony_ci  POW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - power
78c2ecf20Sopenharmony_ci  RPW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - reverse power
88c2ecf20Sopenharmony_ci  POL{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - polar angle (arctan2)
98c2ecf20Sopenharmony_ci
108c2ecf20Sopenharmony_ci  LOG{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base 10
118c2ecf20Sopenharmony_ci  LGN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base e
128c2ecf20Sopenharmony_ci  EXP{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - exponent
138c2ecf20Sopenharmony_ci  SIN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - sine
148c2ecf20Sopenharmony_ci  COS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - cosine
158c2ecf20Sopenharmony_ci  TAN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - tangent
168c2ecf20Sopenharmony_ci  ASN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arcsine
178c2ecf20Sopenharmony_ci  ACS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arccosine
188c2ecf20Sopenharmony_ci  ATN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arctangent
198c2ecf20Sopenharmony_ci
208c2ecf20Sopenharmony_ciThese are not implemented.  They are not currently issued by the compiler,
218c2ecf20Sopenharmony_ciand are handled by routines in libc.  These are not implemented by the FPA11
228c2ecf20Sopenharmony_cihardware, but are handled by the floating point support code.  They should
238c2ecf20Sopenharmony_cibe implemented in future versions.
248c2ecf20Sopenharmony_ci
258c2ecf20Sopenharmony_ciThere are a couple of ways to approach the implementation of these.  One
268c2ecf20Sopenharmony_cimethod would be to use accurate table methods for these routines.  I have
278c2ecf20Sopenharmony_cia couple of papers by S. Gal from IBM's research labs in Haifa, Israel that
288c2ecf20Sopenharmony_ciseem to promise extreme accuracy (in the order of 99.8%) and reasonable speed.
298c2ecf20Sopenharmony_ciThese methods are used in GLIBC for some of the transcendental functions.
308c2ecf20Sopenharmony_ci
318c2ecf20Sopenharmony_ciAnother approach, which I know little about is CORDIC.  This stands for
328c2ecf20Sopenharmony_ciCoordinate Rotation Digital Computer, and is a method of computing
338c2ecf20Sopenharmony_citranscendental functions using mostly shifts and adds and a few
348c2ecf20Sopenharmony_cimultiplications and divisions.  The ARM excels at shifts and adds,
358c2ecf20Sopenharmony_ciso such a method could be promising, but requires more research to
368c2ecf20Sopenharmony_cidetermine if it is feasible.
378c2ecf20Sopenharmony_ci
388c2ecf20Sopenharmony_ciRounding Methods
398c2ecf20Sopenharmony_ci----------------
408c2ecf20Sopenharmony_ci
418c2ecf20Sopenharmony_ciThe IEEE standard defines 4 rounding modes.  Round to nearest is the
428c2ecf20Sopenharmony_cidefault, but rounding to + or - infinity or round to zero are also allowed.
438c2ecf20Sopenharmony_ciMany architectures allow the rounding mode to be specified by modifying bits
448c2ecf20Sopenharmony_ciin a control register.  Not so with the ARM FPA11 architecture.  To change
458c2ecf20Sopenharmony_cithe rounding mode one must specify it with each instruction.
468c2ecf20Sopenharmony_ci
478c2ecf20Sopenharmony_ciThis has made porting some benchmarks difficult.  It is possible to
488c2ecf20Sopenharmony_ciintroduce such a capability into the emulator.  The FPCR contains
498c2ecf20Sopenharmony_cibits describing the rounding mode.  The emulator could be altered to
508c2ecf20Sopenharmony_ciexamine a flag, which if set forced it to ignore the rounding mode in
518c2ecf20Sopenharmony_cithe instruction, and use the mode specified in the bits in the FPCR.
528c2ecf20Sopenharmony_ci
538c2ecf20Sopenharmony_ciThis would require a method of getting/setting the flag, and the bits
548c2ecf20Sopenharmony_ciin the FPCR.  This requires a kernel call in ArmLinux, as WFC/RFC are
558c2ecf20Sopenharmony_cisupervisor only instructions.  If anyone has any ideas or comments I
568c2ecf20Sopenharmony_ciwould like to hear them.
578c2ecf20Sopenharmony_ci
588c2ecf20Sopenharmony_ciNOTE:
598c2ecf20Sopenharmony_ci pulled out from some docs on ARM floating point, specifically
608c2ecf20Sopenharmony_ci for the Acorn FPE, but not limited to it:
618c2ecf20Sopenharmony_ci
628c2ecf20Sopenharmony_ci The floating point control register (FPCR) may only be present in some
638c2ecf20Sopenharmony_ci implementations: it is there to control the hardware in an implementation-
648c2ecf20Sopenharmony_ci specific manner, for example to disable the floating point system.  The user
658c2ecf20Sopenharmony_ci mode of the ARM is not permitted to use this register (since the right is
668c2ecf20Sopenharmony_ci reserved to alter it between implementations) and the WFC and RFC
678c2ecf20Sopenharmony_ci instructions will trap if tried in user mode.
688c2ecf20Sopenharmony_ci
698c2ecf20Sopenharmony_ci Hence, the answer is yes, you could do this, but then you will run a high
708c2ecf20Sopenharmony_ci risk of becoming isolated if and when hardware FP emulation comes out
718c2ecf20Sopenharmony_ci
728c2ecf20Sopenharmony_ci		-- Russell.
73