From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IgeWX-0001da-FE for qemu-devel@nongnu.org; Sat, 13 Oct 2007 06:47:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IgeWW-0001cg-1W for qemu-devel@nongnu.org; Sat, 13 Oct 2007 06:47:13 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IgeWV-0001cN-Qq for qemu-devel@nongnu.org; Sat, 13 Oct 2007 06:47:11 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IgeWV-0003jS-KZ for qemu-devel@nongnu.org; Sat, 13 Oct 2007 06:47:11 -0400 Received: by nf-out-0910.google.com with SMTP id 30so1042878nfu for ; Sat, 13 Oct 2007 03:47:10 -0700 (PDT) Message-ID: Date: Sat, 13 Oct 2007 13:47:09 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] RFC: reverse-endian softmmu memory accessors In-Reply-To: <1192269372.9976.305.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> 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/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. Other memory access functions could be merged too. Is the 32 bit load with sign extension to 64 bits used in other architectures?