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