I reviewed the STM8 eForth Wiki under and tried to make it more readable for the casual visitor. Also removing some of the Forth evangelizing hyperbole doesn't hurt. Forth is still amazing, not only for philosophical reasons, but nobody likes Forth extremists, right?

Another activity is experimenting with interfacing STM8 eForth with SDCC C. Use-cases, approaches and the progress so far have been documented in Add/mix/graft STM8 eForth into a C project.

I found no documentation on parameter passing in the SDCC STM8 port, and after some experiments I have the following hypothesis:

• parameters are copied to the return stack in the relevant size, ready for access with "SP indirect addressing", and in the reverse order of the definition
• 8bit return values are in A
• 16bit return values are in X
• 32bit return values are in MSW X - LSW Y

SDCC passes most data on the (return) stack. The main difference to a stack oriented language is that this parameter passing behavior is not defined in the language, it's a mere implementation detail. The effect is that stack transfers have to be done over and over again, which creates a lot of waste.

From the software engineering point of view it becomes apparent that a minor change of paradigm (maintaining the stack is the responsibility of in the called function instead of the calling function) can be the defining feature of the architecture.