avr-llvm-devel

[avr-llvm-devel] Current Status?

[Sherard D. <sc...@gm...>]

Hello everyone,

I'm curious as to the current status of this project. From the looks of
the SVN (and the mailing list) it would appear that the project is
fairly inactive. Is it simply that work is going on behind closed doors?
Or perhaps, is it a dead project?

[avr-llvm-devel] Current Status?

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

Hello everybody,

Sorry about the delay of my reply, but I'm very busy this month with my
finals. First thing I would like to say is to welcome Sherard. As a short
summary, the current status to answer Sherard's question is:

Basically most of what is required to compile sequential code (no jumps) is
implemented, this includes all memory addressing modes, arithmetic
instructions, function calls, passing arguments, etc. Last thing I finished
working on before Christmas was frames and stack manipulation. So we can
now allocate automatic variables on the stack, pass arguments using the
stack, and spill registers.
Next thing I'm going to work on are jumps and conditional code, I'll head
into this in February when I'm done with my finals, I only had time to
implement the jmp instruction which was pretty fast to do, but conditional
code requires a lot more of work.

Please don't look or work on any code in SVN because that is going to be
removed, and I doubt it even compiles with the latest LLVM release. It's my
fault because i haven't uploaded yet any of the work I've done out of trunk
to SVN but i want to have something in shape before commiting it, I think I
will do it once conditional code is done. Looking in SVN is misleading
because it looks as the project is dead, but that is totally wrong because
we're getting a lot done out of there.

About patches, I would say most of them are updated, I commited a patch
some weeks ago for the register allocator, but if you want to check them
it's ok. Related to code, i think patches are the only useful thing SVN has
now, the backend code will go away.

Since the LLVM backend code is not yet commited, I would suggest as John
said working on regression tests, we're going to need this soon, and we're
getting behind on this because we need a good test suite to catch as many
errors as possible, so patches there are welcome. Something similar to what
the MSP430 backend has would be a decent start. Tests related to arithmetic
ops, function calls, testing ABI, and other things you can think of that
dont require jumps.
Also on the other side, a lot of work is needed in Clang, we need to
support many of the custom extensions AVR has like address spaces or
interrupt handlers, so work is needed there aswell. We discussed some
months ago about how to deal with address spaces but we didnt reach to any
formal decisions, so if you want to work on that aswell you're welcome. In
fact, if you want to work both with tests and this that would be great :)

Another thing, I've noticed that the new register allocator in 3.0 uses
less stack memory than IAR or GCC so that is something positive. I see a
lot of potential in getting better code than gcc in the future, because
with the current generated code which is not optimized at all (i want to
leave that for a later stage) we're getting in par or improving what gcc
does and sometimes getting a bit longer code but nothing that is too bad to
worry. But once we introduce custom patters for instruction selection
things will improve exponentially.

If you want to ask any specific questions after this general summary?

Re: [avr-llvm-devel] Current Status?

[Sherard D. <sc...@gm...>]

Thanks for responding Borja. I do have a question, posed to everyone
really. Does anyone know where I can find a reference for which
instructions are available for which AVR architectures? Haven't been
able to stumble upon one in my searches.

Thanks,

On Tue, 2012-01-10 at 17:35 +0100, Borja Ferrer wrote:
> Hello everybody, 
> 
> Sorry about the delay of my reply, but I'm very busy this month with
> my finals. First thing I would like to say is to welcome Sherard. As a
> short summary, the current status to answer Sherard's question is:
> 
> Basically most of what is required to compile sequential code (no
> jumps) is implemented, this includes all memory addressing modes,
> arithmetic instructions, function calls, passing arguments, etc. Last
> thing I finished working on before Christmas was frames and stack
> manipulation. So we can now allocate automatic variables on the stack,
> pass arguments using the stack, and spill registers.
> Next thing I'm going to work on are jumps and conditional code, I'll
> head into this in February when I'm done with my finals, I only had
> time to implement the jmp instruction which was pretty fast to do, but
> conditional code requires a lot more of work.
> 
> Please don't look or work on any code in SVN because that is going to
> be removed, and I doubt it even compiles with the latest LLVM release.
> It's my fault because i haven't uploaded yet any of the work I've done
> out of trunk to SVN but i want to have something in shape before
> commiting it, I think I will do it once conditional code is done.
> Looking in SVN is misleading because it looks as the project is dead,
> but that is totally wrong because we're getting a lot done out of
> there.
> 
> About patches, I would say most of them are updated, I commited a
> patch some weeks ago for the register allocator, but if you want to
> check them it's ok. Related to code, i think patches are the only
> useful thing SVN has now, the backend code will go away.
> 
> Since the LLVM backend code is not yet commited, I would suggest as
> John said working on regression tests, we're going to need this soon,
> and we're getting behind on this because we need a good test suite to
> catch as many errors as possible, so patches there are welcome.
> Something similar to what the MSP430 backend has would be a decent
> start. Tests related to arithmetic ops, function calls, testing ABI,
> and other things you can think of that dont require jumps. 
> Also on the other side, a lot of work is needed in Clang, we need to
> support many of the custom extensions AVR has like address spaces or
> interrupt handlers, so work is needed there aswell. We discussed some
> months ago about how to deal with address spaces but we didnt reach to
> any formal decisions, so if you want to work on that aswell you're
> welcome. In fact, if you want to work both with tests and this that
> would be great :)
> 
> Another thing, I've noticed that the new register allocator in 3.0
> uses less stack memory than IAR or GCC so that is something positive.
> I see a lot of potential in getting better code than gcc in the
> future, because with the current generated code which is not optimized
> at all (i want to leave that for a later stage) we're getting in par
> or improving what gcc does and sometimes getting a bit longer code but
> nothing that is too bad to worry. But once we introduce custom patters
> for instruction selection things will improve exponentially.
> 
> If you want to ask any specific questions after this general summary?
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create 
> new or port existing apps to sell to consumers worldwide. Explore the 
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________ avr-llvm-devel mailing list avr...@li... https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel

Re: [avr-llvm-devel] Current Status?

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

I can't really say, maybe Eric can help here. What I use to develope the
backend is a pdf of the instruction set, but it doesnt specify what devices
are supported for each instruction.

2012/1/11 Sherard Dames <sc...@gm...>

