avr-llvm-devel

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

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

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

I've been very busy these days so i haven't got time to discuss this with my
friend, i hope to do it in the next few days.

Also mention that during my nearly inexistent spare time i've been reading
the codegeneration source code line by line to grasp all the low level
details to get a better general view in how to continue developing the
backend. I had some doubts about DAGs that i've resolved by reading the
code. I would like to finish reading it (70% done) before writing more code
in order to do it as better as possible.

2010/11/10 Borja Ferrer <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.
>>
>
>