From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43512) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QJWMA-0000xe-G1 for qemu-devel@nongnu.org; Mon, 09 May 2011 15:43:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QJWM9-0005ML-Ey for qemu-devel@nongnu.org; Mon, 09 May 2011 15:43:02 -0400 Received: from va3ehsobe002.messaging.microsoft.com ([216.32.180.12]:3074 helo=VA3EHSOBE002.bigfish.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QJWM9-0005MF-Ci for qemu-devel@nongnu.org; Mon, 09 May 2011 15:43:01 -0400 Date: Mon, 9 May 2011 14:42:57 -0500 From: Scott Wood Message-ID: <20110509144257.34c06b1b@schlenkerla.am.freescale.net> In-Reply-To: References: <1304683237-26177-1-git-send-email-agraf@suse.de> <1304683237-26177-6-git-send-email-agraf@suse.de> <20110506172532.6f03cd81@schlenkerla.am.freescale.net> <47DDFCCF-2385-4763-BDFD-1E945809D0FC@suse.de> <20110509142715.3d296805@schlenkerla.am.freescale.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 5/7] PPC: Implement e500 (FSL) MMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: "Edgar E. Iglesias" , Liu Yu , QEMU-devel Developers On Mon, 9 May 2011 21:36:12 +0200 Alexander Graf wrote: > > On 09.05.2011, at 21:27, Scott Wood wrote: > > > On Sat, 7 May 2011 23:36:29 +0200 > > Alexander Graf wrote: > > > >> On 07.05.2011, at 00:25, Scott Wood wrote: > >>>> +void helper_booke206_tlbsx(target_ulong address_hi, target_ulong address_lo) > >>> > >>> What is address_hi? > >>> > >>> From gen_tlbsx_booke206() it looks like these two arguments correspond to > >>> the two operands, so shouldn't they be added together? I only see > >>> address_lo used. > >> > >> Yup. According to the e500 spec: > >> > >> Note that rA = 0 is the preferred form for tlbsx and that some Freescale implementations, such as the e500, take an illegal instruction exception program interrupt if rA!=0. > >> > >> So I figured that we're architecturally close enough if we just ignore it for now :). > > > > Architecturally, ignoring it and taking a trap are significantly > > different. :-) > > > > In practice it won't matter much, but it seems simple to handle it (why > > handle it in tlbivax but not here?), especially if this is to be general > > book3e code rather than e500. I'm still confused about the "address_hi/lo" > > naming. > > So what would you prefer? Just do whatever the 2.06 spec says and ignore e500 specifics? :) Or always do what the e500 spec says? Do what the architecture says. I doubt any software is going to be worse off if this instruction form succeeds rather than traps -- if such a situation actually turns up, we can deal with it then. -Scott