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