Orange Pi5 kernel

^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  1) Notes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  2) =====
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  3) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  4) There seems to be a problem with exp(double) and our emulator.  I haven't
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  5) been able to track it down yet.  This does not occur with the emulator
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  6) supplied by Russell King.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  7) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  8) I also found one oddity in the emulator.  I don't think it is serious but
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  9) will point it out.  The ARM calling conventions require floating point
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) registers f4-f7 to be preserved over a function call.  The compiler quite
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) often uses an stfe instruction to save f4 on the stack upon entry to a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) function, and an ldfe instruction to restore it before returning.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) I was looking at some code, that calculated a double result, stored it in f4
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) then made a function call. Upon return from the function call the number in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) f4 had been converted to an extended value in the emulator.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) This is a side effect of the stfe instruction.  The double in f4 had to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) converted to extended, then stored.  If an lfm/sfm combination had been used,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) then no conversion would occur.  This has performance considerations.  The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) result from the function call and f4 were used in a multiplication.  If the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) emulator sees a multiply of a double and extended, it promotes the double to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) extended, then does the multiply in extended precision.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) This code will cause this problem:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) double x, y, z;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) z = log(x)/log(y);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) The result of log(x) (a double) will be calculated, returned in f0, then
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) moved to f4 to preserve it over the log(y) call.  The division will be done
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) in extended precision, due to the stfe instruction used to save f4 in log(y).