Re: [avr-libc-dev] gcc-3.3 branch

[Joerg Wunsch]

As Marek Michalkiewicz wrote:

> sorry for late reply

Better late than never. :)

> I've just looked at the issue of indirect 16-bit writes not working
> with 16-bit I/O registers (because high byte should be written
> first).  I'm afraid it's not that simple - if you look at
> out_movhi_mr_r, you will see that there are several places that
> would need to be changed.

I was afraid of that, that's why i've been asking a number of times
already for a review/discussion.  Too bad the discussion starts only
now that gcc 3.3 is already around the corner.

> If we fix just one case, people will assume that
> using pointers for 16-bit I/O is safe, when it still isn't.

It seems to fix the most problematic case though (i've also got this
patch as an add-on patch in my FreeBSD port): indirect assignment to
an IO register, without any postfix or prefix {in,de}crement.  The
latter would probably not make that much sense for IO registers
anyway.

> In some cases, where post-increment is used (most likely with the X
> pointer), writing high byte first would make less efficient code
> (when writing to normal SRAM, where order doesn't matter) - we lose
> the reg_unused_after optimizations.

Hmm.  Would it make sense to generally use the less efficient form,
and then leave it to the optimizer to reorder the registers?  I wonder
whether it would make sense to always try optimizing them unless
forbidden by a "volatile" keyword.  That way, we could document that
pointers to 16-bit IO registers are required to be declared "volatile"
if a particular read/write order is required.  That sounds a bit like
a crock, but should IMHO be within the possible actions for the
"volatile" keyword.

> So, my opinion is that it would
> be best to simply document the fact that 16-bit I/O register access
> works correctly only with constant addresses (which is the common case
> for most I/O register accesses anyway).  If you need to do a 16-bit
> write high byte first to non-constant addresses, better don't depend
> on GCC, but write a piece of inline asm, like this (not tested):

Well, there's already a FAQ entry documenting the use of indirect IO
port addresses within a function call, maybe we could just add this
information there.

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/