porting uClibc to a new arch

[Bernhard Reutner-Fischer]

On Wed, Jun 03, 2009 at 10:02:47AM +0200, Ricard Wanderlof wrote:
>
> On Wed, 3 Jun 2009, Florent DEFAY wrote:
>
>> I am working on a toolchain for a new arch.
>> We already ported binutils, GCC and Newlib.
>>
>> This is an embedded micro-controller. There is no OS because we don't need one.
>> We are interested particularly in printf and scanf, which Newlib can do.
>>
>> The problem is that program linked with Newlib calling printf are too  
>> large. The target is 16 bit and RAM is addressed on 16 bit. We thought  
>> that replacing Newlib by uClibc could solve the problem.
>
> Without any research into the matter, I would think that uClibc would be  
> larger than Newlib. To my mind, uClibc is geared towards the larger end 
> of the embedded market, i.e. 32-bit processors with MMU's (even if there 
> are exceptions), megabytes of memory etc, whereas Newlib is intended to 
> be small. Also uClibc is really designed as a small-scale replacement to  
> glibc which in turn is geared towards Linux. There are exceptions, but  

Given that you can turn off most if not all those linux-specific things and
can configure uClibc down to way below 100k on-disk footprint and that mjn
use(d) uClibc on some 16bit platform i tend to think that uClibc should
be useful on small devices also.

There was once a patch that added libgloss support for uClibc. I certainly
support any attempt to add libgloss(-like) targets.

> that's the general direction.

One advantage of uClibc is configurability, both up and down.