Uncertainty of modification in .prm-file QD4

[P_B]

Hi!

I am wondering if the lines where I have a comment is needed or not (the stuff about STACK in PLACEMENT). It works great without it, but I have seen in some other threads that it is used.

I have looked at the .map-file and variables are placed from 0x060 and up and the Stack is placed where it should be.

So to finalize, is it enough to have things about the stack in the SEGMENTS area or do I need the extra lines in the PLACEMENT area?

Thanks for any answers!!

/Patrik

/* This is a linker parameter file for the mc9s08qd4 */NAMES END SEGMENTS     Z_RAM                    =  READ_WRITE   0x0060 TO 0x00FF;    RAM                      =  READ_WRITE   0x0100 TO 0x012F;    STACK_AREA               =  READ_WRITE   0x0130 TO 0x015F;    ROM                      =  READ_ONLY    0xF000 TO 0xFFA9;    ROM1                     =  READ_ONLY    0xFFC0 TO 0xFFCF;ENDPLACEMENT     DEFAULT_RAM,                                                                INTO  Z_RAM, RAM;    STACK                                           INTO  STACK_AREA  // <-- is this neccessary?!    _PRESTART,                              STARTUP,                                ROM_VAR,                                STRINGS,                                VIRTUAL_TABLE_SEGMENT,                  DEFAULT_ROM,    COPY                                                                        INTO  ROM;     _DATA_ZEROPAGE,                         MY_ZEROPAGE                         INTO  Z_RAM;ENDSTACKTOP 0x15FVECTOR 0 _Startup

[bigmac · Accepted solution]

Hello Patrik,

Since the linker will usually not be attempting to place any variables or code into the stack area, the absence of a placement for the stack should not generate a link error or warning.  I can think of only one exception to this, when a "dummy" variable is required at the bottom of the stack, to dynamically check for stack overflow.  A placement would then be needed to create the variable.

The allocation of a stack segment requires the use of STACKTOP, rather than STACKSIZE.  The different method of handling the stack was probably dictated by the very small RAM resources for this device.  This basic method will also happily work for larger devices, provided the use of a heap is not required, as is likely for an 8-bit device. 

With the usual STACKSIZE method, the position of the stack will change, depending on the allocation of static and global variables immediately below the stack.  With the STACKTOP method, the position of the stack does not alter, and would usually be placed at the very top of RAM.  This means that any unallocated RAM will form a gap between the variables and the bottom of the stack.

Regards,

Mac

[P_B]

Hi BigMac

Thanks for the reply!

Just what I needed