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

[Jan Waclawek]

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

Sorry for the late answer, and the possible breakup of the thread - I messed up 
my mailboxes.


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

Of course. I was not aware it's going to make it there - finally.

----

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

Does this mean that a reference to a function is in fact the address of its 
corresponding entry in the jumptable, making it always 16 bit (and that 
jumptable is a table of jumps) [I am lazy to find it out myself now ;-) ]? If 
so, this item is then irrelevant indeed.

----

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

That doesn't matter. No harm done (as far as functionality concerned) if it's 
<=64kB; all the _far functions/macros will work. It's the programmer's 
responsibility to make an informed choice towards effectivity, if applicable. 
This is the same as with chosing the proper memory model in certain compilers 
on certain platforms.

> If you put it at a fixed location, then how do
> you manage potential overlaps? 

That would be, of course, silly to do.

> This one seems more suited to a custom
> linker script for a particular users' application.
> 

A section defined in this way results in absolutely no penalty or any other 
problem for programs which don't use the _far facilities. In other words, there 
are is no reason in not doing this in the standard linker scripts - except that 
the new linker scripts have to be created. And that's easy, unless I am 
overlooking some pitfall. 

I have no idea how are the linker scripts constructed - are they generated in 
some way, or hand crafted?

------

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

That's it. Point is that it could be done as part of the inclusion of Carlos's 
work, making it more complete.

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

Oh, if this happens, the resulting binary can't run correctly, can it? Hence, 
some sort of build error is appropriate.

I have no idea if this can be accomplished by some linker script magic, or 
requires tweaking the linker, or better left to some post-processing of 
linker's outputs. Please advise.  

-----

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

This might be a more generic problem, not constrained just to PROGMEM data.

Trying to make PROGMEM data to overflow the 64kB boundary (see previous item), 
I created a big array
uint8_t test[] PROGMEM = {0, 1, 2, 3, [...]};
where the initialiser was > 32kBytes. That resulted in a compiler error.  But 
making the initialiser twice as big, i.e. >64kBytes, the compiler quietly 
discarded the initialiser and compiled cleanly, allocating zero bytes for test. 
IMHO, this is a compiler bug. 

Jan Waclawek