[avr-libc-dev] RE: [bug #26365] Better PROGMEM_FAR support

[Weddington, Eric]

> -----Original Message-----
> From: Jan Waclawek [mailto:address@hidden 
> Sent: Tuesday, April 28, 2009 1:20 AM
> To: Weddington, Eric; Jan Waclawek; address@hidden
> Subject: [bug #26365] Better PROGMEM_FAR support
> 
> 
> Follow-up Comment #2, bug #26365 (project avr-libc):
> 
> I beg to differ.
> 
> The request is a list, of which only the first item is 
> duplicate of patch
> #6352.
> 
> Shall I submit it as a series of feature requests, rather? 

Let's discuss the issues on the avr-libc-dev mailing list first, before 
submitting a whole bunch of feature requests.

- inclusion of complete https://savannah.nongnu.org/patch/?6352 of Carlos 
Lamas, especially the GET_FAR_ADDRESS() macro

Duplicate.

- similar macros for far function pointers, if possible

Function pointers (all pointers) are limited to 16-bits because of the AVR 
backend. Calls to functions in high memory (> 128K) are done through a jump 
table generated by the toolchain.

- a section to the relevant default linker scripts, placed just above the end 
of code (.fini0) - maybe called .progmem_far

If you put a section just above .fini0, you cannot guarantee that it will 
actually be in memory > 64K. If you put it at a fixed location, then how do you 
manage potential overlaps? This one seems more suited to a custom linker script 
for a particular users' application.

- a macro hiding usage of the above section, maybe as PROGMEM_FAR, analogous to 
the existing PROGMEM macro

Part of above.

- detection of crossing of the 64kB boundary by PROGMEM variables (and other 
related data which needs to be positioned at the bottom 64kB)

... And then what? Could you be more detailed?

- better detection of big PROGMEM data initialiser - at the moment, the 
compiler throws an error if the initialiser is >32kB, but compiles cleanly 
(albeit incorrectly) if the initialiser is >64kB.

Could you be more specific here?

As I mentioned, we are planning on adding patch #6352, so please let us know 
what additional problems remain that that patch does not cover, and any 
suggested fixes to those problems.

Thanks,
Eric Weddington