avr-llvm-devel

[avr-llvm-devel] Flash data

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

I've started to work in adding support for storing data in flash memory. As
we discussed a year ago the best approach is to use named adress spaces and
clang and llvm supports them. During the weekend I've been working to store
the variables in the .progmem.data section. By default all static variables
are declared in assembly using the .comm directive, so I had to change the
way this works to save them in the mentioned section. Unfortunately I
couldn't find a way to do this without patching a file that is target
independent.

Having this solved, or atleast for now if something else pops, I would like
to add some sanity checks in the frontend for bad usage of using flash
variables. Again, I think this will mean patching target independent files
of clang, but I can't find a better way of doing it, I'm open to
suggestions if anybody finds a way of avoiding this.
The first checks I can think of is to force users to declare flash
variables with the const qualifier, and pointers that point to flash memory
to be const. Another one would be to error when writing a flash variable
(only initialization is allowed). One could cast away the const and write
to the var so this would have to be checked. On what other things should we
check for?
Btw, if somebody wants to work on this, I could move to the codegen side.

Re: [avr-llvm-devel] Flash data

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

Ok I've finished working on all this. Native english speakers check out
these strings for a more formal way of saying the following:

1) Cannot write to flash memory. <-- emitted when trying to assign a value
to a flash var
2) Flash variables are read only and should be declared with a const
qualifier. <-- emitted when doing something like __flash int, we want
__flash const int
3) The pointee type of a flash pointer should be declared with a const
qualifier. <-- i cant think of a better way of saying it, this is emitted
when doing __flash int* ptr, we want __flash const int *ptr.

Again, if anybody can think of any other sanity checks, list them here.
Once these strings are verified i'll commit my work.

Re: [avr-llvm-devel] Flash data

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

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?  Then you could say:

int __flash a;

int __flash * b;

int __flash * __flash c;

This would be an int in flash, a pointer in ram to an int in flash,
and a pointer in flash that points to an int in flash.  And all of the
constness would be guaranteed.

If __flash does not behave as a qualifier then I'm not sure how you
would achieve the third example above.

Thanks,
    Anton

p.s. Still lurking around on this list.  :)  I hope to get back to
hacking on avr-llvm at some point.

On Thu, Mar 15, 2012 at 1:01 PM, Borja Ferrer <bor...@gm...> wrote:
> Ok I've finished working on all this. Native english speakers check out
> these strings for a more formal way of saying the following:
>
> 1) Cannot write to flash memory. <-- emitted when trying to assign a value
> to a flash var
> 2) Flash variables are read only and should be declared with a const
> qualifier. <-- emitted when doing something like __flash int, we want
> __flash const int
> 3) The pointee type of a flash pointer should be declared with a const
> qualifier. <-- i cant think of a better way of saying it, this is emitted
> when doing __flash int* ptr, we want __flash const int *ptr.
>
> Again, if anybody can think of any other sanity checks, list them here.
> Once these strings are verified i'll commit my work.
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>

Re: [avr-llvm-devel] Flash data

