Re: [cc65] Platform specific docs

Date view Thread view Subject view

From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2003-10-28 21:05:40


On Tue, Oct 28, 2003 at 11:37:15AM -0800, Shawn Jefferson wrote:
> Doh!  I think I see what you mean.  the heapend initialization doesn't
> really do anything... and the initheap is assigning the heapend to
> just below the stack, not really in the BSS segment at all...

Correct, but ...

> Hmmm, another question then, if the above is correct, will moving the
> BSS segment on the Atari platform cause problems with the heap?  Since
> heaporg and heapptr are assigned values from the BSS segment, or does
> these variables get changed somewhere else?

... heaporg and heapptr are preset with values calculated from the BSS
segment. If you move the stack somewhere else, heapend will also get moved,
because it is calculated from the stack pointer. So the end of the heap does
no longer relate to the start, and things go wrong. This is what I meant with
"The current implementation of the heap assumes that the stack is located at
the end of the BSS segment".

The memory setup for most platforms (including the Atari) is:

        +------------------------+      <- top of usable RAM, sp points here
        |          stack         |
        .                        .
        .                        .
        |    free space/heap     |
        +------------------------+      <- __BSS_RUN__ + __BSS_SIZE__
        |           BSS          |
        +------------------------+      <- __BSS_RUN__
        |          DATA          |
        +------------------------+
        |         RODATA         |
        +------------------------+
        |          CODE          |
        |         LOWCODE        |
        |         STARTUP        |
        +------------------------+      <- load address

All stuff written in capital letters is part of your program as generated by
the compiler. All segments with the exception of BSS are part of the program
image generated by the compiler. The BSS contains uninitialized data, so
there's no need to store it in the program image (saves some space). Instead
it is cleared by the startup code, so it contains zeroes when main() is
called.

The stack is set up in high memory, it grows downwards. Between the stack and
the end of the program data (the BSS segment) is free space, which will be
used by the heap. To locate this free space, the heap initialization code
references the BSS segment. To locate the end of the free space, the heap
initialization code uses the stack pointer (which was already set up by the
startup code) and subtracts the maximum stack size as defined in the linker
config.

Please note that most platforms use this setup, but apart from being practial
and used on many other (non 6502 platforms) as well, there is no real reason
for it. If you use your own startup code and config file, you may as well
place the stack below the code segment, change the order of the segments, or
place the heap between program segments. Most parts of the existing runtime
and C library code won't care about such changes, the only exception I know of
is the initialization of the heap. However, since this initialization is
located in exactly one module, you can just replace the module and things
should be ok. There will be a more flexible solution in the future, but as
stated before, it needs an extension of the linker.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz_at_musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.


Date view Thread view Subject view

This archive was generated by hypermail 2.1.3 : 2003-10-28 21:05:54 CET