avr-llvm-devel Mailing List for avr-llvm (Page 20)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hello John i'm not at home now to check this but i've noticed your last
commit introduces a change that im unsure now if it's compatible with our
current code base which is v2.8.

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

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

> -----Original Message-----
> From: John Myers [mailto:ato...@gm...] 
> Sent: Tuesday, November 09, 2010 5:36 PM
> To: Kevin Schoedel
> Cc: avr...@li...
> Subject: Re: [avr-llvm-devel] Load / Store
> 
> 
> 
> 
> This could be taken care of with generic pointers similar to 
> the ones 8052 compilers like Keil and SDCC have.
> It wouldn't be pretty or very efficient but nether would it 
> be fatal. When users require more efficiency they explicitly 
> qualify the pointer parameter which would then only allow 
> them to use the specific type qualified object as an 
> argument. Also, this problem would happen even with 
> explicitly qualified types. So without a generic pointer the 
> compiler would throw an error either way.
> 
> 
> 
> 
> 	>However how
> 	>should we treate inline strings like printf("hello")? 
> place them in ROM by
> 	>default? because declaring a ptr for each string 
> similar to what gcc does
> 	>is a bit insane.
> 	
> 	
> 	In principle, you could have an optimization pass that 
> would, for instance,
> 	replace __builtin_printf(const char *, ...) with 
> __builtin_printf(__flash
> 	const char *, ...) while placing the format string in 
> ROM. To do much more
> 	than that, for C, sounds to me like a large research project.
> 	
> 

In all reality, wouldn't avr-llvm have to work with avr-libc as it's standard C library? If so, then we need to keep that in mind when working on avr-llvm. Using avr-libc would be the path of least resistance to gain users over to avr-llvm. If it works just like GCC, but with some improvements (namely better optimizations), then it will be easy for users to convert. I'd rather keep things as simple as possible, at least at first.

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

On Tue, Nov 9, 2010 at 2:19 PM, Kevin Schoedel <sch...@kw...> wrote:

> At 9:35 pm +0100 2010/11/09, you wrote:
> >If i remember correctly, when i worked with CodeWarrior for the HC08s,
> >placing a const qualifier directly meant placing the data in ROM
>
> That's fine when you have a single address space, but on the AVR, you'd
> have to fake one in software, which would be fatal for performance.
> Consider for example:
>
> &a[0] is an address in RAM, but, if you magically put any object declared
> const into ROM, &b[0] is a an address in flash. How is f() supposed to deal
> with that?
>
This could be taken care of with generic pointers similar to the ones 8052
compilers like Keil and SDCC have.
It wouldn't be pretty or very efficient but nether would it be fatal. When
users require more efficiency they explicitly qualify the pointer parameter
which would then *only* allow them to use the specific type qualified object
as an argument. Also, this problem would happen even with explicitly
qualified types. So without a generic pointer the compiler would throw an
error either way.

>However how
> >should we treate inline strings like printf("hello")? place them in ROM by
> >default? because declaring a ptr for each string similar to what gcc does
> >is a bit insane.
>
> In principle, you could have an optimization pass that would, for instance,
> replace __builtin_printf(const char *, ...) with __builtin_printf(__flash
> const char *, ...) while placing the format string in ROM. To do much more
> than that, for C, sounds to me like a large research project.
>
> >I'm going to ask about this to a friend who is a compiler expert, and i'll
> >reply about his thoughts, probably during this weekend, im very busy these
> >days.
>
> Until 2004, I did commercial compiler work on quite a few oddball
> processors that would make the AVR look like a model of simplicity. These
> days I'm doing compiler work professionally again, which means I'm not
> really inclined to do it recreationally as well, but I'm usually happy to
> comment. 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.
>
> --
> Kevin Schoedel <sch...@kw...> VA3TCS
>
>
> ------------------------------------------------------------------------------
> 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
>

On Tue, Nov 9, 2010 at 11:42 AM, Weddington, Eric <Eri...@at...
> wrote:

