------- 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
