From owner-p4-projects@FreeBSD.ORG Fri Jan 25 18:13:40 2008 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id DF22B16A468; Fri, 25 Jan 2008 18:13:39 +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 8B5DF16A41B; Fri, 25 Jan 2008 18:13:39 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from mail.semihalf.com (mail.semihalf.com [83.15.139.206]) by mx1.freebsd.org (Postfix) with ESMTP id D77B713C45A; Fri, 25 Jan 2008 18:13:38 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from localhost (unknown [127.0.0.1]) by mail.semihalf.com (Postfix) with ESMTP id 99D94145DE; Fri, 25 Jan 2008 19:21:04 +0100 (CET) Received: from mail.semihalf.com ([127.0.0.1]) by localhost (mail.semihalf.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22198-07; Fri, 25 Jan 2008 19:21:03 +0100 (CET) Message-ID: <479A26CE.6020104@semihalf.com> Date: Fri, 25 Jan 2008 19:13:34 +0100 From: Rafal Jaworowski MIME-Version: 1.0 To: grehan@freebsd.org References: <200801230414.m0N4E4ng009323@repoman.freebsd.org> <4797C8E0.4070100@freebsd.org> <4798C436.6090904@gmail.com> <20080125.100006.-262784007.imp@bsdimp.com> <479A17AC.4070004@freebsd.org> In-Reply-To: <479A17AC.4070004@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at semihalf.com 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 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:13:40 -0000 Peter Grehan wrote: >> I'd rather hoped to run the Cisco stuff using EABI, which doesn't need >> fp emulation in the kernel... > > EABI to my mind only helps in ultra-tight embedded environments, which > I don't think exist anymore. 8-byte vs 16-byte stack alignment isn't > going to help anyone. > Yes, it's mostly about stack conventions and registers usage policy, so no FP-strictly related (although among others it tells how to use FPRs for [non-]volatile purposes etc.) > And if embedded environments are using a lot of soft-float, they are > running on the wrong type of CPU. Trapping to the kernel should be > infrequent, and it does allow a single ABI for all processor types. > 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. 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.. My 0.02 PLN :) Rafal