Byte Magazine Sieve Benchmark

[apersson850]

On 5/16/2023 at 1:45 AM, TheBF said:

Variables, branching and code to enter a routine exist separate from the NEXT interpreter. So that's where Forth spends extra time that is not seen if we just look at Forth's NEXT code. 

It's pretty similar to the p-code interpreter I've shown pieces of before. It executes 5-6 instructions to find out two things: What to do to interpret the instruction and if there are any parameters to it, and if there is, how to handle them.

Then it actually interprets the p-code (if there are no parameters) or fetches the parameter(s) and after that executes the interpretation.

 

The p-code interpreter does this:

• Fetch p-code.
• Increment address (runs only if code is in auto-incrementing memory, since then you can't just auto-increment the pointer).
• Shift left to make byte-code a word-index.
• Fetch address to interpreter's code for the instruction from interpreter's instruction table.
• Fetch branch address for parameters for instruction. If there are no parameters, this one just points to the instruction's interpretation code, which normally is the next word.

 

So yes, these byte code interpreters do handle things that are "hidden" when you look at Forth's inner interpreter. The p-code interpreter is probably the most complex of them all, since it can run p-code from VDP RAM, GROM and CPU RAM. The first two are auto-incrementing with the same reading address, the third is not. The first two load the address in different ways, the third is just a normal memory access. Forth and GPL at least runs from the same type of memory all the time.