[avr-libc-dev] [bug #38021] pgm_read macros don't model the memory accesses

[Jan Waclawek]

Follow-up Comment #1, bug #38021 (project avr-libc):

It is a very bad idea overall. It would increase code size of existing
programs, with little to no benefit except of a negligibly small group of
applications.

1. FLASH is inherently non-volatile; SPM out of bootloader context is uncommon
and those who use that should be aware of the risks (there are much more
involved anyway). Your suggestion is the same as to make all global variables
volatile just because some of them may be used both in interrupts and "main".

Instead, I suggest documentation enhancement, and perhaps a new set of macros,
named perhaps pgm_read_volatile_xxx, maybe even placed into a separate header
(or bootloader.h, as the holder of SPM-related stuff, maybe?)

2. in <4.7 is not an issue; in >4.7 is covered by 3.

3. is related only to the _far variety of pgm_read. That is used only by a
minority group of users using the >64kB FLASH varieties (including me), and
given the relatively large FLASH, it is likely the pessimisation imposed by
your suggestion would be significantly detrimental to their existing
applications. 

On the other hand, the far memory access introduced thanks to your work on the
named address space 4.7+ is still not completely mature (see the recent
discussion on the linker script) and I have not heard of any user reporting
about using them in a real-world application (honestly, I believe nobody uses
it so far, amongst the reason being lack of comprehensive binary builds we
discussed recently, and also the lack of user-grade documentation for it,
sorry). I don't believe it would become the preferred method for far memory
access sooner than in a year or even later. That's why I believe the existing
forms of _far variety of pgm_read should not be pessimized in favour of 4.7+
features.

Again, I suggest enhancements in documentation before any other measures. The
_far macros usage is far from being seamless anyway and its documentation
should be enhanced (see my remarks on avrfreaks on this topic, for example).
The implementation details should not be hidden from the user, contrary.
Warnings could be provided through some compiler or macro magic if the two
approaches clash, but I don't believe it's important at all. And again,
alternative macros or an alternative header could be provided, but I
personally see that as completely useless, as I don't see any point in mixing
the two accesses, once the named address space methods will mature.

JW


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?38021>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/