On 8 Feb 2012 at 16:36, Eric Smith wrote:
It is true that you can't run mixed SWEET16 and
6502 code on such a
setup, unless you simulate the 6502 also, but that's beside the point.
SWEET16 code is NOT native 6502 code, even though it usually is run
on an interpreter on a 6502.
That's precisely the point--the program starts out in 6502 native
mode. It calls (via JSR) a subroutine (SWEET16) that goes through
the argument list (follows the JSR) until the end.
If that's not native code, then neither is a printf(), which is
invoked via a native-mode CALL instruction, which then interprets the
string passed as an argument.
I suppose you could argue that printf() is executing printf
instructions and not native code, but that seems to be stretching the
point.
I can similarly run a sequence similar to the following (and I have):
CALL DoSomething
integer operation-one
address operand-one
address operand-two
integer operation-two
address operand-one
address operand-two
address operand-three
0
But let's get back to my original proposal. Suppose I want to
implement an indirect fetch-and-postincrement operation corresponding
to C *p++.
I could write (in 8080 pseudocode):
RST 5
db increment-and-fetch code
dw address of pointer
and write a servicer for RST 5 that would execute a short subroutine
that would fetch the pointer, load and return the byte it points to
and then increment and store the pointer. If fetch-and-increment-
pointer is a common operation, I can potentially save a large amount
of code.
It's not emulation.
That you need to use emulation to execute a 6502 program on a
different platform should be the clue.
--Chuck