printf size requirement

[Joel Sherrill]

Schwarz, Konrad wrote:
> Umm,... to add some historical context:
>
> printf() has always been heavy weight,
> since it requires malloc() (to potentially allocate
> the buffer for buffered I/O), and there was
> a special hack in PDP-11 compilers to determine
> whether the floating-point-capable version of
> printf() needed to be linked or not.
>
> I am sure I remember reading a warning
> about the resulting size of executables
> when using stdio.
>
>   
I started my UNIX days back in those days with
glorious 64K limits also and I remember those
warnings.  :)
> Programs which just fit into the 64K of the PDP-11,
> such as the Bourne Shell, did not use stdio and
> had idiosyncratic ways of allocating memory.
>
>   
I can appreciate all those tricks.  :)

RTEMS executables are statically linked, include all hardware
and OS initialization, library code, the application code, and
shutdown code.  We are seeing minimum footprints for
hello world being in the 70K range on the SPARC.  If you
don't call printf, that same code drops to 54K. 

With that, we have a basic multithreaded environment with
newlib reentrancy support, malloc, and a fair smattering of
other things that tend to always be there like memset and memcpy. 

What I try to be clear about is that our "minimum" footprint tends
not to grow very quickly because it already includes a lot of functionality
most real applications need anyway.  An application including the
TCP/IP stack and the httpd server will usually come in at 250-300K
depending on the CPU architecture.
> So in that sense, this isn't really a shortcoming
> of newlib; it's just always been that way.  Users
> have no right to expect that programs using
> printf() be small.
>
>   
Agreed.  With RTEMS, there is no hard requirement for
stdin, out, and error.  So needing printf implies there is somewhere
to send the output, which in our world means you get some
device driver along with termios support code.  It goes up.

All I was really asking is the set of symbols pulled in reasonable.
For example, if printf implied rmdir() showed up in your executable,
I would want to know why.

Code in libraries tends to grow spiderwebs where functions get
pulled out that you didn't originally require.  Just curious if
someone spots signs of them in newlib based on this case.

> VxWorks' printf() is implemented independently of
> the rest of stdio and therefore does not suffer
> the weight, but also does not have the performance
> advantage of buffered I/O (as far as I understand).
>
>   
RTEMS has a printk() which also shares those characteristics.
It costs < 2K code space and has a reasonable subset of non-FP
formats. 

--joel
> Regards,
>
> Konrad
>