View previous topic :: View next topic |
Author |
Message |
Blake
Joined: 31 Dec 2004 Posts: 31
|
Posted: Sat Sep 05, 2009 4:31 am Post subject: Frame size, Hardware stack size, Software stack size |
|
|
After entering the following simple code:
$regfile = "m16def.dat"
$hwstack = 3
$swstack = 3
$framesize = 3
End
the compilation report shows:
hardware stack start address: 1119 (base 10) / $045F hex (last SRAM byte)
software stack start address: 1117 (base 10) / $045D hex
frame start address: 1113 (base 10) / $0459 hex
As shown in the attachment it appears that each memory area overlaps each other - am I missing something?
Also, in the Bascom help its states that the hardware and software stack grows DOWN memory which is why I show the byte #'s for each increasing (growing) while going DOWN in memory address - is this correct?
I show the frame byte # increasing with increasing memory address (have not seen anything on this in help files) as this only made since if these 3 reserved memory areas are continuous - is this correct? |
|
Back to top |
|
|
for_ro
Joined: 11 Nov 2007 Posts: 260
|
Posted: Sat Sep 05, 2009 10:02 am Post subject: |
|
|
Hi,
try to include the $dbg directive into your code. Then check in the simulator with opened memory map what happens. $dbg tells the compiler to preset all effected memory location in hardware stack with the character "H", in soft stack with "S" and in frame with "F".
There is no real overlapping. It only seems to happen, if you give odd numbers for the size of these areas. With even numbers, everything looks ok. I can imagine, that this "mistake" happens because the memory is organized in 16-bit words.
You will also recognize, that there are no "F" characters (don't confuse with the FF's for not used locations). 3 for the frame is much to small in Bascom's view, as the first 24 are used for the system. So you have to give at least 25 for the frame to see the first "F". |
|
Back to top |
|
|
Blake
Joined: 31 Dec 2004 Posts: 31
|
Posted: Sat Sep 05, 2009 4:51 pm Post subject: |
|
|
Yes your right about the minimum size of the frame needs to be at least 25. Obviously this is just useless code to learn about stack and frame placement in memory and I should have set the frame size to 25. However, after doing so AND making the software and hardware stacks an even number of bytes as shown below in the code:
$regfile = "m16def.dat"
$hwstack = 4
$swstack = 4
$framesize = 25
End
the following compilation report is generated and shown graphically in the attachment.
Stack start : 45F hex
Stack size : 4 hex
S-Stacksize : 4 hex
S-Stackstart : 45C hex
Framesize : 19 hex
Framestart : 442 hex
Space left : 1085 dec
I am not trying to make a big deal or problem out of this but just trying to understand. Obviously unless SRAM is limited allowing extra space for each hardware and software stacks and framesize should prevent any problems. But looking at the graphic when byte 1 of the software stack starts at 045C and byte 4 of the hardware stack ends at this same SRAM address this appears to me to be overlapping unless I am missing something obvious to everyone else. Again the same holds true for the frame area "appears" to be overlapping the software stack at addresses 0459 hex and 045A hex.
What am I overlooking or misunderstanding? |
|
Back to top |
|
|
for_ro
Joined: 11 Nov 2007 Posts: 260
|
Posted: Sat Sep 05, 2009 5:42 pm Post subject: |
|
|
Did you check it in the simulator?
The only thing which is wrong is the start position of the SW stack, which is one to high. In your example the actual start is at 45B, not at 45C.
So it doesn't overlap. |
|
Back to top |
|
|
Blake
Joined: 31 Dec 2004 Posts: 31
|
Posted: Sat Sep 05, 2009 6:25 pm Post subject: |
|
|
Yes I can see that the hardware stack occupies addresses 45C through 45F and the software stack occupies 45B through 458 and then finally the frame occupies memory address 457. I guess my point is that this is not what the compilation report shows so I wonder if in some "real code" situations one would not overwrite the other.
Again if a few extra bytes was allowed for each there should be no problem. However I can see from this experiment that $dbg should be used with stack analyzer to set frame, HW & SW stacks to be sure in cases where the sizes of each are being held to a minimum to save space.
Thanx for your help. |
|
Back to top |
|
|
DToolan
Joined: 14 Aug 2004 Posts: 1384 Location: Dallas / Fort Worth, Texas (USA)
|
Posted: Sun Sep 06, 2009 3:25 am Post subject: |
|
|
Some start at their "start address" and fill backward (toward the start of actual SRAM) while some start and their "start address" and fill upward (toward the end of actual SRAM). And, of course, it is entirely possible to overflow one area into the boundries of another area (stack overflow). |
|
Back to top |
|
|
|