q4kx@vax5.cit.cornell.edu (Joel Sumner) (02/03/90)
With all of this talk about a Toolbox co-processor or something, how about
this: A chip that will take over all tasks that do not return parameters.
Example. It would execute all MoveTo(),LineTo(), calls while making the
65C816 think that those calls were done so it could move on to the next
instruction. That way the processor isn't bogged down doing graphics
calls or whatever and the applications should speed up.
I don't know much about how this may work except for one idea. Have all
JSR calls routed to this Toolbox coprocessor. If the argument for the JSR
is a toolbox call that returns no parameters, have it make the 65816 think
that an RTS instruction is the first instruction in the subroutine so the
65816 returns to whatever comes next in the program. At the same time, the
coprocessor exectues the Toolbox instruction.
If the JSR instruction is not one of those the coprocessor can hande,
have it just pass execution of the subroutine back to the 65816.
Problems with this plan.
-----------------------
Suppose the instructions are:
SetBackColor();
something:=GetBackColor;
Now we have a problem because the 65816 may very well be trying to
GetBackColor at the same time the coprocessor is trying to SetBackColor
possibly resulting in total gibberish or an incorrect result to GetBackColor
This may be solved by having the coprocessor halt operation of the 65816
if it receives a JSR in the queue before it is finished executing the first
JSR. That way you could not possibly have two Toolbox calls executing at
once.
Now, if anyone decides to skip toolbox commands or use them intermittently,
they may be in real trouble. Then again, that's what the toolbox is for
right?
Please comment on the viability or craziness of this idea. It's just a
thought [while donning my flame suit]
Joel Sumner
Q4KX@cornella.ccs.cornell.edu
Q4KX@cornella.bitnet
dlyons@Apple.COM (David A. Lyons) (02/05/90)
In article <3399.25c9904b@vax5.cit.cornell.edu> q4kx@vax5.cit.cornell.edu (Joel Sumner) writes: [How 'bout doing toolbox calls with hardware--asynchronously for the ones that don't return any information to the caller.] Getting control of the processor at the right times isn't a problem-- toolbox calls are dispatched through tables of addresses of the functions, and these can be patched to do whatever you want, including pointing them at small pieces of code that ask some hardware to do the work. Letting the application continue before the operation is complete is not appropriate for most existing toolbox calls, though (it would have to be synchronous). Doing stuff like QuickDraw II calls in hardware is far from trivial-- consider all the clipping to regions of any shape (and, if you're a 3rd-party developer, consider Apple's region-related patent). >Joel Sumner >Q4KX@cornella.ccs.cornell.edu >Q4KX@cornella.bitnet -- --David A. Lyons, Apple Computer, Inc. | DAL Systems Apple II Developer Technical Support | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
jason@madnix.UUCP (Jason Blochowiak) (02/12/90)
q4kx@vax5.cit.cornell.edu (Joel Sumner) writes: >With all of this talk about a Toolbox co-processor or something, how about >this: A chip that will take over all tasks that do not return parameters. > [I nuked the rest of the article] As Dave Lyons mentioned, this idea is fairly flawed. Although certainly possible (although it would be JSL/RTL, not JSR/RTS) with a few major changes, it would almost certainly not be economically feasible. What I think would be better would be something fairly simple, but RFF (really darn fast). Although regions couldn't be used in their entirety (unless Apple wanted to be _really_ nice to somebody), they could be transformed into something useable by hardware. I'm not sure exactly what hold Apple has on regions legally, but, seeing as regions are basically just area definitions (with, I believe, the possibility of being infinitely complex), they could be transformed into a bitmap, element by element. This could be done by either software or hardware - the engine would run through each element in the region and modify the bitmap accordingly. When that was done, the graphics operations could be performed using the bitmap. This almost certainly wouldn't help with region modification operations (intersection, union, etc.), but could make actual drawing RFF. Unless my memory is totally blown (entirely possible, folks), the elements used in the region definition and the elements used in drawing are basically the same (sans color/pattern info), the amount of hardware would be (roughly) proportional to the number of elements, plus some constant. That last paragraph wasn't exactly what I meant by something that's "fairly simple" - it's just a nice thought. By something fairly simple I meant a co-processor of some sort that would allow for memory moves (both skewed and normal) and basic logical ops (AND, OR, NOT, EOR). This would speed up the basic operations (and would be pretty cheap), allowing the CPU to play with the higher level stuff (this could also possibly give the System Software folks more time to optimize at a higher level - giving even greater speed improvements). I know that I've commented on this before, but it seems that a graphics-intensive machine without a graphics coprocessor is missing something. All of this is, of course, just my (vaguely educated) opinion. >Please comment on the viability or craziness of this idea. It's just a >thought [while donning my flame suit] Flames? People would have to be nuts to flame that. Everybody on the net is sane, rational, and polite, as been demonstrated a number of times. >Joel Sumner >Q4KX@cornella.ccs.cornell.edu >Q4KX@cornella.bitnet -- Jason Blochowiak - jason@madnix.UUCP or, try: astroatc!nicmad!madnix!jason@spool.cs.wisc.edu "Education, like neurosis, begins at home." - Milton R. Saperstein