From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IgyhE-0005J2-JP for qemu-devel@nongnu.org; Sun, 14 Oct 2007 04:19:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Igyh9-0005IT-FX for qemu-devel@nongnu.org; Sun, 14 Oct 2007 04:19:35 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Igyh9-0005IG-8J for qemu-devel@nongnu.org; Sun, 14 Oct 2007 04:19:31 -0400 Received: from nf-out-0910.google.com ([64.233.182.188]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Igyh8-00074C-Pq for qemu-devel@nongnu.org; Sun, 14 Oct 2007 04:19:31 -0400 Received: by nf-out-0910.google.com with SMTP id 30so1150080nfu for ; Sun, 14 Oct 2007 01:19:30 -0700 (PDT) Message-ID: Date: Sun, 14 Oct 2007 11:19:29 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] RFC: reverse-endian softmmu memory accessors In-Reply-To: <1192313247.9976.356.camel@rapid> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1192269372.9976.305.camel@rapid> <1192279414.9976.332.camel@rapid> <1192285067.9976.338.camel@rapid> <1192313247.9976.356.camel@rapid> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 10/14/07, J. Mayer wrote: > On Sat, 2007-10-13 at 16:17 +0200, J. Mayer wrote: > > On Sat, 2007-10-13 at 16:07 +0300, Blue Swirl wrote: > > > On 10/13/07, J. Mayer wrote: > > > > On Sat, 2007-10-13 at 13:47 +0300, Blue Swirl wrote: > > > > > On 10/13/07, J. Mayer wrote: > > > > > > The problem: > > > > > > some CPU architectures, namely PowerPC and maybe others, offers > > > > > > facilities to access the memory or I/O in the reverse endianness, ie > > > > > > little-endian instead of big-endian for PowerPC, or provide instruction > > > > > > to make memory accesses in the "reverse-endian". This is implemented as > > > > > > a global flag on some CPU. This case is already handled by the PowerPC > > > > > > emulation but is is far from being optimal. Some other implementations > > > > > > allow the OS to store an "reverse-endian" flag in the TLB or the segment > > > > > > descriptors, thus providing per-page or per-segment endianness control. > > > > > > This is mostly used to ease driver migration from a PC platform to > > > > > > PowerPC without taking any care of the device endianness in the driver > > > > > > code (yes, this is bad...). > > > > > > > > > > Nice, this may be useful for Sparc64. It has a global CPU flag for > > > > > endianness, individual pages can be marked as reverse endian, and > > > > > finally there are instructions that access memory in reverse endian. > > > > > The end result is a XOR of all these reverses. Though I don't know if > > > > > any of these features are used at all. > > > > > > > > I realized that I/O accesses for reverse-endian pages were not correct > > > > in the softmmu_template.h header. This new version fixes this. It also > > > > remove duplicated code in the case of unaligned accesses in a > > > > reverse-endian page. > > > > > > I think 64 bit access case is not handled correctly, but to solve that > > > it would be nice to extend the current IO access system to 64 bits. > > > > I think that if it was previously correct, it should still be, but... I > > don't know how much having 64 bits I/O accesses is interresting, as I > > don't know if there are real hw buses that have 64 bits data path... > > > > Here's another version taking care of your remark about ldl memory > > accessors. > > * I replaced all ldl occurences with ldul > > * when TARGET_LONG_BITS == 64, I also added ldsl accessors. And I > > started using it in the PowerPC memory access micro-ops. > > Then the patch is really more invasive than the previous ones. > > This still does not break PowerPC or i386 target, as it seems. > > Here's a new version. The only change is that, for consistency, I did > add the big-endian and little-endian accessors that were documented in > cpu-all.h as unimplemented. The implementation is quite trivial, having > native and reverse-endian accessors available, and changes functionnally > nothing to the previous version. The patch does not apply anymore. The Sparc part looks OK. The benefits from the patch can be gained by mapping Sparc64 lduw and ldsw in op_mem.h directly to ldul and ldsl using SPARC_LD_OP and replacing the ldl+bswap etc. for the LE cases with ldlr in op_helper.c. If you prefer, I can do this after you have applied the patch.