avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Georg-Johann Lay
Subject: [avr-libc-dev] [bug #38021] pgm_read macros don't model the memory accesses
Date: Sat, 05 Jan 2013 08:56:58 +0000
User-agent: Opera/9.80 (Windows NT 5.0; U; de) Presto/2.6.30 Version/10.63

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

Jan Waclawek wrote in comment #1:
> 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.

Would you give a test case from the real world?

I don't see how this would increase the code size in ordinary programs --
except in the case where a clear if RAMPZ is missing and must be added to
comply with avr-gcc.  But in that case, the code size increase is inevitable.

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

No, that is not true.  The pgm-macros don't model a memory access at all. 
Notice that the memory access can be modeled and there is no need for a
volatile.  Please read my example code again and try to understand it.
 
> Instead, I suggest documentation enhancement, and perhaps
> a new set of macros,

The problem is that it is very hard for the user to cover the remaining,
uncommon cases, whereas providing proper macros does not do harm.  Not even a
memory barrier will help to fix the uncommon cases because there is no memory
access in the asm.

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

It's not a pessimization, it's inevitable so that your code will still work
with GCC 4.7.  I don't see a point in code that is efficient but incorrect.


    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht gesendet von/durch Savannah
  http://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]