>
>
> > -----Original Message-----
> > From: John Myers [mailto:ato...@gm...]
> > Sent: Tuesday, November 09, 2010 12:14 PM
> > To: Weddington, Eric
> > Cc: Borja Ferrer; avr...@li...
> > Subject: Re: [avr-llvm-devel] Load / Store
> >
> >
> >
> >
> >
> > I don't see why it would be inappropriate from the standpoint
> > of a High Level Language or even C.  A linker frees the user
> > from needing to manually place objects and it seems to me
> > having the compiler place const qualified objects in specific
> > areas is no different. I agree that we will still need to
> > support memory space qualifiers.
>
> Then I will say it stronger: It violates the C language standard if you do
> this. None of the current C compilers for the AVR do this, and they are all
> fairly well conforming to the C language standard.
>

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

At 9:35 pm +0100 2010/11/09, you wrote:
>If i remember correctly, when i worked with CodeWarrior for the HC08s,
>placing a const qualifier directly meant placing the data in ROM

That's fine when you have a single address space, but on the AVR, you'd
have to fake one in software, which would be fatal for performance.
Consider for example:

  int a[] = { 1, 2 };
  const int b[] = { 3, 4 };
  extern int f(const int*);
  int g(void)
  {
    return f(&a[0]) + f(&b[0]);
  }

&a[0] is an address in RAM, but, if you magically put any object declared
const into ROM, &b[0] is a an address in flash. How is f() supposed to deal
with that?

>However how
>should we treate inline strings like printf("hello")? place them in ROM by
>default? because declaring a ptr for each string similar to what gcc does
>is a bit insane.

In principle, you could have an optimization pass that would, for instance,
replace __builtin_printf(const char *, ...) with __builtin_printf(__flash
const char *, ...) while placing the format string in ROM. To do much more
than that, for C, sounds to me like a large research project.

>I'm going to ask about this to a friend who is a compiler expert, and i'll
>reply about his thoughts, probably during this weekend, im very busy these
>days.

Until 2004, I did commercial compiler work on quite a few oddball
processors that would make the AVR look like a model of simplicity. These
days I'm doing compiler work professionally again, which means I'm not
really inclined to do it recreationally as well, but I'm usually happy to
comment. 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.

-- 
Kevin Schoedel <sch...@kw...> VA3TCS

If i remember correctly, when i worked with CodeWarrior for the HC08s,
placing a const qualifier directly meant placing the data in ROM, John's
idea. If we do what Eric says, i would place everything in RAM if it's not
explictly stated with a space qualifier, ignoring constness. However how
should we treate inline strings like printf("hello")? place them in ROM by
default? because declaring a ptr for each string similar to what gcc does is
a bit insane.

I'm going to ask about this to a friend who is a compiler expert, and i'll
reply about his thoughts, probably during this weekend, im very busy these
days.

> -----Original Message-----
> From: John Myers [mailto:ato...@gm...] 
> Sent: Tuesday, November 09, 2010 12:14 PM
> To: Weddington, Eric
> Cc: Borja Ferrer; avr...@li...
> Subject: Re: [avr-llvm-devel] Load / Store
> 
> 
> 
> 
> 
> I don't see why it would be inappropriate from the standpoint 
> of a High Level Language or even C.  A linker frees the user 
> from needing to manually place objects and it seems to me 
> having the compiler place const qualified objects in specific 
> areas is no different. I agree that we will still need to 
> support memory space qualifiers.

Then I will say it stronger: It violates the C language standard if you do this. None of the current C compilers for the AVR do this, and they are all fairly well conforming to the C language standard. 

On Thu, Nov 4, 2010 at 7:09 PM, Weddington, Eric
<Eri...@at...>wrote:

>  >
> > Eric,
> >
> > I think transparently placing, for example, const qualified
> > objects in flash will only take creating an LLVM
> > transformation Pass. Which means the extra work has already
> > been done by the LLVM Pass Framework. Now if we have to do
> > work in the front end then I can see your point.
> >
> > --John
>
> Oh, I'm sorry, I didn't fully grasp what we're talking about here.
>
> It really is not appropriate to automatically put const qualified objects
> in flash. The keyword 'const' has a specific meaning (read-only value) which
> does not necessarily mean that it should be put into a specific memory
> space, even if it is a read-only value. We will need to have an additional
> memory space qualifier on the object to put it in a different address space.
> That way it is the least surprise to users who are used to using GCC and IAR
> (and other compilers).
>
> Eric
>

I don't see why it would be inappropriate from the standpoint of a High
Level Language or even C.  A linker frees the user from needing to manually
place objects and it seems to me having the compiler place const qualified
objects in specific areas is no different. I agree that we will still need
to support memory space qualifiers.

> -----Original Message-----
> From: John Myers [mailto:ato...@gm...] 
> Sent: Thursday, November 04, 2010 5:43 PM
> To: Weddington, Eric
> Cc: Borja Ferrer; avr...@li...
> Subject: Re: [avr-llvm-devel] Load / Store
> 
> 
> 	>       Another thing, i dont know how feasible is doing this,
> 	> but should we make program and data space addrs transparent
> 	> to the user?
> 	>
> 	>
> 	
> 
>  On Mon, Nov 1, 2010 at 9:10 PM, Weddington, Eric 
> <Eri...@at...> wrote:
> 
> 	>
> 	> Yes I believe that would be a useful feature.
> 	> I think we should try as much as possible without, of course,
> 	> violating any language standards.
> 	> It would allow users to write more portable/generic code.
> 	> We probable should have a command line option to
> 	> enable/disable this so users have more control.
> 	> LLVM has an address space qualifier mechanism already so I
> 	> don't think it will take too much work.
> 	
> 	
> 	I definitely agree with the above, except for the part 
> about a command line option: I would suggest that there be no 
> command line option for this. It will just be extra work for 
> something that I doubt anyone will ever use (a command-line 
> option). Just implement the feature.
> 	
> 
> 
> Eric,
> 
> I think transparently placing, for example, const qualified 
> objects in flash will only take creating an LLVM 
> transformation Pass. Which means the extra work has already 
> been done by the LLVM Pass Framework. Now if we have to do 
> work in the front end then I can see your point.
> 
> --John

Oh, I'm sorry, I didn't fully grasp what we're talking about here.

It really is not appropriate to automatically put const qualified objects in flash. The keyword 'const' has a specific meaning (read-only value) which does not necessarily mean that it should be put into a specific memory space, even if it is a read-only value. We will need to have an additional memory space qualifier on the object to put it in a different address space. That way it is the least surprise to users who are used to using GCC and IAR (and other compilers).

Eric

> >       Another thing, i dont know how feasible is doing this,
> > but should we make program and data space addrs transparent
> > to the user?
> >
> >
>
 On Mon, Nov 1, 2010 at 9:10 PM, Weddington, Eric <Eri...@at...
> wrote:

> >
> > Yes I believe that would be a useful feature.
> > I think we should try as much as possible without, of course,
> > violating any language standards.
> > It would allow users to write more portable/generic code.
> > We probable should have a command line option to
> > enable/disable this so users have more control.
> > LLVM has an address space qualifier mechanism already so I
> > don't think it will take too much work.
>
> I definitely agree with the above, except for the part about a command line
> option: I would suggest that there be no command line option for this. It
> will just be extra work for something that I doubt anyone will ever use (a
> command-line option). Just implement the feature.
>

Eric,

I think transparently placing, for example, const qualified objects in flash
will only take creating an LLVM transformation Pass. Which means the extra
work has already been done by the LLVM Pass Framework. Now if we have to do
work in the front end then I can see your point.

--John

Ahh thanks for the replies, this brings to me some other doubts. If gcc
doesnt support different ptr sizes, when it comes to the code emission
stage, when doing a load or a store for the 8bit ptr case, does it move the
whole reg pair addr to X/Y/Z or it knows it only needs the lower half
because the upper is always 0, otherwise it is a huge waste.

If clang supports named spaces then it's great as Kevin pointed out.
I'm a bit concerend about portability in different devices because
sizeof(void *) is going to be 1, 2 or 3, do you think this can cause any
issues?
About what John mentioned, what would you suggest Eric to overcome this
issue? you're the libc expert here, so how would you manage different ptr
sizes in the library?

On Thu, Nov 4, 2010 at 10:32 AM, Weddington, Eric <Eri...@at...
> wrote:

