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

[Josef E. <za...@za...>]

On 11/10/2010 01:00 PM, Borja Ferrer wrote:
>>>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.

The only reason (I can think of) for rewriting (parts of) the avr-libc
is that it might result in better code in combination with LTO. But for
now I'd prefer using avr-libc.

Josef

> 
> 
> 2010/11/10 Weddington, Eric <Eri...@at...
> <mailto:Eri...@at...>>
> 
> 
> 
>     > -----Original Message-----
>     > From: John Myers [mailto:ato...@gm...
>     <mailto:ato...@gm...>]
>     > Sent: Tuesday, November 09, 2010 4:47 PM
>     > To: Weddington, Eric
>     > Cc: Borja Ferrer; avr...@li...
>     <mailto: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.
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a 
> Billion" shares his insights and actions to help propel your 
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
> 
> 
> 
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel