18c2ecf20Sopenharmony_ciNotes
28c2ecf20Sopenharmony_ci=====
38c2ecf20Sopenharmony_ci
48c2ecf20Sopenharmony_ciThere seems to be a problem with exp(double) and our emulator.  I haven't
58c2ecf20Sopenharmony_cibeen able to track it down yet.  This does not occur with the emulator
68c2ecf20Sopenharmony_cisupplied by Russell King.
78c2ecf20Sopenharmony_ci
88c2ecf20Sopenharmony_ciI also found one oddity in the emulator.  I don't think it is serious but
98c2ecf20Sopenharmony_ciwill point it out.  The ARM calling conventions require floating point
108c2ecf20Sopenharmony_ciregisters f4-f7 to be preserved over a function call.  The compiler quite
118c2ecf20Sopenharmony_cioften uses an stfe instruction to save f4 on the stack upon entry to a
128c2ecf20Sopenharmony_cifunction, and an ldfe instruction to restore it before returning.
138c2ecf20Sopenharmony_ci
148c2ecf20Sopenharmony_ciI was looking at some code, that calculated a double result, stored it in f4
158c2ecf20Sopenharmony_cithen made a function call. Upon return from the function call the number in
168c2ecf20Sopenharmony_cif4 had been converted to an extended value in the emulator.
178c2ecf20Sopenharmony_ci
188c2ecf20Sopenharmony_ciThis is a side effect of the stfe instruction.  The double in f4 had to be
198c2ecf20Sopenharmony_ciconverted to extended, then stored.  If an lfm/sfm combination had been used,
208c2ecf20Sopenharmony_cithen no conversion would occur.  This has performance considerations.  The
218c2ecf20Sopenharmony_ciresult from the function call and f4 were used in a multiplication.  If the
228c2ecf20Sopenharmony_ciemulator sees a multiply of a double and extended, it promotes the double to
238c2ecf20Sopenharmony_ciextended, then does the multiply in extended precision.
248c2ecf20Sopenharmony_ci
258c2ecf20Sopenharmony_ciThis code will cause this problem:
268c2ecf20Sopenharmony_ci
278c2ecf20Sopenharmony_cidouble x, y, z;
288c2ecf20Sopenharmony_ciz = log(x)/log(y);
298c2ecf20Sopenharmony_ci
308c2ecf20Sopenharmony_ciThe result of log(x) (a double) will be calculated, returned in f0, then
318c2ecf20Sopenharmony_cimoved to f4 to preserve it over the log(y) call.  The division will be done
328c2ecf20Sopenharmony_ciin extended precision, due to the stfe instruction used to save f4 in log(y).
33