Code for a Job Handler -- Locator

[commodorejohn]

Plus, saving three bytes per system call is fairly non-negligible on an architecture where the maximum possible memory size is 16MB and typical sizes are more like 64-512KB.

[BigDumbDinosaur]

whartung wrote:

BigDumbDinosaur wrote:

The main value in using COP for API calls is nothing special has to be done to call an API from another bank. All of that is handled for you due to COP being just another interrupt.

Is the problem that the caller simply doesn't have to distinguish between JSR and JSL?

That's part of it. The API backend also has to distinguish between the two, since the return from JSL (RTL) has to pull one more byte from the stack than does RTS. Also consider that JSL is a four-byte instruction, whereas COP is a two-byte instruction. Furthermore, if one has to JSL to an API then it is implied the kernel must be loaded to an immutable location.

Contrary to one might think, using JSL to call an API function confers no performance advantage over COP—both instructions require eight clock cycles to execute. Use of COP automatically pushes SR to the stack, which may be important in an API call from which some sort of "error" status is to be returned (usually via the carry bit). However, in native mode, RTL is one clock cycle faster than the RTI needed to return following an interrupt. On the other hand, since RTI automatically restores SR, the two cycles that would be required to "manually" pull SR as part of a JSL/RTL return are avoided.

COP also offers the possibility of a change in machine state when an OS API is called. During cycles 7 and 8 of COP, the 65C816's VPB output is driven low to indicate an interrupt vector is being fetched. This same signal could be used to switch the hardware protection, if present, from user to kernel mode. How would you do this if the API is called via JSL, especially when you consider the fact that the kernel address space should be protected from user-space accesses?

[Chromatix]

As a point of order, the performance cost quoted for using COP/RTI doesn't include the cost of dispatching on the argument of COP. Since there is no "indirect long via stack" addressing mode, accessing that argument is not trivial, and probably requires pushing/restoring DPR. A JSL call would be direct to a well-known entry point specific to the routine required, though this may itself merely be a jump to the real code.

[BigEd]

(I think we said upthread that the COP argument byte isn't much use, for that very reason.)

[Chromatix]

In which case, how *do* you handle more than one routine, given that COP only provides a single entry point? You have to stuff a code into a well-known location in memory, or sacrifice a register to it. And you still need to index a jump table (or something) to get to the routine itself. All of these are costly to some degree.

So I think the performance argument for COP is bogus. The other arguments may have merit.

[BigDumbDinosaur]

Chromatix wrote:

In which case, how *do* you handle more than one routine, given that COP only provides a single entry point? You have to stuff a code into a well-known location in memory, or sacrifice a register to it. And you still need to index a jump table (or something) to get to the routine itself. All of these are costly to some degree.

So I think the performance argument for COP is bogus. The other arguments may have merit.

I already posted example code illustrating how it could be done. In any case, no one is claiming that use of COP confers performance advantages over JSL/RTL. What it confers is flexibility.

Anyhow, this line of discussion should be terminated here and resumed over here.