This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: printf size requirement
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