avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] Re: Revised release criteria for GCC 4.0


From: Joerg Wunsch
Subject: Re: [avr-libc-dev] Re: Revised release criteria for GCC 4.0
Date: Thu, 16 Dec 2004 21:18:10 +0100
User-agent: Mutt/1.4.2.1i

As Bernardo Innocenti wrote:

> A long term goal could be merging intersting bits of avr-libc into
> newlib and switching AVR toolchain distributions for Linux and
> Windows to use newlib by default.

Perhaps, yes.

What's their CVS [commit] access policy?

> This would make AVR applications more portable while concentrating
> development effort in a single C library.

Well, forgot about portability in microcontroller environments. ;-)

Either you design your application to be real portable, then it will
be, but it'll probably require a hardware abstraction layer, and thus
less optimal than a specific version.

If you've got an AVR-specific C file, you can probably pull out
algorithms into another controller project, but the overall
maintenance effort is bad enough so changing a couple of other items
(which could be automated by an editor) is no additional work.  As for
the library itself, it uses C standard names where appropriate, so
nothing would change.

> Toolchain distributors would still need to add some AVR-specific
> headers for register definitions and asm macros, which wouldn't be
> appropriate for inclusion in newlib.

That sounds bad.  Do you really think it's feasible to offload this to
``toolchain distributors''?  No centralized repository for it, where
it can be coherently maintained regardless of the person who is
shipping the toolchain?  Right now, you can at least shuffle an
AVR-GCC project back and forward between Windows & Linux & FreeBSD (&
Solaris & MacOS X) without any need to change your code (and if you
design it that way, hopefully even with the same Makefile).  This
would seem a much more important source code compatibility issue in my
opinion than a hypothetically increasing probability to port an AVR
project to an ARM7 or such.

I strongly disagree with that aspect.  Why couldn't this be integrated
into newlib as well?  All these header files purposely go into an avr/
subdirectory already anyway.  Otherwise, we end up with one CVS repo
for newlib and one CVS repo for the avr-specific header files, which
would be no different than the current situation.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]