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