Re: [avr-llvm-devel] Load / Store

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

>>Obviously all the real decisions, especially on what's worth spending time
on, need to be made by the people actually spending their
>> time doing the work.
Yes Kevin, but the more opinions and arguments we get the better we'll be
able to decide, because this is as a C standard issue that is always hard to
decide.

>> In all reality, wouldn't avr-llvm have to work with avr-libc as it's
standard C library?
Yes, i've never thought of using a different C library or remaking a new
one, my opinion is that we should stick to it.


2010/11/10 Weddington, Eric <Eri...@at...>

>
>
> > -----Original Message-----
> > From: John Myers [mailto:ato...@gm...]
> > Sent: Tuesday, November 09, 2010 4:47 PM
> > To: Weddington, Eric
> > Cc: Borja Ferrer; avr...@li...
> > Subject: Re: [avr-llvm-devel] Load / Store
> >
> >
> >
>
> > I don't believe it does. What part of the standard do you
> > think it violates? The C language standard doesn't really
> > deal with multiple address spaces so it can't be an explicit
> > violation of the standard.
>
> There is a draft change to the standard that deals with multiple address
> spaces. The work that has been done in GCC for multiple address spaces
> conforms to this draft.
>
> > I even see a superscript text note
> > in the draft of the standard that says: "implementations may
> > place a const object that is not volatile in a read-only
> > region of storage".
>
> Hmm. Ok, so I'm wrong. :-)
>
> Most implementations I've seen have a semantic difference between something
> that is just *read only* and actually placing it in a different address
> space.
>
> If we don't equate the two it might make implementation easier though.
>