[Weddington, E. <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

Re: [avr-llvm-devel] Flash data

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

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
>

Re: [avr-llvm-devel] Flash data

[Anton S. <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
>
>

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

Re: [avr-llvm-devel] Flash data

[Weddington, E. <Eri...@at...>]

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...]
> Sent: Sunday, March 18, 2012 12:49 PM
> To: Anton Staaf
> Cc: Weddington, Eric; avr...@li...
> Subject: Re: [avr-llvm-devel] Flash data
> 
> Ohhh, I misuderstood you Anton, I read the opposite thing xD
> 

My apologies too. I also mis-read you, and thought the opposite.

My bad. :-(

Eric

Re: [avr-llvm-devel] Flash data

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

On Sun, Mar 18, 2012 at 11:48 AM, Borja Ferrer <bor...@gm...> wrote:
> 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?

Yes, I can see the reason for wanting to preserve the standard error
messages over adding __flash specific error messages in as many cases
as possible.  Perhaps making __flash a type qualifier and having a
single check that every instance of __flash is associated with a const
qualifier would work?

-Anton

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

Re: [avr-llvm-devel] Flash data

[Weddington, E. <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

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
>

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

Re: [avr-llvm-devel] Flash data

[John M. <ato...@gm...>]

I share Anton's concern about *__flash* not being a type qualifier.
Will *__flash* behave as a type qualifier?
   int __flash * __flash c;
If not and a *__flash* type qualifier had to be created then the constness
of the qualifier would be an inherent feature of the  *__flash* type
qualifier.

Re: [avr-llvm-devel] Flash data

[John M. <ato...@gm...>]

Hi Borja,

On Mon, Mar 12, 2012 at 5:10 PM, Borja Ferrer <bor...@gm...> wrote:

> I've started to work in adding support for storing data in flash memory.
> As we discussed a year ago the best approach is to use named adress spaces
> and clang and llvm supports them. During the weekend I've been working to
> store the variables in the .progmem.data section. By default all static
> variables are declared in assembly using the .comm directive, so I had to
> change the way this works to save them in the mentioned section.
> Unfortunately I couldn't find a way to do this without patching a file that
> is target independent.
>

Can these patches be pushed back upstream to the LLVM trunk?

--John

Re: [avr-llvm-devel] Flash data

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

On Sun, Mar 18, 2012 at 12:34 PM, John Myers <ato...@gm...> wrote:
> I share Anton's concern about __flash not being a type qualifier.
> Will __flash behave as a type qualifier?
>    int __flash * __flash c;
> If not and a __flash type qualifier had to be created then the constness of
> the qualifier would be an inherent feature of the  __flash type qualifier.

Yes, I think it's important that __flash be a qualifier.  We can
probably decouple that requirement from whether or not __flash implies
constness.

-Anton

Re: [avr-llvm-devel] Flash data

[John M. <ato...@gm...>]

After looking at the Clang code some it looks like the address space
__attribute__ *does* cause a type qualifier for the address space to be
set.

On Sun, Mar 18, 2012 at 1:47 PM, Anton Staaf <an...@so...> wrote:

> On Sun, Mar 18, 2012 at 12:34 PM, John Myers <ato...@gm...>
> wrote:
> > I share Anton's concern about __flash not being a type qualifier.
> > Will __flash behave as a type qualifier?
> >    int __flash * __flash c;
> > If not and a __flash type qualifier had to be created then the constness
> of
> > the qualifier would be an inherent feature of the  __flash type
> qualifier.
>
> Yes, I think it's important that __flash be a qualifier.  We can
> probably decouple that requirement from whether or not __flash implies
> constness.
>
> -Anton
>

Re: [avr-llvm-devel] Flash data

[John M. <ato...@gm...>]

> 1) Cannot write to flash memory. <-- emitted when trying to assign a value
> to a flash var
>
The error for a const being assigned a value is "error: read-only variable
is not assignable" so I would make the wording consistent and just do...

      "error: Flash variable is not assignable"       ...or...
      "error: __flash qualified variable is not assignable"


> 2) Flash variables are read only and should be declared with a const
> qualifier. <-- emitted when doing something like __flash int, we want
> __flash const int
>

Something like the below and then also have one of those clang fix-it hints
showing const being added.

   "error: Flash variable requires const qualifier"

3) The pointee type of a flash pointer should be declared with a const
> qualifier. <-- i cant think of a better way of saying it, this is emitted
> when doing __flash int* ptr, we want __flash const int *ptr.
>

I think this can be the same as or similar to #2 and again use the fix-it
hint to show explicitly where the const needs to be placed.

Re: [avr-llvm-devel] Flash data

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

Indeed __flash is a type qualifier just like const or volatile, the syntax
you're all writing above is how it works. You can have an insane chain of
pointers like __flash const int * const __flash * * const __flash * __flash
ptr; and it's totally valid. The issue I'm talking about is, should __flash
qualify a variable with a const aswell? As we discussed above i think it
shouldn't.

Anton, what you said in the last email is exactly what I think, as __flash
is a type qualifier, check for constness and add errors if the user doesn't
explicitly add them. But after all the usage is what you're all writing
above. I like the idea of adding const because it really models how flash
memory works, and as i said making __flash imply const is like cheating on
the C language. But well, we're all here to discuss about it so it's not a
closed decision in any sense.

