rhyde@ucrmath.ucr.edu (randy hyde) (12/10/90)
All you need to do multitasking on a II is a timer interrupt. I used an old 6840 timer chip on a board from some (now history) peripheral manufacturer. I managed to get four processes running at once (at $800, $2000, $4000, and $6000). Needless to say, these processes were highly aware of one another. I did not attempt to take the project any farther than that. To truely implement multitasking on the II you need either memory management or specially written applications. I didn't have memory management and I wasn't willing to write all the software myself. When the GS came out, I said "aha, reasonable memory management" and attempted to write "Multi-ANIX". Alas, GS/OS has some problems with multiprogramming so I eventually scrapped that project as well (Although GS/OS does not allow true multi-tasking or multiprogramming, it can support light-weight processes very well). *** Randy Hyde O-)
gwyn@smoke.brl.mil (Doug Gwyn) (12/11/90)
In article <10425@ucrmath.ucr.edu> rhyde@ucrmath.ucr.edu (randy hyde) writes: >All you need to do multitasking on a II is a timer interrupt. >... To truely implement multitasking on the II you need either >memory management or specially written applications. This is simply not true. Timer interrupt is needed only for preemptive scheduling, but multitasking does not have to be preemptive. Memory management offers protection for one task against bugs in another, but this is more a convenience than a necessity. The terminal I am typing this on is truly multitasking, and it uses neither timer interrupts nor memory management.
alfter@uns-helios.nevada.edu (SCOTT ALFTER) (12/11/90)
In article <10425@ucrmath.ucr.edu> rhyde@ucrmath.ucr.edu (randy hyde) writes: >All you need to do multitasking on a II is a timer interrupt. >I used an old 6840 timer chip on a board from some (now history) >peripheral manufacturer. I managed to get four processes running >at once (at $800, $2000, $4000, and $6000). Needless to say, these >processes were highly aware of one another. I did not attempt to >take the project any farther than that.... Sounds like there might be a use for the Thunderclock's interrupt generator after all--it'll make interrupts at any of 3 rates from 60 to 2400 Hz. Set aside some memory to maintain information on each process, and write an interrupt daemon to switch processes, and it ought to work. It also ought to run at a reasonable speed since the processor is giving all its attention to one process until the interrupt comes along to give it something else to work on. It might even be possible to get this thing to work under ProDOS. Considering how slow some programs (such as some of pbmplus's image-manipulation tools) run on even a 68030, I don't think I'd want to try writing UNIX to run on an unaccelerated II. :-| ----------------------------------------------------------------------------- Scott Alfter _/_ / v \ Apple II: Internet: alfter@uns-helios.nevada.edu ( ( the power to be your best! GEnie: S.ALFTER \_^_/
jpenne@ee.ualberta.ca (Jerry Penner) (12/11/90)
In article <14705@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >In article <10425@ucrmath.ucr.edu> rhyde@ucrmath.ucr.edu (randy hyde) writes: >>All you need to do multitasking on a II is a timer interrupt. >>... To truely implement multitasking on the II you need either >>memory management or specially written applications. > >This is simply not true. Timer interrupt is needed only for preemptive >scheduling, but multitasking does not have to be preemptive. Memory Non-preemptive multitasking is not much fun. Especially since we have zillions of programs out there for the GS & other IIs that know nothing about it. They would never give the CPU back. Pre-emptive multitasking is VERY desireable. >management offers protection for one task against bugs in another, but >this is more a convenience than a necessity. ^^^^^^^^^^^^ ^^^^^^^^^ Not quite. Maybe if you only write your own software or can afford to have some other program crash another one. It is a necessity when reliability is considered. And it sure makes life a LOT easier for software developers. This must be taken into account when designing a system. Otherwise, only a few will write for it. >The terminal I am typing this on is truly multitasking, and it uses >neither timer interrupts nor memory management. -- ------------- Jerry Penner ...!alberta!bode!jpenne
gwyn@smoke.brl.mil (Doug Gwyn) (12/11/90)
In article <1990Dec11.004650.8077@ee.ualberta.ca> jpenne@ee.ualberta.ca (Jerry Penner) writes:
-Non-preemptive multitasking is not much fun. Especially since we have zillions
-of programs out there for the GS & other IIs that know nothing about it. They
-would never give the CPU back. Pre-emptive multitasking is VERY desireable.
Leapfrog demonstrated that the processes don't have to be aware of the
scheduling. Almost any sensible application is going to make frequent
calls to the OS and ToolBox, providing a nice opportunity for rescheduling.
->management offers protection for one task against bugs in another, but
->this is more a convenience than a necessity.
-Not quite. Maybe if you only write your own software or can afford to have
-some other program crash another one. It is a necessity when reliability is
-considered. And it sure makes life a LOT easier for software developers.
-This must be taken into account when designing a system. Otherwise, only a
-few will write for it.
People are used to PCs crashing during software development. I stand by
what I said.
->The terminal I am typing this on is truly multitasking, and it uses
->neither timer interrupts nor memory management.
It also seldom crashes or hangs..rhyde@ucrmath.ucr.edu (randy hyde) (12/13/90)
>>Timer interrupt is needed only for preemptive scheduling...
I don't want to start an rwar on what is and what isn't "true" multitasking...
But let me explain my terminology (which, btw, has a historical basis):
Multitasking- The ability of more than one job to execute at a time without
explicitly requiring another job to give up the computer (i.e., pre-emptive
based on priority, timer, or even explicit operations like I/O).
Multiprocessing-the ability for several processes to execute concurrently
on different processors.
Multiprogramming- the ability for multiple programs to run concurrently, but
each process must explicitly give up the CPU.
People tend to call multiprogramming "non-preemptive multitasking" or, perhaps,
"cooperative multitasking." To avoid confusion I always use the correct term.
*** randy Hyde O-)gwyn@smoke.brl.mil (Doug Gwyn) (12/13/90)
In article <10548@ucrmath.ucr.edu> rhyde@ucrmath.ucr.edu (randy hyde) writes: >>>Timer interrupt is needed only for preemptive scheduling... >I don't want to start an rwar on what is and what isn't "true" multitasking... Before carrying this any further, go LOOK at a member of the "Blit" family of dot-mapped display terminals running in "layers" mode, e.g. AT&T Teletype model 5620 or 630, then ask yourself if such performance would meet your wishes for an Apple IIGS multitasking environment. These are true multitasking computers WITHOUT timer- interrupt scheduling. I am intimately familiar with their design, and assure you that an Apple IIGS has all the necessary hardware to support such an operating environment.
rhyde@ucrmath.ucr.edu (randy hyde) (12/13/90)
>> An Apple //gs has all the necessary hardware to support such >> an operating environment... Gee... The Apple //gs even has a timer interrupt. It could easily support pre-emptive multitasking. Hardware isn't the problem, *SOFTWARE* is the problem. GS/OS cannot support multiple processes without some *MAJOR* hacks. Sure, you can easily get a multiprogramming demonstration running just fine, but the system is not robust enough for commercial quality work. No developers would support multiprogramming unless it was very robust. *** Randy Hyde O-)
floyd@pawl.rpi.edu (Patrick J Wetmore) (12/13/90)
In article <10563@ucrmath.ucr.edu> rhyde@ucrmath.ucr.edu (randy hyde) writes: >>> An Apple //gs has all the necessary hardware to support such >>> an operating environment... > >Gee... The Apple //gs even has a timer interrupt. It could easily >support pre-emptive multitasking. Hardware isn't the problem, >*SOFTWARE* is the problem. GS/OS cannot support multiple processes >without some *MAJOR* hacks. >*** Randy Hyde O-) Bull. The apple iigs (curse its evil presence. I hate hate hate it. Infernal lousy piece of... growl snarl.) has no protected memory, and no virtualling hardware. Any machine can multitask, but without the proper memory architecture the thing will be completely useless. Plus, the damnable thing is so slow. It plods. Pat Wetmore PS I hate the damn keyboard bus on this thing. -- +------------------+ Could you fancy me as a pirate bold |Patrick J. Wetmore| Or a longship Viking warrior with the old gods on his side |floyd@pawl.rpi.edu| Well, I'm an inshore man and I'm nobody's hero +------------------+ But I'll make you tight for a windy night and a dark ride
unknown@ucscb.UCSC.EDU (The Unknown User) (12/13/90)
In article <&RF^T6-@rpi.edu> floyd@pawl.rpi.edu (Patrick J Wetmore) writes: >Bull. The apple iigs (curse its evil presence. I hate hate hate it. Infernal >lousy piece of... growl snarl.) has no protected memory, and no virtualling >hardware. Any machine can multitask, but without the proper memory >architecture the thing will be completely useless. Plus, the damnable >thing is so slow. It plods. I realize that this is going to be a "I think, I'm pretty sure" type of post (i.e. I'm not positive of any of my facts)... but bear with me. I believe that the original IBM PC can run Xenix... At least some of the "lower" IBM PCs can, I'm sure of that... And I'm also under the impression that IBM PCs have nothing in the way of memory protection... So since they seem to run Xenix well, it seems that blows your argument out of the water. BESIDES, a 68881 card (that will actually fit in the 65816 connector space) is being built and that'll deal with all of the protected memory problems... -- /Apple II(GS) Forever! unknown@ucscb.ucsc.edu MAIL ME FOR INFO ABOUT CHEAP CDs\ |WRITE TO ORIGIN ABOUT ULTIMA VI //e and IIGS! Mail me for addresses, & info. | \ "Dammit Bev, is it you inside or is it the clown?" -IT by Stephen King /
floyd@pawl.rpi.edu (Patrick J Wetmore) (12/13/90)
In article <10063@darkstar.ucsc.edu> unknown@ucscb.UCSC.EDU (The Unknown User) writes: > > I realize that this is going to be a "I think, I'm pretty sure" >type of post (i.e. I'm not positive of any of my facts)... but bear with me. You should have kept your mouth shut. > > I believe that the original IBM PC can run Xenix... At least some >of the "lower" IBM PCs can, I'm sure of that... > > And I'm also under the impression that IBM PCs have nothing in >the way of memory protection... So since they seem to run Xenix well, it >seems that blows your argument out of the water. Yah, you can run it fine, until a poitner gets screwed and zaps something in another processes memory. Then you get crashes. If it worked just fine, we wouldn't have MMUs, would we? > > BESIDES, a 68881 card (that will actually fit in the 65816 >connector space) is being built and that'll deal with all of the protected >memory problems... Well, now, lots of things are 'being built'. There is mucho IIGS vaporware that has been supposed to 'be built'. Never put faith in a GS product until its actually released, because they rarely are. I've watched planned projects go down the tubes for the last two and half years i've had the machine again and again. The GS is not a profitable machine. There are much better machines much more geared towards multitasking. I shudder to think of UNIX on the plodding beast. The GS is overpriced and overrated. (Well, I got mine free. So, you know, what the hell, I took it. Won't ever make that mistake again.) > >-- >/Apple II(GS) Forever! unknown@ucscb.ucsc.edu MAIL ME FOR INFO ABOUT CHEAP CDs\ >|WRITE TO ORIGIN ABOUT ULTIMA VI //e and IIGS! Mail me for addresses, & info. | >\ "Dammit Bev, is it you inside or is it the clown?" -IT by Stephen King / Patrick Wetmore, another unfortunate IIGS owner (fortunately not deluded) -- +------------------+ Could you fancy me as a pirate bold |Patrick J. Wetmore| Or a longship Viking warrior with the old gods on his side |floyd@pawl.rpi.edu| Well, I'm an inshore man and I'm nobody's hero +------------------+ But I'll make you tight for a windy night and a dark ride
alfter@uns-helios.nevada.edu (SCOTT ALFTER) (12/13/90)
In article <7TF^W^=@rpi.edu> floyd@pawl.rpi.edu (Patrick J Wetmore) writes: >and again. The GS is not a profitable machine. There are much better machines >much more geared towards multitasking. I shudder to think of UNIX on the >plodding beast. The GS is overpriced and overrated. (Well, I got mine free. >So, you know, what the hell, I took it. Won't ever make that mistake again.) >[...] >Patrick Wetmore, another unfortunate IIGS owner (fortunately not deluded) setenv FLAME on If the machine is so lousy, then what the hell are you doing using it? Also, why are you polluting this newsgroup with your "Apple IIs suck" drivel? I've only seen two of your posts and already I get the feeling you're the Mac or MeSsy-DOS invader who's trying to put down everyone's choice of machine. Nobody is forcing you to use your GS. If you don't like it, then use it only as a terminal to access your mainframe. (Better yet, send it to me; I can appreciate the machine for what it is. :-) ) I'm not trying to sound defensive, but if you have nothing positive to add to this newsgroup, I'd suggest that you just shut the fuck up. setenv FLAME off (sorry about the disturbance to all the others who read this) Scott Alfter-----------------------------_/_---------------------------- / v \ Apple II: Internet: alfter@uns-helios.nevada.edu ( ( the power to be your best! GEnie: S.ALFTER \_^_/
rhyde@ucrmath.ucr.edu (randy hyde) (12/14/90)
>>Bull. ... The machine can multitask...but it would be worthless.
That's what I've been saying all along. I was only answering the
question "Is it possible at all?"
For those who really want to multitask an Apple II GS, let met
offer an alternative: multiprocess. Go buy another GS and run
your multiple programs on multiple machines at the same time!
*** Randy Hyde O-)gwyn@smoke.brl.mil (Doug Gwyn) (12/14/90)
In article <&RF^T6-@rpi.edu> floyd@pawl.rpi.edu (Patrick J Wetmore) writes: >Bull. The apple iigs (curse its evil presence. I hate hate hate it. Infernal >lousy piece of... growl snarl.) has no protected memory, and no virtualling >hardware. Any machine can multitask, but without the proper memory >architecture the thing will be completely useless. Plus, the damnable >thing is so slow. It plods. Again, you shouldn't make pronouncements about these things if you don't have the practical experience to back it up. There is no MMU in the Blit multitasking terminals either, but they multitask fine and are FAR from "useless". (Indeed, I use one as my primary user interface to a Sun workstation, in preference to the Sun's famous graphic windowing interface.) As I type this in one window running a news system interface, another window is running an alarm clock, another has the "sam" bitmap mouse-driven text editor running in it, another has a dynamic system load monitor (smoothly varying bar graph), another has a screen-dump printer interface, and another has a pair of "eyes" that always look toward the mouse cursor. (Of course I could have had different applications running; this happens to be what I'm actually using at the moment.) These windows appear to operate SIMULTANEOUSLY, asynchronously, and without overlap interference (unlike many windowing systems, the process associated with a window need not take any action to redraw uncovered portions). As a reminder, the processor in Blit terminals is not significantly more powerful than a 65816, and the other hardware is quite simple, with no use of timer interrupts or memory management unit. If the IIGS hardware had been exploited by Apple to the extent that the Blit terminal hardware was exploited by AT&T, we would have a wonderful user environment. Instead, the mickey-mouse Macintosh notion of one active process at a time (with the only multitasking provision the "desk accesories") must have been foremost in the minds of the IIGS developers at Apple. While it is true that GS/OS is not designed with multitasking in mind, it also doesn't particularly get in the way. A multitasking monitor (meaning system module, not display) could use GS/OS for storage- device access, for example. At least the IIGS does use a centralized memory manager, so that concurrent tasks can be loaded without interference. Since the 65816 architecture has an inherently limited supply of direct-page memory, probably a multitasking monitor ought to switch direct pages as part of task context. IIGS multitasking is eminently doable, but should be undertaken only by experienced OS designers.
rhyde@ucrmath.ucr.edu (randy hyde) (12/14/90)
>> Nothing positive to add .. shut **** up.
Please don't tell anyone to shut up. As much as I hate the amount
of noise in this conference, I encourage everyone to speak their
mind. That's one thing nice about living in the USofA.
For those who think *I* blast the GS, let me point out that I do not
consider the GS a *lousy* machine. It's a nice machine. Alas, it
is not as nice as most other machines I own. Furthermore, it is
not cost effective compared to other, better, machines. I don't
see any reason to sell my GS, OTOH, I can't recommend that anyone
else buy one as their first machine, either.
*** Randy Hyderankins@argentina (raymond r rankins) (12/14/90)
In article <7TF^W^=@rpi.edu>, floyd@pawl (Patrick J Wetmore) writes: >In article <10063@darkstar.ucsc.edu> unknown@ucscb.UCSC.EDU (The Unknown User) writes: >> I believe that the original IBM PC can run Xenix... At least some >>of the "lower" IBM PCs can, I'm sure of that... >> >> And I'm also under the impression that IBM PCs have nothing in >>the way of memory protection... So since they seem to run Xenix well, it >>seems that blows your argument out of the water. > >Yah, you can run it fine, until a poitner gets screwed and zaps something >in another processes memory. Then you get crashes. If it worked just fine, >we wouldn't have MMUs, would we? Well, I've got to agree with you on that one. I was once running a precursor to Xenix, PC/IX, on an XT one time and had a pointer go out of bounds. It ended up trashing the hard drive and I lost 2 weeks worth of work. >.... The GS is overpriced and overrated. (Well, I got mine free. >So, you know, what the hell, I took it. Won't ever make that mistake again.) >.... >Patrick Wetmore, another unfortunate IIGS owner (fortunately not deluded) If you don't like the machine, why don't you sell it to someone who would and buy yourself a cheap 286/386 clone? It seems like such a waste to own a piece of hardware that you don't like to use. Personally, I do not feel "unfortunate" or "deluded" because I own and actually like my IIGS. It does for me everything I need it to do and everything that I expected of it when I bought it. If a personal computer can meet a users needs in this way, it's a good computer. Who the hell cares if it can run UNIX or not if that's not what you bought it for? Ray Ray Rankins |(518) 387-7174 | INTERNET: rankins@argentina.crd.ge.com 2 Moonglow Rd. |(518) 583-3320 | COMPUSERVE: 71131,3236 Gansevoort, NY 12831 | | AmericaOnline: RayRankins <insert standard disclaimer here> | GEnie: R.Rankins
gwyn@smoke.brl.mil (Doug Gwyn) (12/14/90)
In article <7TF^W^=@rpi.edu> floyd@pawl.rpi.edu (Patrick J Wetmore) writes: >> I believe that the original IBM PC can run Xenix... >Yah, you can run it fine, until a poitner gets screwed and zaps something >in another processes memory. Then you get crashes. If it worked just fine, >we wouldn't have MMUs, would we? MMUs serve several purposes, interprocess protection being merely one of them, and relatively unimportant at that in a single-user (albeit multitasking) environment. There have been many implementations of UNIX, UNIX-like, and other multitasking operating systems without use of an MMU; I believe "MiniUNIX" was described in the 1978 BSTJ UNIX special issue, and Whitesmiths' Idris was another such system from roughly the same time frame. While it is convenient to have an amok task aborted without adverse effect on other concurrent tasks or the OS kernel, it is certainly not necessary under normal situations. My normal working environment is a fully-protected UNIX system that would abort tasks that attempt to use pointers out of their own address space, and I almost never see a task aborted for that reason. Without an MMU, the main difference in operation is that relocation must be provided as task images are loaded into memory for execution (except if position-independent code is involved, but normally that imposes too stiff a speed penalty and requires cooperating compilers). The IIGS already does this, in ROM no less. >The GS is not a profitable machine. There are much better machines >much more geared towards multitasking. I shudder to think of UNIX on the >plodding beast. The GS is overpriced and overrated. While I would never recommend a IIGS for multitasking, since at present there isn't very much support along those lines, it's not particularly slow. Mine is easily a match for typical IBM PC clones for significant applications that I happen to care about. I don't know who it would be that is "overrating" the IIGS. Apple surely doesn't, the software industry in general doesn't, and the IIGS is seldom mentioned favorably (or at all!) in computing publications. Most experienced IIGS developers seem to think that its capabilities are UNDERrated. I second the motion for the fellow who suggested that if you don't like your (free) IIGS you quit whining about it here. Particularly since you don't know what you're talking about.
floyd@pawl.rpi.edu (Patrick J Wetmore) (12/14/90)
In article <2489@unsvax.NEVADA.EDU> alfter@uns-helios.nevada.edu (SCOTT ALFTER) writes: >Also, why are you polluting this newsgroup with your "Apple IIs suck" >drivel? I've only seen two of your posts and already I get the >feeling you're the Mac or MeSsy-DOS invader who's trying to put down >everyone's choice of machine. Nobody is forcing you to use your GS. I'm not much for the Mac, either, and MS-DOS is not an appealing operating system. I prefer UNIX boxes. And I'm afraid finances dictate my use of the GS (it was free, and I have no money.) >If you don't like it, then use it only as a terminal to access your >mainframe. Hey! What do you think I use it for? Certainly not its computational power. > I'm not trying to sound defensive, but if you >have nothing positive to add to this newsgroup, I'd suggest that you >just shut the fuck up. If you had bothered to read anything I'd written, rather than just seeing "I'm not fond of my Apple IIGS" and started frothing at the mouth, you would have noticed I was pointing out certain misconceptions about the GS's use as a multitasking machine - namely, it ain't gonna happen. If you'd please shut your trap for a moment, and think before posting your rabid nonsense, you'd maybe learn something. But I won't count on it. >(sorry about the disturbance to all the others who read this) Then you should have mailed me privately. But of course, you're not sorry. > >Scott Alfter-----------------------------_/_---------------------------- > / v \ Apple II: >Internet: alfter@uns-helios.nevada.edu ( ( the power to be your best! > GEnie: S.ALFTER \_^_/ Pat Wetmore (gimme a sun 3/50 anyday) -- +------------------+ Could you fancy me as a pirate bold |Patrick J. Wetmore| Or a longship Viking warrior with the old gods on his side |floyd@pawl.rpi.edu| Well, I'm an inshore man and I'm nobody's hero +------------------+ But I'll make you tight for a windy night and a dark ride
floyd@pawl.rpi.edu (Patrick J Wetmore) (12/14/90)
In article <14730@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >MMUs serve several purposes, interprocess protection being merely one >of them, and relatively unimportant at that in a single-user (albeit >multitasking) environment. There have been many implementations of Yes, I am fully aware that you can multitask in an unprotected environment. For serious work, however, I do NOT recommend this. Pointers get curdled all the time - I, for one, would get annoyed tremendously if my machine crashed every time this happened as I was debugging a program. >While I would never recommend a IIGS for multitasking, since at present >there isn't very much support along those lines, it's not particularly >slow. Mine is easily a match for typical IBM PC clones for significant >applications that I happen to care about. Some of us have higher standards than an IBM PC clone. Think 286, minimum. You can pick up an 8088 with monitor and drives and a shitload of memory for well under a grand. >I don't know who it would be that is "overrating" the IIGS. Apple >surely doesn't, the software industry in general doesn't, and the IIGS >is seldom mentioned favorably (or at all!) in computing publications. >Most experienced IIGS developers seem to think that its capabilities >are UNDERrated. Apparently, YOU, for one. >I second the motion for the fellow who suggested that if you don't >like your (free) IIGS you quit whining about it here. Particularly >since you don't know what you're talking about. Again, if you would stop your frothing and read the content, you might learn something. Please. I know my shit. Patrick Wetmore -- +------------------+ Could you fancy me as a pirate bold |Patrick J. Wetmore| Or a longship Viking warrior with the old gods on his side |floyd@pawl.rpi.edu| Well, I'm an inshore man and I'm nobody's hero +------------------+ But I'll make you tight for a windy night and a dark ride
fadden@cory.Berkeley.EDU (Andy McFadden) (12/14/90)
In article <14730@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >In article <7TF^W^=@rpi.edu> floyd@pawl.rpi.edu (Patrick J Wetmore) writes: >>> I believe that the original IBM PC can run Xenix... >>Yah, you can run it fine, until a poitner gets screwed and zaps something >>in another processes memory. Then you get crashes. If it worked just fine, >>we wouldn't have MMUs, would we? Maybe you should go over to Xerox PARC and tell them that they've got it all wrong... Would save them some money, I'm sure. Cedar, anyone? > My >normal working environment is a fully-protected UNIX system that would >abort tasks that attempt to use pointers out of their own address >space, and I almost never see a task aborted for that reason. "Segmentation fault"...? I see it all the time... About the ONLY reason a program crashes. >Without an MMU, the main difference in operation is that relocation >must be provided as task images are loaded into memory for execution Unless you want to do something weird like 8088 segmentation registers... but that's not really a very good solution (not at all). >I second the motion for the fellow who suggested that if you don't >like your (free) IIGS you quit whining about it here. Particularly >since you don't know what you're talking about. Want to do preemptive multitasking on a //gs? I'll send you a (pre-alpha) copy of LWP-GS... -- fadden@cory.berkeley.edu (Andy McFadden) ..!ucbvax!cory!fadden fadden@hermes.berkeley.edu (when cory throws up)
AABENSON@MTUS5.BITNET (12/14/90)
I don't have any idea what kind of performance those terminals or whatever they were you mentioned have... (Oooo, bad sentence.) Could you fill us in? By the way, if you're using a IIgs, you can have a timer interrupt.
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (12/14/90)
gwyn@smoke.brl.mil (Doug Gwyn) writes: >In article <7TF^W^=@rpi.edu> floyd@pawl.rpi.edu (Patrick J Wetmore) writes: >Without an MMU, the main difference in operation is that relocation >must be provided as task images are loaded into memory for execution >(except if position-independent code is involved, but normally that >imposes too stiff a speed penalty and requires cooperating compilers). position-independent code is easier than it looks. you just have to be prepared to do without an index register. for example, assuming PHK PLB is already in effect, execute PER baseaddress PLX and voila, you can access 64K starting at baseaddress by using Abs,X -- LDA |variable-baseaddress,x ;'|' forces Abs addressing since you can use nearly any register/memory instruction with Abs,X this is a big win, because you can do the same operations on globals as you can on locals (direct page). I have pondered the idea of writing a tiny C compiler that outputs ORCA/M assembly (I'm not about to tackle OMF, ok?) but I've got other, more immediately useful projects to worry about. Todd Whitesel toddpw @ tybalt.caltech.edu
taob@pnet91.cts.com (Brian Tao) (12/14/90)
> Patrick Wetmore, another unfortunate IIGS owner (fortunately not deluded)
.... and very closed-minded... Well, if you loathe the GS so much, why
don't you sell it and stop talking about it here? I'm sure you could get
around $1200 to $1600 depending on what's on your system. What are you
expecting out of it? A Mac IIci?
\/\/\/\/\/\/\/\/\/ | Brian T. Tao | UUCP: torag!pnet91!taob |
/ \ | University of Toronto | INET: taob@pnet91.cts.com |
\ The Apple II / | Scarberia, ON | taob@pro-micol.cts.com |
/ Lives On!! \ |:::::::::::::::::::::::::::::::::::::::::::::::::::::::|
\ / | "Computer guru? Someone who got their computer a |
/\/\/\/\/\/\/\/\/\ | couple of weeks before you did." (Alvin Toffler) |taob@pnet91.cts.com (Brian Tao) (12/14/90)
From alfter@uns-helios.nevada.edu (SCOTT ALFTER): > setenv FLAME on > > If the machine is so lousy, then what the hell are you doing using it? ...[snip]... > I'm not trying to sound defensive, but if you have nothing positive to > add to this newsgroup, I'd suggest that you just shut the fuck up. > > setenv FLAME off Burn, baby, burn... :) Where do these guys come from? I think we've got two of 'em on here presently (I e-mailed both of them already, thinking they wouldn't read csa2 again...) Terror-twits. > > (sorry about the disturbance to all the others who read this) > No problem at all. \/\/\/\/\/\/\/\/\/ | Brian T. Tao | UUCP: torag!pnet91!taob | / \ | University of Toronto | INET: taob@pnet91.cts.com | \ The Apple II / | Scarberia, ON | taob@pro-micol.cts.com | / Lives On!! \ |:::::::::::::::::::::::::::::::::::::::::::::::::::::::| \ / | "Computer guru? Someone who got their computer a | /\/\/\/\/\/\/\/\/\ | couple of weeks before you did." (Alvin Toffler) |
AABENSON@MTUS5.BITNET (12/15/90)
Patrick W.,
Oooo! Some harsh words! Somebody wake up on the wrong side of the
mess this morning?AABENSON@MTUS5.BITNET (12/15/90)
Hey Pat! Listen up! An IBM PC is somewhat lower on the power scale than a IIgs. A IIgs DOES have this thing called a "Memory Manager". You see, what it does is it allocates pieces of memory for whoever asks for it. The reason for this is so that programs won't trample all over each other. To my knowledge, IBM PC's do not have this. IIgs's do. The reason people are making MMUs is NOT because software versions do not work, it's simply because it's less for the software to do. And we ALL know that, in general, hardware does things quite a bit faster than software. By the way, if you don't want your IIgs, please send it to me. I'd be more than happy to accept it. Some of us who don't have all that much money are grateful for such gifts. - Andrew. aabenson@balance.cs.mtu.edu Bitnet: AABENSON@MTUS5.BITNET
gwyn@smoke.brl.mil (Doug Gwyn) (12/15/90)
In article <P!G^~4@rpi.edu> floyd@pawl.rpi.edu (Patrick J Wetmore) writes: >Yes, I am fully aware that you can multitask in an unprotected environment. >For serious work, however, I do NOT recommend this. Pointers get curdled >all the time - I, for one, would get annoyed tremendously if my machine >crashed every time this happened as I was debugging a program. >Again, if you would stop your frothing and read the content, you >might learn something. Please. I know my shit. You should follow your own advice. Pointers do NOT repeat NOT "get curdled all the time" in such an environment; as I have pointed out in related postings, I use such a system as my primary UNIX user interface, and it has NOT been a problem. Of course, if YOU really do curdle your pointers all the time, we'll have to take your word for it.
gwyn@smoke.brl.mil (Doug Gwyn) (12/15/90)
In article <90347.210619AABENSON@MTUS5.BITNET> AABENSON@MTUS5.BITNET writes: >I don't have any idea what kind of performance those terminals or whatever >they were you mentioned have... (Oooo, bad sentence.) >Could you fill us in? You have to see them in action to appreciate them. The fact that I have a choice between SGI and Sun workstation human interfaces and using an AT&T 630 (Blit descendant), usually choosing to use the 630 for most work, should offer some practical reference point. At least the user interfaces are comparably convenient, and much better than the Macintosh/Apple IIGS desktop, especially with regard to concurrent processes. >By the way, if you're using a IIgs, you can have a timer interrupt. Yes, but since Apple's system software and toolbox don't expect to be reentered while executing, you would have to mask interrupts while using Apple's system software. It is simpler to use nonpreemptive task switching, which works just about as well for this kind of multitasking environment.
m.tiernan@pro-angmar.UUCP (Michael Tiernan) (12/15/90)
In-Reply-To: message from floyd@pawl.rpi.edu
One thought, the 8088 and subsequent processors of that bastardized family
have all had one little thing that none of the others (6502, Z80, etc) have
had and that's some kind of instruction that CANNOT under ANY circumstances be
preempted. Now, I am not dead sure of the 8088 but the children of it have
had this instruction. Now you can't still say that this legitimizes the idea
of multiprocessing (or any other word prefixed by "multi") but it did allow
you to do more than you can without it.
But as has been shown many times you ain't close without hardware level memory
management.
<< MCT >>
GEnie : M.Tiernan
AppleLinkPE : M Tiernan or BCS Mike
Internet : pro-angmar!m.tiernan@alphalpha.com
UUCP : ...!uunet!alphalpha!pro-angmar!m.tiernan
"God isn't dead, he's only missing in action."
- Phil Ochsfloyd@pawl.rpi.edu (Patrick J Wetmore) (12/15/90)
In article <90348.145140AABENSON@MTUS5.BITNET> <AABENSON@MTUS5.BITNET> writes: >Hey Pat! Listen up! I did. And was unimpressed. >An IBM PC is somewhat lower on the power scale than a IIgs. A IIgs DOES >have this thing called a "Memory Manager". You see, what it does is it >allocates pieces of memory for whoever asks for it. The reason for this is Thank you very much, I know about it. However, an MMU prevents you from zapping memory that has been allocated to another process. If you are programming, and have a teensy little bug that curdles a pointer (this happens to ANYONE who programs in C. It's part of a process called debugging. If you're a programmer who's never gotten a coredump, well, then, my hat's off to you.) then you will overwrite another processes memory, on the IIGS and other machines without an MMU. Yes, you can get along fine multi- tasking without an MMU, as long as your software has not a single bug in it. An error in one process is likely to hammer the machine badly, and crash it, without an MMU - it's not that hard to send a pointer into the OS's space and just write some garbage. >so that programs won't trample all over each other. To my knowledge, IBM >PC's do not have this. IIgs's do. The reason people are making MMUs is >NOT because software versions do not work, it's simply because it's less for >the software to do. And we ALL know that, in general, hardware does things >quite a bit faster than software. No, people make MMUs for the reason above - to keep processes from reading and writing another processes space accidentally. And yes, BIOS does have a memory allocation package. It's No Big Deal, you know. > >By the way, if you don't want your IIgs, please send it to me. I'd be >more than happy to accept it. Some of us who don't have all that much money >are grateful for such gifts. Oh, give me a break. > >- Andrew. aabenson@balance.cs.mtu.edu Bitnet: AABENSON@MTUS5.BITNET Patrick Wetmore P.S. multitasking in an unprotected environment is not good, if you do any kind of real work at all. -- +------------------+ Could you fancy me as a pirate bold |Patrick J. Wetmore| Or a longship Viking warrior with the old gods on his side |floyd@pawl.rpi.edu| Well, I'm an inshore man and I'm nobody's hero +------------------+ But I'll make you tight for a windy night and a dark ride
rhyde@ucrmath.ucr.edu (randy hyde) (12/15/90)
Isn't it okay to want to keep an Apple //gs but not give it flowery reviews all the time? I'm not about to sell my GS. But I would never recommend that someone else buy one. I've already bought a PC and a Mac (and several other machines, for that matter). I have the luxury few can afford of being able to pick the best machine for the job. Alas, the GS sits around unused for several long spells. So many other machines do the job at hand much better. If you go back and read most of the "Anit-GS" messages appearing here, you'll find that most of them do not recommend that everyone unload these white elephants. Instead, they ask why would anyone buy one today? The only person I could seriously suggest to buy a GS is a long-time Apple II user who has a lot of experience with the machine. Other alternatives are cheaper and/or better for the new user. *** Randy Hyde The Apple II had its day. Let it die in glory, supported by those who love the machine rather than trying to force it on to those who will only hate it.
rhyde@ucrmath.ucr.edu (randy hyde) (12/15/90)
>> the 8088 and subsequent processor...have had.. (an) instruction that >> CANNOT .. be preempted. So did the 6502, Z80, etc. ASL and LSR will do the job just find. As I pointed out earlier, a non-preemptible instruction is not necessary to prevent two processes from entering a critical region. *** Randy Hyde
lhaider@pro-grouch.cts.com (Laer Haider) (12/15/90)
In-Reply-To: message from floyd@pawl.rpi.edu >Again, if you would stop your frothing and read the content, you >might learn something. Please. I know my shit. You have demonstrated, as to leave no uncertainty in any GS users mind, that you don't. Why don't you just get off this newsgroup if you don't have anything positive to contribute. You're just wasting bandwidth and demonstrating verbose ignorance. / \ / / ______________________________________________________ \\\' , / // ProLine: pro-grouch!lhaider \\\//, _/ //, INET: lhaider@pro-grouch.cts.com \_-//' / //<, /\\ UUCP: crash!pro-grouch!lhaider \ /// <//` //\\\ UUCP: crash!pro-grouch!lhaider@nosc.mil / >> \\\`__/_ ///\\\\ /,)-^>> _\` \\\ ////\\\\\ The opinions expressed here belong to (/ \\ //\\ // IIgs \\\ no entity(s), living or dead! // _//\\\\ ------------------------------------------------------ ((` ((
jb10320@uxa.cso.uiuc.edu (Desdinova) (12/15/90)
m.tiernan@pro-angmar.UUCP (Michael Tiernan) writes: >In-Reply-To: message from floyd@pawl.rpi.edu >One thought, the 8088 and subsequent processors of that bastardized family >have all had one little thing that none of the others (6502, Z80, etc) have >had and that's some kind of instruction that CANNOT under ANY circumstances be >preempted. The 65816 has the TSB and TRB instructions. Only one of the two is necessary for preemtpive multitasking. Trust me on this, I just took a final exam on this stuff. The 65c02 also has this instruction. The gist of this is that you must (in an uninterruptible step) test the value of a location and then set it to some value. This is used to implement simple mutex, and from that semaphores, monitors, ad naseum. In short, and FOR THE LAST TIME, there is nothing in the architecture that prevents preemptive multitasking. Arguments have been presented that a MMU would be nice, but it's definitely NOT necessary (witness the Amiga). > Now, I am not dead sure of the 8088 but the children of it have >had this instruction. Now you can't still say that this legitimizes the idea >of multiprocessing (or any other word prefixed by "multi") but it did allow >you to do more than you can without it. Well, actually- without an uninterruptible Test-And-Set (the aforementioned instructions) you can't have preemptive multitasking without resorting to some pretty clumsy and inefficient software techniques. >But as has been shown many times you ain't close without hardware level memory >management. Oh, I suppose the Amiga "ain't close" then? What IS close- a Sequent? a Pyramid? Cray perhaps? What do you people want, a personal computer or a bloody UNIX mainframe? (I would like to have Unix on my GS, as a sort of intellectual exercise- I'd much prefer a truly multitasking GS/OS) ><< MCT >> -- Jawaid Bazyar | Being is Mathematics Senior/Computer Engineering | Love is Chemistry jb10320@uxa.cso.uiuc.edu | Sex is Physics Apple II Forever! | Babies are engineering
alfter@uns-helios.nevada.edu (SCOTT ALFTER) (12/15/90)
In article <90348.145140AABENSON@MTUS5.BITNET> AABENSON@MTUS5.BITNET writes: >By the way, if you don't want your IIgs, please send it to me. I'd be >more than happy to accept it. Some of us who don't have all that much money >are grateful for such gifts. Hey! I asked first! :-) Scott Alfter-----------------------------_/_---------------------------- / v \ Apple II: Internet: alfter@uns-helios.nevada.edu ( ( the power to be your best! GEnie: S.ALFTER \_^_/
rhyde@ucrmath.ucr.edu (randy hyde) (12/16/90)
>> You're just wasting bandwidth...
And you don't consider this message more of the same? C'mon, quit
using "bandwidth" as an excuse to shut other people up. If *YOU*
really cared about bandwidth, why is there such a large banner at
the end of each message you post. If *YOU* really care about
bandwidth why didn't you simply mail your message rather than
posting it here.
Personally, I could care less about "bandwidth". The crazy
headers and trailers on all these messages consume well over 50%
of the data sent around here. If someone was really concerned
about bandwidth on the node they would change the way this info
gets transmitted (i.e., compact the audit trail/header and only
present it when someone requests it [e.g., when replying to a message]).
*** Randy Hyderhyde@ucrmath.ucr.edu (randy hyde) (12/16/90)
>> I'd much prefer a truly multitasking GS/OS..
That is the most reasonable thing I've heard anyone post here in a
long time.
Actually, I'd settle for multiprogramming rather than multitasking,
but most people confuse the two anyway. If Apple would add a process
manager to the toolbox, GS/OS would be great.
*** Randy Hydejpenne@ee.ualberta.ca (Jerry Penner) (12/16/90)
In article <1990Dec15.093137.17304@ux1.cso.uiuc.edu> jb10320@uxa.cso.uiuc.edu (Desdinova) writes: [lots of stuff deleted] > Oh, I suppose the Amiga "ain't close" then? What IS close- a Sequent? >a Pyramid? Cray perhaps? What do you people want, a personal computer or >a bloody UNIX mainframe? (I would like to have Unix on my GS, as a sort of >intellectual exercise- I'd much prefer a truly multitasking GS/OS) > >Jawaid Bazyar | Being is Mathematics Just a little note here. Cray's don't multitask. They run one job till it's done to get the maximum CPU throughput for the job. Then the next job is sent through. Anyhow, can we quit whining about multitasking on the GS? It's not fast enough to do two things at once and GS/OS and the Toolbox are not re-entrant, making it hard to do. It might be acceptable on a Zip'ed GS, but I don't have one. -- ------------- Jerry Penner alberta!bode!jpenne Edmonton, Alberta, Canada
alfter@uns-helios.nevada.edu (SCOTT ALFTER) (12/16/90)
In article <8299.apple.net2@pro-grouch> lhaider@pro-grouch.cts.com (Laer Haider) writes: >In-Reply-To: message from floyd@pawl.rpi.edu > >>Again, if you would stop your frothing and read the content, you >>might learn something. Please. I know my shit. > >You have demonstrated, as to leave no uncertainty in any GS users mind, >that you don't. Why don't you just get off this newsgroup if you don't >have anything positive to contribute. You're just wasting bandwidth >and demonstrating verbose ignorance. Could this what's-his-name Wetmore possibly be... Tracy Brooks in disguise? First she made a fool of herself in rec.humor. Now she's out to piss everybody off in comp.sys.apple2! Maybe comp.sys.apple2 is about to join the ranks of those newsgroups that are regularly visited by a few select idiots! :-) :-) :-) Scott Alfter-----------------------------_/_---------------------------- / v \ Apple II: Internet: alfter@uns-helios.nevada.edu ( ( the power to be your best! GEnie: S.ALFTER \_^_/
stc7@cunixb.cc.columbia.edu (Steven T Chiang) (12/16/90)
> I'd much prefer a truly multitasking GS/OS.. We were contacted by a company called BrainStorm from France. They claim to have a program that could be called the MultiFinder, but since they can't call it that, they call it The Manager. Supposedly, it is supposed to do exactly what the multifinder does on the mac, except it will also allow for Background printing, something the multifinder doesn't support. They also said that the programs are almost ready to be shipped, but who knows how long until we see them in the states... _______________________________________________ _______________ | Steve Chiang Apple //gs forever | Coming Soon: | |-----------------------------------------------|---------------| | Internet : stc7@cunixb.cc.columbia.edu | DreamGrafix | | America_Online : DWS Steve | 3200 power | |_______________________________________________|_______________|
fadden@cory.Berkeley.EDU (Andy McFadden) (12/16/90)
In article <1990Dec15.210148.24966@ee.ualberta.ca> jpenne@ee.ualberta.ca (Jerry Penner) writes: >Just a little note here. Cray's don't multitask. They run one job till >it's done to get the maximum CPU throughput for the job. Then the next >job is sent through. Not entirely correct. Under the default Cray OS, this is true. However, a version of UNIX does exist for the Cray (unicos?), and it does multitask. I've seen it. Check out lynx.berkeley.edu... registered as a cray/xmp. >It's not fast enough to do two things at once and GS/OS and the Toolbox >are not re-entrant, making it hard to do. It might be acceptable on a >Zip'ed GS, but I don't have one. Depends on what you're trying to do. And there are ways around the non- reentrancy problems. > Jerry Penner alberta!bode!jpenne Edmonton, Alberta, Canada -- fadden@cory.berkeley.edu (Andy McFadden) .!ucbvax!cory!fadden fadden@hermes.berkeley.edu (when cory throws up)
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (12/16/90)
rhyde@ucrmath.ucr.edu (randy hyde) writes: (Re : "I'd much prefer a truly multitasking GS/OS..") >That is the most reasonable thing I've heard anyone post here in a >long time. >Actually, I'd settle for multiprogramming rather than multitasking, >but most people confuse the two anyway. If Apple would add a process >manager to the toolbox, GS/OS would be great. Let me second that. The toolbox already supports user ID's, and could be patched to keep track of who's started which tools and so on. This would help avoid A LOT of problems with DA's (and other processes) starting tools and shutting them down without giving the foreground application a serious headache. The real barrier is GS/OS. There is a good deal of application context (33 or so prefixes, the file level, and such) which is a real pain to switch among processes from outside, but would be really easy for GS/OS to do internally. Apple is turning the Mac O/S into a patchwork quilt trying to force it to provide real multitasking/multiprogramming support. The GS Toolbox and O/S were far better designed for it, but the guys who laid out the actual tool calls screwed it up. All of the tools should have used UserID's to keep track of who's using which resources -- this support can be patched in but it should have been there in the first place. By the way, atomic instructions are NOT required for process communication, as Randy said (BTW Randy, Using 6502 Assembly Language was my first ML textbook) -- lack of them just makes it tougher. However, the 6502 has always had INC/DEC, which are atomic Todd Whitesel toddpw @ tybalt.caltech.edu
AABENSON@MTUS5.BITNET (12/16/90)
Randy Hyde says something about adding a "Process Manager". This WOULD be quite a good idea. I think everybody needs to get a speed accelerator, though.
AABENSON@MTUS5.BITNET (12/16/90)
Andy says something about ways around non-reentrant code.... How? I mean, other than rewriting the code. Are we just talking about a busy flag or something? - Andrew. aabenson@balance.cs.mtu.edu or AABENSON@MTUS5.BITNET
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (12/16/90)
I wrote: >By the way, atomic instructions are NOT required for process communication, >as Randy said (BTW Randy, Using 6502 Assembly Language was my >first ML textbook) -- lack of them just makes it tougher. However, the 6502 >has always had INC/DEC, which are atomic This was posted incomplete by mistake, it was supposed to finish with has always had INC/DEC, which are atomic and are in fact used by the busy flag routines of the toolbox. Todd Whitesel toddpw @ tybalt.caltech.edu
ericmcg@pnet91.cts.com (Eric Mcgillicuddy) (12/17/90)
The 65C02 and 65816 have two uninteruptible instruction, TSB and TRB. These are Test and Set (or Reset) Bit. Perhaps the *RESET line would prevent interuption, but nothing else will stop them from completing their function (usually marking a semaphore). Any subsequent accesses to the semaphore will show it as being in use. I hope Prodos uses this for the "PRODOS_BUSY" flag and for locking Handles. (?). These instructions take 5-7 cycles to execute, so they damn well better work as advertised, eh? UUCP: bkj386!pnet91!ericmcg INET: ericmcg@pnet91.cts.com
m.tiernan@pro-angmar.UUCP (Michael Tiernan) (12/17/90)
In-Reply-To: message from gwyn@smoke.brl.mil
All of this is truly correct but let me add one small point, there is a flag
in ProDOS (I'm not too sure anymore if it's in any of the toolbox stuff) that
tells you when it's busy. If you call a ProDOS write command, interrupt it,
and want to call a read (as examples) from the ISR, you check this flag, if
it's set then ProDOS is currently servicing a request and through some small
gymnastics, you put a pointer to your routine to call as soon as the
foreground process finishes thereby unbusying ProDOS. No, the system isn't
reentrant but it is slightly intellegent.
<< MCT >>
GEnie : M.Tiernan
AppleLinkPE : M Tiernan or BCS Mike
Internet : pro-angmar!m.tiernan@alphalpha.com
UUCP : ...!uunet!alphalpha!pro-angmar!m.tiernan
"God isn't dead, he's only missing in action."
- Phil Ochswilner@motcid.UUCP (Corey S. Wilner) (12/18/90)
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: > Stuff omitted >By the way, atomic instructions are NOT required for process communication, >as Randy said (BTW Randy, Using 6502 Assembly Language was my >first ML textbook) -- lack of them just makes it tougher. However, the 6502 >has always had INC/DEC, which are atomic I don't see how the INC/DEC are going to do any good. You cannot detect the resource and sieze it with INC or DEC which is what is truly necessary for a preemptive environment. It is interesting to note that the operating system we are using on a project here at work is VRTX32/68000 and they use one special rule: There is a parameter called the component disable level which sets the interrupt mask level whenever an indivisible check must be done. An ISR at a level above the CDL must not make any calls to VRTX. This prevents breakup of an indivisible operation. The major problem I have seen was during the debugging stage where I read the manual wrong and did not allocate enough stack space per task. Needless to say, we are not using an MMU and this led to one task's stack overwriting another's! Thank heaven for emulators! *********************************************** Corey S. Wilner | Give me a jingle: Motorola Cellular | ..!uunet!motcid!wilner 708-632-7206 | *********************************************** McAfee's Law of Physical Material Balance: Matter can be neither created nor destroyed. However, it can be lost!
rhyde@koufax.ucr.edu (randy hyde) (12/19/90)
Alas, the system busy flag isn't sufficient to support multiple processes. For example, there is still the problem with the "close all files" command. This would close all files in all processes regardless of who opened the files. I think that, due to the interest in multitasking on the GS, we should discuss exactly what the 65816 needs to support a decent multiprogramming or multitasking system. Such a discussion would be considerably more positive than the bickering that's going on now. Such a discussion wouldn't be without merit. WDC is currently working on the new generation 65xxx chips and welcomes input from various users. I can post their address sometime (when I'm home on my Mac rather than here at school). If anyone is interested, I can post an article (quite long) I once wrote on a "dream machine" upgrade to the 65816. *** Randy Hyde
rbannon@batman.elee.CalPoly.EDU (Roy Bannon) (12/19/90)
In article <10663@ucrmath.ucr.edu> rhyde@koufax.ucr.edu (randy hyde) writes: > >I think that, due to the interest in multitasking on the GS, >we should discuss exactly what the 65816 needs to support a >decent multiprogramming or multitasking system. Such a >discussion would be considerably more positive than the >bickering that's going on now. Such a discussion wouldn't >be without merit. WDC is currently working on the new >generation 65xxx chips and welcomes input from various users. >I can post their address sometime (when I'm home on my Mac >rather than here at school). If anyone is interested, I can >post an article (quite long) I once wrote on a "dream machine" >upgrade to the 65816. >*** Randy Hyde Here Here! Lets get a positive discussion going. I am pretty much finished with my DSP card project. After hacking a DSP card which is able to sample at 47k and has a processor on board that is doing 8 Mips, I'm ready for another hardware project. I think a mmu hack would be perfect. I am game for a try anyway. So, what does it need, form the software point of view that is. I remember hearing something to the effect that the abort line to the wdc65c816 doesnt work reliablely. Is this true? Might make things a bit more complicated if it is true. Initial thought, how bout a daughter board that plugs into the 65816 socket and has the 65816 and an mmu on it. Something to think about anyway. Roy Bannon rbannon@batman.elee.calpoly.edu
jh4o+@andrew.cmu.edu (Jeffrey T. Hutzelman) (12/19/90)
I have to agree. Until my hard drive died, I was working diligently
on LWP GS, a library (first created by our own Andy McFadden) that
allows a single application to create multiple lightweight processes
that run more or less simultaneously. Since I am going home tomorrow
(will still have net access, thank goodness) AND my drive should be
returning this week with all data INTACT (thank God or your own
favorite diety :) ), I will be working on it once again. The basic
context switch algorithm could be VERY useful in a multi-tasking O/S;
I am currently working on adding whatever needs added to make it work
effectively with things like more than one process using QuickDraw II
and other resources. If anyone else wants a copy of this code (65816
assembly, ORCA/M) or the entire library, let me know and I'll send you
the latest version. When the library gets stable, it will be posted
on the net, with a demo (which has yet to be written, but I hope it
will effectively show off the impressive things that can be done with
LWP GS).
--------------------
Jeffrey Hutzelman America Online: JeffreyH11
Internet: jh4o+@andrew.cmu.edu BITNET: JHUTZ@DRYCAS
>> Apple // Forever!!! <<AABENSON@MTUS5.BITNET (12/20/90)
In response to Randy: No, a "close all files" command would NOT be a problem. I think I mentioned this earlier, but all you'd need to do is what Orca, APW, and that one other shell (I forgot the name) do -- INTERCEPT GS/OS calls. Then, you can keep track of which programs are doing what (by ID), and then when a program says "close all", you just make sure to only close theirs. Get it? - Andrew. aabenson@balance.cs.mtu.edu (Preferred) aabenson@mtu.edu aabenson@mtus5.bitnet
johns@pro-library.cts.com (John Sparkman) (12/20/90)
In-Reply-To: message from rhyde@koufax.ucr.edu I hope someone comes up with a solution to be able to multitask on a GS. It would be very beneficial to a sysop running a BBS, also to anyone for that matter. Please someone do it!!!! John ----
unknown@ucscb.UCSC.EDU (The Unknown User) (12/20/90)
In article <1990Dec19.232757.15685@clark.edu> johns@pro-library.cts.com (John Sparkman) writes: >I hope someone comes up with a solution to be able to multitask on a GS. It >would be very beneficial to a sysop running a BBS, also to anyone for that >matter. Please someone do it!!!! Is your BBS a GS specific program running under GS/OS? I may be wrong, but I would presume that any multitasking programs or OSs would work only with GS specific programs that run under GS/OS... People who are working on multitasking on the GS: Am I correct in this presumption? -- /Apple II(GS) Forever! unknown@ucscb.ucsc.edu MAIL ME FOR INFO ABOUT CHEAP CDs\ |WRITE TO ORIGIN ABOUT ULTIMA VI //e and IIGS! Mail me for addresses, & info. | \ "Dammit Bev, is it you inside or is it the clown?" -IT by Stephen King /
danield@pro-grouch.cts.com (Daniel Davidson) (12/20/90)
In-Reply-To: message from rbannon@batman.elee.CalPoly.EDU >I think a mmu hack would be perfect. Sounds great to me! Actualy, I think that is just what the IIgs needs. The weakest thing about it is that there is no hardware memory protection. this makes a Multi-tasking OS nearly wothless since any process can clobber any other process. > Initial thought, how bout a daughter board that plugs into the > 65816 socket and has the 65816 and an mmu on it. Something to think about > anyway. Only problem I see is that it will not be compatible with a Transwarp GS or ZipChip GS. I don't know about you, But it would be hard to give up my Transwarp. What I would like to see is AE or Zip putting an MMU on their speed up cards. This would make them Much more valuable, and useful. Daniel UUCP: crash!pro-grouch!danield ARPA: crash!pro-grouch!danield@nosc.mil INET: danield@pro-grouch.cts.com or ddavidso@ucsd.edu
jeffb@world.std.com (Jeffrey T Berntsen) (12/20/90)
ericmcg@pnet91.cts.com (Eric Mcgillicuddy) writes: >The 65C02 and 65816 have two uninteruptible instruction, TSB and TRB. These >are Test and Set (or Reset) Bit. Perhaps the *RESET line would prevent >interuption, but nothing else will stop them from completing their function >(usually marking a semaphore). Any subsequent accesses to the semaphore will >show it as being in use. I hope Prodos uses this for the "PRODOS_BUSY" flag >and for locking Handles. (?). I know that ProDOS couldn't use them because ProDOS runs on a ][+ or unenhanced //e both of which have plain 6502's. The original 6502 doesn't have those instructions. ProDOS uses shift instructions for its busy flag; that was documented in a technote someplace because there was a bug in it at some point (fixed now). I don't know how ProDOS locks file handles or even if it does at all. I'd be interested in finding out myself but don't feel like disassembling ProDOS right now. ------------------------------------------------------------------------------- Jeffrey T. Berntsen | Looking for a good .sig jeffb@world.std.com | -------------------------------------------------------------------------------
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (12/21/90)
Prodos 8 has a busy flag. Prodos 8 runs on a 6502. Therefore, the 6502 has some kind of instruction that can be used for busy flags. (In the case of Prodos 8, it's LSR/ROR.) The IIgs toolbox and firmware, by the way, use INC/DEC. Look in the firmware reference on page 270, and disassemble the routines pointed to by e1/64 and e1/68. Whoever said INC/DEC were useless for this should go back to school. Uninterruptable instructions are not even necessary for this sort of thing, but they do make it a lot easier. Todd Whitesel toddpw @ tybalt.caltech.edu
rhyde@ucrmath.ucr.edu (randy hyde) (12/21/90)
INC/DEC cannot be used as test and set instructions. However, ASL/LSR can. Consider: asl flag bcc inuse <critical region> lda #1 sta flag <end of critical region> works like a charm. *** RAndy Hyde
rhyde@ucrmath.ucr.edu (randy hyde) (12/21/90)
Unless the hardware is set up to use the bus interlock signal, a DMA access most certainly can interrupt the TSB and TRB instructions.
rhyde@ucrmath.ucr.edu (randy hyde) (12/21/90)
>> Whoever said INC/DEC were useless for this ...
ProDOS is not using INC/DEC to prevent entry into a critical region and the
(whoops, in the) TSB/
TRB sense. They are used to implement a variant of the Bakery algorithm
(which doesn't require uninterruptable instructions). If you can come
up with some code to protect a crtical region using only INC or DEC as
a test and set instruction I'd be interested in seeing it (I'm not being
facetious, I really don't know if it can be done, although I tend to doubt
it).
*** Randy Hydemziober@trocadero.ics.uci.edu (Michael A. Ziober) (12/22/90)
In <10739@ucrmath.ucr.edu> rhyde@ucrmath.ucr.edu (randy hyde) writes: > If you can come >up with some code to protect a critical region using only INC or DEC as >a test and set instruction I'd be interested in seeing it (I'm not being >facetious, I really don't know if it can be done, although I tend to doubt >it). >*** Randy Hyde Why not? When the resource is initialized by the system: resource_init ... ;blah, blah, blah lda #1 ;could be $ff if you prefer to sta flag ; grab resource with inc ... ;blah, blah, blah Then for each process that wants a piece of the action: your_code ... ;blah, blah, blah loop dec flag ;try to grab resource beq locked ;got it! inc flag ;undo attempt jmp loop ;block until available locked ... ;Here you get exclusive use of the resource. release inc flag ;undo resource lock ... ;blah, blah, blah I think this should work for about 254 processes. With a slight variation on this theme, you can also implement non-blocking resource contention. Michael Ziober
rhyde@ucrmath.ucr.edu (randy hyde) (12/23/90)
>Why not? >When the resource is initialized by the system: >resource_init ... ;blah, blah, blah > lda #1 ;could be $ff if you prefer to > sta flag ; grab resource with inc > ... ;blah, blah, blah > >Then for each process that wants a piece of the action: >your_code ... ;blah, blah, blah >loop dec flag ;try to grab resource > beq locked ;got it! > inc flag ;undo attempt > jmp loop ;block until available >locked ... ;Here you get exclusive use of the resource. >release inc flag ;undo resource lock > ... ;blah, blah, blah >I think this should work for about 254 processes. With a slight >variation on this theme, you can also implement non-blocking resource >contention. Sorry, this won't work for a variety of reasons. Let me offer two (above and beyond the 255 process "limitation"): 1) Consider the situation where P1 has a resource that P2 wants. Presumably the flag contains zero because P1 owns the resource. Now suppose that P2 decrements the flag and gets interrupted by P3 *before* the inc flag (after the beq above). P3 will *never* be able to gain access to these resource until *after* P2 gets it. Even if P1 gives it up in the meantime. Assuming P2 eventually runs again (which isn't a safe assumption) P3 will eventually get the resource, but the result it poor resource scheduling. If P2 doesn't run again for another hour, P3 will have to wait for (at least) an hour before gaining access to the resource even if P1 returned it a second after P2 asked for it. 2) Suppose the interrupt occurs after the dec flag but before the beq instruction. The flag now contains -1. Suppose P3 comes along and decrements the flag and gets suspended before the beq. The flag now contains -2. Now suppose P1 releases the resource and increments the flag. The flag now contains -1. I can imagine a scenerio where P2 and P3 constantly increment and decrement the flag out of phase, forming a deadlock even though the resource is available. Nice try. Handling degenerate cases like this is *HAIRY*! I look forward to your next attempt! Like I said, I'm not sure it *can't* be done using INC and DEC. *** Randy Hyde .
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (12/23/90)
rhyde@ucrmath.ucr.edu (randy hyde) writes: (In response to somebody else's code which is fairly equivalent to what I posted) >Nice try. Handling degenerate cases like this is *HAIRY*! I look forward >to your next attempt! Like I said, I'm not sure it *can't* be done using >INC and DEC. Hey. We both gave valid solutions. The problem is that they can both fall into indefinite length deadlock in the absolute worst case -- but I don't remember you saying that From your comment it sounds like finite-length deadlock as a requirement -- in which case I will flatly say NO it cannot be done with only INC's and DEC's. Todd Whitesel toddpw @ tybalt.caltech.edu
ericmcg@pnet91.cts.com (Eric Mcgillicuddy) (12/23/90)
>When the resource is initialized by the system: >resource_init ... ;blah, blah, blah > lda #1 ;could be $ff if you prefer to > sta flag ; grab resource with inc > ... ;blah, blah, blah > >Then for each process that wants a piece of the action: >your_code ... ;blah, blah, blah >loop dec flag ;try to grab resource > beq locked ;got it! > inc flag ;undo attempt > jmp loop ;block until available >locked ... ;Here you get exclusive use of the resource. >release inc flag ;undo resource lock > ... ;blah, blah, blah > >I think this should work for about 254 processes. With a slight >variation on this theme, you can also implement non-blocking resource >contention. > >Michael Ziober That will not work since you do not test the flag before modifying it. Suppose the Flag were 0, meaning that the resource is locked. You now decrement it and it is not zero meaning that it is unlocked. If you only grab a resource when it is free ($01 in flag) not just when is not locked (big difference logically), then it could work, but requires much more protection coding. Another problem is that your test loop will eventually DEC FLAG to $01 and on the next pass tell you that the resource is free. Even on a 65816 where FLAG is a 2 byte value, you will eventually luck out and grab a locked resource. Multiprocesses will compound the problem. Regardless of how you test a flag, you must not alter it unless you are claiming it, this is where TSB comes in. lda flag_mask w8_4_free tsb global_flag bne w8_4_free ......your code lda flag_mask trb global_flag ;clear busy bit when done with resource This should protect whatever resources capable of being claimed in a pre-emptive multitasking emvironment. The limited addressing modes available will cause problems in a 65816 system unless this is in a shared memory region of the system since the global semaphores must be in the same bank as the code that tests and claims them. An advantage is that a single byte/word can hold 8/16 flags as opposed to just a single flag using ASL or INC/DEC. Of course it is dead simple in a Toolbox based system such as the GS. UUCP: bkj386!pnet91!ericmcg INET: ericmcg@pnet91.cts.com
gammal@CAM.ORG (Michael Gammal) (12/23/90)
ericmcg@pnet91.cts.com (Eric Mcgillicuddy) writes: >The 65C02 and 65816 have two uninteruptible instruction, TSB and TRB. These >are Test and Set (or Reset) Bit. Perhaps the *RESET line would prevent >interuption, but nothing else will stop them from completing their function >(usually marking a semaphore). Any subsequent accesses to the semaphore will >show it as being in use. I hope Prodos uses this for the "PRODOS_BUSY" flag >and for locking Handles. (?). >These instructions take 5-7 cycles to execute, so they damn well better work >as advertised, eh? I have a program made by a friend's friend called IIe.MultiTask and apparently it works very well...(I personally have never used it but some friends of mine say it's pretty good) I brought this up as I was wondering if it would be of use to anyone as I could put it in comp.binaries.apple2 if necessary. -- Michael Gammal Concordia University M.Gammal@CAM.ORG
ericmcg@pnet91.cts.com (Eric Mcgillicuddy) (12/25/90)
>I have a program made by a friend's friend called IIe.MultiTask and apparently >it works very well...(I personally have never used it but some friends of mine >say it's pretty good) > >I brought this up as I was wondering if it would be of use to anyone as I >could >put it in comp.binaries.apple2 if necessary. > >-- >Michael Gammal Concordia University M.Gammal@CAM.ORG I would like to see the source, if it is available. But if it is not too large, then the binary is fine. A third year project involved writing a multitasking pseudo-machine. I got it working on my //c, but had to use co-operative multitasking (couldn't figure out the VBL interupt in time to complete the project as pre-emptive). Worked well enough to pass the project. Certainly multiprogramming on an Apple II is no more difficult than on any other system, but it certainly isn't any easier. UUCP: bkj386!pnet91!ericmcg INET: ericmcg@pnet91.cts.com
flee@gnh-applesauce.cts.com (FRANK LEE) (12/27/90)
What IS "pre-emptive multitasking," anyway?? INET: flee@gnh-applesauce.cts.com UUCP: crash!pnet01!gnh-applesauce!flee ARPA: crash!pnet01!gnh-applesauce!flee@nosc.mil
unknown@ucscb.UCSC.EDU (The Unknown User) (12/27/90)
In article <m0ioqbP-00009YC@jartel.info.com> flee@gnh-applesauce.cts.com (FRANK LEE) writes: >What IS "pre-emptive multitasking," anyway?? Where the computer controls the multitasking (I'm presuming you know what that means! heh) with no "knowledge" from the individual processes being run concurrently.. That is, each process runs for a certain period of time (time_slice) and then the computer saves the registers and everything, then runs the next process for a period of time... Apparently you can also has "cooperative" multitasking, where I presume each process says "Hey, go ahead, you can run a while"... And if a process never says that, it's being a naughty boy and hogging all the CPU time. -- /Apple II(GS) Forever! unknown@ucscb.ucsc.edu MAIL ME FOR INFO ABOUT CHEAP CDs\ \WRITE TO ORIGIN ABOUT ULTIMA VI //e and IIGS! Mail me for addresses, & info. /
flee@gnh-applesauce.cts.com (FRANK LEE) (12/27/90)
All 65x02 instructions are uninterruptible. Say it takes 3 cycles to execute a BEQ. If during the first cycle I pull an INT (IRQ,NMI,RESET), the cpu IGNORES the interrrupt until AFTER the BEQ has finished executing. The philosophy behind this design feature was to prevent accidentally "flashing" random memory locations if a mem-modifying instruction was executed. This also leads to some of the poorest interrupt latencies in the known market. An interrupt can be ignored, at worst, up to 7 cycles. Why not just use the SEI instruction to block interrupts before executing your critical code? INET: flee@gnh-applesauce.cts.com UUCP: crash!pnet01!gnh-applesauce!flee ARPA: crash!pnet01!gnh-applesauce!flee@nosc.mil
jb10320@uxa.cso.uiuc.edu (Desdinova) (12/28/90)
In article <m0ioqbR-0000BFC@jartel.info.com> flee@gnh-applesauce.cts.com (FRANK LEE) writes: >All 65x02 instructions are uninterruptible. Say it takes 3 cycles to execute a >BEQ. If during the first cycle I pull an INT (IRQ,NMI,RESET), the cpu IGNORES >the interrrupt until AFTER the BEQ has finished executing. The philosophy >behind this design feature was to prevent accidentally "flashing" random memory >locations if a mem-modifying instruction was executed. This also leads to some >of the poorest interrupt latencies in the known market. An interrupt can be >ignored, at worst, up to 7 cycles. According to many people I know who BUILD (yes, design and construct) computers the 6502/65816 has one of THE FASTEST interrupt response times of any processor. It is known by anyone who studies microprocessor design that normal IRQ type interrupts are always put off until the end of an instruction. DMA interruption can occur at any cycle- but restarting an instruction in the middle after another series of instructions has executed is not the job of an interrupt request. MY request is that you look around before you spout unfounded information. >Why not just use the SEI instruction to block interrupts before executing your >critical code? Because this prevents anything else in the system from executing. You can't turn off interrupts just because you want a critical section. The Disk ][ drivers do this and just watch what happens when you use the drive. The user response of the system drops to almost zero. No, semaphores are the correct and accepted method of protecting critical sections. -- Jawaid Bazyar | Being is Mathematics Senior/Computer Engineering | Love is Chemistry jb10320@uxa.cso.uiuc.edu | Sex is Physics Apple II Forever! | Babies are engineering
rhyde@ucrmath.ucr.edu (randy hyde) (12/29/90)
>>> All 65x02 instructions are uninterruptible. This is true for the 65x02, but not the 65c816. The 65c816 as the /abort pin which can interrupt an instruction on any given clock cycle, not just an instruction fetch. As mentioned earlier, uninterruptible instructions don't stop DMA (e.g., multiple processors like a MILL, Softcard, or other coprocessor) from munging data between clock cycles. Why not just use the SEI instruction to prevent entrance into a critical section? On cheap systems you can do this. An error in the program (i.e., forgetting to turn the interrupts back on) could destroy the multitasking system though. >> Poorest interrupt latencies in the known market. Hmm.., let's see here. 7 cycles at 2.8Mhz is approx 2.5 usec. That's much better than a lot of processors. Furthermore, the 65xxx has a limited number of registers to save on an interrupt, meaning many fewer cycles pushing and popping registers. The 80x86, 68000, 32000, and RISC chips are the ones that have terrible interrupt latency times, not the 65xxx. Keep in mind, the 65xxx was designed as a controller chip-- it's supposed to be used in an interrupt driven environment. It handles interrupts rather well. Indeed, the 65xxx isn't a bad chip for fast interrupt response. It's just lacking certain features for a full general purpose preemptive multitasking OS (like memory management). *** Randy Hyde
rockeys@pro-abilink.cts.com (Rockey Stanaland) (12/30/90)
In-Reply-To: message from rankins@argentina I feel that the IIGS can do multitasking.... There is a REAL nice CDA that will transfer files in background. This is just part of what the GS can do if people can write the programs for it. (I just wish I could) ------------------------------------------------------------------------- Don't blame me... I only work in the Oil Patch. Rockey Stanaland ProLine: Pro-Abilink@rockeys --------------------------------------------------------------------------
brianw@microsoft.UUCP (Brian WILLOUGHBY) (01/01/91)
m.tiernan@pro-angmar.UUCP (Michael Tiernan) writes: >In-Reply-To: message from floyd@pawl.rpi.edu > >One thought, the 8088 and subsequent processors of that bastardized family >have all had one little thing that none of the others (6502, Z80, etc) have >had and that's some kind of instruction that CANNOT under ANY circumstances be >preempted. Now, I am not dead sure of the 8088 but the children of it have >had this instruction. Now you can't still say that this legitimizes the idea >of multiprocessing (or any other word prefixed by "multi") but it did allow >you to do more than you can without it. > >But as has been shown many times you ain't close without hardware level memory >management. > ><< MCT >> What sort of "preemption" are you expecting on an Apple ][ system, anyway? If there were multiple processors, or even multiple bus masters, then perhaps there might be some trouble. But the truth of the matter is that only interrupts can stop the flow of a program running on a 65x02, and all instructions of the 6502 are non-preemptable by interrupts. If you need to protect multiple instructions, then you will need to use the interrupt mask. I'm not saying that this 80x86 instruction is not useful, but I am saying that the design of the Apple ][ system would not be benefitted in any way by the existence of such an instruction. There are a few peripherals which use DMA for data transfer on the Apple ][, but there is no harm in preemption here, since those peripherals do not directly affect the program flow. They merely move data to/from memory - so as long as you don't try to overwrite your system semaphores, there will be no problems due to preemption. Brian Willoughby UUCP: ...!{tikal, sun, uunet, elwood}!microsoft!brianw InterNet: microsoft!brianw@uunet.UU.NET or: microsoft!brianw@Sun.COM Bitnet brianw@microsoft.UUCP
brianw@microsoft.UUCP (Brian WILLOUGHBY) (01/03/91)
In article <10806@ucrmath.ucr.edu> rhyde@ucrmath.ucr.edu (randy hyde) writes: >>>> All 65x02 instructions are uninterruptible. > >This is true for the 65x02, but not the 65c816. The 65c816 as the >/abort pin which can interrupt an instruction on any given clock >cycle, not just an instruction fetch. As mentioned earlier, uninterruptible >instructions don't stop DMA (e.g., multiple processors like a MILL, Softcard, >or other coprocessor) from munging data between clock cycles. I thought we were talking about the Apple ][ in this thread? To multitask or not to multitask, that is the question. None of the Apples use the ABORT pin, so it is totally ridiculous to mention it here except, perhaps, as an exercise in developing new hardware around the 65c816 (which would make a very interesting alternate thread, I'll admit). I wouldn't consider the loss of the use of my CPM card (which isn't even plugged in now) a serious drawback if it's DMA prevented multitasking. The truth is, there is nothing (but software development) preventing multitasking in the ][. >Why not just use the SEI instruction to prevent entrance into a critical >section? > >On cheap systems you can do this. An error in the program (i.e., forgetting >to turn the interrupts back on) could destroy the multitasking system though. The key issue is that you can do it. Most of the critical sections would be in the operating system code (if my assumptions are correct), so once the multitasking system were debugged, general development would not be affected by this minor imperfection. >>> Poorest interrupt latencies in the known market. > >... It handles interrupts rather well. >*** Randy Hyde Thank you for your support. At least the advantages of the 6502 can be mentioned alongside its deficiencies. Brian Willoughby UUCP: ...!{tikal, sun, uunet, elwood}!microsoft!brianw InterNet: microsoft!brianw@uunet.UU.NET or: microsoft!brianw@Sun.COM Bitnet brianw@microsoft.UUCP
rat@madnix.UUCP (David Douthitt) (01/06/91)
brianw@microsoft.UUCP (Brian WILLOUGHBY) writes: | The key issue is that you can do it. [multitasking] I HAD to add my .2c worth.... You CAN do multitasking on a II... Four or five years ago, I watched an Apple II handle 2 background tasks and a foreground task, and I also watched same said Apple II go multiuser with 2 users online as well. Of course, this was a co-operative multitasking environment. The system was an Apple II+ running Mad Apple Forth under DOS 3.3. Forth has been able to multitask (and multiuser) machines of incredibly SMALL size for years... PS: Mad Apple Forth is available for ProDOS - ask me! But multitasking was never re-implemented/cleaned-up/brushed-up/whatever when I converted from DOS 3.3 -- ! InterNet: deety!rat@spool.cs.wisc.edu ! David Douthitt ! UUCP: ...uwvax!astroatc!nicmad!madnix!deety!rat ! Madison, Wisconsin ! {decvax!att}! ! === Apple II Forever === ! Home of Mad Apple Forth and the Tiger Toolbox ! The Stainless Steel Rat
gwyn@smoke.brl.mil (Doug Gwyn) (01/09/91)
In article <m0ioqbP-00009YC@jartel.info.com> flee@gnh-applesauce.cts.com (FRANK LEE) writes: >What IS "pre-emptive multitasking," anyway?? It's switching of tasks without regard for what a currently running task is doing -- thus preempting it (for a while). Generally this is done by a task scheduler that is driven by clock interrupts; when an interrupt says that it is time to change tasks, if there are any ready tasks other than the currently executing one, the current task is suspended (its state must be preserved) and a new task is selected for execution until the next scheduler interrupt or until it blocks upon making a system service request that cannot be immediately satisfied, whichever comes first. For more details, consult any good text on operating system design. The obvious alternative is to schedule tasks only at system service request points; since a looping computation would indefinitely delay other tasks, this approach can hang the system if an application has such an error. However, for single-user multitasking environments it normally works quite well.
gwyn@smoke.brl.mil (Doug Gwyn) (01/11/91)
In article <60167@microsoft.UUCP> brianw@microsoft.UUCP (Brian WILLOUGHBY) writes: >I'm not saying that this 80x86 instruction is not useful, but I am >saying that the design of the Apple ][ system would not be benefitted >in any way by the existence of such an instruction. That's not true; in a multiprocessing environment there would certainly be the need for processes to coordinate access to shared resources. Some form of mutual exclusion would definitely be required. An instruction that can be exploited to implement some form of "mutex" locking is the simplest and most efficient way to accomplish this; often there is some instruction that can be exploited for the purpose even though it wasn't designed specifically for "test and set" usage. For example, on the PDP-11 one could exploit INC and ASRB in this manner.