From: Borja F. <bor...@gm...> - 2010-11-10 12:01:00
|
>>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. > |