>
> > If we want to have generic pointers (like Keil, SDCC...) we
> > will also need 32 bit pointer. Generic pointers allow the
> > user to create a pointer that can access all the address space's.
>
> I'm not sure that something like that would ever be used effectively on the
> AVR. At the moment, I suggest avoiding generic pointers.
>

It isn't efficient but it allows you to simplify your code. Without generic
pointers multiply functions, doing the same thing, are needed. Like *printf*vs.
*printf_P*. Needing multiply functions that do basically the same thing also
adds overhead. Generic pointers for the smaller AVR's would only need 16/24
bits.

> -----Original Message-----
> From: John Myers [mailto:ato...@gm...] 
> Sent: Thursday, November 04, 2010 11:24 AM
> To: Borja Ferrer
> Cc: avr...@li...
> Subject: Re: [avr-llvm-devel] Load / Store
> 
> 
> 
> On Thu, Nov 4, 2010 at 7:52 AM, Borja Ferrer 
> <bor...@gm...> wrote:
> 
> 
> 	 As far as i know LLVM has address space identifiers in 
> its IR so in theory it's possible to do it, however i havent 
> looked yet how to implement this in the backend. Another 
> thing, i havent checked if clang supports named address 
> spaces, i know gcc does, but at the end we should end up 
> using only clang as the frontend?
> 	
> 	Can somebody clarify me if GCC has support for 24 bit 
> ptrs for largest devices and 8 bit ptrs for the smallests? 
> i'm only used to 16 bit ptrs so i dont what gcc does outside 
> this case.
> 	Implementing 24bit ptrs should be possible, same for 8bit.

AVR GCC currently only has 16-bit pointers. I don't know if it is possible in the generic parts of GCC to have 24-bit pointers. But I think in this case, avr-llvm should have 8, 16, and 24-bit pointers. Not sure about 32-bit pointers yet.

> If we want to have generic pointers (like Keil, SDCC...) we 
> will also need 32 bit pointer. Generic pointers allow the 
> user to create a pointer that can access all the address space's.

I'm not sure that something like that would ever be used effectively on the AVR. At the moment, I suggest avoiding generic pointers.

On Thu, Nov 4, 2010 at 7:52 AM, Borja Ferrer <bor...@gm...> wrote:

>  As far as i know LLVM has address space identifiers in its IR so in theory
> it's possible to do it, however i havent looked yet how to implement this in
> the backend. Another thing, i havent checked if clang supports named address
> spaces, i know gcc does, but at the end we should end up using only clang as
> the frontend?
>
> Can somebody clarify me if GCC has support for 24 bit ptrs for largest
> devices and 8 bit ptrs for the smallests? i'm only used to 16 bit ptrs so i
> dont what gcc does outside this case.
> Implementing 24bit ptrs should be possible, same for 8bit.
>

I was playing around with this a while ago, so I created the clang patch to
enable address space type qualifiers. so adding __eeprom__ or __flash__ will
put the object in a different address space. It produces the correct LLVM IR
but I didn't put the time in to figuring out how to get it to add the
appropriate section name in asm.

If we want to have generic pointers (like Keil, SDCC...) we will also need
32 bit pointer. Generic pointers allow the user to create a pointer that can
access all the address space's.

> -----Original Message-----
> From: sch...@kw... [mailto:sch...@kw...] 
> Sent: Thursday, November 04, 2010 9:50 AM
> To: Borja Ferrer; avr...@li...
> Subject: Re: [avr-llvm-devel] Load / Store
> 
> On Thu, 4 Nov 2010 15:52:05 +0100, Borja Ferrer wrote
> > i havent checked if clang supports named address spaces, i know gcc 
> > does, but at the end we should end up using only clang as 
> the frontend?
> 
> Clang uses __attribute__((address_space(N))). In clang 
> attributes act like type
> qualifiers, so this works correctly. These would presumably 
> be given pre-defined
> macro names; I believe avr-gcc plans to follow IAR in naming 
> them __flash,
> __eeprom, etc. I expect Eric can confirm.

Confirmed. It's being worked on at the moment.

On Thu, 4 Nov 2010 15:52:05 +0100, Borja Ferrer wrote
> i havent checked if clang supports named address spaces, i know gcc 
> does, but at the end we should end up using only clang as the frontend?

