Date: Tue, 13 Jul 2004 16:45:37 -0400 From: David Muse Subject: Re: [nanogui] reduced memory/storage patch 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 --------------------------------------------------------------------- To unsubscribe, e-mail: nanogui-unsubscribe@linuxhacker.org For additional commands, e-mail: nanogui-help@linuxhacker.org