From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15998 invoked by alias); 1 Sep 2011 14:46:27 -0000 Received: (qmail 15983 invoked by uid 22791); 1 Sep 2011 14:46:27 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate3.uk.ibm.com (HELO mtagate3.uk.ibm.com) (194.196.100.163) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 01 Sep 2011 14:46:10 +0000 Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate3.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p81Ek8cX024593 for ; Thu, 1 Sep 2011 14:46:08 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1507.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p81Ek8mS2498634 for ; Thu, 1 Sep 2011 15:46:08 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p81Ek8fA007148 for ; Thu, 1 Sep 2011 08:46:08 -0600 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id p81Ek6Tl007113; Thu, 1 Sep 2011 08:46:07 -0600 Message-Id: <201109011446.p81Ek6Tl007113@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 01 Sep 2011 16:46:06 +0200 Subject: Re: [PATCH, ARM] Unaligned accesses for packed structures [1/2] To: julian@codesourcery.com (Julian Brown) Date: Thu, 01 Sep 2011 14:46:00 -0000 From: "Ulrich Weigand" Cc: gcc-patches@gcc.gnu.org, paul@codesourcery.com, rearnsha@arm.com, ramana.radhakrishnan@linaro.org (Ramana Radhakrishnan) In-Reply-To: <20110825164650.01ec842f@rex.config> from "Julian Brown" at Aug 25, 2011 04:46:50 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-09/txt/msg00069.txt.bz2 Julian Brown wrote: > The problem is, if we're using little-endian bit numbering for memory > locations in big-endian-bytes mode, we need to define an origin from > which to count "backwards" from. For the current implementation, this > will now be (I believe) one word beyond the base address of the access > in question, which is IMO slightly bizarre, to say the least. It doesn't seem all that bizarre to me. Conceptually, the extraction (etc.) operation works on an operand of integer type (usually, word sized) in two steps: - read the operand from its storage location, resulting in a plain (conceptual) integer value - extract certain numbered bits from that integer value The first step, reading the operand from the storage location, depends on BYTES_BIG_ENDIAN (as all memory reads do). It does not depend on BITS_BIG_ENDIAN at all. The second step, extracting numbered bits, depends on BITS_BIG_ENDIAN, which provides the link between bit number and its value. This step however does not depend on BYTES_BIG_ENDIAN at all. [However, if BITS_BIG_ENDIAN is true, you need to consider the total size of the operand in order to perform the conversion, since bit 0 then refers to the most-significant bit, and which bit that is depends on the size ... But this still does not depend on *BYTES_BIG_ENDIAN*.] Thus, the two flags can be considered really independent, and any combination is quite well-defined. When actually implementing the extraction, you will of course deviate from that conceptual sequence, e.g. by avoiding to read certain bytes if you know none of the bits in them will end up in the final result. But while this might result in some computations that may not immediately look obvious, in the end this is just an optimization step and doesn't change that the endian flags remain well-defined ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com