mirror of https://github.com/Qortal/Brooklyn
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
72 lines
3.3 KiB
72 lines
3.3 KiB
TODO LIST |
|
========= |
|
|
|
:: |
|
|
|
POW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - power |
|
RPW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - reverse power |
|
POL{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - polar angle (arctan2) |
|
|
|
LOG{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base 10 |
|
LGN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base e |
|
EXP{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - exponent |
|
SIN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - sine |
|
COS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - cosine |
|
TAN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - tangent |
|
ASN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arcsine |
|
ACS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arccosine |
|
ATN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arctangent |
|
|
|
These are not implemented. They are not currently issued by the compiler, |
|
and are handled by routines in libc. These are not implemented by the FPA11 |
|
hardware, but are handled by the floating point support code. They should |
|
be implemented in future versions. |
|
|
|
There are a couple of ways to approach the implementation of these. One |
|
method would be to use accurate table methods for these routines. I have |
|
a couple of papers by S. Gal from IBM's research labs in Haifa, Israel that |
|
seem to promise extreme accuracy (in the order of 99.8%) and reasonable speed. |
|
These methods are used in GLIBC for some of the transcendental functions. |
|
|
|
Another approach, which I know little about is CORDIC. This stands for |
|
Coordinate Rotation Digital Computer, and is a method of computing |
|
transcendental functions using mostly shifts and adds and a few |
|
multiplications and divisions. The ARM excels at shifts and adds, |
|
so such a method could be promising, but requires more research to |
|
determine if it is feasible. |
|
|
|
Rounding Methods |
|
---------------- |
|
|
|
The IEEE standard defines 4 rounding modes. Round to nearest is the |
|
default, but rounding to + or - infinity or round to zero are also allowed. |
|
Many architectures allow the rounding mode to be specified by modifying bits |
|
in a control register. Not so with the ARM FPA11 architecture. To change |
|
the rounding mode one must specify it with each instruction. |
|
|
|
This has made porting some benchmarks difficult. It is possible to |
|
introduce such a capability into the emulator. The FPCR contains |
|
bits describing the rounding mode. The emulator could be altered to |
|
examine a flag, which if set forced it to ignore the rounding mode in |
|
the instruction, and use the mode specified in the bits in the FPCR. |
|
|
|
This would require a method of getting/setting the flag, and the bits |
|
in the FPCR. This requires a kernel call in ArmLinux, as WFC/RFC are |
|
supervisor only instructions. If anyone has any ideas or comments I |
|
would like to hear them. |
|
|
|
NOTE: |
|
pulled out from some docs on ARM floating point, specifically |
|
for the Acorn FPE, but not limited to it: |
|
|
|
The floating point control register (FPCR) may only be present in some |
|
implementations: it is there to control the hardware in an implementation- |
|
specific manner, for example to disable the floating point system. The user |
|
mode of the ARM is not permitted to use this register (since the right is |
|
reserved to alter it between implementations) and the WFC and RFC |
|
instructions will trap if tried in user mode. |
|
|
|
Hence, the answer is yes, you could do this, but then you will run a high |
|
risk of becoming isolated if and when hardware FP emulation comes out |
|
|
|
-- Russell.
|
|
|