Code size problems with Platform Builders ARM C Compiler

I have an Initial Program Loader (a very stripped down bootloader) for
an ARM 922 based CPU that must fit in 16K so that it can be auto-loaded
from the NAND Flash's boot block when the processor is reset.
The current code builds under the ARM development suite and fits into
the 16K space. I want to move away from using the ARM development
suite tools and use only the Platform Builder tools.

When I build the same exact code with the Platform Builder tools it
generates an image that is 32K and after MAKEIMG runs, it is 64K.

What could be causing the PB C compiler to generate code that is 2x
larger than the ARM development suite? I have double checked the
optimization flags to ensure it is optimizing for size.

I'm doing a retail/release build.

Mark Moeller
Qualnetics Corporation

Dean
Mon Apr 25 08:44:41 CDT 2005

Some common things to look for...

The tools will put a 4K space at the beginning of the image that contains a
signature, table of contents pointer, etc. That space can be manually
deleted if you like. The tools will also put the table of contents
structure at the end of the image, aligned on a 4K boundary. That will chew
up more space, (the alignment, plus the TOC).

In general, take a look at the log output from romimage in combination with
the map file from your loader. That should tell you where everything is
being located, and give you an idea of what is going on.

--
Dean Ramsier - eMVP
Vibren Technologies
http://www.vibren.com/Products/schema_bsp.htm


"Mark Moeller" <markmo@qualnetics.com> wrote in message
news:1114216799.361293.148280@l41g2000cwc.googlegroups.com...
> I have an Initial Program Loader (a very stripped down bootloader) for
> an ARM 922 based CPU that must fit in 16K so that it can be auto-loaded
> from the NAND Flash's boot block when the processor is reset.
> The current code builds under the ARM development suite and fits into
> the 16K space. I want to move away from using the ARM development
> suite tools and use only the Platform Builder tools.
>
> When I build the same exact code with the Platform Builder tools it
> generates an image that is 32K and after MAKEIMG runs, it is 64K.
>
> What could be causing the PB C compiler to generate code that is 2x
> larger than the ARM development suite? I have double checked the
> optimization flags to ensure it is optimizing for size.
>
> I'm doing a retail/release build.
>
> Mark Moeller
> Qualnetics Corporation
>

arun_k
Tue Apr 26 11:20:13 CDT 2005

hello ramsier,

Even I find that the code size generated by PB is too huge. How can we
delete the 4K space in the begining and end of image manually. Can you
please explain more on this.

thanks
Arun

Steve
Tue Apr 26 11:34:16 CDT 2005

You can't delete that section - it's part of the way the tools work and
there is nothing you can do about it. Various attempts have been made to
"get around that" to various degrees. A google search of the newsgroups will
provide information on what has been tried and under what specific
conditions it was successful.

--
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com

Dean
Tue Apr 26 12:08:44 CDT 2005

I was referring to a brute force deletion of the first 4K with some external
tool you develop yourself. You would only do this in a scenario where you
really knew what you were doing, and what the potential ramifications might
be.

--
Dean Ramsier - eMVP
Vibren Technologies
http://www.vibren.com/Products/schema_bsp.htm


"arun_k" <arun_kalmanje@yahoo.com> wrote in message
news:1114532413.932375.208090@f14g2000cwb.googlegroups.com...
> hello ramsier,
>
> Even I find that the code size generated by PB is too huge. How can we
> delete the 4K space in the begining and end of image manually. Can you
> please explain more on this.
>
> thanks
> Arun
>

Mark
Fri Apr 29 02:52:09 CDT 2005

I've managed to reduce the code down to 16k by changing several
compiler flags, coalescing sections, and replacing the fulllibc.lib
with hand written routines that were being linked to. I still don't
have the image fitting in the NAND boot block but will continue further
exploration. Looks like a custom version of ROMIMAGE may be in order
to ditch that wasted 4K at the top of the image.

Mark Moeller
Qualnetics Corporation

Steve
Fri Apr 29 09:24:19 CDT 2005

As I recall, ROMIMAGE isn't the culprit. It's the linker itself that does
the dirty work. ROMIMAGE faithfully locates based on the EXE information set
up by the linker.

--
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com

Mark
Sat Apr 30 02:55:37 CDT 2005

My code size is now down to about 15K. Once I add in the other
sections to the .text (code) area it comes to about 17K. Here are the
settings I am using:

set WINCESHIP=1
set FIXED_BASE_ADDRESS=0
set WINCE_OVERRIDE_CFLAGS=/GL /O1 /Ob0 /Oi- /Os /Og /QRthumb /GF
/QRimplicit-import- /Zl
SET LINKER_DEBUG=-merge:.rdata=.text -merge:.data=.text
-merge:E32=.text -merge:O32=.text
call build %1
romimage ipl.bib

I've also added a header file that does a #undef of UNDER_CE and also
defines a bunch of common Windows data types. This allows me to avoid
including Windows.h at all to guard against dragging something
unindented from nested windows header files.

I'll post more if I make progress. I'm going to try the GNU C compiler
next.

Mark Moeller
Qualnetics Corp.