ptorric wrote:
in my opinion the second byte can be used as a parameter for a BRK routine, some kind of indexed o.s. call
That is precisely what "is more trouble than its worth," according to Garth. And, I'm inclined to agree. To gain access to that byte, you need to preserve all your registers, pop the address from the stack, decrement it by one, read the byte (which requires 8-bit registers, thus requiring you switch modes if you're on a 65816), and branch based on that byte.
Alternatively, you could just do this:
Code:
LDX #syscall_foo
BRK
and be done with it. Inside the BRK handler, then:
Code:
JMP (table,X)
table:
.dw func1, func2, ..., funcFoo, ... funcX
This code will work with 8- or 16-bit registers, provided your syscall_X constants are even values and start from 0.
At any rate, since BRK is a genuine interrupt, you're going to impose some additional amount of overhead compared to a normal JSR or JSL. I think JSR/JSL is preferable for nearly everything I can think of, except when having to deal with memory banking (since the processor's VP# signal can trigger external MMU hardware to a known-good, supervisory-compatible state) and thread-switching (since BRK pushes P onto the stack for you, thus saving you the 3 cycles you'd impose otherwise through PHP). Thus, BRK makes a great entry-point for a microkernel, but everything above the microkernel layer is, perhaps, better implemented through JSR/JSL calls.
Anyway, that's my take on it.
Login
Register
FAQ
Search
