Re: [Amforth] Stack pointer

[Erich W. <ew....@na...>]

Hello,

tur bine writes:

> Hi just wished to expand my knowledge base with forth, the stack pointer
> increases during runtime and does not decrease unless using certain
> commands if etc, can somebody explain what happens when sp and thus the
> stack gets full please

Martin has answered your question already. I would like to add a
a few bits.

1.

The exact region, how memory (RAM) is used, is documented in
> http://amforth.sourceforge.net/TG/AVR8.html
(similar for the other targets). More precisely
> http://amforth.sourceforge.net/TG/AVR8.html#ramfigure
shows that in this partcular case, the datastack grows towards
the HLD/PAD area. This might be quite some distance, but Martins
answer holds: if you overwrite something "important", then most
likely your programm will crash.

I cannot yet explain the purpose of the two different layouts,
but I assume that the latter is needed to accomodate one or more
of the other hardware targets. I have not tried to understand
this so far. I do have a hifive1 board, so it is on the list to
understand better, what the boundary conditions are (beside
using a different asm format).


2.

When using the multitasker, you will run into finite stack space
conditions much sooner. To define a task, you specifiy the size
of the data/return stacks explicitly. If your nice programm
crashes once in a while, I would strongly recommend to increase
stack sizes as a first experiment. Been there, done that. :-)

The command " .res " does actually output some information about
stack usage. And it's worthwile to study its code.
> .../avr8/lib/dot-res.frt


3.

When using the multitasker, the above mentioned HLD/PAD area is
interesting as well, because currently there is only one such
area shared between all tasks. I have been bitten by this: Task
A runs the command loop on usart0; Task B runs a function, which
writes to an LCDisplay via spi or i2c. Please note: two tasks
using different hw periphery with distinct versions of " emit ".
However, both tasks used pictured numeric output (this is
actually quite hard to avoid :-) And once in a while, the
formated output bound for the LCD would overwrite the output
bound for the serial interface. It "looked" like amforth was
doing calculation errors once in a while ...

As I have mentioned a while back, I would like to either provide
task-local areas for HLD/PAD  or play with semaphores to solve
this.

However, my days are much too short --- as I'm sure everyone
elses are as well :-)


-------------------------------------------------------------

While rereading your question, it occurs to me that you might
talk about FLASH rather than RAM.

When compiling a word, the new word will consume some flash
space. DP points to the next available position. The dictionary
grows from low flash addresses towards higher ones.

On AVR8 it will eventually hit the NRWW section boundary. I
expect that compiling will fail at this point, because the NRWW
section is kind of protected. I have not tried this.

In order to reclaim FLASH memory without erasing/flashing the
controller, you can use the word " marker " (which you need to
load first) Example:

> my_code.frt
>| \ maybe more includes needed here ...
>| include lib-avr8/forth2012/core-ext/marker.frt
>| 
>| marker --main--
>| 
>| \ ... your code goes here


Now when you don't like your code anymore, you can call

> --main-- ok
>
on the serial connection. This word will reset book-keeping in
such a way, that everything from " --main-- " and onward is not
available any more. Please note that " --main-- " itself
vanishes as well and needs to be set anew.

There is one symptom related to this. If you load a lengthy
programm for the first time, it takes so long. If you load it
again, without reclaiming flash by calling the marker before ---
then it will take a little longer every time. This is noticable.
This is caused by the increasing length of the wordlist. To
find a word at the low end of the list, it will take
increasingly longer, because the length of the wordlist
increases. And guess what, all the important words stay at the
low end of the wordlist.



Thanks for reading,
and welcome to the list!

Cheers,
Erich


-- 
May the Forth be with you ...