> Thanks for responding Borja. I do have a question, posed to everyone
> really. Does anyone know where I can find a reference for which
> instructions are available for which AVR architectures? Haven't been
> able to stumble upon one in my searches.
>
> Thanks,
>
> On Tue, 2012-01-10 at 17:35 +0100, Borja Ferrer wrote:
> > Hello everybody,
> >
> > Sorry about the delay of my reply, but I'm very busy this month with
> > my finals. First thing I would like to say is to welcome Sherard. As a
> > short summary, the current status to answer Sherard's question is:
> >
> > Basically most of what is required to compile sequential code (no
> > jumps) is implemented, this includes all memory addressing modes,
> > arithmetic instructions, function calls, passing arguments, etc. Last
> > thing I finished working on before Christmas was frames and stack
> > manipulation. So we can now allocate automatic variables on the stack,
> > pass arguments using the stack, and spill registers.
> > Next thing I'm going to work on are jumps and conditional code, I'll
> > head into this in February when I'm done with my finals, I only had
> > time to implement the jmp instruction which was pretty fast to do, but
> > conditional code requires a lot more of work.
> >
> > Please don't look or work on any code in SVN because that is going to
> > be removed, and I doubt it even compiles with the latest LLVM release.
> > It's my fault because i haven't uploaded yet any of the work I've done
> > out of trunk to SVN but i want to have something in shape before
> > commiting it, I think I will do it once conditional code is done.
> > Looking in SVN is misleading because it looks as the project is dead,
> > but that is totally wrong because we're getting a lot done out of
> > there.
> >
> > About patches, I would say most of them are updated, I commited a
> > patch some weeks ago for the register allocator, but if you want to
> > check them it's ok. Related to code, i think patches are the only
> > useful thing SVN has now, the backend code will go away.
> >
> > Since the LLVM backend code is not yet commited, I would suggest as
> > John said working on regression tests, we're going to need this soon,
> > and we're getting behind on this because we need a good test suite to
> > catch as many errors as possible, so patches there are welcome.
> > Something similar to what the MSP430 backend has would be a decent
> > start. Tests related to arithmetic ops, function calls, testing ABI,
> > and other things you can think of that dont require jumps.
> > Also on the other side, a lot of work is needed in Clang, we need to
> > support many of the custom extensions AVR has like address spaces or
> > interrupt handlers, so work is needed there aswell. We discussed some
> > months ago about how to deal with address spaces but we didnt reach to
> > any formal decisions, so if you want to work on that aswell you're
> > welcome. In fact, if you want to work both with tests and this that
> > would be great :)
> >
> > Another thing, I've noticed that the new register allocator in 3.0
> > uses less stack memory than IAR or GCC so that is something positive.
> > I see a lot of potential in getting better code than gcc in the
> > future, because with the current generated code which is not optimized
> > at all (i want to leave that for a later stage) we're getting in par
> > or improving what gcc does and sometimes getting a bit longer code but
> > nothing that is too bad to worry. But once we introduce custom patters
> > for instruction selection things will improve exponentially.
> >
> > If you want to ask any specific questions after this general summary?
> >
> ------------------------------------------------------------------------------
> > Write once. Port to many.
> > Get the SDK and tools to simplify cross-platform app development. Create
> > new or port existing apps to sell to consumers worldwide. Explore the
> > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> > http://p.sf.net/sfu/intel-appdev
> > _______________________________________________ avr-llvm-devel mailing
> list avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>
>
>

Re: [avr-llvm-devel] Current Status?

[Weddington, E. <Eri...@at...>]

Unfortunately, I don't know of a document that describes that layout.

Probably the best bet would be to look at the GNU Binutils source code
at the AVR backend. That source is about the best documentation we have.

Eric Weddington

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...]
> Sent: Wednesday, January 11, 2012 3:03 PM
> To: Sherard Dames
> Cc: avr...@li...
> Subject: Re: [avr-llvm-devel] Current Status?
> 
> I can't really say, maybe Eric can help here. What I use to develope
the
> backend is a pdf of the instruction set, but it doesnt specify what
> devices are supported for each instruction.
> 
> 
> 2012/1/11 Sherard Dames <sc...@gm...>
> 
> 
> 	Thanks for responding Borja. I do have a question, posed to
everyone
> 	really. Does anyone know where I can find a reference for which
> 	instructions are available for which AVR architectures? Haven't
been
> 	able to stumble upon one in my searches.
> 
> 	Thanks,
> 
> 
> 	On Tue, 2012-01-10 at 17:35 +0100, Borja Ferrer wrote:
> 	> Hello everybody,
> 	>
> 	> Sorry about the delay of my reply, but I'm very busy this
month
> with
> 	> my finals. First thing I would like to say is to welcome
Sherard.
> As a
> 	> short summary, the current status to answer Sherard's question
is:
> 	>
> 	> Basically most of what is required to compile sequential code
(no
> 	> jumps) is implemented, this includes all memory addressing
modes,
> 	> arithmetic instructions, function calls, passing arguments,
etc.
> Last
> 	> thing I finished working on before Christmas was frames and
stack
> 	> manipulation. So we can now allocate automatic variables on
the
> stack,
> 	> pass arguments using the stack, and spill registers.
> 	> Next thing I'm going to work on are jumps and conditional
code,
> I'll
> 	> head into this in February when I'm done with my finals, I
only
> had
> 	> time to implement the jmp instruction which was pretty fast to
do,
> but
> 	> conditional code requires a lot more of work.
> 	>
> 	> Please don't look or work on any code in SVN because that is
going
> to
> 	> be removed, and I doubt it even compiles with the latest LLVM
> release.
> 	> It's my fault because i haven't uploaded yet any of the work
I've
> done
> 	> out of trunk to SVN but i want to have something in shape
before
> 	> commiting it, I think I will do it once conditional code is
done.
> 	> Looking in SVN is misleading because it looks as the project
is
> dead,
> 	> but that is totally wrong because we're getting a lot done out
of
> 	> there.
> 	>
> 	> About patches, I would say most of them are updated, I
commited a
> 	> patch some weeks ago for the register allocator, but if you
want
> to
> 	> check them it's ok. Related to code, i think patches are the
only
> 	> useful thing SVN has now, the backend code will go away.
> 	>
> 	> Since the LLVM backend code is not yet commited, I would
suggest
> as
> 	> John said working on regression tests, we're going to need
this
> soon,
> 	> and we're getting behind on this because we need a good test
suite
> to
> 	> catch as many errors as possible, so patches there are
welcome.
> 	> Something similar to what the MSP430 backend has would be a
decent
> 	> start. Tests related to arithmetic ops, function calls,
testing
> ABI,
> 	> and other things you can think of that dont require jumps.
> 	> Also on the other side, a lot of work is needed in Clang, we
need
> to
> 	> support many of the custom extensions AVR has like address
spaces
> or
> 	> interrupt handlers, so work is needed there aswell. We
discussed
> some
> 	> months ago about how to deal with address spaces but we didnt
> reach to
> 	> any formal decisions, so if you want to work on that aswell
you're
> 	> welcome. In fact, if you want to work both with tests and this
> that
> 	> would be great :)
> 	>
> 	> Another thing, I've noticed that the new register allocator in
3.0
> 	> uses less stack memory than IAR or GCC so that is something
> positive.
> 	> I see a lot of potential in getting better code than gcc in
the
> 	> future, because with the current generated code which is not
> optimized
> 	> at all (i want to leave that for a later stage) we're getting
in
> par
> 	> or improving what gcc does and sometimes getting a bit longer
code
> but
> 	> nothing that is too bad to worry. But once we introduce custom
> patters
> 	> for instruction selection things will improve exponentially.
> 	>
> 	> If you want to ask any specific questions after this general
> summary?
> 
> 	>
------------------------------------------------------------------
> ------------
> 	> Write once. Port to many.
> 	> Get the SDK and tools to simplify cross-platform app
development.
> Create
> 	> new or port existing apps to sell to consumers worldwide.
Explore
> the
> 	> Intel AppUpSM program developer opportunity.
> appdeveloper.intel.com/join
> 	> http://p.sf.net/sfu/intel-appdev
> 	> _______________________________________________ avr-llvm-devel
> mailing list avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
> 
> 
> 
> 

Re: [avr-llvm-devel] Current Status?

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

Eric I have one question, when passing function parameters through the
stack, why does gcc allocate stack space doing the typical copy from SP to
a reg, decrement it for the needed amount and then copy it back to SP and
then use std instructions, instead of directly pushing the registers saving
all the SP manipulation?
Is there particular reason for not doing this?

2012/1/11 Weddington, Eric <Eri...@at...>

>
> Unfortunately, I don't know of a document that describes that layout.
>
> Probably the best bet would be to look at the GNU Binutils source code
> at the AVR backend. That source is about the best documentation we have.
>
> Eric Weddington
>
> > -----Original Message-----
> > From: Borja Ferrer [mailto:bor...@gm...]
> > Sent: Wednesday, January 11, 2012 3:03 PM
> > To: Sherard Dames
> > Cc: avr...@li...
> > Subject: Re: [avr-llvm-devel] Current Status?
> >
> > I can't really say, maybe Eric can help here. What I use to develope
> the
> > backend is a pdf of the instruction set, but it doesnt specify what
> > devices are supported for each instruction.
> >
> >
> > 2012/1/11 Sherard Dames <sc...@gm...>
> >
> >
> >       Thanks for responding Borja. I do have a question, posed to
> everyone
> >       really. Does anyone know where I can find a reference for which
> >       instructions are available for which AVR architectures? Haven't
> been
> >       able to stumble upon one in my searches.
> >
> >       Thanks,
> >
> >
> >       On Tue, 2012-01-10 at 17:35 +0100, Borja Ferrer wrote:
> >       > Hello everybody,
> >       >
> >       > Sorry about the delay of my reply, but I'm very busy this
> month
> > with
> >       > my finals. First thing I would like to say is to welcome
> Sherard.
> > As a
> >       > short summary, the current status to answer Sherard's question
> is:
> >       >
> >       > Basically most of what is required to compile sequential code
> (no
> >       > jumps) is implemented, this includes all memory addressing
> modes,
> >       > arithmetic instructions, function calls, passing arguments,
> etc.
> > Last
> >       > thing I finished working on before Christmas was frames and
> stack
> >       > manipulation. So we can now allocate automatic variables on
> the
> > stack,
> >       > pass arguments using the stack, and spill registers.
> >       > Next thing I'm going to work on are jumps and conditional
> code,
> > I'll
> >       > head into this in February when I'm done with my finals, I
> only
> > had
> >       > time to implement the jmp instruction which was pretty fast to
> do,
> > but
> >       > conditional code requires a lot more of work.
> >       >
> >       > Please don't look or work on any code in SVN because that is
> going
> > to
> >       > be removed, and I doubt it even compiles with the latest LLVM
> > release.
> >       > It's my fault because i haven't uploaded yet any of the work
> I've
> > done
> >       > out of trunk to SVN but i want to have something in shape
> before
> >       > commiting it, I think I will do it once conditional code is
> done.
> >       > Looking in SVN is misleading because it looks as the project
> is
> > dead,
> >       > but that is totally wrong because we're getting a lot done out
> of
> >       > there.
> >       >
> >       > About patches, I would say most of them are updated, I
> commited a
> >       > patch some weeks ago for the register allocator, but if you
> want
> > to
> >       > check them it's ok. Related to code, i think patches are the
> only
> >       > useful thing SVN has now, the backend code will go away.
> >       >
> >       > Since the LLVM backend code is not yet commited, I would
> suggest
> > as
> >       > John said working on regression tests, we're going to need
> this
> > soon,
> >       > and we're getting behind on this because we need a good test
> suite
> > to
> >       > catch as many errors as possible, so patches there are
> welcome.
> >       > Something similar to what the MSP430 backend has would be a
> decent
> >       > start. Tests related to arithmetic ops, function calls,
> testing
> > ABI,
> >       > and other things you can think of that dont require jumps.
> >       > Also on the other side, a lot of work is needed in Clang, we
> need
> > to
> >       > support many of the custom extensions AVR has like address
> spaces
> > or
> >       > interrupt handlers, so work is needed there aswell. We
> discussed
> > some
> >       > months ago about how to deal with address spaces but we didnt
> > reach to
> >       > any formal decisions, so if you want to work on that aswell
> you're
> >       > welcome. In fact, if you want to work both with tests and this
> > that
> >       > would be great :)
> >       >
> >       > Another thing, I've noticed that the new register allocator in
> 3.0
> >       > uses less stack memory than IAR or GCC so that is something
> > positive.
> >       > I see a lot of potential in getting better code than gcc in
> the
> >       > future, because with the current generated code which is not
> > optimized
> >       > at all (i want to leave that for a later stage) we're getting
> in
> > par
> >       > or improving what gcc does and sometimes getting a bit longer
> code
> > but
> >       > nothing that is too bad to worry. But once we introduce custom
> > patters
> >       > for instruction selection things will improve exponentially.
> >       >
> >       > If you want to ask any specific questions after this general
> > summary?
> >
> >       >
> ------------------------------------------------------------------
> > ------------
> >       > Write once. Port to many.
> >       > Get the SDK and tools to simplify cross-platform app
> development.
> > Create
> >       > new or port existing apps to sell to consumers worldwide.
> Explore
> > the
> >       > Intel AppUpSM program developer opportunity.
> > appdeveloper.intel.com/join
> >       > http://p.sf.net/sfu/intel-appdev
> >       > _______________________________________________ avr-llvm-devel
> > mailing list avr...@li...
> > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
> >
> >
> >
> >
>
>

Re: [avr-llvm-devel] Current Status?

[Weddington, E. <Eri...@at...>]

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...]
> Sent: Thursday, January 12, 2012 10:14 AM
> To: Weddington, Eric
> Cc: Sherard Dames; avr...@li...
> Subject: Re: [avr-llvm-devel] Current Status?
> 
> Eric I have one question, when passing function parameters through the
> stack, why does gcc allocate stack space doing the typical copy from
SP to
> a reg, decrement it for the needed amount and then copy it back to SP
and
> then use std instructions, instead of directly pushing the registers
> saving all the SP manipulation?
> Is there particular reason for not doing this?
> 

I can only speculate on why GCC does that, and that would be to probably
save on code space. It depends (or, at least, it *should* depend) on how
much data is being passed as parameters. It might be smaller to do:
1. copy SP to reg
2. decrement reg by needed amount
3. copy reg back to SP
than it would be to do multiple pushes.

But, again, I stress that I'm just speculating as to why it would be the
case.

For llvm, I would suggest that you do as you see fit, as long as it's
*correct* code, and then let's go back later to optimize it. If you
think it is easier to deal with doing all pushes, then go ahead and
implement it. Then we'll look at the code output.

Eric Weddington

Re: [avr-llvm-devel] Current Status?

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

For now I've implemented it the same way as gcc, but it's something that
popped to me when i was coding it.
I don't see how it saves space :) what I think is that you get the same
amount of pushes and std's when moving data into the stack no matter what
method is used. The difference I see is that when using std, you have to
adjust the SP pointer which creates an additional overhead. Just to clarify
I'm talking about the case when you want to pass function arguments before
a function call, not in a function prologue which is a different story.

In x86 it would be something like:

sub esp, 8
mov DWORD PTR [esp], reg1
mov DWORD PTR [esp+4], reg 2
call foo
...

instead of

push reg1
push reg2
call foo
...

which saves 1 instruction, but in our case doing "sub esp, 8" means adding
5 or 6 more instructions.

2012/1/12 Weddington, Eric <Eri...@at...>

>
> > -----Original Message-----
> > From: Borja Ferrer [mailto:bor...@gm...]
> > Sent: Thursday, January 12, 2012 10:14 AM
> > To: Weddington, Eric
> > Cc: Sherard Dames; avr...@li...
> > Subject: Re: [avr-llvm-devel] Current Status?
> >
> > Eric I have one question, when passing function parameters through the
> > stack, why does gcc allocate stack space doing the typical copy from
> SP to
> > a reg, decrement it for the needed amount and then copy it back to SP
> and
> > then use std instructions, instead of directly pushing the registers
> > saving all the SP manipulation?
> > Is there particular reason for not doing this?
> >
>
> I can only speculate on why GCC does that, and that would be to probably
> save on code space. It depends (or, at least, it *should* depend) on how
> much data is being passed as parameters. It might be smaller to do:
> 1. copy SP to reg
> 2. decrement reg by needed amount
> 3. copy reg back to SP
> than it would be to do multiple pushes.
>
> But, again, I stress that I'm just speculating as to why it would be the
> case.
>
> For llvm, I would suggest that you do as you see fit, as long as it's
> *correct* code, and then let's go back later to optimize it. If you
> think it is easier to deal with doing all pushes, then go ahead and
> implement it. Then we'll look at the code output.
>
> Eric Weddington
>

