[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] gcc-3.3 branch
From: |
Joerg Wunsch |
Subject: |
Re: [avr-libc-dev] gcc-3.3 branch |
Date: |
Wed, 15 Jan 2003 18:02:46 +0100 |
User-agent: |
Mutt/1.2.5i |
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/
- [avr-libc-dev] gcc-3.3 branch, Theodore A. Roth, 2003/01/08
- Re: [avr-libc-dev] gcc-3.3 branch, E. Weddington, 2003/01/08
- Re: [avr-libc-dev] gcc-3.3 branch, Joerg Wunsch, 2003/01/08
- Re: [avr-libc-dev] gcc-3.3 branch, E. Weddington, 2003/01/09
- Re: [avr-libc-dev] gcc-3.3 branch, Joerg Wunsch, 2003/01/09
- Re: [avr-libc-dev] gcc-3.3 branch, E. Weddington, 2003/01/09
- Re: [avr-libc-dev] gcc-3.3 branch, Marek Michalkiewicz, 2003/01/14
- Re: [avr-libc-dev] gcc-3.3 branch,
Joerg Wunsch <=
- Re: [avr-libc-dev] gcc-3.3 branch, E. Weddington, 2003/01/15
- Re: [avr-libc-dev] gcc-3.3 branch, Marek Michalkiewicz, 2003/01/15
- Re: [avr-libc-dev] gcc-3.3 branch, Joerg Wunsch, 2003/01/16