Clang uses __attribute__((address_space(N))). In clang attributes act like type
qualifiers, so this works correctly. These would presumably be given pre-defined
macro names; I believe avr-gcc plans to follow IAR in naming them __flash,
__eeprom, etc. I expect Eric can confirm.

-- 
Kevin Schoedel <sch...@kw...> VA3TCS

Heh i knew this part was going to bring in some debate. Kevin thanks for the
link to the C spec pdf file, i think we should try this approach now that we
have the opportunity of doing things from scratch to improve what GCC
offers. The PROGMEM attribute is a good workaround, but supporting this
natively would bring around more benefits like pushing optimizations further
avoiding many function calls and having some alias ptr analysis. As far as i
know LLVM has address space identifiers in its IR so in theory it's possible
to do it, however i havent looked yet how to implement this in the backend.
Another thing, i havent checked if clang supports named address spaces, i
know gcc does, but at the end we should end up using only clang as the
frontend?

Can somebody clarify me if GCC has support for 24 bit ptrs for largest
devices and 8 bit ptrs for the smallests? i'm only used to 16 bit ptrs so i
dont what gcc does outside this case.
Implementing 24bit ptrs should be possible, same for 8bit.

Deciding what ptr to use is not trivial, i took a fast read to gcc's code
and i think there was a function that decided which reg pair had to be used,
i could be wrong though. I did some tests and for example the Y ptr is
favored against X if there's no frame ptr in the function, so this has to be
taken into account. I need to look how ARM does this, they have 5 or 6
different addressing modes in their .td file. These decisions have to be
taken after knowing what type of operations are done in the ptr itself, so
for example if we have one ptr access that doesnt need doing ptr+<offs> X
can be used otherwise use Z or Y, but as i said this needs doing a previous
analysis, imagine functions with lots of traffic between arrays, there has
to be some logic behind.

We could probably do the same as AVR GCC for now. I'll check with some other people to see what would perhaps be the most ideal. 

> -----Original Message-----
> From: John Myers [mailto:ato...@gm...] 
> Sent: Wednesday, November 03, 2010 6:20 PM
> To: Borja Ferrer
> Cc: avr...@li...
> Subject: Re: [avr-llvm-devel] Load / Store
> 
> 
> 	- If ptrs were 8 bits we could have a reg class with 
> r26, r28 and r30 for st/ld and the compiler would be able to 
> choose between this class what reg to use. However we have to 
> stick with reg pairs so we have to think how to overcome 
> this, if we dont use reg classes will we have to decide which 
> pair has to be used manually in each operation??.
> 	Also notice that we should try to avoid using X to 
> access struct members or whatever because it doesnt support 
> doing "X+<offs>" so we have to see how to handle different 
> addressing modes, favouring Y or Z in such cases etc.
> 	
> 
> 
> The avr-gcc ABI uses the Y ptr for the stack frame so that 
> would leave the Z ptr as the favored pointer.
> 
> 
> 

> - If ptrs were 8 bits we could have a reg class with r26, r28 and r30 for
> st/ld and the compiler would be able to choose between this class what reg
> to use. However we have to stick with reg pairs so we have to think how to
> overcome this, if we dont use reg classes will we have to decide which pair
> has to be used manually in each operation??.
> Also notice that we should try to avoid using X to access struct members or
> whatever because it doesnt support doing "X+<offs>" so we have to see how to
> handle different addressing modes, favouring Y or Z in such cases etc.
>

The avr-gcc ABI uses the Y ptr for the stack frame so that would leave the Z
ptr as the favored pointer.

Agreed. This is something that is currently being worked on for the AVR port of GCC. So we need to have this for AVR LLVM.

And yes, 24-bit pointers for spaces (flash and data) that require it, and even 8-bit pointers if necessary.

Eric Weddington 

