Re: [avr-libc-dev] 1.8.1?

[Weddington, Eric]

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On
> Behalf Of Erik Walthinsen
> Sent: Friday, November 30, 2012 9:38 AM
> To: address@hidden
> Subject: Re: [avr-libc-dev] 1.8.1?
> 
> On 11/29/2012 11:20 PM, Joerg Wunsch wrote:
> > Still, if it's not the IDE that does it on their behalf, most of those
> > professional ARM developers are hosed.  They solely rely on their
> > (often payware, like CodeSourcery) IDE to do it for them.  If the IDE
> > doesn't do it, they are standing in about the same rain as an AVR
> > developer whose device is not supported by the toolchain.
> 
> I've looked at using a number of ARM chips (stm32, Freescale MC13224,
> and others) and constantly run into that problem.  I will not use an IDE
> let alone a manufacturer's IDE, so I have to try to figure out all the
> arcana for that chip and hope I can get it working in one of the 17
> "generic" Cortex toolchains, or roll my own.  It's insane, especially
> when the manuf seems to provide multiple incompatible sets of files.

Good feedback!

 
> > The AVR approach is somewhat more user-friendly, in that you can add
> > a single -mmcu option, and then compile your sources the same simple
> > way as you would e.g. be able to compile code for your host computer.
> 
> I gave a talk at DEFCON this last year about MC13224-based 6LowPAN
> hardware we're trying to get moving, 

Cool! Do you have any public links to your talk?

> and while I doubt most of the
> audience understood exactly what I was talking about here, the "-mmcu"
> function of the avr toolchain is *by far* the best lead AVR has on ARM
> at this point, for that exact reason.
 
I know that ARM GCC has a similar switch. IIRC, it only selects the core.


> > However, that's not the way the GNU tools would currently work.  And
> > no, the GCC specs file wasn't really an alternative: first, it would
> > not work for binutils anyway.  Then, it's got an incomprehensible
> > syntax (even for seasoned developers), and changes were needed in many
> > places to add a single device.  In order to be really able to offload
> > new device support to the end user, it has to be a one-liner (or
> > perhaps, a one-record addition, like to an XML file), and it must be
> > possible to do this at run-time, without recompilation.
> 
> Honestly I've got to wonder if LLVM does this any better.  I know
> basically nothing about it except that it's not quite up to GCC's
> standards yet, but it might have potential and be more properly layered.

In terms of the code, yes it is, I think, better layered. But that's mainly 
because GCC is quite a mess. I'm not sure if LLVM necessarily solves the 
problem any better.

FYI, there's an open source project that adds the AVR backend to LLVM. It's 
currently on SourceForge (name: avr-llvm).
 
> In the meantime I've built a python script that very carefully goes into
> all the files in gcc, binutils, and avr-libc that have references to the
> Xmega parts, and pulls from a master list I derived from Digikey to
> rewrite all those sections.  It's a very poor substitute and doesn't
> scale to any of the other chips, but it should get the Xmega patch put
> together with the least possible inconsistency...
> 
> > For avr-libc, this would be even harder though, as some of the device
> > support is really compiled in right now.  But I think if the other
> > tools agreed on such a central device definition file, we could start
> > an effort to generalize avr-libc as well (perhaps accompanied by a
> > script that recreates some of the device-dependant header files from a
> > template file, based on those device definitions).
> 
> I think extending AVR-style -mmcu into the ARM world is absolutely
> possible, *iff* there is a shift in how devices are described as you
> suggest.  Short of entirely new instruction sets, it should be possible
> to *trivially* define a new processor in the same style as avrdude does
> currently, and have *all* the tools reference it at run-time.  The only
> thing the toolchain should need a recompile for is new family opcodes,
> or updated optimizations.
> 
> Would it be even remotely practical to do this within the existing
> binutils/gcc/avr-libc setup?  It seems to me that if there were a way of
> removing the individual devices from the entire binutils/gcc codebase in
> favor of *nothing* but the "families" (avr5, avr6, atxmega5, etc.) and
> rewrite the -mmcu handling so it looks at a directory containing the
> relevant config, crt, linker, and even header files for each chip and
> hands them off internally (and to binutils) as appropriate.
> 
> Basically it would be a thin *top*-level wrapper (inside gcc getopts)
> around what Johann suggests that people do now (which I've done *once*
> in coercing gcc to compile to the attiny15), rather than having the
> -mmcu decisions made all the way down the stack.
> 
> Unfortunately as I've said before, I know *very* little about the
> structure of either binutils or gcc, having only been exposed to the
> tiny bits that I'm messing with now.

Guys, the main point of this thread is to get avr-libc 1.8.1 out the door. I'll 
I was asking for was help with the avr-libc bug list.

I understand the desire to reorganize the world to make it sane. I'd like that, 
too. Yes, it's a big task. If anyone is really serious about doing that, then 
let's put a plan together that can actually be worked on. Maybe that would be a 
good reason to move avr-libc to 2.0.

But I'd really like to have an avr-libc 1.8.1 release.

Eric Weddington