It was thus said that the Great Chuck Guzis once stated:
On 8 Feb 2012 at 16:02, Eric Smith wrote:
Chuck Guzis wrote:
Contrast this with P-code implementations, or CPU
emulatons, where
the program never gets control of the real P-counter--it's always
being managed by the P-code interpreter or the emulation package.
But P-code isn't considered to be native code either.
Precisely my point. The P-code interpreter never relinquishes access
of the *real* P-counter to the calling program. A native code
subroutine (and Sweet16) does. You JSR to Sweet16 and it eventually
returns.
That's not the case with any interpreted code.
It's turtles all the way down though.
SWEET16 is a set of routines with an unsual
argument-passing
convention.
The calling program has control at the outset and receives control
back when SWEET16 returns.
There are other VMs that do this. Granted, they too, have unusual
argument-passing conventions, but in C, I can call subroutines that run in
the Lua VM [1] and receive control back. And said Lua VM can call back into
my C code as well.
That's not the case with Java, UCSD Pascal, etc.
During execution of
those the program is never aware of the underlying architecture. I
can run P-code compiled programs on any platform that supports that
variety of P-code. I cannot do the same with a 6502 program using
SWEET16. Too much 6502 native code!
I'm looking at some technical documentation I have on OS-9 (the
non-Macinstosh operating system from Microware) and while I've never
actually run OS-9, the documentation does state (about modules):
BASIC09, for example, may run either I-code or 6809 machine language
procedures arbitrarily by checking the langauge type code.
To me, and the fact that the module type can be one of four different types
of code [2], says to me that code *can* be written to load up a "module" and
"call" it [3]. In fact, the documentation for OS-9 lists seven pre-defined
module types, one of which is "program" and one of which is
"subroutine", so
the implication I see is that you can write "subroutines" in any language,
and call them [4].
And yes, you can run a 6502 program using SWEET16---you just need to
interpret 6502 code (although that's typically called an "emulator" [5]).
-spc (SWEET16 is a simple 16-bit VM inside an Apple ][. I can run an
Apple ][ emulator on an Amiga, which itself is emulated on a virtual
PC running on a physical PC. At which point do the turtles stop?)
[1] Lua code is compiled into an internal representation, and it's this
"byte code" that Lua interprets directly. The actual byte code is
an implementation detail, as LuaJIT uses a completely different
form of bytecode prior to final conversion to native code [6].
[2] 6809 machine code
BASIC09 I-code
Pascal P-code
COBOL I-code
[3] Maybe by checking the type of code it is [2], and calling a
code-specific argument passing method to invoke it.
[4] In theory. Also in theory there is no difference between theory and
practice. In practice however ...
[5] Odd, isn't it? If the CPU can interpret the binary data directly,
it's execution. If not, then it's interpretation, unless you are
trying to interpret the machine code for another machine, then it's
called emulation.
[6] The LuaJIT is a drop-in replacement for the standard Lua intepreter.
You can use either one interchangibly---even if you use Lua as a
library. You can either link against lua or luajit. Also, the code
LuaJIT produces is *fast* (although Lua itself is one of the fastest
interpreters out there) and can rival C code in some cases.