> -----Original Message-----
> From: Kevin Schoedel [mailto:sch...@kw...] 
> Sent: Monday, November 01, 2010 9:33 PM
> To: Borja Ferrer; avr...@li...
> Subject: Re: [avr-llvm-devel] Load / Store
> 
> First, thanks for the all work you've done, Borja.
> 
> >Another thing, i dont know how feasible is doing this, but 
> should we make
> >program and data space addrs transparent to the user?
> 
> If you're asking what I think you're asking, notation for 
> this will be part
> of the next version of the C standard. The approved final 
> draft of this, TR
> 18037 "Extensions to support embedded processors", is available at
> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1275.pdf>. 
> See "Named
> Address Spaces" in section 5. I believe LLVM can now support 
> this directly.
> 
> In the long run, I think it would be ideal to have code 
> pointers be either
> two or three bytes depending on the processor model. This would imply
> supporting 24-bit integers as well; it looks like LLVM can do 
> this now,
> though it couldn't when I looked at using it for AVR a couple 
> years ago. It
> would also be nice to have one-byte pointers (i.e. an 
> additional address
> space) to efficiently reference I/O registers.
> 
> -- 
> Kevin Schoedel <sch...@kw...> VA3TCS
> 
> --------------------------------------------------------------
> ----------------
> Nokia and AT&T present the 2010 Calling All Innovators-North 
> America contest
> Create new apps & games for the Nokia N8 for consumers in  
> U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly 
> $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish 
> to Ovi Store 
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
> 

> -----Original Message-----
> From: John Myers [mailto:ato...@gm...] 
> Sent: Monday, November 01, 2010 9:34 PM
> To: Borja Ferrer
> Cc: avr...@li...
> Subject: Re: [avr-llvm-devel] Load / Store
> 
> 
> 	Another thing, i dont know how feasible is doing this, 
> but should we make program and data space addrs transparent 
> to the user?
> 	
> 
> 
> Yes I believe that would be a useful feature.
> I think we should try as much as possible without, of course, 
> violating any language standards.
> It would allow users to write more portable/generic code. 
> We probable should have a command line option to 
> enable/disable this so users have more control.
> LLVM has an address space qualifier mechanism already so I 
> don't think it will take too much work.
> I think most of the work of making it transparent will need 
> to be done in the front ends and optimizer passes. Either way 
> (like a lot of commercial embedded compilers) we'll need to 
> extend the type qualifiers to include things like flash, 
> eeprom, near / far pointers...

I definitely agree with the above, except for the part about a command line option: I would suggest that there be no command line option for this. It will just be extra work for something that I doubt anyone will ever use (a command-line option). Just implement the feature.

First, thanks for the all work you've done, Borja.

>Another thing, i dont know how feasible is doing this, but should we make
>program and data space addrs transparent to the user?

If you're asking what I think you're asking, notation for this will be part
of the next version of the C standard. The approved final draft of this, TR
18037 "Extensions to support embedded processors", is available at
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1275.pdf>. See "Named
Address Spaces" in section 5. I believe LLVM can now support this directly.

In the long run, I think it would be ideal to have code pointers be either
two or three bytes depending on the processor model. This would imply
supporting 24-bit integers as well; it looks like LLVM can do this now,
though it couldn't when I looked at using it for AVR a couple years ago. It
would also be nice to have one-byte pointers (i.e. an additional address
space) to efficiently reference I/O registers.

-- 
Kevin Schoedel <sch...@kw...> VA3TCS

2009	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (26)	Dec (15)
2010	Jan	Feb	Mar	Apr	May	Jun (2)	Jul	Aug	Sep (14)	Oct (16)	Nov (36)	Dec (3)
2011	Jan	Feb	Mar (1)	Apr (17)	May (9)	Jun (6)	Jul	Aug	Sep	Oct (1)	Nov (2)	Dec (4)
2012	Jan (22)	Feb (12)	Mar (39)	Apr (31)	May (42)	Jun (35)	Jul (32)	Aug (2)	Sep (5)	Oct	Nov	Dec (9)
2013	Jan	Feb	Mar	Apr (2)	May	Jun (121)	Jul (61)	Aug (7)	Sep (8)	Oct (6)	Nov	Dec (1)
2014	Jan	Feb	Mar	Apr	May	Jun	Jul (1)	Aug	Sep	Oct	Nov	Dec
2015	Jan (1)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

avr-llvm-devel Mailing List for avr-llvm (Page 20)

This is the AVR port of LLVM.

avr-llvm-devel — Developers mailing list.