Re: [openrisc] gcc, data and bss segments

["Damjan Lampret" <lampret@opencores.org>]

Hi Chris,

are these buffers uninitialized data? If yes, then this is probably a simple
bug in or1k gcc backend. I'll look into this.

Also did you try to strip your RTEMS image? Of course this won't fix above's
problem but maybe you have debug information or something in your image as
well?

regards,
Damjan

----- Original Message -----
From: "Chris Ziomkowski" <chris@asics.ws>
To: <openrisc@opencores.org>
Sent: Monday, July 30, 2001 6:50 AM
Subject: [openrisc] gcc, data and bss segments


> In my attempts to port RTEMS to the or1k architecture, I have
> been appalled at the size of the binaries that are resulting
> from the compiled gcc code.
>
> The RTEMS kernel that I have been working on, even completely
> stripped of all symbols, is approximately 2 MB in size! In doing
> some research into why this is so large, it has come to my
> attention that about 10% of this figure is the result of large
> buffers which have been inadvertently placed into the .data
> segment instead of the .bss segment. This causes large blocks
> of zeroes to appear in the binary image, when the fact is they
> should be created when the program starts up.
>
> There are several advantages to placing all variables that are
> initialized to zero in the .bss segment. These include but are
> not limited to:
>
> Faster boot times. It is alot faster to simply create a RAM block
> of zeroes than it is to copy a block of zeroes from flash to RAM.
>
> Lower power consumption. Power can be saved by creating this block
> internally, rather than driving signals offchip to get at a block
> of zeroes stored in a flash every time a new process is loaded. This
> is addative with the power saved by faster process startup times.
>
> Smaller binaries. On the RTEMS image, the resulting binary will
> be about 10% smaller. Other processes may yield different results.
> This means smaller flash images (and less expensive chips) for the
> same functionality and increased performance.
>
> Since I didn't work on gcc, I am not sure what is involved in
> making this change, or why it wasn't done originally. Can someone
> comment on what it will take to make this change? While this is
> not a crtical bug (it doesn't prevent meaningful work from being
> accomplished) it is a serious issue which needs to be fixed.
>
> I would really like to shrink my RTEMS image by about 50%, and
> this seems to be a good way to recover alot of wasted space.
>
> Thanks for any advice/asssitance,
>
> Chris
> chris@asics.ws
>
>
>
>
>
> _______________________________________________________
> www.asics.ws - Solutions for your ASIC needs
> --
> To unsubscribe from openrisc mailing list please visit
http://www.opencores.org/mailinglists.shtml
>

--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml