Re: [avr-llvm-devel] Flash data

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

Ohhh, I misuderstood you Anton, I read the opposite thing xD

Ok, so you and Eric are saying the same thing. As I said above, we wouldn't
benefit from the constantness optimizations, unless we set every flash
variable as const internally for the frontend, but that doesn't feel very
good to me. So doing __flash const int and __flash int would be the same
thing introducing redundancy in the language which is not standard at all.
I personally like the idea of making the user add the const so he doesn't
assign values accidentally to variables even if then we have a check for
erroring when this happens because he will get the typical error of "can't
assign a value to const variables" which is language specific and standard
and not a custom error added because the flash space cant be written which
is not language standard.

So what do you think?

2012/3/18 Anton Staaf <an...@so...>

> I'm confused, or have miss-communicated.  If you look again at what I
> said, I explicitly said that __flash would imply const, not the other
> way around.  Of coarse you want to be able to have const types that
> don't imply flash storage.  And the examples I gave all used __flash,
> not const.  No where did I suggest that const should imply __flash.
>
> Thanks,
>    Anton
>
> On Sun, Mar 18, 2012 at 8:35 AM, Borja Ferrer <bor...@gm...>
> wrote:
> > 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.
> >
> > 2012/3/18 Weddington, Eric <Eri...@at...>
> >
> >>
> >>
> >> > -----Original Message-----
> >> > From: Anton Staaf [mailto:an...@so...]
> >> > Sent: Saturday, March 17, 2012 2:15 PM
> >> > To: Borja Ferrer
> >> > Cc: avr...@li...
> >> > Subject: Re: [avr-llvm-devel] Flash data
> >> >
> >> > Hmm, if __flash acts in the same way as const, as in it's a qualifier.
> >> >  Then could you make it a super set of const?  In other words __flash
> >> > implies const?
> >>
> >> No, no, no and no.
> >>
> >> One can have const data, but not want it in flash. And having const
> >> imply a particular address space really does violate the C standard.
> >>
> >> However, what I do question is if the user writes __flash, are they
> >> really required to use const? It seems implicit in the use of __flash.
> >>
> >> Eric Weddington
> >
> >
>