toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (05/22/91)
Here's an idea (directed mainly at Dave since he's in a position to forward it where it might do some good) about a future direction for the Text Tools. Most of us know that the GS/OS team strongly discourages the use of the Text Tools, mainly because they are butt-slow and don't like the idea of slot arbitration. Yet, Orca (and therefore APW) use them for I/O redirection because those programs were written before the standard prefixes and the Console driver were available, as were other text-only apps (of which there aren't too many). Also, the Text Tools are extremely convenient compared to GS/OS driver calls. The idea is this: extend the Text Tools to make GS/OS device calls on behalf of the application where appropriate -- internal slot 3 would use the standard prefix for the device that is being set, and requests for other slots would search the device list for loaded drivers claiming the requested slot. If only a generated driver (or no driver) is available, then the firmware is used. This is an extension on the concept behind the MIDI Toolset, and it would solve a lot of problems for Orca/APW EXEs -- I/O redirection for PD shells would be trivial and backwards compatible, and since the console driver is nice and fast we wouldn't need the FasText init any more. Todd Whitesel toddpw @ tybalt.caltech.edu
jb10320@uxa.cso.uiuc.edu (Jawaid Bazyar) (05/23/91)
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: >Here's an idea (directed mainly at Dave since he's in a position to forward it >where it might do some good) about a future direction for the Text Tools. >Most of us know that the GS/OS team strongly discourages the use of the Text >Tools, mainly because they are butt-slow and don't like the idea of slot >arbitration. Yet, Orca (and therefore APW) use them for I/O redirection because >those programs were written before the standard prefixes and the Console driver >were available, as were other text-only apps (of which there aren't too many). >Also, the Text Tools are extremely convenient compared to GS/OS driver calls. You hit the nail quite squarely on the head. ToolBox overhead isn't negligible, but GS/OS overhead is not something I want to deal with on a character by character basis. >The idea is this: extend the Text Tools to make GS/OS device calls on behalf >of the application where appropriate -- internal slot 3 would use the standard >prefix for the device that is being set, and requests for other slots would >search the device list for loaded drivers claiming the requested slot. If only >a generated driver (or no driver) is available, then the firmware is used. >This is an extension on the concept behind the MIDI Toolset, and it would solve >a lot of problems for Orca/APW EXEs -- I/O redirection for PD shells would be >trivial and backwards compatible, and since the console driver is nice and fast >we wouldn't need the FasText init any more. I agree with the points about slot arbitration, etc, in regards to the Text Tools. But what I don't understand is why something like FasText isn't already a standard part of the system. It's trivial to implement, and completely unobtrusive. I have a bit of a philosophical problem with the console driver- it's pretty darn high level to be a device driver. I'll have no complaints if a way to patch out the lowest level I/O routines is available- otherwise I'll have the heinous task of reproducing the functionality of the console driver. NOT something I particularly care to do. Apple's big thing over the years has been expandability and ease of enhancement- that ideal seems to have been forgotten in the design of the console driver. Now, if I'm missing something here (i.e. if there IS a way to change low-level I/O in the Console Driver) punish me like I deserve. But until then, I stand by my original assertion that Westerfield's use of the Console Driver in his utilities will be bad for our project. (BTW, stupid annoying Illinois Bell blew up my phone. "We'll send someone out sometime between today and tomorrow to fix it" doesn't allow me to talk to Mike.) -- Jawaid Bazyar | "Twenty seven faces- with their eyes turned to Graduated!/Comp Engineering | the sky. I have got a camera, and an airtight bazyar@cs.uiuc.edu | alibi.." Apple II Forever! | I need a job... Be privileged to pay me! :-)
meekins@anaconda.cis.ohio-state.edu (Tim Meekins) (05/23/91)
In article <1991May22.224402.12467@ux1.cso.uiuc.edu> jb10320@uxa.cso.uiuc.edu (Jawaid Bazyar) writes: > Now, if I'm missing something here (i.e. if there IS a way to change low-level >I/O in the Console Driver) punish me like I deserve. But until then, I >stand by my original assertion that Westerfield's use of the Console Driver >in his utilities will be bad for our project. I would think it would also be bad for Mike. Afterall, there ARE shell utilities in existence which Mike didn't write (heaven forbid!). Can you say APW C? Gee, it doesn't use GS/OS console drivers..what happens if I compile something under APW/C while using Orca/Shell 2.0? For those who are interested, I just finished completely patching the text tools for the GNO project, it is now running 2 to 3 times faster than fasttext. It has to be seen to believed... -- ++------------S-U-P-P-O-R-T---S-H-A-R-E-W-A-R-E---O-R---D-I-E-!-----------++ || Tim Meekins || Snail Mail: || Apple II || || meekins@cis.ohio-state.edu || 8372 Morris Rd. || Forever! || \\___timm@pro-tcc.cts.com________/\____Hilliard, OH 43026__/\_____________//
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (05/23/91)
jb10320@uxa.cso.uiuc.edu (Jawaid Bazyar) writes: >You hit the nail quite squarely on the head. ToolBox overhead isn't negligible, >but GS/OS overhead is not something I want to deal with on a character by >character basis. What the?? My idea was that TextTools calls would fill in DWrite or DRead call blocks and ship the entire string, block, etc., to the device driver or standard prefix in one shebang so the call overhead is minimized while retaining the convenience of Tool calls and the speed/flexibility of loaded drivers (when available) and the standard prefixes. I suspect you're just pathologically worried about programs explicitly opening .CONSOLE so your speedy text routines won't have total control of the screen. I submit you're going to have to deal with this anyway so you're better off figuring out how to use the .CONSOLE driver to advantage rather than insisting on replacing it entirely!! Just what is it that you have to do that is so easily endangered by the console driver? If it's simply screen saving and restoring for process swaps, I don't see what the problem is. Todd Whitesel toddpw @ tybalt.caltech.edu
dat33228@uxa.cso.uiuc.edu (Derek A. Taubert) (05/24/91)
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: >I suspect you're just pathologically worried about programs explicitly opening >.CONSOLE so your speedy text routines won't have total control of the screen. >I submit you're going to have to deal with this anyway so you're better off >figuring out how to use the .CONSOLE driver to advantage rather than insisting >on replacing it entirely!! Just what is it that you have to do that is so >easily endangered by the console driver? If it's simply screen saving and >restoring for process swaps, I don't see what the problem is. Not quite. Think about multiple processes running at the same time. How do you control who writes to the screen? You patch the TextTools. -- + Derek Taubert --> derek@mrcnext.cso.uiuc.edu + Author of : GScii+ + + dat33228@uxa.cso.uiuc.edu + and the world's most useless + ++++++++++++++++++++++++++++++++++++++++++++++++ desk accessory -> Amaze me + + There are MOUSE technotes? + *******8-) ++++++++++++++++++++++++++++++++ + Ask me about my GS load meter + ^^^^^^^^^^ Marge Simpson +
jb10320@uxa.cso.uiuc.edu (Jawaid Bazyar) (05/24/91)
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: >What the?? My idea was that TextTools calls would fill in DWrite or DRead >call blocks and ship the entire string, block, etc., to the device driver >or standard prefix in one shebang so the call overhead is minimized while >retaining the convenience of Tool calls and the speed/flexibility of loaded >drivers (when available) and the standard prefixes. That's reasonable. I was evidently rambling... but still doesn't fix my problem. >I suspect you're just pathologically worried about programs explicitly opening >.CONSOLE so your speedy text routines won't have total control of the screen. >I submit you're going to have to deal with this anyway so you're better off >figuring out how to use the .CONSOLE driver to advantage rather than insisting >on replacing it entirely!! Just what is it that you have to do that is so >easily endangered by the console driver? If it's simply screen saving and >restoring for process swaps, I don't see what the problem is. I'm not concerned about output. I'm concerned about input. Let's say, we have lots of programs running. Program A is unbinsciing a file (just for example), and Program B is doing some user interface stuff. Program B makes a call to the Console Driver. All other processes stop, because we have to turn off task switching during GS/OS calls (becuase we don't know which calls are reentrant, and which are not- I suspect none of them are). So while the user is fiddling 'round with input, he's not getting any work done. Sort of the antithesis of what we're trying to accomplish. I don't hold convictions trivially. And I didn't say I wanted to replace it- I said (in my latest word on the subject) that I'd like a way to patch the lowest level I/O so I can have a bit of control over this. -- Jawaid Bazyar | "Twenty seven faces- with their eyes turned to Graduated!/Comp Engineering | the sky. I have got a camera, and an airtight bazyar@cs.uiuc.edu | alibi.." Apple II Forever! | I need a job... Be privileged to pay me! :-)
ericmcg@pnet91.cts.com (Eric Mcgillicuddy) (05/25/91)
>B makes a call to the Console Driver. All other processes stop, because >we have to turn off task switching during GS/OS calls (becuase we don't know >which calls are reentrant, and which are not- I suspect none of them are). That is not neccessary, as long as you can prevent other processes from accessing the toolbox or making GS/OS calls while they are in use. As far as I can tell Calls do not use a processes zero page space for anything, they steal a bit of stack space, usually less than $20 bytes (Memory Manager is the only one I have seen in depth though). I don't care much stack space is taken since it would be grabbed if this was a single task anyhow, the problem is with the Work area memory assigned during boot (or tool initialization). Thsi is global to all processes accessing a given Toolset and can not be counted to be in any given state if more than one access is made to it simultaneously. I believe there is a flag that tells whether the tools are in use, something like the "prodos busy" flag I assume, if not then a small patch to the tool dispatcher and a global flag could easily be installed. If the flag is set, then the called process is immediately suspended (it should be possible to determine the process state prior to the call from the parameters on the stack and thus reset the state to just prior to making the call, this allows the process to run again at a later date and the dispatcher will again check the flag. A strictly fair queue can be established if one wishes to be fancy to insure that no process is ever locked out for more than one tool call, an alternate Call Pending flag that is test if the Toolbox busy flag is clear). This should allow both pre-emptive and co-operative multitasking to be used. UUCP: bkj386!pnet91!ericmcg INET: ericmcg@pnet91.cts.com
dlyons@Apple.COM (David A Lyons) (05/28/91)
In article <767@generic.UUCP> ericmcg@pnet91.cts.com (Eric Mcgillicuddy) writes: >[toolbox] Calls do not use a processes zero page space for anything, they steal >a bit of stack space, usually less than $20 bytes (Memory Manager is the only >one I have seen in depth though). Correct, tool calls frequently use space on the caller's stack (sometimes much more than 32 bytes...more like half a K for Standard File, since it calls the Dialog Manager, and the Dialog Manager uses a whole page). But the caller's direct page is off-limits, and the D register could actually point into ROM or softswitches, or overlap the stack in some inconvenient way. (That's why, in general, it is *not* okay to "borrow" direct-page locations, preserving and restoring them, if you don't know where D points! Very unsafe!) >[...] >there is a flag that tells whether the tools are in use, something like the >"prodos busy" flag I assume, if not then a small patch to the tool dispatcher >and a global flag could easily be installed. If the flag is set, then the >called process is immediately suspended There is a system BUSY flag managed by calling INCBUSY and DECBUSY, and a lot of tool sets use it. Hopefully it is used everywhere it should be, but I suspect there are a few non-reentrant calls that fail to use it, and such problems probably won't show up until somebody stress-tests it by writing something that depends on it. Note that the BUSY flag is frequently nonzero for long periods of time. For example, while a ChooseFont or Standard File dialog is up, or when you're waiting for a key inside ReadChar. -- David A. Lyons, Apple Computer, Inc. | DAL Systems Apple II System Software Engineer | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie:DAVE.LYONS CompuServe:72177,3233 Internet:dlyons@apple.com My opinions are my own, not Apple's.
jh4o+@andrew.cmu.edu (Jeffrey T. Hutzelman) (05/30/91)
I have something that uses it, archived on disk here. It's the context switching code from LWP/GS, which uses both the toolbox's and GS/OS's busy flags to make sure it doesn't do a switch in the middle of an OS or tool call. I'd be happy to upload the current version of the code somewhere if it will help you guys eliminate toolbox bugs. Now that I have my machine back, I'll be finishing some changes I wanted to make, including saving/restoring the current GrafPort so that more than one process can draw. .
ericmcg@pnet91.cts.com (Eric Mcgillicuddy) (05/30/91)
>Note that the BUSY flag is frequently nonzero for long periods of time. >For example, while a ChooseFont or Standard File dialog is up, or when >you're waiting for a key inside ReadChar. >-- >David A. Lyons, Apple Computer, Inc. | DAL Systems What about GetNextEvent or TaskMaster? Would the ADB Manager be set to use interupts for inputs rather than busy-waiting polling loops? What about interupts for other I/O such as serial ports? I am getting intrigued by this talk of multitasking on the GS. I would like to see pre-emptive (with constraints as mentioned previously), but Multi-Finder would be OK. UUCP: bkj386!pnet91!ericmcg INET: ericmcg@pnet91.cts.com
dlyons@Apple.COM (David A Lyons) (05/30/91)
In article <scF47e_00UiiQWBFs3@andrew.cmu.edu> jh4o+@andrew.cmu.edu (Jeffrey T. Hutzelman) writes: >I have something that uses it, archived on disk here. It's the context >switching code from LWP/GS, which uses both the toolbox's and GS/OS's busy >flags to make sure it doesn't do a switch in the middle of an OS or tool call. >I'd be happy to upload the current version of the code somewhere if it will >help you guys eliminate toolbox bugs. Now that I have my machine back, I'll >be finishing some changes I wanted to make, including saving/restoring the >current GrafPort so that more than one process can draw. Sure, I'd like to see what you've got. But saving and restoring the current port is only the tip of the iceberg if you're trying to allow use of the toolbox by multiple applications. -- David A. Lyons, Apple Computer, Inc. | DAL Systems Apple II System Software Engineer | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie:DAVE.LYONS CompuServe:72177,3233 Internet:dlyons@apple.com My opinions are my own, not Apple's.