Re: [avr-llvm-devel] Current Status?

[Weddington, E. <Eri...@at...>]

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...]
> Sent: Thursday, January 12, 2012 1:25 PM
> To: Weddington, Eric
> Cc: Sherard Dames; avr...@li...
> Subject: Re: [avr-llvm-devel] Current Status?
> 
> For now I've implemented it the same way as gcc, but it's something
that
> popped to me when i was coding it.
> I don't see how it saves space :) what I think is that you get the
same
> amount of pushes and std's when moving data into the stack no matter
what
> method is used. The difference I see is that when using std, you have
to
> adjust the SP pointer which creates an additional overhead. Just to
> clarify I'm talking about the case when you want to pass function
> arguments before a function call, not in a function prologue which is
a
> different story.
> 
> In x86 it would be something like:
> 
> sub esp, 8
> mov DWORD PTR [esp], reg1
> mov DWORD PTR [esp+4], reg 2
> call foo
> ...
> 
> instead of
> 
> push reg1
> push reg2
> call foo
> ...
> 
> which saves 1 instruction, but in our case doing "sub esp, 8" means
adding
> 5 or 6 more instructions.
>

My x86 assembly is extremely rusty. ;-)

Maybe we should work with a real test case... Do you have something that
shows the issue?

Eric
 

Re: [avr-llvm-devel] Current Status?

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

Haha, well in avr asm it would be something like:

in    r30, 0x3d
in    r31, 0x3e
sbiw    r30, 0x08
in    r0, 0x3f
cli
out    0x3e, r30
out    0x3f, r0
out    0x3d, r31 <--- 8 instructions to allocate 8 bytes of stack space!
std Z+1, reg1 <-- move 8 regs into the stack
std Z+2, reg2
....
std Z+8, reg8
call foo

instead of:

push reg1
push reg2
...
push reg8
call foo

You still have 8 instructions to copy the data into the stack for both
cases, but in the 2nd you've saved 8 instructions that manipulate SP.
Does it make more sense now?

2012/1/12 Weddington, Eric <Eri...@at...>

>
>
> > -----Original Message-----
> > From: Borja Ferrer [mailto:bor...@gm...]
> > Sent: Thursday, January 12, 2012 1:25 PM
> > To: Weddington, Eric
> > Cc: Sherard Dames; avr...@li...
> > Subject: Re: [avr-llvm-devel] Current Status?
> >
> > For now I've implemented it the same way as gcc, but it's something
> that
> > popped to me when i was coding it.
> > I don't see how it saves space :) what I think is that you get the
> same
> > amount of pushes and std's when moving data into the stack no matter
> what
> > method is used. The difference I see is that when using std, you have
> to
> > adjust the SP pointer which creates an additional overhead. Just to
> > clarify I'm talking about the case when you want to pass function
> > arguments before a function call, not in a function prologue which is
> a
> > different story.
> >
> > In x86 it would be something like:
> >
> > sub esp, 8
> > mov DWORD PTR [esp], reg1
> > mov DWORD PTR [esp+4], reg 2
> > call foo
> > ...
> >
> > instead of
> >
> > push reg1
> > push reg2
> > call foo
> > ...
> >
> > which saves 1 instruction, but in our case doing "sub esp, 8" means
> adding
> > 5 or 6 more instructions.
> >
>
> My x86 assembly is extremely rusty. ;-)
>
> Maybe we should work with a real test case... Do you have something that
> shows the issue?
>
> Eric
>
>
>

Re: [avr-llvm-devel] Current Status?

[Weddington, E. <Eri...@at...>]

Well, then, I'm not sure what to tell you. I agree it seems stupid, if
the compiler generates it that way.

Another reason why I suggested a real test case is that way I can check
what different gcc versions are doing, and specifically what gcc trunk
is doing now. There's been a lot of new work going on with the avr port
in gcc. I'd like to be able to do some comparisons.

Eric

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...]
> Sent: Thursday, January 12, 2012 2:16 PM
> To: Weddington, Eric
> Cc: Sherard Dames; avr...@li...
> Subject: Re: [avr-llvm-devel] Current Status?
> 
> Haha, well in avr asm it would be something like:
> 
> in    r30, 0x3d
> in    r31, 0x3e
> sbiw    r30, 0x08
> in    r0, 0x3f
> cli
> out    0x3e, r30
> out    0x3f, r0
> out    0x3d, r31 <--- 8 instructions to allocate 8 bytes of stack
space!
> std Z+1, reg1 <-- move 8 regs into the stack
> std Z+2, reg2
> ....
> std Z+8, reg8
> call foo
> 
> instead of:
> 
> push reg1
> push reg2
> ...
> push reg8
> call foo
> 
> You still have 8 instructions to copy the data into the stack for both
> cases, but in the 2nd you've saved 8 instructions that manipulate SP.
> Does it make more sense now?
> 
> 
> 2012/1/12 Weddington, Eric <Eri...@at...>
> 
> 
> 
> 
> 	> -----Original Message-----
> 	> From: Borja Ferrer [mailto:bor...@gm...]
> 
> 	> Sent: Thursday, January 12, 2012 1:25 PM
> 	> To: Weddington, Eric
> 	> Cc: Sherard Dames; avr...@li...
> 	> Subject: Re: [avr-llvm-devel] Current Status?
> 	>
> 
> 	> For now I've implemented it the same way as gcc, but it's
> something
> 	that
> 	> popped to me when i was coding it.
> 	> I don't see how it saves space :) what I think is that you get
the
> 	same
> 	> amount of pushes and std's when moving data into the stack no
> matter
> 	what
> 	> method is used. The difference I see is that when using std,
you
> have
> 	to
> 	> adjust the SP pointer which creates an additional overhead.
Just
> to
> 	> clarify I'm talking about the case when you want to pass
function
> 	> arguments before a function call, not in a function prologue
which
> is
> 	a
> 	> different story.
> 	>
> 	> In x86 it would be something like:
> 	>
> 	> sub esp, 8
> 	> mov DWORD PTR [esp], reg1
> 	> mov DWORD PTR [esp+4], reg 2
> 	> call foo
> 	> ...
> 	>
> 	> instead of
> 	>
> 	> push reg1
> 	> push reg2
> 	> call foo
> 	> ...
> 	>
> 	> which saves 1 instruction, but in our case doing "sub esp, 8"
> means
> 	adding
> 	> 5 or 6 more instructions.
> 	>
> 
> 
> 	My x86 assembly is extremely rusty. ;-)
> 
> 	Maybe we should work with a real test case... Do you have
something
> that
> 	shows the issue?
> 
> 	Eric
> 
> 
> 
> 

Re: [avr-llvm-devel] Current Status?

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

Ahh I see, well any function call that needs 8 bytes passed through the
stack will do.

2012/1/12 Weddington, Eric <Eri...@at...>

>
> Well, then, I'm not sure what to tell you. I agree it seems stupid, if
> the compiler generates it that way.
>
> Another reason why I suggested a real test case is that way I can check
> what different gcc versions are doing, and specifically what gcc trunk
> is doing now. There's been a lot of new work going on with the avr port
> in gcc. I'd like to be able to do some comparisons.
>
> Eric
>
> > -----Original Message-----
> > From: Borja Ferrer [mailto:bor...@gm...]
> > Sent: Thursday, January 12, 2012 2:16 PM
> > To: Weddington, Eric
> > Cc: Sherard Dames; avr...@li...
> > Subject: Re: [avr-llvm-devel] Current Status?
> >
> > Haha, well in avr asm it would be something like:
> >
> > in    r30, 0x3d
> > in    r31, 0x3e
> > sbiw    r30, 0x08
> > in    r0, 0x3f
> > cli
> > out    0x3e, r30
> > out    0x3f, r0
> > out    0x3d, r31 <--- 8 instructions to allocate 8 bytes of stack
> space!
> > std Z+1, reg1 <-- move 8 regs into the stack
> > std Z+2, reg2
> > ....
> > std Z+8, reg8
> > call foo
> >
> > instead of:
> >
> > push reg1
> > push reg2
> > ...
> > push reg8
> > call foo
> >
> > You still have 8 instructions to copy the data into the stack for both
> > cases, but in the 2nd you've saved 8 instructions that manipulate SP.
> > Does it make more sense now?
> >
> >
> > 2012/1/12 Weddington, Eric <Eri...@at...>
> >
> >
> >
> >
> >       > -----Original Message-----
> >       > From: Borja Ferrer [mailto:bor...@gm...]
> >
> >       > Sent: Thursday, January 12, 2012 1:25 PM
> >       > To: Weddington, Eric
> >       > Cc: Sherard Dames; avr...@li...
> >       > Subject: Re: [avr-llvm-devel] Current Status?
> >       >
> >
> >       > For now I've implemented it the same way as gcc, but it's
> > something
> >       that
> >       > popped to me when i was coding it.
> >       > I don't see how it saves space :) what I think is that you get
> the
> >       same
> >       > amount of pushes and std's when moving data into the stack no
> > matter
> >       what
> >       > method is used. The difference I see is that when using std,
> you
> > have
> >       to
> >       > adjust the SP pointer which creates an additional overhead.
> Just
> > to
> >       > clarify I'm talking about the case when you want to pass
> function
> >       > arguments before a function call, not in a function prologue
> which
> > is
> >       a
> >       > different story.
> >       >
> >       > In x86 it would be something like:
> >       >
> >       > sub esp, 8
> >       > mov DWORD PTR [esp], reg1
> >       > mov DWORD PTR [esp+4], reg 2
> >       > call foo
> >       > ...
> >       >
> >       > instead of
> >       >
> >       > push reg1
> >       > push reg2
> >       > call foo
> >       > ...
> >       >
> >       > which saves 1 instruction, but in our case doing "sub esp, 8"
> > means
> >       adding
> >       > 5 or 6 more instructions.
> >       >
> >
> >
> >       My x86 assembly is extremely rusty. ;-)
> >
> >       Maybe we should work with a real test case... Do you have
> something
> > that
> >       shows the issue?
> >
> >       Eric
> >
> >
> >
> >
>
>

Re: [avr-llvm-devel] Current Status?

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

Eric one more thing, you mentioned that some work has been done lately in
gcc's backend, can you tell me what are the main features added and if
there are any code quality improvements.

2012/1/13 Borja Ferrer <bor...@gm...>

> Ahh I see, well any function call that needs 8 bytes passed through the
> stack will do.
>
> 2012/1/12 Weddington, Eric <Eri...@at...>
>
>
>> Well, then, I'm not sure what to tell you. I agree it seems stupid, if
>> the compiler generates it that way.
>>
>> Another reason why I suggested a real test case is that way I can check
>> what different gcc versions are doing, and specifically what gcc trunk
>> is doing now. There's been a lot of new work going on with the avr port
>> in gcc. I'd like to be able to do some comparisons.
>>
>> Eric
>>
>> > -----Original Message-----
>> > From: Borja Ferrer [mailto:bor...@gm...]
>> > Sent: Thursday, January 12, 2012 2:16 PM
>> > To: Weddington, Eric
>> > Cc: Sherard Dames; avr...@li...
>> > Subject: Re: [avr-llvm-devel] Current Status?
>> >
>> > Haha, well in avr asm it would be something like:
>> >
>> > in    r30, 0x3d
>> > in    r31, 0x3e
>> > sbiw    r30, 0x08
>> > in    r0, 0x3f
>> > cli
>> > out    0x3e, r30
>> > out    0x3f, r0
>> > out    0x3d, r31 <--- 8 instructions to allocate 8 bytes of stack
>> space!
>> > std Z+1, reg1 <-- move 8 regs into the stack
>> > std Z+2, reg2
>> > ....
>> > std Z+8, reg8
>> > call foo
>> >
>> > instead of:
>> >
>> > push reg1
>> > push reg2
>> > ...
>> > push reg8
>> > call foo
>> >
>> > You still have 8 instructions to copy the data into the stack for both
>> > cases, but in the 2nd you've saved 8 instructions that manipulate SP.
>> > Does it make more sense now?
>> >
>> >
>> > 2012/1/12 Weddington, Eric <Eri...@at...>
>> >
>> >
>> >
>> >
>> >       > -----Original Message-----
>> >       > From: Borja Ferrer [mailto:bor...@gm...]
>> >
>> >       > Sent: Thursday, January 12, 2012 1:25 PM
>> >       > To: Weddington, Eric
>> >       > Cc: Sherard Dames; avr...@li...
>> >       > Subject: Re: [avr-llvm-devel] Current Status?
>> >       >
>> >
>> >       > For now I've implemented it the same way as gcc, but it's
>> > something
>> >       that
>> >       > popped to me when i was coding it.
>> >       > I don't see how it saves space :) what I think is that you get
>> the
>> >       same
>> >       > amount of pushes and std's when moving data into the stack no
>> > matter
>> >       what
>> >       > method is used. The difference I see is that when using std,
>> you
>> > have
>> >       to
>> >       > adjust the SP pointer which creates an additional overhead.
>> Just
>> > to
>> >       > clarify I'm talking about the case when you want to pass
>> function
>> >       > arguments before a function call, not in a function prologue
>> which
>> > is
>> >       a
>> >       > different story.
>> >       >
>> >       > In x86 it would be something like:
>> >       >
>> >       > sub esp, 8
>> >       > mov DWORD PTR [esp], reg1
>> >       > mov DWORD PTR [esp+4], reg 2
>> >       > call foo
>> >       > ...
>> >       >
>> >       > instead of
>> >       >
>> >       > push reg1
>> >       > push reg2
>> >       > call foo
>> >       > ...
>> >       >
>> >       > which saves 1 instruction, but in our case doing "sub esp, 8"
>> > means
>> >       adding
>> >       > 5 or 6 more instructions.
>> >       >
>> >
>> >
>> >       My x86 assembly is extremely rusty. ;-)
>> >
>> >       Maybe we should work with a real test case... Do you have
>> something
>> > that
>> >       shows the issue?
>> >
>> >       Eric
>> >
>> >
>> >
>> >
>>
>>
>

Re: [avr-llvm-devel] Current Status?

[Weddington, E. <Eri...@at...>]

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...]
> Sent: Friday, January 13, 2012 9:19 AM
> To: Weddington, Eric
> Cc: Sherard Dames; avr...@li...
> Subject: Re: [avr-llvm-devel] Current Status?
> 
> Eric one more thing, you mentioned that some work has been done lately
in
> gcc's backend, can you tell me what are the main features added and if
> there are any code quality improvements.

