162306a36Sopenharmony_ciNotes 262306a36Sopenharmony_ci===== 362306a36Sopenharmony_ci 462306a36Sopenharmony_ciThere seems to be a problem with exp(double) and our emulator. I haven't 562306a36Sopenharmony_cibeen able to track it down yet. This does not occur with the emulator 662306a36Sopenharmony_cisupplied by Russell King. 762306a36Sopenharmony_ci 862306a36Sopenharmony_ciI also found one oddity in the emulator. I don't think it is serious but 962306a36Sopenharmony_ciwill point it out. The ARM calling conventions require floating point 1062306a36Sopenharmony_ciregisters f4-f7 to be preserved over a function call. The compiler quite 1162306a36Sopenharmony_cioften uses an stfe instruction to save f4 on the stack upon entry to a 1262306a36Sopenharmony_cifunction, and an ldfe instruction to restore it before returning. 1362306a36Sopenharmony_ci 1462306a36Sopenharmony_ciI was looking at some code, that calculated a double result, stored it in f4 1562306a36Sopenharmony_cithen made a function call. Upon return from the function call the number in 1662306a36Sopenharmony_cif4 had been converted to an extended value in the emulator. 1762306a36Sopenharmony_ci 1862306a36Sopenharmony_ciThis is a side effect of the stfe instruction. The double in f4 had to be 1962306a36Sopenharmony_ciconverted to extended, then stored. If an lfm/sfm combination had been used, 2062306a36Sopenharmony_cithen no conversion would occur. This has performance considerations. The 2162306a36Sopenharmony_ciresult from the function call and f4 were used in a multiplication. If the 2262306a36Sopenharmony_ciemulator sees a multiply of a double and extended, it promotes the double to 2362306a36Sopenharmony_ciextended, then does the multiply in extended precision. 2462306a36Sopenharmony_ci 2562306a36Sopenharmony_ciThis code will cause this problem: 2662306a36Sopenharmony_ci 2762306a36Sopenharmony_cidouble x, y, z; 2862306a36Sopenharmony_ciz = log(x)/log(y); 2962306a36Sopenharmony_ci 3062306a36Sopenharmony_ciThe result of log(x) (a double) will be calculated, returned in f0, then 3162306a36Sopenharmony_cimoved to f4 to preserve it over the log(y) call. The division will be done 3262306a36Sopenharmony_ciin extended precision, due to the stfe instruction used to save f4 in log(y). 33