Re: [avr-llvm-devel] Flash data

[Borja F. <bor...@gm...>]

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
>