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 ... _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
