From owner-p4-projects@FreeBSD.ORG Fri Jan 25 18:22:54 2008 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 35E2916A46C; Fri, 25 Jan 2008 18:22:54 +0000 (UTC) Delivered-To: perforce@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEA2016A420; Fri, 25 Jan 2008 18:22:53 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by mx1.freebsd.org (Postfix) with ESMTP id 5EE8B13C459; Fri, 25 Jan 2008 18:22:53 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from peter-grehans-power-mac-g5.local (dsl-63-249-90-35.cruzio.com [63.249.90.35]) by dommail.onthenet.com.au (MOS 3.7.5a-GA) with ESMTP id DMU25696 (AUTH peterg@ptree32.com.au); Sat, 26 Jan 2008 04:22:38 +1000 (EST) Message-ID: <479A28E8.1060509@freebsd.org> Date: Fri, 25 Jan 2008 10:22:32 -0800 From: Peter Grehan User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Rafal Jaworowski 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> In-Reply-To: <479A26CE.6020104@semihalf.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: yanegomi@gmail.com, perforce@FreeBSD.org, marcel@FreeBSD.org, "M. Warner Losh" Subject: Re: PERFORCE change 133911 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: grehan@freebsd.org List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2008 18:22:54 -0000 > 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.