On 19/07/17 22:35, Jiri Gaisler wrote:
On 07/19/2017 07:36 PM, Sebastian Huber wrote:
----- Jiri Gaisler <j...@gaisler.se> schrieb:
On 07/19/2017 04:04 PM, Sebastian Huber wrote:
Hello Jiri,
I fixed a couple of tests. One remaining failure on the leon2 is mathf:
*** BEGIN OF TEST MATHF ***
acosf : 1.570796
acoshf : -nan
asinf : 1.570796
asinhf : 0.881374
atanf : 0.665774
atan2f : 0.785398
atanhf : inf
cbrtf : 3.000000
ceilf : 4.000000
copysignf : -3.500000
cosf : -0.000000
coshf : 2.509179
erff : 1.000000
erfcf : 0.000000
expf : 1.521962
exp2f : 1.337928
expm1f : 0.000420
fabsf : 1.123000
fdimf : 0.000000
floorf : 0.000000
floorf : -1.000000
Breakpoint 1, 0x40004044 in fmaf (x=x@entry=2.0999999, y=2.20000005,
z=3.00999999) at
/home/EB/sebastian_h/archive/gcc-git/newlib/libm/common/sf_fma.c:25
25 return (float) (((double) x * (double) y) + (double) z);
(gdb) disas 0x40004044
Dump of assembler code for function fmaf:
0x40004024 <+0>: add %sp, -80, %sp
0x40004028 <+4>: st %o1, [ %sp + 0x4c ]
0x4000402c <+8>: ld [ %sp + 0x4c ], %f8
0x40004030 <+12>: st %o0, [ %sp + 0x4c ]
0x40004034 <+16>: ld [ %sp + 0x4c ], %f9
0x40004038 <+20>: st %o2, [ %sp + 0x4c ]
0x4000403c <+24>: fsmuld %f8, %f9, %f0
0x40004040 <+28>: ld [ %sp + 0x4c ], %f8
=> 0x40004044 <+32>: fstod %f8, %f8
0x40004048 <+36>: add %sp, 0x50, %sp
0x4000404c <+40>: faddd %f0, %f8, %f0
0x40004050 <+44>: retl
0x40004054 <+48>: fdtos %f0, %f0
End of assembler dump.
(gdb) p/x $fsr
$1 = 0xe660
Is fstod implemented on the SIS?
fstod is implemented.
The instruction that takes the trap is at 0x40004040, which is ld [ %sp
+ 0x4c ], %f8. Remember that SPARC has deferred FPU trap model so it is
actually the previous FPU instruction FSMULD at 0x4000403c that
generated the trap. This instruction is not implemented in sis, and I am
not sure it is even implemented in some leon2/leon3 hardware. I will
check and report back ...
Jiri.
I use -mcpu=leon -mfix-at697f and according to the manual we have:
The AT697F floating-point unit is based on the MEIKO core and implements the
SPARC floating-point instruction-set defined in the SPARC Architecture Manual
version 8.
I am certain that AT697E did not implement FSMULD, whether AT697F does
it I do not know but I doubt it. On the other hand, most (all?) leon3
with an FPU does support FSMULD. Maybe somebody with an AT697F board
could run the MATHF test and report if it runs or traps. I will add
fsmuld support to sis, but we should really try to find out if it is
appropriate for leon2.
Jiri.
Yes, we probably have to test this on real hardware, since according to
the SPARC v8 manual we have:
"Appendix G — SPARC ABI Software Considerations
FsMULd instruction
The floating-point
multiply single-to-double instruction (FsMULd) is new in Version 8 of
the SPARC
architecture. Some SPARC systems in the field emulate this instruction in
software.
Recommended use of FsMULd instruction in SPARC ABI programs:
* If FsMULd is used infrequently (on a dynamic basis):
Use the FsMULd instruction in-line.
* If FsMULd is used heavily (on a dynamic basis), and reasonable perfor-
mance across all systems is preferred over optimal performance on the
fastest
systems: Convert the operands to double precision in scratch
registers, then
calculate the result with the FMULd instruction. For example,
fsmuld %f20,%f21,%f8
might be replaced by:
fstod %f20,%f0
fstod %f23,%f2
fmuld %f0,%f2,%f8
This provides reasonable performance on machines with hardware
support for
FsMULd, while not penalizing those without it with the overhead of
trap- ping
and emulating the instructions in supervisor software.
* If FsMULd is used heavily (on a dynamic basis), and optimal performance
on systems which implement FsMULd in hardware is desired at the cost of
performance degradation on most systems: Use the FsMULd instruction
in-line."
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
