This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: finding out what's taking space in .bss wrote:

for the HAL to link in a function that is called in the idle
thread. This could for example change the power saving of the
processor. Such a function needs some stack space. For "normal"
systems 1k does not count, so 1k seems a reasonable default.

the funny thing is CYGNUM_THREADS_IDLE_STACK_SIZE is set to 512 in the
configuration tool, I have SMP support turned off, and there are 1120
bytes between idle_thread_stack and the next symbol. Did I read the
map incorrectly?

No, there is some jiggery pokery in kernel/current/src/common/thread.cxx which makes sure the stack size is at least CYGNUM_HAL_STACK_SIZE_MINIMUM. This figure is meant to be the absolute minimum a thread (like the idle thread) could get away with, due to potentially needing to handle interrupts on that stack or not.

In the ARM HAL for example:
// A minimal, optimized stack frame, rounded up - no autos

// Space for the maximum number of nested interrupts, plus room to call functions

// Interrupt + call to ISR, interrupt_end() and the DSR
    ((4 * 20) + 2 * CYGNUM_HAL_STACK_FRAME_SIZE)


If you could guarantee that interrupts will never nest in practice in an application, you could reduce this, but eCos in general can't make such an assumption. That's where that space is going anyway.

One bit of known wastage in the ARM HAL is the startup stack - 512 bytes. It probably shouldn't be used and instead an interrupt stack should always be defined and used for startup, irrespective of CYGIMP_HAL_COMMON_INTERRUPTS_USE_INTERRUPT_STACK which would instead determine the size of the interrupt stack in the ARM HAL rather than its presence or absence.

One regression we've had as well is that virtual vectors, and therefore hal_virtual_vector_table (272 bytes), are meant to be optional but many platform ports make them compulsory. On the plus side, it isn't difficult to make them optional.

eCos is designed to be small, but sometimes there are little things like this that linger for a while because no-one seems to be bothered about the last few bytes. I'd love to spend time clearing up stuff like this, but there's always something more important...

eCosCentric    The eCos and RedBoot experts
>>>>> Visit us in booth 2527 at the Embedded Systems Conference 2004 <<<<<
March 30 - April 1, San Francisco
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

-- Before posting, please read the FAQ: and search the list archive:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]