Umpf. There's been so much happening, I'm not sure if I can remember it
all

- Improvements in the AVR backend, especially a number of missed
optimization bugs fixed

- The beginning of a Multiple Address Spaces feature

- The beginning of 24-bit types, mainly used for Multiple Address Spaces
(i.e. large code space, or large data space)

- Some work done on 64-bit double types

And other fixed bugs.

Eric

Re: [avr-llvm-devel] Current Status?

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

Ahh ok thanks for the info Eric, about the work on doubles, what sort of
support is it? shouldn't that go into write the math functions in the C
library? or do you mean removing the constraint of making double a float?
Is there a place on how the multiple address space feature will work, we
should implement this aswell in an early stage so it's important that we
see how it works to be compatible with what gcc does.

2012/1/16 Weddington, Eric <Eri...@at...>

>
>
>
> > -----Original Message-----
> > From: Borja Ferrer [mailto:bor...@gm...]
> > Sent: Friday, January 13, 2012 9:19 AM
> > To: Weddington, Eric
> > Cc: Sherard Dames; avr...@li...
> > Subject: Re: [avr-llvm-devel] Current Status?
> >
> > Eric one more thing, you mentioned that some work has been done lately
> in
> > gcc's backend, can you tell me what are the main features added and if
> > there are any code quality improvements.
>
> Umpf. There's been so much happening, I'm not sure if I can remember it
> all
>
> - Improvements in the AVR backend, especially a number of missed
> optimization bugs fixed
>
> - The beginning of a Multiple Address Spaces feature
>
> - The beginning of 24-bit types, mainly used for Multiple Address Spaces
> (i.e. large code space, or large data space)
>
> - Some work done on 64-bit double types
>
> And other fixed bugs.
>
> Eric
>

Re: [avr-llvm-devel] Current Status?

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

Update: I've already started working on conditional branches and compares.
Eric ping?

2012/1/20 Borja Ferrer <bor...@gm...>

> Ahh ok thanks for the info Eric, about the work on doubles, what sort of
> support is it? shouldn't that go into write the math functions in the C
> library? or do you mean removing the constraint of making double a float?
> Is there a place on how the multiple address space feature will work, we
> should implement this aswell in an early stage so it's important that we
> see how it works to be compatible with what gcc does.
>
> 2012/1/16 Weddington, Eric <Eri...@at...>
>
>
>>
>>
>> > -----Original Message-----
>> > From: Borja Ferrer [mailto:bor...@gm...]
>> > Sent: Friday, January 13, 2012 9:19 AM
>> > To: Weddington, Eric
>> > Cc: Sherard Dames; avr...@li...
>> > Subject: Re: [avr-llvm-devel] Current Status?
>> >
>> > Eric one more thing, you mentioned that some work has been done lately
>> in
>> > gcc's backend, can you tell me what are the main features added and if
>> > there are any code quality improvements.
>>
>> Umpf. There's been so much happening, I'm not sure if I can remember it
>> all
>>
>> - Improvements in the AVR backend, especially a number of missed
>> optimization bugs fixed
>>
>> - The beginning of a Multiple Address Spaces feature
>>
>> - The beginning of 24-bit types, mainly used for Multiple Address Spaces
>> (i.e. large code space, or large data space)
>>
>> - Some work done on 64-bit double types
>>
>> And other fixed bugs.
>>
>> Eric
>>
>
>

Re: [avr-llvm-devel] Current Status?

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

Ahh ok, I will take a look then.

Update: I've already implemented conditional branches for if() conditions
(BR_CC node). I still need to work on overriding some virtual functions in
some interfaces to improve the generated code. Then I will move to SETCC
and SELECT nodes which are used in things like: a = (b > c) and a = (b > c)
? 1 : 2 respectively.
I'm happy because we can now compile loops :)

2012/1/31 Weddington, Eric <Eri...@at...>

