From 171b08b4b90e9ce7780e383a4eaee95cefcfc127 Mon Sep 17 00:00:00 2001 From: scw Date: Sat, 28 Sep 2002 11:11:01 +0000 Subject: [PATCH] Set the new process' FPSCR.DN bit so that denormalised FP numbers are quietly flushed to zero before they're used. While this isn't perfect, it seems to mimic the behaviour on i386 at least. --- sys/arch/sh5/sh5/process_machdep.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/sys/arch/sh5/sh5/process_machdep.c b/sys/arch/sh5/sh5/process_machdep.c index ba396e70b8f7..2d688ed0d5bc 100644 --- a/sys/arch/sh5/sh5/process_machdep.c +++ b/sys/arch/sh5/sh5/process_machdep.c @@ -1,4 +1,4 @@ -/* $NetBSD: process_machdep.c,v 1.4 2002/09/06 15:39:16 scw Exp $ */ +/* $NetBSD: process_machdep.c,v 1.5 2002/09/28 11:11:01 scw Exp $ */ /* * Copyright 2002 Wasabi Systems, Inc. @@ -90,6 +90,23 @@ setregs(struct proc *p, struct exec_package *pack, u_long stack) /* Give the new process a clean set of FP regs */ memset(&p->p_addr->u_pcb.pcb_ctx.sf_fpregs, 0, sizeof(struct fpregs)); + + /* + * I debated with myself about the following for a wee while. + * + * Disable FPU Exceptions for arithmetic operations on de-normalised + * numbers. While this is contrary to the IEEE-754, it's how things + * work in NetBSD/i386. + * + * Since most applications are likely to have been developed on i386 + * platforms, most application programmers would never see this + * fault in their code. The in-tree top(1) program is one such + * offender, under certain circumstances. + * + * With FPSCR.DN set, denormalised numbers are quietly flushed to zero. + */ + p->p_addr->u_pcb.pcb_ctx.sf_fpregs.fpscr = 0x20000; + sh5_fprestore(SH5_CONREG_USR_FPRS_MASK << SH5_CONREG_USR_FPRS_SHIFT, &p->p_addr->u_pcb); }