Re: [avr-gcc-list] using exceptions

[Gabriel Dos Reis]

On Thu, May 3, 2012 at 9:01 AM, David Brown <address@hidden> wrote:

>>> I think this is okay for C++, too?
>>
>>
>> In C++, you can also access a non-const object with
>> a const qualified pointer.  But, that is not what I was
>> suggesting.  I am suggesting that a const(expr) *object* should
>> go in program memory because it cannot be modified.  The
>> only requirement is that it is statically initialized (e.g. at most
>> at link time.)
>>
>> The only time one can't put a const object in program memory
>> is when it requires a dynamic initialization. Constexpr objects
>> do not require dynamic initialization; the same is true for
>> statically initialized const object.
>>
>
> The trouble here is that the AVR uses different instructions to read from
> program memory and from data (ram + peripherals) space.  It is legal to
> write code like this:
>
> int x;                  // Must go in ram
> const int * p = &x;
> int foo(void) {
>        return *p;
> }
>
> Thus when the compiler generates code for reading "*p", it must generate the
> "read from ram" instructions.
>
> If the first line is changed to "const int x = 10;", then x must still be
> put in ram, even though it never changes, because otherwise foo() would
> fail.
>
> So on the AVR, constant data is forced into ram because of the instructions
> used to access it, not because it might change.

Yes.

Adding a qualifier to a pointer does not change the fundamental
problem.  Unless you also change the type of the object itself to reflect
the address space.  This is because, in general qualifiers on pointers
do not reflect the "true" address space of the object pointed to.

For internal compiler artifacts such as vtable and rtti objects, the type
are unique (and known to the compiler) therefore the compiler can put
them in program memory even if they might be access by pointers.

For const objects defined in a given translation unit, if their addresses escape
and the compiler cannot determine uses then they must go in RAM.

>
> If the new memory spaces can be used to avoid this, then that's great. The
> ideal is that the constant data gets put into a __flash memory space, which
> would be the most efficient.  An alternative might be to use the general
> memory space, which would allow some constant data to go in flash and other
> bits to go in ram, at the cost of using 24-bit pointers.  But I don't know
> enough about this to know if what is possible or desirable here.

It is tricky; but it can be done for "unique" types, e.g. vtables and
rtti objects,
and flash<T> if we decide to have one.

>
> mvh.,
>
> David