Date: Fri, 25 Jan 2008 10:22:32 -0800 From: Peter Grehan <grehan@freebsd.org> To: Rafal Jaworowski <raj@semihalf.com> Cc: yanegomi@gmail.com, perforce@FreeBSD.org, marcel@FreeBSD.org, "M. Warner Losh" <imp@bsdimp.com> Subject: Re: PERFORCE change 133911 for review Message-ID: <479A28E8.1060509@freebsd.org> In-Reply-To: <479A26CE.6020104@semihalf.com> References: <200801230414.m0N4E4ng009323@repoman.freebsd.org> <4797C8E0.4070100@freebsd.org> <4798C436.6090904@gmail.com> <20080125.100006.-262784007.imp@bsdimp.com> <479A17AC.4070004@freebsd.org> <479A26CE.6020104@semihalf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> IIRC, almost any AIM binary I tried executing caused FP exceptions (actually, > an illegal instrusction ;) on e500, even such that wouldn't be expected tu use > FPU. I didn't investigate this at all, but maybe the compiler was using FPRs > for optimizations or something of that sort, don't know, so the frequency > might not be that low in reality. It would be interesting to see what is going on. Maybe gcc4 is using FP a lot more than gcc3, which is what the compiler was when the initial ppc FP trap code was done. > The interesting aspect about the trapped approach is that we could dispatch > the call farther, as please remember that embedded PowerPC can have floating > point/signal processing engines that can do the job, but just not the > traditional model. This is the very case of PQ3 and its SPE/SPFP which lay > idle at the moment.. Another option is to vector the trap back to user-space and deal with the emulation there. I heard a rumour that the sparc64 port does this: it sounded like a good idea since the process causing the traps would be the one paying the price, not the system at large. later, Peter.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?479A28E8.1060509>