From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M0L0A-0002cl-UA for qemu-devel@nongnu.org; Sat, 02 May 2009 15:35:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M0L06-0002cV-EM for qemu-devel@nongnu.org; Sat, 02 May 2009 15:35:58 -0400 Received: from [199.232.76.173] (port=48796 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M0L06-0002cS-8z for qemu-devel@nongnu.org; Sat, 02 May 2009 15:35:54 -0400 Received: from mx20.gnu.org ([199.232.41.8]:40040) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M0L05-0000u8-T1 for qemu-devel@nongnu.org; Sat, 02 May 2009 15:35:54 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M0L04-0007XC-2n for qemu-devel@nongnu.org; Sat, 02 May 2009 15:35:52 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] 64 bit I/O support v7 Date: Sat, 2 May 2009 20:35:44 +0100 References: <49EDB109.5010009@earthlink.net> <200905020057.23902.paul@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905022035.45562.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Blue Swirl , Robert Reif On Saturday 02 May 2009, Blue Swirl wrote: > On 5/2/09, Paul Brook wrote: > > > Should a new intermediate bus layer also do byte swapping? > > > > Yes, though a bus layer isn't actually a necessary prerequisite. > > > > As I mentioned in the recent "Smarter compilation for target devices" > > thread[1], having individual devices do byteswapping is bogus. A while > > ago I reworked the TLB handling, so there should now be spare bits that > > can be used for things like byteswapping. > > This version does the byte swapping and width translation in exec.c. > Sparc32 OpenBIOS/Linux does not use the wrong sized accesses, so that > part may be untested. This appears to be adding yet annother layer of indirection, which isn't really what I had inmind. Paul