Re: AVR 16-bit I/O access order fix, PR target/20288

[Paul Schlie <schlie at comcast dot net>]

> From: Marek Michalkiewicz <marekm@amelek.gda.pl>
> On Mon, Mar 07, 2005 at 02:14:30AM -0500, Paul Schlie wrote:
> 
>> Hi Marek, Although not likely a big deal, but just in case it hadn't been
>> considered: unlike the constant addresses which uniquely reference atmel's
>> defined i/o registers; pointers reference the entire memory space, including
>> portion mapped externally which may have been used to interface to external
>> peripherals which may, although unlikely, rely on it's previous behavior?
> 
> Constant addresses are not unique to Atmel's I/O registers - they could
> be used for access to external peripherals too (just as well as pointers).

- the present code only uniquely attempts to map low-order constant
  addresses which correspond to atmel defined internal peripheral registers
  into in/out vs ld/st instructions, without regard to their being volatile
  references or not.

> Previous behavior was inconsistent (access order was dependent on the
> addressing mode used), so there was nothing to rely on :-)

- the present patch changes this to include all volatile references, which
  the more I think about it; is likely a mistake and should be reverted from
  4.1, as it is both an inconsistent change and unnecessary complexity.
  (candidly, the previous unique treatment of low-order constant address
  16-bit presumed i/o data access should likely be backed out in favor of
  being made consistent with the all remaining access sequences; and simply
  encode i/o peripheral access sequences explicitly as may be required).

>> This would seem necessary to enable the optional simple allocation of
>> read-only const data into progmem, and then simply identify corresponding
>> references to it via it's MEM_READONLY_P property, just as you had used
>> MEM_VOLATILE_P to identify volatile memory reference operands; so suspect
>> it should be retained for BLKmode operands as well, and may simply be a bug?
> 
> Supporting multiple address spaces in GCC is not that simple - "const"
> is not a good indication that the data should be in program memory.
> When a "char *" pointer is cast to "const char *" and then passed as
> a function argument, how do you tell the difference inside the function?
> (for example, should strcpy() copy from RAM or from flash?)

- the read-only attribute seems consistently valid for "static const"
  references, not "const" references in general, so appears to possibly
  be a good discriminator?

> It might be possible (but don't hold your breath, it's a lot of work
> and completely unrelated to the current 16-bit I/O register issue) to
> implement 3-byte pointers, where the highest bit of the address is used
> to choose the address space for each read access.  This would give us
> a single unified address space, at the cost of less efficient code.

- In my opinion 3-byte pointers are both unnecessary and undesirable; the
  only thing truly necessary to be able to directly "static const" data
  in from FLASH program ROM, without having to place a copy of it in RAM
  by default, or require the use of explicit progmem access routines to
  do so. (where if some attribute may be consistently used to identify
  such references to const data placed in ROM, then it would provide 64KB
  of directly accessible static const data utilizing 16-bit pointers, which
  seems more than sufficient to satisfy any reasonable avr application
  likely need.