Subject:
Re: [nanogui] reduced memory/storage patch
From:
David Muse ####@####.####
Date:
13 Jul 2004 21:45:41 +0100
Message-Id: <20040713164537.2e96369a.dmuse@4accesscommunications.com>
On Tue, 13 Jul 2004 12:39:11 -0600
"Greg Haerr" ####@####.#### wrote:
> David - cool, I've got a couple of questions though...
> In devimage.c, you remade a declaration non-static:
> - static int table[2][(1 << MAX_LWZ_BITS)];
>
> - static int stack[(1 << (MAX_LWZ_BITS)) * 2], *sp;
>
> + /*static int table[2][(1 << MAX_LWZ_BITS)];
>
> + static int stack[(1 << (MAX_LWZ_BITS)) * 2], *sp;*/
>
> +
>
> + /* DLM made these non-static */
>
> + int table[2][(1 << MAX_LWZ_BITS)];
>
> + int stack[(1 << (MAX_LWZ_BITS)) * 2];
>
> + static int *sp
>
> What's the reason for this?
devimage.o ends up having a large bss section if those buffers are left
static. I believe the bss section is initialized when the process is created
and hangs around unless it's paged out to swap. If the buffers are made
non-static then they are allocated on the stack when the function is called
and deallocated when the function exits. This is slower but allows the
program to use less ram most of the time.
>
> Also, some comments on the other items:
>
> : * Made some things static. If a symbol in a library is static, it is
> local and thus strippable, making the library smaller on disk/flash.
>
> Sounds good - is there a strip option that will perform this
> anyways?
I use "strip --strip-unneeded" on all of the libraries that I put on my platform.
This removes all symbols that are declared local and leaves all symbols
that are declared global. Declaring a variable static marks it as local
and causes "strip --strip-unneeded" to remove the symbol. Otherwise,
you'd have to use "strip --strip-symbol" and remove each symbol that
you know is safe to remove individually.
>
>
> : * Made some things const. If a symbol is const, then it can be put into
> the text section of the library and can be shared across processes.
>
> An example, the mwstdpal2[] array was made const. This allows
> the code to be shared amonst processes. However, this file is
> only used in the nano-X server, so how does this help?
>
> Even the font data structures are only used in the nano-X server,
> so I'm still wondering how the RAM (or flash)
> usage diminishes in this case.
>
> In general, though, I agree that if the item is constant, it
> might as well be declared that way.
On a platform where code could be executed off of a rom, it would help
because the table wouldn't have to be copied into ram. I'm not sure that
microwindows runs on any platform like that though, does it?
In truth, I just went through and const-ed everything that looked like it could
be const and static-ed everything that looked like it could be static. There
are probably numerous cases where the code is only loaded into the
server and no ram is actually saved since that code would never be shared.
Where I work, we're trying to squeeze way too much stuff into way too small
of a device right now :)
I've been scrounging for a few hundred K in every piece of code that we
use. After doing all of the obvious things, I resorted to inspecting individual
object files. After finding looking in openssl's libcrypto and finding lots of tables
and strings that could be made static and/or const, it occurred to me to look for
the same things everywhere else, including in microwindows. It's possible
that I went overboard here and there :)
>
>
> : * Made some local variables non-static. If a buffer is local to a
> function, but is declared to be static, then it is allocated when the
> process starts rather than on the stack when the function is called. Making
> buffers static can speed up execution though. Sometimes code depends on
> buffers being static, I was careful of that.
>
>
>
> : * Made some arrays of pointers to strings into const 2d arrays. This
> makes the code slightly larger, but makes it possible to put the arrays in
> the text rather than data section, even when using -fPIC.
>
> Yes, this is the case with nxErrorStrings, and these are used by client
> programs, so that data will get shared between nano-X apps.
>
> : * Removed unused code. If some compile time options are set, then some
> code will never be called, I put ifdef's around that.
>
> You're referring to the fblinearX drivers... For production use
> I agree this definitely makes things smaller, with the cost that
> the server can't change resolutions. I think this is where you
> got all your size decreases. I'd be interested to know with
> this addition removed what size decreases actually happen.
I don't know offhand. I'll compile it both ways though, take a look and let
you know.
>
>
> Also, why did you use cc to link, rather than ld?
When we switched from gcc-2.95.3 to gcc-3 we ran into trouble.
I don't remember the exact details, I believe that everything would link fine
but we had problems at runtime, I think maybe there were relocation errors.
We were using the montavista compiler at the time and so we got montavista
to look at the problem. Their solution was to use gcc to link rather than ld.
When we switched to using a uClibc toolchain, I tried using ld again, but ran
into the same problem, so it appeared not to be montavista-specific. I ran into
similar problems with gcc-3 on ppc, sparc and x86 with my own open source
projects about the same time and switched them to use libtool for compilation
and linking. Libtool uses cc to link as well, so I figured it was probably a good
idea.
I had actually forgotten entirely about having made that change.
>
> Regards,
>
> Greg
>
Take care, let me know if you have any more questions.
Dave
