8 Feb
2012
8 Feb
'12
4:22 p.m.
On 8 Feb 2012 at 16:02, Eric Smith wrote:
Chuck Guzis wrote:
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.
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.
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!
--Chuck
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.