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