Re: [avr-llvm-devel] Status update

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

Wow! Thanks for the update! :-)

I like what I'm hearing so far. The cons don't sound all that bad, considering the pros that you mentioned. It sounds to me that you're on the right track, but I'll be interested in what others have to say, too.

My only caution comes from what you said about using movw always: There are avr chip variants that don't have a movw instruction. For that matter there are different instruction set variants that are dependent on the avr device type. AVR GCC sort-of handles this by organizing the list of chips into arbitrary "architectures", which are then associated with memory ranges and loosely based instruction sets. However, there always seems to be some exceptions to the rule.

So my only advice to you is to keep this in mind and that we'll need to have some sort of mechanism to tie the avr device type with enabling/disabling specific instructions. I don't really care if we use a similar mechanism as AVR GCC with these arbitrary architectures. However, I would be fine too if we dropped the "architectures", because these are arbitrary and there are exceptions and sometimes they're more of a maintenance headache than it's worth. (As a side note, this is one area where I hope to help out in, though I still have quite a learning curve.)

With this, also keep in mind that there is a relatively new AVR sub-family, based on the newly released ATtiny10 (all variants: ATtiny10/4/5/9/20/40). This is a weird family:
- The register file is cut in half. It only has R16-R31, however R0-R15 still exist, they just map to the upper half of the register file.
- Reduced instruction set. There are a number of disabled instructions (have to see datasheets for full list).
- Really small amounts of flash (code), and even smaller amounts of RAM (data).
Yet, with all of these limitations, there is still a desire to have a C compiler for these devices. The latest "AVR Toolchain" release from Atmel has support for these devices.

Thanks again, Borja, for your work on this! I'm really excited to see your work committed! :-)

Eric Weddington

> -----Original Message-----
> From: Borja Ferrer [mailto:bor...@gm...]
> Sent: Tuesday, April 05, 2011 3:31 PM
> To: avr...@li...
> Subject: [avr-llvm-devel] Status update
> 
> Hello, it's been a little while since last time we got an update. Although
> I haven't commited any code during the last 3 months, I want to say that
> doesn't mean the project is dead or something similar, it's just the
> opposite that's why i want to explain what is the current status, in fact
> i havent stopped working on this at all.
> 
> From Jan to approximately March I've been investigating different ways to
> handle the insane reg constraints to pair adjacent regs to store 16bit and
> wider data with the PBQP allocator and other ideas i had, I think i had
> like 4 branches to see which one was the best. From here I want to give a
> big thank to Lang Hames, the author of this allocator for all the help he
> gave me and for his interest. But solving this using this approach was
> getting pretty hard, tracking which virtual reg had the low and hi part of
> a 16bit value is simply impossible in LLVM with the current interfaces in
> order to build the constraint matrix for the PBPQ allocator, in addition,
> there were other underlying problems when working with only 8bit types as
> a legal sizes, like 16 bit pointers.
> 
> So around mid March I started a new backend from scratch with a new idea
> which has simplified everything in a huge manner. Like everything in this
> life, all things have pros and cons so we have to get a balance. The
> biggest pro of this approach is it's simplicity, the cons is that we'll
> have to work a bit harder to get some nice optimizations in. But these
> cons aren't too bad at all, because most of them would have to be handled
> in all aproaches so after all, we will have to get our hands dirty to get
> really nice code.
> The basic idea is to make 16bit data legal, that means working with pseudo
> register pairs and psuedo 16 bit instructions that need to get expanded
> into 8 bit instructions in a later stage. When we get a movw or adiw/sbiw
> we leave them alone because they're legal instructions but when we get say
> a 16bit and instr we have to expand it to two and instructions. As i said,
> when we move further we can start thinking in introducing optimizations
> over pseudo intrs which is something that gcc doesn't do very well, and
> after all we want to beat it.
> 
> So the current status is:
> - Added support for all arithmetic and binary instructions for all data
> types, except mul. Including, INC/DEC, COM/NEG and SWAP.
> - Convert all (add x, imm) into sub(x, -imm) since we dont have an add
> with imm instruction. This saves doing ldi+add into a subi.
> - Handle adiw/sbiw instructions when it's beneficial.
> - Allocate everything in register pairs, as it should be, and emit movw
> always, no need for more heuristics.
> - Implemented calling conventions, including argument passing, return
> values, and function calls, including externals symbols which isn't
> handled in the current backend in SVN.
> - Pointers are now 16bits as it should be, and not 8bits as a hack.
> - Added support for ICALL.
> - BIG ONE: Added support for data memory operatons, this includes: ld,
> ldd, st and std. This adds support for the reg+imm addressing mode when
> imm<64.
> - Print for ld, ldd, st and std when emmiting asm code the X, Y, Z names.
> 
> I think this is it for the moment, probably i've left something out, but
> those are the basic points. I'm currently working in adding support for
> lds and sts, so we can load/store global symbols. And after that is
> implemented we'll be able to implement stack frames, which is an important
> milestone.
> I'll commit the new code in a few days, i want to get something done
> before. Let me know your thoughts. For me the most important part is to
> remark that we're moving further.
> 
> PS: John do you get clang rebuilt each time you recompile LLVM, if that's
> the case do you know a way to stop this because linking it takes like
> 40secs here. Im using ccache as mentioned in some doc file.