John thanks for the strings, I'll add them to my patch. If you want, once
it is commited you can add further changes or add any additional hints. I
still have to prepare the patch because I was waiting for this, I will
split it in 2 parts, one for the clang side and another for llvm.

Oh and if anybody else can think of any additional checks let me know, we
should be here as robust as possible.

2012/3/19 John Myers <ato...@gm...>

>
> 1) Cannot write to flash memory. <-- emitted when trying to assign a value
>> to a flash var
>>
> The error for a const being assigned a value is "error: read-only variable
> is not assignable" so I would make the wording consistent and just do...
>
>       "error: Flash variable is not assignable"       ...or...
>       "error: __flash qualified variable is not assignable"
>
>
>> 2) Flash variables are read only and should be declared with a const
>> qualifier. <-- emitted when doing something like __flash int, we want
>> __flash const int
>>
>
> Something like the below and then also have one of those clang fix-it
> hints showing const being added.
>
>    "error: Flash variable requires const qualifier"
>
> 3) The pointee type of a flash pointer should be declared with a const
>> qualifier. <-- i cant think of a better way of saying it, this is emitted
>> when doing __flash int* ptr, we want __flash const int *ptr.
>>
>
> I think this can be the same as or similar to #2 and again use the fix-it
> hint to show explicitly where the const needs to be placed.
>

Re: [avr-llvm-devel] Flash data

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

Ok I've just commited all patches and code related to this. Please try them
out and let me know any issues. John you'll notice some patches duplicate
some code compared to the interrupt.diff file because i added some code to
the same files like that patch, you may want to fix this, I didnt know what
to do.

2012/3/19 Borja Ferrer <bor...@gm...>

> Indeed __flash is a type qualifier just like const or volatile, the syntax
> you're all writing above is how it works. You can have an insane chain of
> pointers like __flash const int * const __flash * * const __flash * __flash
> ptr; and it's totally valid. The issue I'm talking about is, should __flash
> qualify a variable with a const aswell? As we discussed above i think it
> shouldn't.
>
> Anton, what you said in the last email is exactly what I think, as __flash
> is a type qualifier, check for constness and add errors if the user doesn't
> explicitly add them. But after all the usage is what you're all writing
> above. I like the idea of adding const because it really models how flash
> memory works, and as i said making __flash imply const is like cheating on
> the C language. But well, we're all here to discuss about it so it's not a
> closed decision in any sense.
>
> John thanks for the strings, I'll add them to my patch. If you want, once
> it is commited you can add further changes or add any additional hints. I
> still have to prepare the patch because I was waiting for this, I will
> split it in 2 parts, one for the clang side and another for llvm.
>
> Oh and if anybody else can think of any additional checks let me know, we
> should be here as robust as possible.
>
>
> 2012/3/19 John Myers <ato...@gm...>
>
>>
>> 1) Cannot write to flash memory. <-- emitted when trying to assign a
>>> value to a flash var
>>>
>> The error for a const being assigned a value is "error: read-only
>> variable is not assignable" so I would make the wording consistent and just
>> do...
>>
>>       "error: Flash variable is not assignable"       ...or...
>>       "error: __flash qualified variable is not assignable"
>>
>>
>>> 2) Flash variables are read only and should be declared with a const
>>> qualifier. <-- emitted when doing something like __flash int, we want
>>> __flash const int
>>>
>>
>> Something like the below and then also have one of those clang fix-it
>> hints showing const being added.
>>
>>    "error: Flash variable requires const qualifier"
>>
>> 3) The pointee type of a flash pointer should be declared with a const
>>> qualifier. <-- i cant think of a better way of saying it, this is emitted
>>> when doing __flash int* ptr, we want __flash const int *ptr.
>>>
>>
>> I think this can be the same as or similar to #2 and again use the fix-it
>> hint to show explicitly where the const needs to be placed.
>>
>
>

Re: [avr-llvm-devel] Flash data

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

John I noticed that in your latest commit you removed a piece of valid code
inside lib/CodeGen/TargetInfo.cpp, although this code is for flash
variables, it goes under the code that handles interrupt attributes.

 +  } else
 +    // Global variables that do not belong to the generic address space
and
 +    // have common linkage are set to have external linkage.
 +    if ((GV->getType()->getAddressSpace() != 0)
 +        && (GV->getLinkage() == llvm::GlobalValue::CommonLinkage))
 +      GV->setLinkage(llvm::GlobalValue::ExternalLinkage);
 +}
You may want to place this bit in the interrupt patch or something, I leave
that up to you.

Btw has anybody tried or tested the backend lately? I would like to hear
some opinions.

2012/3/20 Borja Ferrer <bor...@gm...>

> Ok I've just commited all patches and code related to this. Please try
> them out and let me know any issues. John you'll notice some patches
> duplicate some code compared to the interrupt.diff file because i added
> some code to the same files like that patch, you may want to fix this, I
> didnt know what to do.
>
>
> 2012/3/19 Borja Ferrer <bor...@gm...>
>
>> Indeed __flash is a type qualifier just like const or volatile, the
>> syntax you're all writing above is how it works. You can have an insane
>> chain of pointers like __flash const int * const __flash * * const __flash
>> * __flash ptr; and it's totally valid. The issue I'm talking about is,
>> should __flash qualify a variable with a const aswell? As we discussed
>> above i think it shouldn't.
>>
>> Anton, what you said in the last email is exactly what I think, as
>> __flash is a type qualifier, check for constness and add errors if the user
>> doesn't explicitly add them. But after all the usage is what you're all
>> writing above. I like the idea of adding const because it really models how
>> flash memory works, and as i said making __flash imply const is like
>> cheating on the C language. But well, we're all here to discuss about it so
>> it's not a closed decision in any sense.
>>
>> John thanks for the strings, I'll add them to my patch. If you want, once
>> it is commited you can add further changes or add any additional hints. I
>> still have to prepare the patch because I was waiting for this, I will
>> split it in 2 parts, one for the clang side and another for llvm.
>>
>> Oh and if anybody else can think of any additional checks let me know, we
>> should be here as robust as possible.
>>
>>
>> 2012/3/19 John Myers <ato...@gm...>
>>
>>>
>>> 1) Cannot write to flash memory. <-- emitted when trying to assign a
>>>> value to a flash var
>>>>
>>> The error for a const being assigned a value is "error: read-only
>>> variable is not assignable" so I would make the wording consistent and just
>>> do...
>>>
>>>       "error: Flash variable is not assignable"       ...or...
>>>       "error: __flash qualified variable is not assignable"
>>>
>>>
>>>> 2) Flash variables are read only and should be declared with a const
>>>> qualifier. <-- emitted when doing something like __flash int, we want
>>>> __flash const int
>>>>
>>>
>>> Something like the below and then also have one of those clang fix-it
>>> hints showing const being added.
>>>
>>>    "error: Flash variable requires const qualifier"
>>>
>>> 3) The pointee type of a flash pointer should be declared with a const
>>>> qualifier. <-- i cant think of a better way of saying it, this is emitted
>>>> when doing __flash int* ptr, we want __flash const int *ptr.
>>>>
>>>
>>> I think this can be the same as or similar to #2 and again use the
>>> fix-it hint to show explicitly where the const needs to be placed.
>>>
>>
>>
>

Re: [avr-llvm-devel] Flash data

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

John ping?

2012/4/12 Borja Ferrer <bor...@gm...>

> John I noticed that in your latest commit you removed a piece of valid
> code inside lib/CodeGen/TargetInfo.cpp, although this code is for flash
> variables, it goes under the code that handles interrupt attributes.
>
>   +  } else
>  +    // Global variables that do not belong to the generic address space
> and
>  +    // have common linkage are set to have external linkage.
>  +    if ((GV->getType()->getAddressSpace() != 0)
>  +        && (GV->getLinkage() == llvm::GlobalValue::CommonLinkage))
>  +      GV->setLinkage(llvm::GlobalValue::ExternalLinkage);
>  +}
> You may want to place this bit in the interrupt patch or something, I
> leave that up to you.
>
> Btw has anybody tried or tested the backend lately? I would like to hear
> some opinions.
>
>
> 2012/3/20 Borja Ferrer <bor...@gm...>
>
>> Ok I've just commited all patches and code related to this. Please try
>> them out and let me know any issues. John you'll notice some patches
>> duplicate some code compared to the interrupt.diff file because i added
>> some code to the same files like that patch, you may want to fix this, I
>> didnt know what to do.
>>
>>
>> 2012/3/19 Borja Ferrer <bor...@gm...>
>>
>>> Indeed __flash is a type qualifier just like const or volatile, the
>>> syntax you're all writing above is how it works. You can have an insane
>>> chain of pointers like __flash const int * const __flash * * const __flash
>>> * __flash ptr; and it's totally valid. The issue I'm talking about is,
>>> should __flash qualify a variable with a const aswell? As we discussed
>>> above i think it shouldn't.
>>>
>>> Anton, what you said in the last email is exactly what I think, as
>>> __flash is a type qualifier, check for constness and add errors if the user
>>> doesn't explicitly add them. But after all the usage is what you're all
>>> writing above. I like the idea of adding const because it really models how
>>> flash memory works, and as i said making __flash imply const is like
>>> cheating on the C language. But well, we're all here to discuss about it so
>>> it's not a closed decision in any sense.
>>>
>>> John thanks for the strings, I'll add them to my patch. If you want,
>>> once it is commited you can add further changes or add any additional
>>> hints. I still have to prepare the patch because I was waiting for this, I
>>> will split it in 2 parts, one for the clang side and another for llvm.
>>>
>>> Oh and if anybody else can think of any additional checks let me know,
>>> we should be here as robust as possible.
>>>
>>>
>>> 2012/3/19 John Myers <ato...@gm...>
>>>
>>>>
>>>> 1) Cannot write to flash memory. <-- emitted when trying to assign a
>>>>> value to a flash var
>>>>>
>>>> The error for a const being assigned a value is "error: read-only
>>>> variable is not assignable" so I would make the wording consistent and just
>>>> do...
>>>>
>>>>       "error: Flash variable is not assignable"       ...or...
>>>>       "error: __flash qualified variable is not assignable"
>>>>
>>>>
>>>>> 2) Flash variables are read only and should be declared with a const
>>>>> qualifier. <-- emitted when doing something like __flash int, we want
>>>>> __flash const int
>>>>>
>>>>
>>>> Something like the below and then also have one of those clang fix-it
>>>> hints showing const being added.
>>>>
>>>>    "error: Flash variable requires const qualifier"
>>>>
>>>> 3) The pointee type of a flash pointer should be declared with a const
>>>>> qualifier. <-- i cant think of a better way of saying it, this is emitted
>>>>> when doing __flash int* ptr, we want __flash const int *ptr.
>>>>>
>>>>
>>>> I think this can be the same as or similar to #2 and again use the
>>>> fix-it hint to show explicitly where the const needs to be placed.
>>>>
>>>
>>>
>>
>

Re: [avr-llvm-devel] Flash data

[John M. <ato...@gm...>]

I haven't had time to fix it.
I'll probably be able to do it this weekend.

On Fri, Apr 20, 2012 at 8:02 AM, Borja Ferrer <bor...@gm...> wrote:

> John ping?
>
>
> 2012/4/12 Borja Ferrer <bor...@gm...>
>
>> John I noticed that in your latest commit you removed a piece of valid
>> code inside lib/CodeGen/TargetInfo.cpp, although this code is for flash
>> variables, it goes under the code that handles interrupt attributes.
>>
>>   +  } else
>>  +    // Global variables that do not belong to the generic address space
>> and
>>  +    // have common linkage are set to have external linkage.
>>  +    if ((GV->getType()->getAddressSpace() != 0)
>>  +        && (GV->getLinkage() == llvm::GlobalValue::CommonLinkage))
>>  +      GV->setLinkage(llvm::GlobalValue::ExternalLinkage);
>>  +}
>> You may want to place this bit in the interrupt patch or something, I
>> leave that up to you.
>>
>> Btw has anybody tried or tested the backend lately? I would like to hear
>> some opinions.
>>
>>
>> 2012/3/20 Borja Ferrer <bor...@gm...>
>>
>>> Ok I've just commited all patches and code related to this. Please try
>>> them out and let me know any issues. John you'll notice some patches
>>> duplicate some code compared to the interrupt.diff file because i added
>>> some code to the same files like that patch, you may want to fix this, I
>>> didnt know what to do.
>>>
>>>
>>> 2012/3/19 Borja Ferrer <bor...@gm...>
>>>
>>>> Indeed __flash is a type qualifier just like const or volatile, the
>>>> syntax you're all writing above is how it works. You can have an insane
>>>> chain of pointers like __flash const int * const __flash * * const __flash
>>>> * __flash ptr; and it's totally valid. The issue I'm talking about is,
>>>> should __flash qualify a variable with a const aswell? As we discussed
>>>> above i think it shouldn't.
>>>>
>>>> Anton, what you said in the last email is exactly what I think, as
>>>> __flash is a type qualifier, check for constness and add errors if the user
>>>> doesn't explicitly add them. But after all the usage is what you're all
>>>> writing above. I like the idea of adding const because it really models how
>>>> flash memory works, and as i said making __flash imply const is like
>>>> cheating on the C language. But well, we're all here to discuss about it so
>>>> it's not a closed decision in any sense.
>>>>
>>>> John thanks for the strings, I'll add them to my patch. If you want,
>>>> once it is commited you can add further changes or add any additional
>>>> hints. I still have to prepare the patch because I was waiting for this, I
>>>> will split it in 2 parts, one for the clang side and another for llvm.
>>>>
>>>> Oh and if anybody else can think of any additional checks let me know,
>>>> we should be here as robust as possible.
>>>>
>>>>
>>>> 2012/3/19 John Myers <ato...@gm...>
>>>>
>>>>>
>>>>> 1) Cannot write to flash memory. <-- emitted when trying to assign a
>>>>>> value to a flash var
>>>>>>
>>>>> The error for a const being assigned a value is "error: read-only
>>>>> variable is not assignable" so I would make the wording consistent and just
>>>>> do...
>>>>>
>>>>>       "error: Flash variable is not assignable"       ...or...
>>>>>       "error: __flash qualified variable is not assignable"
>>>>>
>>>>>
>>>>>> 2) Flash variables are read only and should be declared with a const
>>>>>> qualifier. <-- emitted when doing something like __flash int, we want
>>>>>> __flash const int
>>>>>>
>>>>>
>>>>> Something like the below and then also have one of those clang fix-it
>>>>> hints showing const being added.
>>>>>
>>>>>    "error: Flash variable requires const qualifier"
>>>>>
>>>>> 3) The pointee type of a flash pointer should be declared with a const
>>>>>> qualifier. <-- i cant think of a better way of saying it, this is emitted
>>>>>> when doing __flash int* ptr, we want __flash const int *ptr.
>>>>>>
>>>>>
>>>>> I think this can be the same as or similar to #2 and again use the
>>>>> fix-it hint to show explicitly where the const needs to be placed.
>>>>>
>>>>
>>>>
>>>
>>
>

Re: [avr-llvm-devel] Flash data

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

Ok, thanks John.

2012/4/20 John Myers <ato...@gm...>