> Hi Borja,
>
> Thanks for the ping.
>
> Unfortunately the best place to see how address spaces work is still the
> GCC source code, and documentation :-(
>
> Eric
>
> > -----Original Message-----
> > From: Borja Ferrer [mailto:bor...@gm...]
> > Sent: Tuesday, January 31, 2012 7:08 AM
> > To: Weddington, Eric
> > Cc: Sherard Dames; avr...@li...
> > Subject: Re: [avr-llvm-devel] Current Status?
> >
> > Update: I've already started working on conditional branches and
> compares.
> > Eric ping?
> >
> >
> > 2012/1/20 Borja Ferrer <bor...@gm...>
> >
> >
> >       Ahh ok thanks for the info Eric, about the work on doubles, what
> sort of
> > support is it? shouldn't that go into write the math functions in the
> C
> > library? or do you mean removing the constraint of making double a
> float?
> >       Is there a place on how the multiple address space feature will
> work, we
> > should implement this aswell in an early stage so it's important that
> we see
> > how it works to be compatible with what gcc does.
> >
> >
> >       2012/1/16 Weddington, Eric <Eri...@at...>
> >
> >
> >
> >
> >
> >               > -----Original Message-----
> >               > From: Borja Ferrer [mailto:bor...@gm...]
> >
> >               > Sent: Friday, January 13, 2012 9:19 AM
> >               > To: Weddington, Eric
> >               > Cc: Sherard Dames;
> avr...@li...
> >               > Subject: Re: [avr-llvm-devel] Current Status?
> >               >
> >
> >               > Eric one more thing, you mentioned that some work has
> been done
> > lately
> >               in
> >               > gcc's backend, can you tell me what are the main
> features added
> > and if
> >               > there are any code quality improvements.
> >
> >
> >               Umpf. There's been so much happening, I'm not sure if I
> can
> > remember it
> >               all
> >
> >               - Improvements in the AVR backend, especially a number
> of missed
> >               optimization bugs fixed
> >
> >               - The beginning of a Multiple Address Spaces feature
> >
> >               - The beginning of 24-bit types, mainly used for
> Multiple Address
> > Spaces
> >               (i.e. large code space, or large data space)
> >
> >               - Some work done on 64-bit double types
> >
> >               And other fixed bugs.
> >
> >               Eric
> >
> >
> >
>
>

Re: [avr-llvm-devel] Current Status?

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

Not yet but, I've just finished implementing basic support for branching
and selects. So, before commiting I'm going to update my code to compile
with latest llvm's trunk and then i will finally upload the code. Btw, is
anybody here that is going to compile the code in windows? If yes, I will
update the cmakelist files.

2012/2/3 Weddington, Eric <Eri...@at...>

> Hi Borja,
>
> Do you have any of your work committed yet? There are other people
> interested in helping, but we need to have the latest in the repo...
>
> Eric
>
> > -----Original Message-----
> > From: Borja Ferrer [mailto:bor...@gm...]
> > Sent: Friday, February 03, 2012 9:10 AM
> > To: Weddington, Eric
> > Cc: Sherard Dames; avr...@li...
> > Subject: Re: [avr-llvm-devel] Current Status?
> >
> > Ahh ok, I will take a look then.
> >
> > Update: I've already implemented conditional branches for if()
> conditions
> > (BR_CC node). I still need to work on overriding some virtual
> functions in
> > some interfaces to improve the generated code. Then I will move to
> SETCC and
> > SELECT nodes which are used in things like: a = (b > c) and a = (b >
> c) ? 1 :
> > 2 respectively.
> > I'm happy because we can now compile loops :)
> >
> >
> > 2012/1/31 Weddington, Eric <Eri...@at...>
> >
> >
> >       Hi Borja,
> >
> >       Thanks for the ping.
> >
> >       Unfortunately the best place to see how address spaces work is
> still the
> >       GCC source code, and documentation :-(
> >
> >       Eric
> >
> >
> >       > -----Original Message-----
> >       > From: Borja Ferrer [mailto:bor...@gm...]
> >
> >       > Sent: Tuesday, January 31, 2012 7:08 AM
> >       > To: Weddington, Eric
> >       > Cc: Sherard Dames; avr...@li...
> >       > Subject: Re: [avr-llvm-devel] Current Status?
> >       >
> >       > Update: I've already started working on conditional branches
> and
> >       compares.
> >       > Eric ping?
> >       >
> >       >
> >       > 2012/1/20 Borja Ferrer <bor...@gm...>
> >       >
> >       >
> >       >       Ahh ok thanks for the info Eric, about the work on
> doubles, what
> >       sort of
> >       > support is it? shouldn't that go into write the math functions
> in the
> >       C
> >       > library? or do you mean removing the constraint of making
> double a
> >       float?
> >       >       Is there a place on how the multiple address space
> feature will
> >       work, we
> >       > should implement this aswell in an early stage so it's
> important that
> >       we see
> >       > how it works to be compatible with what gcc does.
> >       >
> >       >
> >       >       2012/1/16 Weddington, Eric <Eri...@at...>
> >       >
> >       >
> >       >
> >       >
> >       >
> >       >               > -----Original Message-----
> >       >               > From: Borja Ferrer
> [mailto:bor...@gm...]
> >       >
> >       >               > Sent: Friday, January 13, 2012 9:19 AM
> >       >               > To: Weddington, Eric
> >       >               > Cc: Sherard Dames;
> >       avr...@li...
> >       >               > Subject: Re: [avr-llvm-devel] Current Status?
> >       >               >
> >       >
> >       >               > Eric one more thing, you mentioned that some
> work has
> >       been done
> >       > lately
> >       >               in
> >       >               > gcc's backend, can you tell me what are the
> main
> >       features added
> >       > and if
> >       >               > there are any code quality improvements.
> >       >
> >       >
> >       >               Umpf. There's been so much happening, I'm not
> sure if I
> >       can
> >       > remember it
> >       >               all
> >       >
> >       >               - Improvements in the AVR backend, especially a
> number
> >       of missed
> >       >               optimization bugs fixed
> >       >
> >       >               - The beginning of a Multiple Address Spaces
> feature
> >       >
> >       >               - The beginning of 24-bit types, mainly used for
> >       Multiple Address
> >       > Spaces
> >       >               (i.e. large code space, or large data space)
> >       >
> >       >               - Some work done on 64-bit double types
> >       >
> >       >               And other fixed bugs.
> >       >
> >       >               Eric
> >       >
> >       >
> >       >
> >
> >
> >
>
>

Re: [avr-llvm-devel] Current Status?

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

Eric, one question. I vaguely remember that when reading or writing (i
can't remember if both) a 16 bit variable from RAM there was a certain
order, MSByte first then LSByte or the other way round. Can you clarify
this information for me and where is this specified and for which memory
space this happens.

2012/3/5 Borja Ferrer <bor...@gm...>

> Ah John one more thing, you may want to combine SelectionDAGBuilder.diff<http://avr-llvm.svn.sourceforge.net/viewvc/avr-llvm/llvm/trunk/patches/SelectionDAGBuilder.diff?sortby=date&view=log>and
> TargetCallingConv.diff<http://avr-llvm.svn.sourceforge.net/viewvc/avr-llvm/llvm/trunk/patches/TargetCallingConv.diff?sortby=date&view=log>into one file since they both are used for the same purpose, you can name
> the patch SplitArgPiece
>
>
> 2012/3/5 Borja Ferrer <bor...@gm...>
>
>> For now, spload should be the only pseudo that is allowed to get into
>> assembly, if you see any other pseudo it is a bug. Expanding spload into
>> real instructions requires a bit of work that is currently unimplemented,
>> so for now we'll have to live with it. I hope it's not a big deal for you.
>>
>> About the patches, it's a good idea what you said, feel free to do it
>> when you have time. I still have to add some more patches about interrupts.
>>
>>
>> 2012/3/5 John Myers <ato...@gm...>
>>
>>> On Sun, Mar 4, 2012 at 1:33 PM, Borja Ferrer <bor...@gm...>wrote:
>>>
>>>> John check the lastest patch files I've just commited to see if they
>>>> patch correctly or i've messed them.
>>>> Btw, have you been able to try the backend?
>>>>
>>>
>>> They all apply cleanly but you have to hunt around to find which
>>> directory to start in for each file. I'm going to combine them into one
>>> patch that can be applied from the root directory.
>>>
>>>
>>> I haven't really looked at the backend yet . I did notice that there was
>>> a pseudo instruction (spload) that made it into the assembly file which
>>> stopped avr-gcc from being able to assemble it though.
>>>
>>> main:
>>>     push    r28
>>>     push    r29
>>>     spload    r29:r28, SP
>>>     sbiw    r29:r28, 2
>>>     ldi    r24, 0
>>>     ldi    r25, 0
>>>     std    Y+1, r24
>>>     std    Y+2, r25
>>>     spload    r29:r28, SP
>>>     adiw    r29:r28, 2
>>>     pop    r29
>>>     pop    r28
>>>     ret
>>>
>>>
>>
>

Re: [avr-llvm-devel] Current Status?

[Weddington, E. <Eri...@at...>]

Hi Borja,

Thanks for the ping.

Unfortunately the best place to see how address spaces work is still the
GCC source code, and documentation :-(

Eric

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...]
> Sent: Tuesday, January 31, 2012 7:08 AM
> To: Weddington, Eric
> Cc: Sherard Dames; avr...@li...
> Subject: Re: [avr-llvm-devel] Current Status?
> 
> Update: I've already started working on conditional branches and
compares.
> Eric ping?
> 
> 
> 2012/1/20 Borja Ferrer <bor...@gm...>
> 
> 
> 	Ahh ok thanks for the info Eric, about the work on doubles, what
sort of
> support is it? shouldn't that go into write the math functions in the
C
> library? or do you mean removing the constraint of making double a
float?
> 	Is there a place on how the multiple address space feature will
work, we
> should implement this aswell in an early stage so it's important that
we see
> how it works to be compatible with what gcc does.
> 
> 
> 	2012/1/16 Weddington, Eric <Eri...@at...>
> 
> 
> 
> 
> 
> 		> -----Original Message-----
> 		> From: Borja Ferrer [mailto:bor...@gm...]
> 
> 		> Sent: Friday, January 13, 2012 9:19 AM
> 		> To: Weddington, Eric
> 		> Cc: Sherard Dames;
avr...@li...
> 		> Subject: Re: [avr-llvm-devel] Current Status?
> 		>
> 
> 		> Eric one more thing, you mentioned that some work has
been done
> lately
> 		in
> 		> gcc's backend, can you tell me what are the main
features added
> and if
> 		> there are any code quality improvements.
> 
> 
> 		Umpf. There's been so much happening, I'm not sure if I
can
> remember it
> 		all
> 
> 		- Improvements in the AVR backend, especially a number
of missed
> 		optimization bugs fixed
> 
> 		- The beginning of a Multiple Address Spaces feature
> 
> 		- The beginning of 24-bit types, mainly used for
Multiple Address
> Spaces
> 		(i.e. large code space, or large data space)
> 
> 		- Some work done on 64-bit double types
> 
> 		And other fixed bugs.
> 
> 		Eric
> 
> 
> 

Re: [avr-llvm-devel] Current Status?

[Weddington, E. <Eri...@at...>]

Hi Borja,

Do you have any of your work committed yet? There are other people
interested in helping, but we need to have the latest in the repo...

Eric

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...]
> Sent: Friday, February 03, 2012 9:10 AM
> To: Weddington, Eric
> Cc: Sherard Dames; avr...@li...
> Subject: Re: [avr-llvm-devel] Current Status?
> 
> Ahh ok, I will take a look then.
> 
> Update: I've already implemented conditional branches for if()
conditions
> (BR_CC node). I still need to work on overriding some virtual
functions in
> some interfaces to improve the generated code. Then I will move to
SETCC and
> SELECT nodes which are used in things like: a = (b > c) and a = (b >
c) ? 1 :
> 2 respectively.
> I'm happy because we can now compile loops :)
> 
> 
> 2012/1/31 Weddington, Eric <Eri...@at...>
> 
> 
> 	Hi Borja,
> 
> 	Thanks for the ping.
> 
> 	Unfortunately the best place to see how address spaces work is
still the
> 	GCC source code, and documentation :-(
> 
> 	Eric
> 
> 
> 	> -----Original Message-----
> 	> From: Borja Ferrer [mailto:bor...@gm...]
> 
> 	> Sent: Tuesday, January 31, 2012 7:08 AM
> 	> To: Weddington, Eric
> 	> Cc: Sherard Dames; avr...@li...
> 	> Subject: Re: [avr-llvm-devel] Current Status?
> 	>
> 	> Update: I've already started working on conditional branches
and
> 	compares.
> 	> Eric ping?
> 	>
> 	>
> 	> 2012/1/20 Borja Ferrer <bor...@gm...>
> 	>
> 	>
> 	>       Ahh ok thanks for the info Eric, about the work on
doubles, what
> 	sort of
> 	> support is it? shouldn't that go into write the math functions
in the
> 	C
> 	> library? or do you mean removing the constraint of making
double a
> 	float?
> 	>       Is there a place on how the multiple address space
feature will
> 	work, we
> 	> should implement this aswell in an early stage so it's
important that
> 	we see
> 	> how it works to be compatible with what gcc does.
> 	>
> 	>
> 	>       2012/1/16 Weddington, Eric <Eri...@at...>
> 	>
> 	>
> 	>
> 	>
> 	>
> 	>               > -----Original Message-----
> 	>               > From: Borja Ferrer
[mailto:bor...@gm...]
> 	>
> 	>               > Sent: Friday, January 13, 2012 9:19 AM
> 	>               > To: Weddington, Eric
> 	>               > Cc: Sherard Dames;
> 	avr...@li...
> 	>               > Subject: Re: [avr-llvm-devel] Current Status?
> 	>               >
> 	>
> 	>               > Eric one more thing, you mentioned that some
work has
> 	been done
> 	> lately
> 	>               in
> 	>               > gcc's backend, can you tell me what are the
main
> 	features added
> 	> and if
> 	>               > there are any code quality improvements.
> 	>
> 	>
> 	>               Umpf. There's been so much happening, I'm not
sure if I
> 	can
> 	> remember it
> 	>               all
> 	>
> 	>               - Improvements in the AVR backend, especially a
number
> 	of missed
> 	>               optimization bugs fixed
> 	>
> 	>               - The beginning of a Multiple Address Spaces
feature
> 	>
> 	>               - The beginning of 24-bit types, mainly used for
> 	Multiple Address
> 	> Spaces
> 	>               (i.e. large code space, or large data space)
> 	>
> 	>               - Some work done on 64-bit double types
> 	>
> 	>               And other fixed bugs.
> 	>
> 	>               Eric
> 	>
> 	>
> 	>
> 
> 
> 

Re: [avr-llvm-devel] Current Status?

[Weddington, E. <Eri...@at...>]

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...]
> Sent: Saturday, February 11, 2012 2:19 PM
> To: Weddington, Eric
> Cc: Sherard Dames; avr...@li...
> Subject: Re: [avr-llvm-devel] Current Status?
> 
> Not yet but, I've just finished implementing basic support for
branching and
> selects. So, before commiting I'm going to update my code to compile
with
> latest llvm's trunk and then i will finally upload the code. Btw, is
anybody
> here that is going to compile the code in windows? If yes, I will
update the
> cmakelist files.

I'm definitely interested in having avr-llvm run on windows.

Re: [avr-llvm-devel] Current Status?

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

Ok then, I'll update all cmakelist files.

2012/2/13 Weddington, Eric <Eri...@at...>

>
>
> > -----Original Message-----
> > From: Borja Ferrer [mailto:bor...@gm...]
> > Sent: Saturday, February 11, 2012 2:19 PM
> > To: Weddington, Eric
> > Cc: Sherard Dames; avr...@li...
> > Subject: Re: [avr-llvm-devel] Current Status?
> >
> > Not yet but, I've just finished implementing basic support for
> branching and
> > selects. So, before commiting I'm going to update my code to compile
> with
> > latest llvm's trunk and then i will finally upload the code. Btw, is
> anybody
> > here that is going to compile the code in windows? If yes, I will
> update the
> > cmakelist files.
>
> I'm definitely interested in having avr-llvm run on windows.
>

Re: [avr-llvm-devel] Current Status?

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

I've just committed the new backend code to SVN. Please let me know any
thoughts about it.

2012/2/13 Borja Ferrer <bor...@gm...>

> Ok then, I'll update all cmakelist files.
>
> 2012/2/13 Weddington, Eric <Eri...@at...>
>
>
>>
>> > -----Original Message-----
>> > From: Borja Ferrer [mailto:bor...@gm...]
>> > Sent: Saturday, February 11, 2012 2:19 PM
>> > To: Weddington, Eric
>> > Cc: Sherard Dames; avr...@li...
>> > Subject: Re: [avr-llvm-devel] Current Status?
>> >
>> > Not yet but, I've just finished implementing basic support for
>> branching and
>> > selects. So, before commiting I'm going to update my code to compile
>> with
>> > latest llvm's trunk and then i will finally upload the code. Btw, is
>> anybody
>> > here that is going to compile the code in windows? If yes, I will
>> update the
>> > cmakelist files.
>>
>> I'm definitely interested in having avr-llvm run on windows.
>>
>
>

Re: [avr-llvm-devel] Current Status?

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

No comments yet?

2012/2/18 Borja Ferrer <bor...@gm...>

> I've just committed the new backend code to SVN. Please let me know any
> thoughts about it.
>
>
> 2012/2/13 Borja Ferrer <bor...@gm...>
>
>> Ok then, I'll update all cmakelist files.
>>
>> 2012/2/13 Weddington, Eric <Eri...@at...>
>>
>>
>>>
>>> > -----Original Message-----
>>> > From: Borja Ferrer [mailto:bor...@gm...]
>>> > Sent: Saturday, February 11, 2012 2:19 PM
>>> > To: Weddington, Eric
>>> > Cc: Sherard Dames; avr...@li...
>>> > Subject: Re: [avr-llvm-devel] Current Status?
>>> >
>>> > Not yet but, I've just finished implementing basic support for
>>> branching and
>>> > selects. So, before commiting I'm going to update my code to compile
>>> with
>>> > latest llvm's trunk and then i will finally upload the code. Btw, is
>>> anybody
>>> > here that is going to compile the code in windows? If yes, I will
>>> update the
>>> > cmakelist files.
>>>
>>> I'm definitely interested in having avr-llvm run on windows.
>>>
>>
>>
>