Re: [avr-gcc-list] Locating Internal /External Memory Sections

[Joerg Wunsch]

"Jim Davis" <address@hidden> wrote:

> Does anybody know if the internal memory sections are
> adjustable with the avr-gcc tools? is there an INTMEMOPTS?

Please don't hijack an existing thread for an unrelated question,
rather start a new thread.  Threading news/mail readers will otherwise
get confused.  (You've been following up to the `leaps and skips'
thread.)

Well, first separate compiler options from make macros in your mind.
It seems to me you're confusing them.

EXTMEMOPTS is a simple make helper macro that is used in order to
assemble the final LDFLAGS option collection that is to be passed to
the linker.  Thus, while its name might appear to be poorly chosen,
you could use it as well for any other linker option that is related
to the location of the various memory sections (though Mfile can no
longer assist you then -- but it cannot do what you want anyway).

> I want to use my own memory manager to be able to boost execution
> speed for certain operations, and want to get at internal memory for
> a fast memory pool.

I can't quite follow you.  You could even write your own replacement
for malloc(), using the very same bounds as the library's malloc() is
using.  Note that malloc() defaults to use internal memory, too.

Just get a better picture of what you're trying to achieve, and study
the available documentation and examples.  In order to see which of
the global symbols are supplied by the linker, try to compare the
linker script to the actual symbol values as found in the linker map.
Together with the documentation about memory sections, it should
eventually get you an idea about who's defining what.  (Hopefully a
better idea than your description gave to me about your actual
goals. ;-)

> Last question is whether the compiler makes use a hardware stack
> like the Codevision compiler has implemented?

GCC uses *the* hardware stack (the one maintained by SPL/SPH), but no
second (software) stack as many other compilers in particular in
microcontroller-land appear to use.  As the stack is by default
located at the top of (internal) RAM, growing down, and variables are
located starting at the bottom of RAM, growing up, this gives you all
available memory for the stack.

> External SRAM         1100 - FFFF                     60 K
> 
>       1100 - XXXX     .data-start,  .bss-end
>       XXXX - EFFF     Common Pool
>       F000 - FFFF     Hardware Stack          1 K

Don't deploy the stack in external memory.  It'll make things slower
than they need to be.

> *  bss_end to EFFF is Common Pool.

I have no idea what `Common Pool' vs. `Fast Pool' might be in your
opinion.
-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)