Commit | Line | Data |
---|---|---|
1da177e4 LT |
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]. |