On 02/08/18 10:32, Chris Johns wrote:
On 02/08/2018 17:47, Sebastian Huber wrote:
On 01/08/18 12:06, Hesham Almatary wrote:
On Wed, Aug 1, 2018 at 10:18 AM, Sebastian Huber<s...@rtems.org> wrote:
Module: rtems
Branch: master
Commit: 529154bad207a42a6d0f03343c7e215eab97ced5
Changeset:
http://git.rtems.org/rtems/commit/?id=529154bad207a42a6d0f03343c7e215eab97ced5
Author: Sebastian Huber<sebastian.hu...@embedded-brains.de>
Date: Tue Jul 31 09:15:00 2018 +0200
bsp/riscv: Initialize FPU depending on ISA
Initialize fcsr to zero for a defined rounding mode.
Update #3433.
---
bsps/riscv/riscv/start/start.S | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/bsps/riscv/riscv/start/start.S b/bsps/riscv/riscv/start/start.S
index 290c95a..feb07fe 100644
--- a/bsps/riscv/riscv/start/start.S
+++ b/bsps/riscv/riscv/start/start.S
@@ -48,9 +48,12 @@ SYM(_start):
LADDR gp, __global_pointer$
.option pop
- /* Init FPU unit if it's there */
+ /* Init FPU */
+#ifdef __riscv_flen
li t0, MSTATUS_FS
csrs mstatus, t0
+ csrw fcsr, zero
+#endif
Do you think it makes sense to check the MISA register for checking
the existence of an FPU unit or not?
I considered adding run-time tests here. I decided to not do it since we should
offer a good multilib for a particular chip. It is the duty of the user to
select the right multilib for its chip.
This seems reasonable.
Will the user get a kind landing if they select the wrong library, ie no support
in the hardware or supported in hardware but using the wrong library? I remember
the horrible error with the FPU on the m68k, it was often incorrect linker
flags.
The RISC-V BSP name is the ISA name currently. If you select the wrong
BSP, you get an exception (e.g. use of FPU, but no FPU present on the
chip) or software FP performance instead of hardware FP performance.
--
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
