westfw:
I think it should work. If you use inline ASM inside a function to do the pushes, you run the risk that the function prologue and epilogue have pushed/will pop values off of the stack that it thinks belong to it, but end up being the values you tried to push. The only way to tell for sure is to try it, perhaps carefully looking at the asm listing to see if the code looks correct. Without a debugger to support you, it might be pretty difficult to tell what is going wrong if it doesn't work immediately...
Hmm. Something like:
void pushfuncs(void*, void*, void*) __attribute__((naked));
void pushfuncs(voida, voidb, void*c) {
asm(" push %A0\n"
" push %B0\n" :"=r"(a));
asm(" push %A0\n"
" push %B0\n" :"=r"(b));
asm(" push %A0\n"
" push %B0\n" :"=r"(c));
}
void loop() {
pushfuncs(f1, f2, f3);
}
If I start off with a call whose return (placed on the stack by the call) takes me back to the engine, that function loads the stack and JUMPS to the top address. I think that the return should clear the top address, all the functions are void func(void) and exchange data and addresses on a stack as well as variables/constants and parameters in the compiled virtual code.
This is for an AVR Virtual Forth work-and-act alike that I hope will run more standard forth than existing AVR forths. I have the help of the author of Pocket Forth, a copy of Starting Forth (got my 1st copy in late 83) and my recollections of writing forth.
I think to you it'd be an interesting toy/tool. Starting Forth is a free PDF now, it gives full details and that book is not very thick. The flexibility it allows is amazing, you can write forth that extends itself even to the compiler.
Our first major boundary is that AVR's do not execute in RAM like every other Forth either of us knew. We have a way past that that puts most all of the load on the compiler and the pre-compiled C functions and data. The return-stack loading is just a way, if it even works to not have the code "return to ground/engine" until a branch command or end of word definition. It's supposed to substitute engine cranking (call after call) with machine-code-threading.
And I'm not sure it's going to save much at all or even that the Arduino compiler will let me do it!
I'm still looking at ways to not have subverted return addys stacked up. Still planning and running mini-tests on ideas.
It won't replace C++ on Arduino but Forth can be a nice learning environment. It has an interpreter that makes it easy to test what the defined words will do, examine the stack and memory. There isn't that much to learn but then there's only 26 letters in our alphabet too.