> I haven't had time to fix it.
> I'll probably be able to do it this weekend.
>
>
> On Fri, Apr 20, 2012 at 8:02 AM, Borja Ferrer <bor...@gm...>wrote:
>
>> John ping?
>>
>>
>> 2012/4/12 Borja Ferrer <bor...@gm...>
>>
>>> John I noticed that in your latest commit you removed a piece of valid
>>> code inside lib/CodeGen/TargetInfo.cpp, although this code is for flash
>>> variables, it goes under the code that handles interrupt attributes.
>>>
>>>   +  } else
>>>  +    // Global variables that do not belong to the generic address
>>> space and
>>>  +    // have common linkage are set to have external linkage.
>>>  +    if ((GV->getType()->getAddressSpace() != 0)
>>>  +        && (GV->getLinkage() == llvm::GlobalValue::CommonLinkage))
>>>  +      GV->setLinkage(llvm::GlobalValue::ExternalLinkage);
>>>  +}
>>> You may want to place this bit in the interrupt patch or something, I
>>> leave that up to you.
>>>
>>> Btw has anybody tried or tested the backend lately? I would like to hear
>>> some opinions.
>>>
>>>
>>> 2012/3/20 Borja Ferrer <bor...@gm...>
>>>
>>>> Ok I've just commited all patches and code related to this. Please try
>>>> them out and let me know any issues. John you'll notice some patches
>>>> duplicate some code compared to the interrupt.diff file because i added
>>>> some code to the same files like that patch, you may want to fix this, I
>>>> didnt know what to do.
>>>>
>>>>
>>>> 2012/3/19 Borja Ferrer <bor...@gm...>
>>>>
>>>>> Indeed __flash is a type qualifier just like const or volatile, the
>>>>> syntax you're all writing above is how it works. You can have an insane
>>>>> chain of pointers like __flash const int * const __flash * * const __flash
>>>>> * __flash ptr; and it's totally valid. The issue I'm talking about is,
>>>>> should __flash qualify a variable with a const aswell? As we discussed
>>>>> above i think it shouldn't.
>>>>>
>>>>> Anton, what you said in the last email is exactly what I think, as
>>>>> __flash is a type qualifier, check for constness and add errors if the user
>>>>> doesn't explicitly add them. But after all the usage is what you're all
>>>>> writing above. I like the idea of adding const because it really models how
>>>>> flash memory works, and as i said making __flash imply const is like
>>>>> cheating on the C language. But well, we're all here to discuss about it so
>>>>> it's not a closed decision in any sense.
>>>>>
>>>>> John thanks for the strings, I'll add them to my patch. If you want,
>>>>> once it is commited you can add further changes or add any additional
>>>>> hints. I still have to prepare the patch because I was waiting for this, I
>>>>> will split it in 2 parts, one for the clang side and another for llvm.
>>>>>
>>>>> Oh and if anybody else can think of any additional checks let me know,
>>>>> we should be here as robust as possible.
>>>>>
>>>>>
>>>>> 2012/3/19 John Myers <ato...@gm...>
>>>>>
>>>>>>
>>>>>> 1) Cannot write to flash memory. <-- emitted when trying to assign a
>>>>>>> value to a flash var
>>>>>>>
>>>>>> The error for a const being assigned a value is "error: read-only
>>>>>> variable is not assignable" so I would make the wording consistent and just
>>>>>> do...
>>>>>>
>>>>>>       "error: Flash variable is not assignable"       ...or...
>>>>>>       "error: __flash qualified variable is not assignable"
>>>>>>
>>>>>>
>>>>>>> 2) Flash variables are read only and should be declared with a const
>>>>>>> qualifier. <-- emitted when doing something like __flash int, we want
>>>>>>> __flash const int
>>>>>>>
>>>>>>
>>>>>> Something like the below and then also have one of those clang fix-it
>>>>>> hints showing const being added.
>>>>>>
>>>>>>    "error: Flash variable requires const qualifier"
>>>>>>
>>>>>> 3) The pointee type of a flash pointer should be declared with a
>>>>>>> const qualifier. <-- i cant think of a better way of saying it, this is
>>>>>>> emitted when doing __flash int* ptr, we want __flash const int *ptr.
>>>>>>>
>>>>>>
>>>>>> I think this can be the same as or similar to #2 and again use the
>>>>>> fix-it hint to show explicitly where the const needs to be placed.
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [avr-llvm-devel] Flash data

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

John I've seen you've updated some patches, but remember to fix the code
you removed from a patch file.

2012/4/22 Borja Ferrer <bor...@gm...>

