Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame^] | 1 | TODO LIST |
| 2 | --------- |
| 3 | |
| 4 | POW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - power |
| 5 | RPW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - reverse power |
| 6 | POL{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - polar angle (arctan2) |
| 7 | |
| 8 | LOG{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base 10 |
| 9 | LGN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base e |
| 10 | EXP{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - exponent |
| 11 | SIN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - sine |
| 12 | COS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - cosine |
| 13 | TAN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - tangent |
| 14 | ASN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arcsine |
| 15 | ACS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arccosine |
| 16 | ATN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arctangent |
| 17 | |
| 18 | These are not implemented. They are not currently issued by the compiler, |
| 19 | and are handled by routines in libc. These are not implemented by the FPA11 |
| 20 | hardware, but are handled by the floating point support code. They should |
| 21 | be implemented in future versions. |
| 22 | |
| 23 | There are a couple of ways to approach the implementation of these. One |
| 24 | method would be to use accurate table methods for these routines. I have |
| 25 | a couple of papers by S. Gal from IBM's research labs in Haifa, Israel that |
| 26 | seem to promise extreme accuracy (in the order of 99.8%) and reasonable speed. |
| 27 | These methods are used in GLIBC for some of the transcendental functions. |
| 28 | |
| 29 | Another approach, which I know little about is CORDIC. This stands for |
| 30 | Coordinate Rotation Digital Computer, and is a method of computing |
| 31 | transcendental functions using mostly shifts and adds and a few |
| 32 | multiplications and divisions. The ARM excels at shifts and adds, |
| 33 | so such a method could be promising, but requires more research to |
| 34 | determine if it is feasible. |
| 35 | |
| 36 | Rounding Methods |
| 37 | |
| 38 | The IEEE standard defines 4 rounding modes. Round to nearest is the |
| 39 | default, but rounding to + or - infinity or round to zero are also allowed. |
| 40 | Many architectures allow the rounding mode to be specified by modifying bits |
| 41 | in a control register. Not so with the ARM FPA11 architecture. To change |
| 42 | the rounding mode one must specify it with each instruction. |
| 43 | |
| 44 | This has made porting some benchmarks difficult. It is possible to |
| 45 | introduce such a capability into the emulator. The FPCR contains |
| 46 | bits describing the rounding mode. The emulator could be altered to |
| 47 | examine a flag, which if set forced it to ignore the rounding mode in |
| 48 | the instruction, and use the mode specified in the bits in the FPCR. |
| 49 | |
| 50 | This would require a method of getting/setting the flag, and the bits |
| 51 | in the FPCR. This requires a kernel call in ArmLinux, as WFC/RFC are |
| 52 | supervisor only instructions. If anyone has any ideas or comments I |
| 53 | would like to hear them. |
| 54 | |
| 55 | [NOTE: pulled out from some docs on ARM floating point, specifically |
| 56 | for the Acorn FPE, but not limited to it: |
| 57 | |
| 58 | The floating point control register (FPCR) may only be present in some |
| 59 | implementations: it is there to control the hardware in an implementation- |
| 60 | specific manner, for example to disable the floating point system. The user |
| 61 | mode of the ARM is not permitted to use this register (since the right is |
| 62 | reserved to alter it between implementations) and the WFC and RFC |
| 63 | instructions will trap if tried in user mode. |
| 64 | |
| 65 | Hence, the answer is yes, you could do this, but then you will run a high |
| 66 | risk of becoming isolated if and when hardware FP emulation comes out |
| 67 | -- Russell]. |