1. Home
  2. Field-Programmable Gate Arrays
  3. Forth-CPU design
  4. Page 3

Forth-CPU design

As far as I can see, that all makes sense for a program structured like this:

(main routine) : do thing1 do thing2 do thing3

Avoiding the call and return makes sense - the end of "thing1" can just be a jump to the start of "thing2", or even better, "thing2" can simply follow on after "thing1".

But if the program is: (main routine) : do thing1 do thing2 do thing1 do thing3

Or if both "thing1" and "thing2" want to call a common routine "thing4", you are stuck. Either you duplicate code (which might be worth doing if the code is short, but not if it is long), or you have some sort of stack - there is no other way (any other solutions are a stack in disguise).

An ideal compiler arrangement would figure this sort of thing out automatically and cut out all the calls and returns when they are not necessary, but include them when they are. I don't know much about forth implementations (it's over fifteen years since I looked at forth), but I do know of C compilers that do this.

Reply to
David Brown
Loading thread data ...

werty schrieb:

You are off topic. This is a thread about a hardware implementation of a FORTH-CPU. Hardware stacks are as fast as register files and not addressed at all.

With modern JITs you might get better performce for stack based machine models like JAVA or FORTH with static scheduling on a register file done by a JIT compilert than you could get on a stack CPU. But a stack based hardware implementation can get OK performance with both software and hardware that is an order of magnitude simpler than the JIT on RISC approach. And due to the lack of a JIT it will have better real time properties.

Kolja Sulimma

Reply to
Kolja Sulimma

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.