Re: [avr-llvm-devel] Flash data

[Anton S. <an...@so...>]

Borja,

    One thought I had was to use the word datum, instead of pointee.
in your third example.

-Anton

On Sun, Mar 18, 2012 at 12:03 PM, Borja Ferrer <bor...@gm...> wrote:
> Ok Eric :)
>
> Btw, can you think of better and more formal error messages as listed in
> message 2?
>
> 2012/3/18 Weddington, Eric <Eri...@at...>
>
>>
>>
>> > -----Original Message-----
>> > From: Borja Ferrer [mailto:bor...@gm...]
>> > Sent: Sunday, March 18, 2012 9:35 AM
>> > To: Weddington, Eric
>> > Cc: Anton Staaf; avr...@li...
>> > Subject: Re: [avr-llvm-devel] Flash data
>> >
>> > Heh I knew Eric was going to get a bit mad about what you said Anton
>> xDD
>> >
>> > Anton, those examples you wrote work exactly the same way as you
>> described.
>> > However you can't make that everything that is declared with const to
>> mean
>> > that it comes from flash memory, because it may be a ptr to ram, it's
>> not a
>> > safe assumption to do. That way, __flash has to be used explicitly, so
>> the
>> > user is telling the compiler to change the storage of that piece of
>> data from
>> > the generic address space to a custom one.
>> >
>> > Eric, about my decision of declaring variables always const, it is
>> because
>> > they are really read-only by hardware, so writing to them is illegal
>> and this
>> > way you're defining the data type as it should be, always readonly.
>> Another
>> > reason is that by telling the compiler the data is not going to change
>> > throughout execution you benefit from a decent amount of optimizations
>> and
>> > alias analysis, avoiding lots of memory reloads and many other goodies
>> you get
>> > when using the const qualifier.
>> >
>> > Even if something is declared const, with a cast the constness can be
>> removed
>> > and one could write to the variable, but I've added an error to handle
>> this
>> > sort of behavior. In theory nobody should want to do this because it
>> would be
>> > going against what flash memory does, so it would be more like wanting
>> to
>> > trick the compiler, but erroring in this case would show it's robust
>> and that
>> > you cant really trick it.
>> >
>>
>> Ok, it sounds reasonable to me. :-)
>>
>> Thanks for the explanation!
>>
>> Eric
>
>