RE: [ANNOUNCE] Lua 5.0 (alpha) now available

["John Passaniti" <jpass@...>]

> So what you're suggesting is that every app
> or library you run on your embedded system 
> create its own mini-printf as needed.  

In many embedded systems (at least the embedded systems I work on),
there is only one application.  It isn't a generic operating system that
has multiple applications running at once (or even sequentially).  In
fact, there is rarely an operating system-- the application is all there
is.  So there aren't multiple copies of *printf or any other routine
occupying memory.

> If you have enough libraries doing that 
> you'll go over the size of the standard 
> C's implementation anyway.  Plus there 
> is the wasted human effort.

As I wrote, if *printf is loaded in elsewhere-- maybe in Lua, or maybe
in some library I've (usefully) linked in-- then this doesn't matter.
The cost is already there, and I have no problem with that because the
routine is necessary and useful.

What I have a problem with is using a routine like vsprintf for a
*single* instance-- such as here converting a number to a string-- when
that can be done more efficiently with dedicated code that doesn't have
to parse a format string, handle variable arguments, and deal with all
the other stuff *printf does.  If you look at the source for most
*printf implementations, you'll see that only a tiny fraction of it is
concerned with converting numbers to strings.  All the rest that *printf
does is wasted-- and that waste is RAM or ROM that someone has to pay
for.

On a desktop-- sure.  You've got gobs of memory (probably most of it
virtual), and so who cares if *printf resides in memory a couple dozen
times in statically linked applications.  Hit a page fault, allocate
some more memory, and away you go.

> If you don't buy that, then consider that if
> your apps and libraries truly don't require the 
> full printf, then all you need do is replace 
> the standard C's implementation according to 
> your constraints (and cover everything you run 
> on your system in one swipe).  

Yep, and in fact, I generally do have various levels of *printf that I
link in.  I have a version that doesn't do floats, a version that
doesn't support some exotic formatting options, and a version that
handles %d and %x alone, without even width specifies.

But that's not the point.  In many embedded systems, the application is
the only thing that runs on the system.  We don't have dozens of other
applications statically linked residing on the system, each with
redundant copies of *printf.

I can turn your argument around-- most *printf implementations use
common core routines (such as itoa and ftoa) to convert numbers to
strings.  So if I happen to have code that uses *both* these core
routines and *printf in one application, then I haven't wasted any
space.  (The only problem is that routines like itoa and ftoa aren't
ANSI, although they are commonly found in most system libraries.)

> With this, the person that needs the special
> case is the one that does the special work, 
> and everyone else gets the generality 
> afforded by the C library.

Nope, there is still a cost.  vsprintf is *always* going to be slower
than a dedicated routine to do the number to string conversion.  And
considering we're talking about an operation that Lua could end up doing
*many* times in some applications, the wasted execution time of vsprintf
is going to slow down Lua.

I'm not the kind of person who takes all this to extremes.  I am not
suggesting that Lua should avoid the use of system libraries and do
everything itself.  I subscribe the principle that one should freely use
system libraries if the code in them does what you want-- and nothing
more.  vsprintf does far more than is necessary to convert a number to a
string, and if this is the only place where *printf is used, then it is
a waste and should be removed.

To be honest, I haven't seriously looked at the latest version of Lua to
see if there is waste.  I have no reason to suspect there is, but if I
find areas of Lua that I and other embedded systems programmers might
question, I'll either offer patches or suggestions to the Lua authors
for creating a more efficient core.  Right now, I'm currently studying
the impact of Lua changing to a register-oriented VM instead of a
stack-based model.