> Ok, thanks John.
>
>
> 2012/4/20 John Myers <ato...@gm...>
>
>> I haven't had time to fix it.
>> I'll probably be able to do it this weekend.
>>
>>
>> On Fri, Apr 20, 2012 at 8:02 AM, Borja Ferrer <bor...@gm...>wrote:
>>
>>> John ping?
>>>
>>>
>>> 2012/4/12 Borja Ferrer <bor...@gm...>
>>>
>>>> John I noticed that in your latest commit you removed a piece of valid
>>>> code inside lib/CodeGen/TargetInfo.cpp, although this code is for flash
>>>> variables, it goes under the code that handles interrupt attributes.
>>>>
>>>>   +  } else
>>>>  +    // Global variables that do not belong to the generic address
>>>> space and
>>>>  +    // have common linkage are set to have external linkage.
>>>>  +    if ((GV->getType()->getAddressSpace() != 0)
>>>>  +        && (GV->getLinkage() == llvm::GlobalValue::CommonLinkage))
>>>>  +      GV->setLinkage(llvm::GlobalValue::ExternalLinkage);
>>>>  +}
>>>> You may want to place this bit in the interrupt patch or something, I
>>>> leave that up to you.
>>>>
>>>> Btw has anybody tried or tested the backend lately? I would like to
>>>> hear some opinions.
>>>>
>>>>
>>>> 2012/3/20 Borja Ferrer <bor...@gm...>
>>>>
>>>>> Ok I've just commited all patches and code related to this. Please try
>>>>> them out and let me know any issues. John you'll notice some patches
>>>>> duplicate some code compared to the interrupt.diff file because i added
>>>>> some code to the same files like that patch, you may want to fix this, I
>>>>> didnt know what to do.
>>>>>
>>>>>
>>>>> 2012/3/19 Borja Ferrer <bor...@gm...>
>>>>>
>>>>>> Indeed __flash is a type qualifier just like const or volatile, the
>>>>>> syntax you're all writing above is how it works. You can have an insane
>>>>>> chain of pointers like __flash const int * const __flash * * const __flash
>>>>>> * __flash ptr; and it's totally valid. The issue I'm talking about is,
>>>>>> should __flash qualify a variable with a const aswell? As we discussed
>>>>>> above i think it shouldn't.
>>>>>>
>>>>>> Anton, what you said in the last email is exactly what I think, as
>>>>>> __flash is a type qualifier, check for constness and add errors if the user
>>>>>> doesn't explicitly add them. But after all the usage is what you're all
>>>>>> writing above. I like the idea of adding const because it really models how
>>>>>> flash memory works, and as i said making __flash imply const is like
>>>>>> cheating on the C language. But well, we're all here to discuss about it so
>>>>>> it's not a closed decision in any sense.
>>>>>>
>>>>>> John thanks for the strings, I'll add them to my patch. If you want,
>>>>>> once it is commited you can add further changes or add any additional
>>>>>> hints. I still have to prepare the patch because I was waiting for this, I
>>>>>> will split it in 2 parts, one for the clang side and another for llvm.
>>>>>>
>>>>>> Oh and if anybody else can think of any additional checks let me
>>>>>> know, we should be here as robust as possible.
>>>>>>
>>>>>>
>>>>>> 2012/3/19 John Myers <ato...@gm...>
>>>>>>
>>>>>>>
>>>>>>> 1) Cannot write to flash memory. <-- emitted when trying to assign a
>>>>>>>> value to a flash var
>>>>>>>>
>>>>>>> The error for a const being assigned a value is "error: read-only
>>>>>>> variable is not assignable" so I would make the wording consistent and just
>>>>>>> do...
>>>>>>>
>>>>>>>       "error: Flash variable is not assignable"       ...or...
>>>>>>>       "error: __flash qualified variable is not assignable"
>>>>>>>
>>>>>>>
>>>>>>>> 2) Flash variables are read only and should be declared with a
>>>>>>>> const qualifier. <-- emitted when doing something like __flash int, we want
>>>>>>>> __flash const int
>>>>>>>>
>>>>>>>
>>>>>>> Something like the below and then also have one of those clang
>>>>>>> fix-it hints showing const being added.
>>>>>>>
>>>>>>>    "error: Flash variable requires const qualifier"
>>>>>>>
>>>>>>> 3) The pointee type of a flash pointer should be declared with a
>>>>>>>> const qualifier. <-- i cant think of a better way of saying it, this is
>>>>>>>> emitted when doing __flash int* ptr, we want __flash const int *ptr.
>>>>>>>>
>>>>>>>
>>>>>>> I think this can be the same as or similar to #2 and again use the
>>>>>>> fix-it hint to show explicitly where the const needs to be placed.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>