Date: Fri, 25 Jan 2008 19:13:34 +0100 From: Rafal Jaworowski <raj@semihalf.com> To: grehan@freebsd.org 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: <479A26CE.6020104@semihalf.com> In-Reply-To: <479A17AC.4070004@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?479A26CE.6020104>