From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31501 invoked by alias); 3 Mar 2005 22:21:59 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 31471 invoked by uid 48); 3 Mar 2005 22:21:55 -0000 Date: Thu, 03 Mar 2005 22:21:00 -0000 Message-ID: <20050303222154.31470.qmail@sourceware.org> From: "bjoern dot m dot haase at web dot de" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050302181643.20288.bob.paddock@gmail.com> References: <20050302181643.20288.bob.paddock@gmail.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug target/20288] AVR assignment of a value through a 16 bit pointer generates out of order code X-Bugzilla-Reason: CC X-SW-Source: 2005-03/txt/msg00423.txt.bz2 List-Id: ------- Additional Comments From bjoern dot m dot haase at web dot de 2005-03-03 22:21 ------- Hi, in order to completely resolve this issue, IIUC, one would have to sacrifice the post-increment addressing modes. In case of the X-Register, forcing the high-byte first rule allways would result in much less efficient code. For this reason, I think that enforcing the high-byte first rule always is not a good solution. There has been the suggestion to 1.) distinguish between pointer variables that are marked "volatile" and pointer variables that are not declared "volatile" and 2.) disable all post increment operations for such variables. In my opinion, this would not really be a clean solution, since IIUC, "volatile uint16_t pointer" is meant to be used for a pointer that, e.g. could be altered by an IRQ function, and the key-word "volatile" not meant to be used for classifying the variable the pointer is refering to. In fact, in the specific case no one would require the pointer no to be hold in a register variable. I also disagree that accessing IO-Memory by use of pointers is a very common case. Possibly it is a useful solution if one does not know at compile time which register will actually be in use. But I'd like to suggest, that this is sufficiently infrequently used to justify to require that sw developers use a special solution for this case, like the following: In order to enforce the byte-ordering, one could define an inline-asm instruction like #define WRITE_WORD_TO_MEMORY_MSB_FIRST(pointer_to_iom,value_to_be_stored) \ asm volatile ("/* Storing %A1:%B1 to the memory address %A0:%B0 is pointing to, high byte first */\n\t" \ "st z+1,%B1 \n\t" \ "st z,%A1 \n\t" \ : \ : "z" (pointer_to_iom), \ "r" (value_to_be_stored) ); \ Such an inline directive could be defined in one of the header files of avr-libc. Anybody that *really* could not avoid to access IOM-Space by pointers then would have the opportunity to make use of this makro. Summing up, my suggestion is not to change the compiler in order to avoid code-size and performace regressions. Instead, I consider it to be best to clearly document the issue and to provide a suitable macro definition in one of the avr-libc headers. Yours, Björn -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20288