[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
smallest executable size was RE: Boot loading
- Date: Thu, 20 May 1999 07:45:56 -0500 (CDT)
- From: joel at OARcorp.com (joel at OARcorp.com)
- Subject: smallest executable size was RE: Boot loading
On Thu, 20 May 1999, Mark Farnan wrote:
> Ok, its simple question time :-)
> How do I selectivley disable (at compile time) various managers in RTEMS so
> I can generate the smallest possible program. i.e I they are not linked in
> at all.
> I don't need (At present, although will later) the following sections.
> dual ported memory
> rate monotonic
> and am only using
> The "Determining Memory Requirments" section in the C Users manual says
> these managers may be optionaly excluded, but it does not say how to do it
> (as far as I can see).
If you use the RTEMS makefile scheme for applications, you can just list
the managers you actually require on the "MANAGERS" definition line.
# optional managers required
> At the moment the simplest program (Flash an LED) takes about 50KB of
> memory, and that much is not available on my EVAL board, it also takes to
> long to download. In production this won't be such a problem (128KB ROM /
> 256kb RAM) but Ineed to get the BSP working, and need to cut down the RTEMS
> code size as much as possible.
I have actually been working on reducing executable size.
Unfortunately, a focus on feature growth has led to some dependencies that
make it difficult to get the executable as small as was formerly possible.
This is part of the cycle -- add features, trim dependencies, repeat.
The next release will include a configure option
"--enable-multiprocessing" that cuts out the MP code.
The RTEMS API implementations were "one manager per file". Now at least
the Classic API and most of the POSIX API are "one function per file".
The contents of libc are now mostly done this way.
The problem I am chasing now, is that bspstart.c actually references a LOT
of stuff and the way a handful of files it references initialization
routines in (malloc.c, termios.c, console.c) are structured and BSPs
.rel's built results in a lot of unused baggage getting pulled in.
> I am sure it is some simple options somewher, but I can't find it :-(
Most of the options are actually there in 4.0 but did not have the
dramatic impact they should have. :(
> The C Users manual also mentions a Memory worksheet in the "Applications
> supplement" for the specific target processor....where can I find this
> document ? (For the Hitachi SH1 port)
There is not an SH CPU supplement at this time.
> Any Sugestions ?
But ... the information you are looking for is the output of "spsize" for
the workspace requirements and "size_rtems" for the code space.