>>>>> "Eric" == Eric S Raymond <esr@thyrsus.com> writes:
Eric> Tim Peters <tim@digicool.com>:
>> The per-opcode fetch-decode-dispatch overhead is very high in SW too,
>> so a register VM can win simply by cutting the number of opcodes
>> needed to accomplish a given bit of useful work.
Eric> That's an interesting idea. OK, so possibly I was wrong -- I
Eric> hadn't considered that stack-push/stack-pop operations might
Eric> introduce overhead comparable to the order-of-magnitude speed
Eric> difference between registers and main memory in hardware. I'm
Eric> still skeptical, but my mind is open.
Order of magnitude increases? Maybe, maybe not. Still, something like
ADD a1,a2,a3
is going to be faster than
PUSH a1
PUSH a2
ADD
POP a3
My original aim in considering a register-based VM was that it is easier to
track data flow and thus optimize out or rearrange operations to reduce the
operation count.
Translating Python's stack-oriented VM into a register-oriented one was
fairly straightforward (at least it was back when I was fiddling with it -
pre-1.5). The main stumbling block was that pesky "from module import *"
statement. It could push an unknown quantity of stuff onto the stack, thus
killing my attempts to track the location of objects on the stack at compile
time.
Skip
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4