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>
index | next in thread | previous in thread | raw e-mail
> 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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?479A28E8.1060509>