01659@AECLCR.BITNET (Greg Csullog) (08/03/89)
It drives me nuts to see so many people worrying about multitasking on the ST. Jeez, at 8 MHz on a 68000 without a co-processor, I'm having trouble getting good performance running one application at a time. If a CPU intensive app is running, I do not want to make it crawl any slower by asking the CPU to service another application. Hell, most people crave multitasking but until you have a 68030 and a co-processor or a 80386 and a co-processor, it ain't worth worrying about for 99% of the users. Want to run a word processor and a spreadsheet at the same time. No problem, get REVOLVER and switch between apps. Want to generate huge dbMAN reports and run .CMD files while executing another CPU intensive app - forget it! Jumping between apps is OK on the ST. Running multiple, CPU intensive apps is silly. Yep the Amiga has multi-tasking; how many people REALLY benefit from it (I know this will spark a "look at me" response but I'm talking widespread use of multitasking, not isolated examples)?
mitchell@janus.uucp (Evan Mitchell) (08/03/89)
In article <8908021826.AA05333@ucbvax.Berkeley.EDU> 01659@AECLCR.BITNET (Greg Csullog) writes: >It drives me nuts to see so many people worrying about multitasking on the >ST. Jeez, at 8 MHz on a 68000 without a co-processor, I'm having trouble > >Jumping between apps is OK on the ST. Running multiple, CPU intensive apps >is silly. > >Yep the Amiga has multi-tasking; how many people REALLY benefit from it (I >know this will spark a "look at me" response but I'm talking widespread use >of multitasking, not isolated examples)? I'm not a power-user, I don't program, most of the time I just play around with my computer. I own an Amiga, I'm almost "typical" of Amiga (Widespread) user's and I can honestly admit, computers that don't multitask don't make sense to me. Everytime I use a mac, pc, st, etc. I always get frustrated because I can only do one (or a select few) thing at a time. Multi-tasking is second nature to Amiga user's. I believe a lot of users don't even realize this until they go to another machine that doesn't multitask, and things start to get frustrating. It's more than just running CPU intensive programs. It really is second nature... p.s. Let's not start a war, there are many more Amiga owner's better equipped to fight it than myself...:-) _______________________________________________________________________________ | Evan Jay Mitchell EECS/ERL Industrial Liaison Program | | mitchell@janus.berkeley.edu University of California at Berkeley | | Phone: (415) 643-6687 | | "Think, it ain't illegal...yet!" - George Clinton | |_____________________________________________________________________________|
koreth@panarthea.sun.com (Steven Grimm) (08/03/89)
In article <8908021826.AA05333@ucbvax.Berkeley.EDU> 01659@AECLCR.BITNET (Greg Csullog) writes: >Jumping between apps is OK on the ST. Running multiple, CPU intensive apps >is silly. I think people will not use multitasking much at home for a long time. The reason is simple. Most people, especially those who aren't especially computer literate, only use highly interactive programs. You can only interact with one program at a time. Multitasking is great for running a compile in the background while you edit a source file, but how many people want to leave their game running (as opposed to suspended) while they go word process for a while? Multitasking will catch on in a very limited way in homes. Print spoolers and little "clock in the corner" programs are current examples of the sorts of things that home users will want to do with multitasking. Task *switching*, on the other hand, is very useful. I have several friends with Amigas, and they mostly use its multitasking as a fancy task-switching system - push the word processor off the bottom of the screen to go play a game for a while, or whatever. I think they're probably typical of most Amiga owners. This may or may not change in the future, as people become more familiar with computers and applications become more intelligent, and can thus operate with less human intervention. The fact that technically-oriented people tend to actually use multitasking makes me think that it will probably be used more at home as time goes by. Of course, this doesn't really justify leaving multitasking out of your computer. Even if the home users almost never know it's there, it won't HURT them to have it, and you'll make your developers a lot happier. (I still miss it on the ST. I *am* a techie, after all. Now that I'm more or less gainfully employed, I should go out and buy RTX, or finish the multitasking stuff I was working on way back when...) --- This message is a figment of your imagination. Any opinions are yours. Steven Grimm Moderator, comp.{sources,binaries}.atari.st sgrimm@sun.com ...!sun!sgrimm
f0057@uafhp.uucp (James E. Ward) (08/03/89)
In article <34027@grapevine.uucp>, koreth@panarthea.sun.com (Steven Grimm) writes: > (I still miss it on the ST. I *am* a techie, after all. Now that I'm more > or less gainfully employed, I should go out and buy RTX, or finish the > multitasking stuff I was working on way back when...) > > --- > This message is a figment of your imagination. Any opinions are yours. > Steven Grimm Moderator, comp.{sources,binaries}.atari.st > sgrimm@sun.com ...!sun!sgrimm I am coming into a bit of money and am thinking about upgrading my ST 520 FM. I currently have two single sided drives and 512K. I'd like to have a little Unix style system on my hands. I've dabbled with OSK and am a rabid Unix fan so I know and use multitasking daily. Here's what I'd like to know: What multitasking kernels are available and how good are they? I use gulam unless I have to resort to GEM and I've heard that MX2 and Gulam work together? I tried MX2 to no avail once, is it better? How stable/good is Minix? Does GNU stuff work under it at all? I have a friend who is a Unix system administrator and has OSK with a hard drive and he says that I am such a rabid Unixer that I would not be satisfied with OSK. What do you think? Is OSK a reasonable alternative? RAM upgrades? I am not a hardware techie, so should I get the solderless variety? Which one? And at last, what about a hard-drive? Which one should I get? Let me know, eh? James E. Ward f0057@uafhp.uucp Use this address or bounce!
swklassen@dahlia.waterloo.edu (Steven W. Klassen) (08/03/89)
In article <8908021826.AA05333@ucbvax.Berkeley.EDU> 01659@AECLCR.BITNET (Greg Csullog) writes: >It drives me nuts to see so many people worrying about multitasking on the >ST. Jeez, at 8 MHz on a 68000 without a co-processor, I'm having trouble >getting good performance running one application at a time. If a CPU intensive >app is running, I do not want to make it crawl any slower by asking the CPU >to service another application. Hell, most people crave multitasking but until >you have a 68030 and a co-processor or a 80386 and a co-processor, it ain't >worth worrying about for 99% of the users. > >Want to run a word processor and a spreadsheet at the same time. No problem, >get REVOLVER and switch between apps. Want to generate huge dbMAN reports >and run .CMD files while executing another CPU intensive app - forget it! > >Jumping between apps is OK on the ST. Running multiple, CPU intensive apps >is silly. > >Yep the Amiga has multi-tasking; how many people REALLY benefit from it (I >know this will spark a "look at me" response but I'm talking widespread use >of multitasking, not isolated examples)? In __THEORY__ multitasking does not have to slow down the processes. "A single user cannot, in general, keep either the cpu or the I/O devices busy at all times. Multiprogramming [or multitasking if you prefer] is an attempt to increase cpu uilization by always having something for the cpu to execute." [_Operating_System_Concepts_ by Silberschatz and Peterson, p. 18] The basic idea (when related to a single user system) is that if you have one high priority (main) process and one or more lower priority processes the lower priority ones will only run during the times that the high priority one is not. For example, in a database program a LOT of the run time is spent doing nothing but waiting for user input. A lot of machine instructions can be executed by an 8Mhz processor during a, say, one second pause at the keyboard. Hence while the high priority process is waiting the low priority processes can run, being interrupted when the high priority one is ready again. Multitasking can actually speed up a program like a spreadsheet or a database by having the program written as a number of processes in which many of the 'housekeeping' tasks are done when the cpu is not otherwise busy. In theory this can be done on any machine. However, one which was designed with this in mind will do it much better than one which was not. Steven W. Klassen Computer Science Major University of Waterloo
NETOPRHM@NCSUVM.BITNET (Hal Meeks) (08/04/89)
Steven Grimm writes: >Summary: It's great for techies, but... In article <8908021826.AA05333@ucbvax.Berkeley.EDU> 01659@AECLCR.BITNET (Greg Csullog) writes: >Jumping between apps is OK on the ST. Running multiple, CPU intensive apps >is silly. >I think people will not use multitasking much at home for a long time. The >reason is simple. Most people, especially those who aren't especially computer >literate, only use highly interactive programs. You can only interact with >one program at a time. Well, in a strict sense yes. But things are changing, rapidly. IPC (Interproces s Communication) has been around on large systems for a long time. It's making its way into the micro arena. Why? Because multitasking is available for micros now. One of many scenarios: You buy a database that comes with a public message port, and you have a terminal program that has one too. You also have a HyperC*rd like program that has one. You build a data retrieval system that has a very pretty, and highly customisable front end. Without having to write a lot of code to do so. In fact, if you have a faint grasp of basic then it's within the realm of possibility. Customisable, modular software that allows a person to take a systems approach to using a computer. And it's available now. Would your average user do this? Sure, if it's easy enough to do. >Task *switching*, on the other hand, is very useful. Multibinder and the like are stopgap measures against the real thing. They are very wasteful of resources. Wouldn't it better to have an OS that has this stuff built in from scratch? Do not underestimate the value of multitasking. It allows a computer to work the same way people work. Very few times in life is an individual doing just _one_ thing. --hal ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hal Meeks "Some people gauge their successes by other people's failures." hgm@ccvr1.ncsu.edu
don@vax1.acs.udel.EDU (Donald R Lloyd) (08/04/89)
In article <8908021826.AA05333@ucbvax.Berkeley.EDU> 01659@AECLCR.BITNET (Greg Csullog) writes: >It drives me nuts to see so many people worrying about multitasking on the >ST. Jeez, at 8 MHz on a 68000 without a co-processor, I'm having trouble >getting good performance running one application at a time. If a CPU intensive >app is running, I do not want to make it crawl any slower by asking the CPU >to service another application. Hell, most people crave multitasking but until >you have a 68030 and a co-processor or a 80386 and a co-processor, it ain't >worth worrying about for 99% of the users. > >Want to run a word processor and a spreadsheet at the same time. No problem, >get REVOLVER and switch between apps. Want to generate huge dbMAN reports >and run .CMD files while executing another CPU intensive app - forget it! > >Jumping between apps is OK on the ST. Running multiple, CPU intensive apps >is silly. > >Yep the Amiga has multi-tasking; how many people REALLY benefit from it (I >know this will spark a "look at me" response but I'm talking widespread use >of multitasking, not isolated examples)? How about downloading a file onto one drive, formatting a disk in another, and editing text all at the same time? Or running your word processor with a ray-tracer going in the background? Running two paint programs and exchanging data between them? These are the kinds of things that amiga people (in your words) "REALLY benefit from", and can be easily done by anybody who's spent a little time learning to use their OS. I can do 'em, and I don't even own an amiga.....how's that for 'widespread use'? I hope this doesn't start Yet Another Flame War.... although I do like amigas, I'm not posting this to preach their obvious superiority :-) ( <-- notice smiley). I'm just trying to point out that multi-tasking DOES have a place in the home....or if it doesn't yet, it's only because IBM still hasn't 'invented' it for anybody who can't afford a 286 or 386 w/a few extra megs of memory and a HD fast enough to make the OS run at faster than Vic-20 speed..... Still stuck on a single-tasking C128 and wishing for a real computer... -- ------------------------------------------------------------------------------- | --------------- Don Lloyd El Campeador don@vax1.acs.udel.edu | | |Gibberish is | DISCLAIMER: don@pyr1.acs.udel.edu | | |spoken here. | My employers are idiots. They wouldn't understand | | --------------- my babbling even if they WERE literate enough to read it. | -------------------------------------------------------------------------------
jtreworgy@eagle.wesleyan.edu (08/04/89)
In article <8908021826.AA05333@ucbvax.Berkeley.EDU>, 01659@AECLCR.BITNET (Greg Csullog) writes: > It drives me nuts to see so many people worrying about multitasking on the > ST. Jeez, at 8 MHz on a 68000 without a co-processor, I'm having trouble > getting good performance running one application at a time. If a CPU intensive > app is running, I do not want to make it crawl any slower by asking the CPU > to service another application. Hell, most people crave multitasking but until > you have a 68030 and a co-processor or a 80386 and a co-processor, it ain't > worth worrying about for 99% of the users. > > Want to run a word processor and a spreadsheet at the same time. No problem, > get REVOLVER and switch between apps. Want to generate huge dbMAN reports > and run .CMD files while executing another CPU intensive app - forget it! > Just becasue an application is CPU intesive doesn't mean you can't benifit from multitasking with it. That's the best part. Suppose you are generating a huge dbMAN report (or generating a ray traced image, or anything that is going to take a long time). Suppose that you also want to use your computer for whatever else at the same time. So fine! You set the cpu-intesive application to a low priority, and start doing whatever you want! You won't notice any slowdown, because there won't be one. If the interactive task (whatever you are doing) has the highest priority, it will get the CPU time when it needs it. The other tasks will just run a little slower. Small price to pay to be able to do whatever you want while some other task is grinding away. > Jumping between apps is OK on the ST. Running multiple, CPU intensive apps > is silly. > Generating two separate ray traced images at the same time IS silly. It would be just as fast to do them one & then the other. But it is NOT silly to let it grind away in the background while you go about your business. > Yep the Amiga has multi-tasking; how many people REALLY benefit from it (I > know this will spark a "look at me" response but I'm talking widespread use > of multitasking, not isolated examples)? Not everybody needs to generate ray-traced images or create huge reports. But I do downloading, word processing, disk copying, printing, and a number of other things on a regular basis. It is very nice not to have to wait for these things to finish. Another added benifit is the ease of installation of little public domain utilities... anything you want, like an alarm clock, a virus checker, etc. can be installed as easily as running it. The way Amiga multitasking works, when these are set to low priority, they only take processor time when it is not being used, thus they don't slow anything down. (I'm sure there are ways to do things like this on the ST, but they probably involve patching or other kludges to run simultaneously, and consequently slow the system down). -- James A. Treworgy "You should have seen me with the poker man, jtreworgy@eagle.wesleyan.edu I had a honey and I bet a grand, jtreworgy%eagle@WESLEYAN.BITNET Just in the nick of time I looked at his hand" Box 5033 Wesleyan Station -Paul McCartney Middletown, CT 06475
greg@bilbo (Greg Wageman) (08/05/89)
In article <15627@watdragon.waterloo.edu> swklassen@dahlia.waterloo.edu (Steven W. Klassen) writes: > >In __THEORY__ multitasking does not have to slow down the processes. > >"A single user cannot, in general, keep either the cpu or the I/O > devices busy at all times. Multiprogramming [or multitasking if you > prefer] is an attempt to increase cpu uilization by always having > something for the cpu to execute." [_Operating_System_Concepts_ by > Silberschatz and Peterson, p. 18] > >Multitasking can actually speed up a program like a spreadsheet or a >database by having the program written as a number of processes in >which many of the 'housekeeping' tasks are done when the cpu is not >otherwise busy. In theory this can be done on any machine. However, >one which was designed with this in mind will do it much better than >one which was not. All of the above is true in general, *but*, the implementation of task scheduling varies from OS to OS and will greatly effect how fast the machine appears to the user. Typically, a task cannot be suspended in a multitasking environment until one of two things happens: it makes an operating system call which must wait for an external event (such as an "operation completed" interrupt) and is then put into a "blocked" state by the OS; or, in time-sliced OS's, its time quantum expires. Some real-time multitasking kernels do not require time slicing, so blocking calls are the only way a task switch ever occurs. The implication is that if the so-called "background" process is doing something CPU intensive(e.g. an in-memory sort), it may not make a blocking call for a very long time (i.e. several seconds). The user will begin to type characters, generating an interrupt which will unblock his foreground task. The OS will move the now-unblocked foreground task to the "ready" task queue, but it *will not begin to run* until the background task blocks (or its time quantum expires). If the system clock is grainy enough (i. e. the clock "tick" interval is very large), or a task context-switch is very expensive, or (yuck!) both, hundreds of milliseconds will elapse between the user's keypress and the resumption of execution of the foreground task. Thus, the user will perceive a very sluggish response from the foreground task. The reference to a machine designed from the start for multitasking is valid, because proper hardware design can minimize the expense of context-switching, provide a suitably fine-grained system clock, and include appropriate interrupt support for devices. Trying to retro-fit multitasking into a machine not designed for it is at best a frustrating job whose results may not justify the effort. Greg Wageman DOMAIN: greg@sj.ate.slb.com Schlumberger Technologies UUCP: ...!uunet!sjsca4!greg 1601 Technology Drive BIX: gwage San Jose, CA 95110-1397 CIS: 74016,352 (408) 437-5198 GEnie: G.WAGEMAN ------------------ Opinions expressed herein are solely the responsibility of the author.
rachamp@mbunix.mitre.org (Richard A. Champeaux) (08/05/89)
In article <8908021826.AA05333@ucbvax.Berkeley.EDU> 01659@AECLCR.BITNET (Greg Csullog) writes: >It drives me nuts to see so many people worrying about multitasking on the >ST. Jeez, at 8 MHz on a 68000 without a co-processor, I'm having trouble >getting good performance running one application at a time. If a CPU intensive >app is running, I do not want to make it crawl any slower by asking the CPU >to service another application. Hell, most people crave multitasking but until >you have a 68030 and a co-processor or a 80386 and a co-processor, it ain't >worth worrying about for 99% of the users. > >Want to run a word processor and a spreadsheet at the same time. No problem, >get REVOLVER and switch between apps. Want to generate huge dbMAN reports >and run .CMD files while executing another CPU intensive app - forget it! First off, the majority of applications are user input driven. Meaning that if the user doesn't provide input, the program is idle. For instance, spread sheets, word processors, etc. In a multi-tasking enviroment, such programs sleep when idle and take up no CPU time. Using multi-tasking to switch between applications like these would have the same affect as using REVOLVER. Although I know nothing about REVOLVER, I imagine that it is only a brute force way of getting some of the advantages of multi-tasking, and I imagine it probably has quite a few limitations. For instance, do you have to tell it what applications you're going to run ahead of time, or can you decide on the fly? Does it work with ALL programs? How easy is it to start up a new process? How much overhead does it require for each application? You asked for simple common uses for multi-tasking on the Amiga. Here are two of the more common, less demanding uses of multi-tasking that I do on my Amiga 2000: I do a considerable amount of programming (all just for sport, not for money). One of the most common things that happens to me is that I'll make a change in one of the files of a 10 or so file program, like maybe change a structure definition, and I'll have to figure out which other files need to be changed. I'm already in the editor, but since I'm multi-tasking, and have a CLI (command line interpreter) sitting out there, I click on the title bar of my editor, making it turn into a small window and exposing the CLI window, and type "grep foobar *.c *.h". Better yet, since my editor can edit multiple files, and since through multi-tasking, it can execute other AmigaDOS commands, I can have my editor execute grep and put the results into a file buffer. Sure, I could have just exited from my editor, and then run grep, but why make life harder, I have multi-tasking. A more Joe Average use of multi-tasking occurs when ever I get a requester saying "Disk Full". This doesn't happen much anymore, since I just bought an 80 Meg drive, but when all I had was a 20 Meg, it happened often. When ever I get one of these messages, I don't worry or get upset, I just click on my CLI window, or press Left-Amiga-ESC (a key sequence which another multi-tasking program intercepts and opens a new CLI window), and start searching through my directory structure for files that can be deleted, or compressed, or copied to another disk. When I'm finished, I click on the retry gadget of the Disk Full requester, and everything proceeds happily. I don't know about the Atari, but if on an IBM, you get a Disk Full error after you told your editor to save and exit, you have three choices: abort, retry, or ignore. Retry won't help any, ignore will give you a trashed file and the editor will exit as soon as it thinks it saved the file, and abort throws you back to the system prompt. Any way you look at it, you're screwed. The question "Why do you need multi-tasking on a personal computer?" is much like the question "Why do you need more than 64k in a personal computer?" which people were asking 8-10 years ago. Once you have, you realize that you can't live without it. A phrase that comes to mind: "Don't knock it til you've tried it." Rich Champeaux (rachamp@mbunix.mitre.org)
alderaan@tubopal.UUCP (Thomas Cervera) (08/05/89)
What's all this about MultiTasking on the ST ? You don't have a MMU (not really and I think that's the worst failure in the ST's hardware architechture), so you are definetely not able to run a *secure* multitasking on this machine even if you want to - basta. All what you can call protected memory inside the ST is a bunch of bytes at the bottom plus the hardware registers - that's it. If you want to realize reasonable memory segmentation (in my experience this is essential for TimeSharing) you MUST have a MMU. -- Thomas Cervera | UUCP: alderaan@tubopal.UUCP SysMan RKOpdp (RSTS/E) | alderaan%tubopal.UUCP@TUB.BITNET (saves $$$) D-1000 Berlin 30 | ...!pyramid!unido!tub!opal!alderaan Motzstrasze 14 | BITNET: alderaan%tub@DB0TUI11.BITNET
mgardi@watdcsu.waterloo.edu (M.Gardi - ICR) (08/05/89)
>In article <8908021826.AA05333@ucbvax.Berkeley.EDU>, 01659@AECLCR.BITNET (Greg Csullog) writes: > It drives me nuts to see so many people worrying about multitasking on the > ST. Jeez, at 8 MHz on a 68000 without a co-processor, I'm having trouble > getting good performance running one application at a time. This sounds a lot like sour grapes. "I can't have it, so it can't be any good." You want to know how to make a million dollars? Write a program, or design a piece of hardware that will make an AT multi-task transparently. Same thing if you're using for a Mac. APPLE and IBM/Compaq/Dell/... would buy it in an instant. The industry seems to recognize the value of Multi- tasking. Witness OS/2, VM-386, the 386 itself, Multi-finder, UNIX, QNX, etc... Just think of the money that could've been saved if they had hired Greg Csullog as a consultant. He could've told them that nobody needs or wants multi-tasking. At work we use PS/2 Model 70 - A21's with 120 MB disks and 6 MB ram just so we can use VM-386 which provides multi-tasking of DOS applications. Let me tell you that it's a real kludge, but it's the best we can do. I know, you're talking about home multi-tasking, but you'd really like to go back to a single-tasking machine at home after using one all day at work? > Yep the Amiga has multi-tasking; how many people REALLY benefit from it (I > know this will spark a "look at me" response but I'm talking widespread use > of multitasking, not isolated examples)? If you're counting votes, then put me down for one "I REALLY benefit from it".
swklassen@dahlia.waterloo.edu (Steven W. Klassen) (08/05/89)
In article <1989Aug4.173233.8259@sj.ate.slb.com> greg@sj.ate.slb.com (Greg Wageman) writes: >In article <15627@watdragon.waterloo.edu> swklassen@dahlia.waterloo.edu (Steven W. Klassen) writes: >>otherwise busy. In theory this can be done on any machine. However, >>one which was designed with this in mind will do it much better than >>one which was not. [...] > >The reference to a machine designed from the start for multitasking is >valid, because proper hardware design can minimize the expense of >context-switching, provide a suitably fine-grained system clock, and >include appropriate interrupt support for devices. Trying to >retro-fit multitasking into a machine not designed for it is at best a >frustrating job whose results may not justify the effort. I was really trying to make two points: 1) Multitasking is good, even on a single user system, since it allows more efficient use of the CPU through background tasks. 2) This should be designed into the system from the start so as to minimize the overhead. (Greg made this one much clearer than I did.) Conclusion: The next generation of Atari machines should be multitasking ones. Any hints as to whether this will happen Atari? Steven W. Klassen Computer Science Major University of Waterloo
James.E..Ward@mamab.FIDONET.ORG (James E. Ward) (08/06/89)
-- Fidonet: James E. Ward via 1:363/9 Internet: James.E..Ward@mamab.FIDONET.ORG Usenet: ...!peora!rtmvax!libcmp!mamab!James.E..Ward
swklassen@dahlia.waterloo.edu (Steven W. Klassen) (08/07/89)
In article <652@opal.tubopal.UUCP> alderaan@tubopal.UUCP (Thomas Cervera) writes: > > What's all this about MultiTasking on the ST ? You don't have a MMU (not >really and I think that's the worst failure in the ST's hardware architechture), >so you are definetely not able to run a *secure* multitasking on this machine >even if you want to - basta. All what you can call protected memory inside the >ST is a bunch of bytes at the bottom plus the hardware registers - that's it. > If you want to realize reasonable memory segmentation (in my experience this >is essential for TimeSharing) you MUST have a MMU. > >-- >Thomas Cervera | UUCP: alderaan@tubopal.UUCP >SysMan RKOpdp (RSTS/E) | alderaan%tubopal.UUCP@TUB.BITNET (saves $$$) >D-1000 Berlin 30 | ...!pyramid!unido!tub!opal!alderaan >Motzstrasze 14 | BITNET: alderaan%tub@DB0TUI11.BITNET Oh really? Then how do you explain the appearance of Minix (a Unix look-alike) for the Atari ST? I have cross posted this to the Minix newsgroup. I thought you (Thomas) might be interested in telling those who gave the ST multitasking just why what they have done is not possible. I agree that the Atari hardware is not designed for multitasking but that does not make it impossible, only less efficient. By creating multitasking systems for the ST (like Minix and MX2) people are telling Atari that we want multitasking and would like the hardware to support it. Steven W. Klassen Computer Science Major University of Waterloo
david.megginson@canremote.uucp (DAVID MEGGINSON) (08/07/89)
We'd love to have some kind of switching ability here, so that we would not have to keep quitting Calamus, going into the drawing program, touching up a graphic, quitting the drawing program, and going back into Calamus again (the story of our lives). As for true multi-tasking, I'd kill for it, but my wife (who is an editor and layout artist) would probably rarely use it. The advantage of multi-tasking is that every program would not have to try to emulate every other program (note the plethora of programs with file functions like copy and disk format built-into them), and that different sorts of programs would not have to compete with each other, but could come together into some kind of large, useful whole. --- * Via ProDoor 3.01R
f-leoe@IFI.UIO.NO (Lars-Erik 0sterud) (08/07/89)
If they can make a standard PC multitasking with DesqView Why not multitasking TOS ? I can't be any worse (or can it ????) Lars-Erik 0sterud / Summer & Christmas: / leoe@ifi.uio.no / f-leoe@ifi.uio.no / ____________________/ _______________________/
rosenkra@hall.cray.com (Bill Rosenkranz) (08/07/89)
In article <62441@linus.UUCP> rachamp@mbunix (Champeaux) writes: =In article <8908021826.AA05333@ucbvax.Berkeley.EDU> 01659@AECLCR.BITNET (Greg Csullog) writes: =>It drives me nuts to see so many people worrying about multitasking on the =>ST. Jeez, at 8 MHz on a 68000 without a co-processor, I'm having trouble =>getting good performance running one application at a time. [stuff deleted...] =>Want to run a word processor and a spreadsheet at the same time. No problem, =>get REVOLVER and switch between apps. = =First off, the majority of applications are user input driven. Meaning that =if the user doesn't provide input, the program is idle. For instance, how about compiles? these SHOULD go in the background more often than not. no input needed... =You asked for simple common uses for multi-tasking on the Amiga. Here are =two of the more common, less demanding uses of multi-tasking that I do on my =Amiga 2000: = [describes a user-initiated edit/cli switch] this is not a good example. you are simply task switching, something that programs like revolver can do. [describes another user-initiated switch, disk full/cli delete scenario] this, again is a simple switch of which program is executing. i think the general topic concerns doing several tasks simultaneously (i.e. let the os kernel do the context switch based on some scheduling mechanism). this way you can be compiling something (or doing some database, raytrace, etc op) while you read mail, play a game, or compile another program. =The question "Why do you need multi-tasking on a personal computer?" is much =like the question "Why do you need more than 64k in a personal computer?" =which people were asking 8-10 years ago. Once you have, you realize that =you can't live without it. = =Rich Champeaux (rachamp@mbunix.mitre.org) agreed... without an mmu to police memory, the os has to do it. this is terribly slow, IMHO. you just don't want one task stepping on another. -bill rosenkra@boston.cray.com
jtreworgy@eagle.wesleyan.edu (08/07/89)
In article <1989Aug4.173233.8259@sj.ate.slb.com>, greg@bilbo (Greg Wageman) writes: [....] > > All of the above is true in general, *but*, the implementation of task > scheduling varies from OS to OS and will greatly effect how fast the > machine appears to the user. > > Typically, a task cannot be suspended in a multitasking environment > until one of two things happens: it makes an operating system call > which must wait for an external event (such as an "operation > completed" interrupt) and is then put into a "blocked" state by the > OS; or, in time-sliced OS's, its time quantum expires. Some real-time > multitasking kernels do not require time slicing, so blocking calls are > the only way a task switch ever occurs. > > The implication is that if the so-called "background" process is doing > something CPU intensive(e.g. an in-memory sort), it may not make a > blocking call for a very long time (i.e. several seconds). The user > will begin to type characters, generating an interrupt which will > unblock his foreground task. The OS will move the now-unblocked > foreground task to the "ready" task queue, but it *will not begin to > run* until the background task blocks (or its time quantum expires). > If the system clock is grainy enough (i. e. the clock "tick" interval > is very large), or a task context-switch is very expensive, or (yuck!) > both, hundreds of milliseconds will elapse between the user's keypress > and the resumption of execution of the foreground task. Thus, the > user will perceive a very sluggish response from the foreground task. > I don't program the Amiga at a low level, so I don't know exactly how it works. I do know, however, that if I am running a task which has a higher priority than the CPU-intensive task, I NEVER have sluggish response from the foreground task. Try it sometime and see for yourself. -- James A. Treworgy "You should have seen me with the poker man, jtreworgy@eagle.wesleyan.edu I had a honey and I bet a grand, jtreworgy%eagle@WESLEYAN.BITNET Just in the nick of time I looked at his hand" Box 5033 Wesleyan Station -Paul McCartney Middletown, CT 06475
rachamp@mbunix.mitre.org (Richard A. Champeaux) (08/07/89)
In article <4050@hall.cray.com> rosenkra@hall.UUCP (Bill Rosenkranz) writes: >In article <62441@linus.UUCP> rachamp@mbunix (Champeaux) writes: > >=You asked for simple common uses for multi-tasking on the Amiga. Here are >=two of the more common, less demanding uses of multi-tasking that I do on my >=Amiga 2000: >= >[describes a user-initiated edit/cli switch] > >this is not a good example. you are simply task switching, something that >programs like revolver can do. > >[describes another user-initiated switch, disk full/cli delete scenario] > >this, again is a simple switch of which program is executing. i think the >general topic concerns doing several tasks simultaneously (i.e. let the os >kernel do the context switch based on some scheduling mechanism). this way >you can be compiling something (or doing some database, raytrace, etc op) >while you read mail, play a game, or compile another program. > >=Rich Champeaux (rachamp@mbunix.mitre.org) > Agreed. The two things I mentioned are not very demanding of a multi-tasking OS, and could be performed by something like REVOLVER. The original author said he didn't want "look at me" examples, he wanted examples of things that everyone might use. To truely make use of running programs simultaneanously, you need a program that requires no user input and will run for a long time. Compiling programs doesn't quite fit the bill. When I'm compiling programs, rarely do I say, "Gee, I have 30 seconds while the compiler is running, lets load up a game." I have raytraced animations in the background while I'm writting programs, or I'm calling a BBS. If the raytracer is put at a lower priority than what I'm currently running, you almost can't tell it's there. Best of all, you don't have to give up your computer for several days. Ahh, the hell with it. It's not worth arguing about. You can lead a horse to water, but you can't make him drink. Let him die of thirst, if that's what he wants. > >without an mmu to police memory, the os has to do it. this is terribly >slow, IMHO. you just don't want one task stepping on another. > >-bill >rosenkra@boston.cray.com Now there's a point to debate. Do you really need memory protection on a single user multi-tasking computer. On a multi-user computer, memory protection is a necessity, since if one user's program crashes, you don't want to bring down the 50 other users. On a personal computer, where cost is an important factor, is it really necessary? (kind of sounds like the question "Is multi-tasking really necessary?" doesn't it?) It would, however, be really nice. Rich Champeaux (rachamp@mbunix.mitre.org)
alderaan@tubopal.UUCP (Thomas Cervera) (08/08/89)
In article <15706@watdragon.waterloo.edu> swklassen@dahlia.waterloo.edu (Steven W. Klassen) writes: >In article <652@opal.tubopal.UUCP> alderaan@tubopal.UUCP (Thomas Cervera) writes: >>so you are definetely not able to run a *secure* multitasking on this machine ^^^^^^^^ keep in mind >> If you want to realize reasonable memory segmentation (in my experience this >>is essential for TimeSharing) you MUST have a MMU. >Oh really? Then how do you explain the appearance of Minix (a Unix >look-alike) for the Atari ST? But look at the performance of that multitasking system. And, If I'd decide to write a real nasty program to run under Minix, the chance is 99% that I crash the WHOLE system with this program. Myself, I am a Minix user and I think I know what I'm talking about. Conclusion : Minix is a very nice software to use it for learning about time sharing, but it's useless for a *secure* (as I said above) every day multi(tasking|user) operation because it is definetely not reliable enough. You WILL have this problem with all multi tasking systems running on an unmodified ST. I think nobody would ever have the serious idea to use Minix to run an open access machine, for example, even if the hardware was sufficient (dialup lines, fast disk for the non-existent Minix swapper etc.). -- Thomas Cervera | UUCP: alderaan@tubopal.UUCP SysMan RKOpdp (RSTS/E) | alderaan%tubopal.UUCP@TUB.BITNET (saves $$$) D-1000 Berlin 30 | ...!pyramid!unido!tub!opal!alderaan Motzstrasze 14 | BITNET: alderaan%tub@DB0TUI11.BITNET
cmcmanis%pepper@Sun.COM (Chuck McManis) (08/08/89)
At the risk of dating myself, the multitasking discussion reminds me of
the CP/M hard disk wars. At the time, ST506 (5Meg) hard disks were real
high tech, but most users had a pair of double sided 8" floppies giving
them 2.4M of removable storage. People with floppies would always argue
how useless a 5Meg drive was, they could replace entire development systems
by just swapping a floppy. And floppies naturally organized their data into
generic chunks. The hard disk users would crow about "high speed access"
and having several editors available without having to change disks. The
fact of the matter was, both were right and both were wrong. Most dedicated
floppy users become convinced after a using a hard disk for a while that it
is the greatest thing since sliced bread ('til it crashes of course! :-))
and most people using single tasking OS's find uses for multitasking OS's
and after a while can't live without them. In another 5 years when the
standard micro is a '030 or '386 based box with an MMU it will be the
rarity that you _don't_ have a multitasking OS. But in the mean time,
OS's are OS's. If they do the job, then like the 8" floppies before them
they are not worth arguing about.
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.
"A most excellent barbarian ... Genghis Kahn!"johnl@tw-rnd.SanDiego.NCR.COM (John Lindwall) (08/08/89)
In article <652@opal.tubopal.UUCP> alderaan@tubopal.UUCP (Thomas Cervera) writes: > > What's all this about MultiTasking on the ST ? You don't have a MMU (not >really and I think that's the worst failure in the ST's hardware architechture), >so you are definetely not able to run a *secure* multitasking on this machine >even if you want to - basta. All what you can call protected memory inside the >ST is a bunch of bytes at the bottom plus the hardware registers - that's it. > If you want to realize reasonable memory segmentation (in my experience this >is essential for TimeSharing) you MUST have a MMU. > Amen to that! Amiga owners have suffered with the lack of an MMU. The usefulness multitasking is a given, IMO. The security of Amiga's multitasking is poor due to the lack of memory protection supplied by an MMU. Those of you who agree multitasking is useful, and would like to see it on an Atari: Demand it from Atari and demand MMU support as well. ---------------------------------------------------------------------- "Above opinions are my own, not my employer's" John Lindwall johnl@tw-rnd.SanDiego.NCR.COM
greg@uop.EDU (Greg Onufer) (08/08/89)
01659@AECLCR.BITNET (Greg Csullog) writes: >It drives me nuts to see so many people worrying about multitasking on the >ST. Jeez, at 8 MHz on a 68000 without a co-processor, I'm having trouble >getting good performance running one application at a time. If a CPU intensive >app is running, I do not want to make it crawl any slower by asking the CPU >to service another application. Hell, most people crave multitasking but until >you have a 68030 and a co-processor or a 80386 and a co-processor, it ain't >worth worrying about for 99% of the users. Well, for comparison, a Sun-2 (or Sun 100U) uses a 10 Mhz 68010, which is not a quantum leap ahead of the 8 Mhz 68000. It runs SunOS 4.0, which many readers may recognize to be a performance limiter, especially compared to previous versions of SunOS. This system is in use at home right next to my ST. Even with the overhead of multiple processes and limited memory (Sun states that 8 Meg is the bottom limit in a useful system, I have 6 Megs), the Sun-100U is still performing useful work every day. Don't belittle the 68000, it is not a slow processor by any means. What you are noticing is poorly written systems software (ie, TOS & GEM). As the QuickST code demonstrates, the code in ROM is not incredibly optimal. What I am getting at is the ST, with a well written OS, could indeed execute multiple programs concurrently and do it well. The problems are not processor speed, but memory protection. Virtual memory is nearly impossible (on the 68000, not the 680[1234]0). Comments? Flames? Cheers!greg (greg@cheers.UUCP, cheers!greg@lll-winken.llnl.gov)
ralph@cc.brunel.ac.uk (Ralph Mitchell) (08/08/89)
In article <15706@watdragon.waterloo.edu> swklassen@dahlia.waterloo.edu (Steven W. Klassen) writes: >In article <652@opal.tubopal.UUCP> alderaan@tubopal.UUCP (Thomas Cervera) writes: >> >> What's all this about MultiTasking on the ST ? You don't have a MMU (not >>really and I think that's the worst failure in the ST's hardware architechture), >>so you are definetely not able to run a *secure* multitasking on this machine >>even if you want to - basta. All what you can call protected memory inside the >>[...] >Oh really? Then how do you explain the appearance of Minix (a Unix >look-alike) for the Atari ST? > >I have cross posted this to the Minix newsgroup. I thought you (Thomas) >might be interested in telling those who gave the ST multitasking >just why what they have done is not possible. Actually, he did say SECURE multitasking was not possible. i.e. One process address space is not protected against another process writing all over it. Ralph Mitchell -- JANET: ralph@uk.ac.brunel.cc ARPA: ralph%cc.brunel.ac.uk@cwi.nl UUCP: ...ukc!cc.brunel!ralph PHONE: +44 895 74000 x2561 "There's so many different worlds, so many different Suns" - Dire Straits "Never underestimate the power of human stupidity" - Salvor Hardin, Foundation
rachamp@mbunix.mitre.org (Richard A. Champeaux) (08/08/89)
>In article <1989Aug4.173233.8259@sj.ate.slb.com>, greg@bilbo (Greg Wageman) writes: >> Typically, a task cannot be suspended in a multitasking environment >> until one of two things happens: it makes an operating system call >> which must wait for an external event (such as an "operation >> completed" interrupt) and is then put into a "blocked" state by the >> OS; or, in time-sliced OS's, its time quantum expires. Some real-time >> multitasking kernels do not require time slicing, so blocking calls are >> the only way a task switch ever occurs. >> >> The implication is that if the so-called "background" process is doing >> something CPU intensive(e.g. an in-memory sort), it may not make a >> blocking call for a very long time (i.e. several seconds). The user >> will begin to type characters, generating an interrupt which will >> unblock his foreground task. The OS will move the now-unblocked >> foreground task to the "ready" task queue, but it *will not begin to >> run* until the background task blocks (or its time quantum expires). >> If the system clock is grainy enough (i. e. the clock "tick" interval >> is very large), or a task context-switch is very expensive, or (yuck!) >> both, hundreds of milliseconds will elapse between the user's keypress >> and the resumption of execution of the foreground task. Thus, the >> user will perceive a very sluggish response from the foreground task. >> From The Amiga ROM Kernel manual: Every task has an assigned priority and tasks are scheduled to use the processor on a priority basis. The highest priority ready task is selected and receives processing until: 1. A higher priority task becomes active. 2. The running task exceeds a preset time period (a quantum) and there is another equal priority task to run, or 3. The task needs to wait for an external event before it can continue. Task scheduling is preemptive in nature. The running task may lose the processor at nearly any moment by being displaced by another more urgent task. Later, when the preempted task regains the processor, it continues where it left off. When a higher priority task becomes active, the running task is immediately interrupted. A task would become active if, for instance, it was waiting for a key to be pressed and the user pressed one. There would would be no degradation in response by a CPU intensive task if that task has a lower priority. Time slicing occurs only within groups of equal priority tasks. In fact, if a CPU intensive task was a higher priority task than other tasks, those tasks would be starved by the CPU intensive one. Last night I ran a raytrace at a lower priority than my Command Line Interpreter and saw no performance degradation. Even when I just mashed my hands down on the keyboard there was no sluggishness. Rich Champeaux (rachamp@mbunix.mitre.org)
swklassen@dahlia.waterloo.edu (Steven W. Klassen) (08/09/89)
In article <666@opal.tubopal.UUCP> alderaan@tubopal.UUCP (Thomas Cervera) writes: >>> If you want to realize reasonable memory segmentation (in my experience this >>>is essential for TimeSharing) you MUST have a MMU. >>Oh really? Then how do you explain the appearance of Minix (a Unix >>look-alike) for the Atari ST? > > But look at the performance of that multitasking system. > And, If I'd decide to write a real nasty program to run under Minix, >the chance is 99% that I crash the WHOLE system with this program. Myself, >I am a Minix user and I think I know what I'm talking about. > > Conclusion : Minix is a very nice software to use it for learning about >time sharing, but it's useless for a *secure* (as I said above) every day >multi(tasking|user) operation because it is definetely not reliable enough. >You WILL have this problem with all multi tasking systems running on an >unmodified ST. "Although MINIX was first implemented on the IBM PC/XT/AT familiy, it was written with portability in mind. We considered it a challenge to test the portability, and used the Atari ST as the target machine for a number of reasons. The ST is a popular machine with a good price/ performance ratio, and attracts a different class of users. The ST uses the Motorola 68000 processor, as several other popular micros do, so that a port to the ST could serve as the starting point for ports to the Apple Macintosh and Commodore Amiga. LASTLY, THERE IS A WIDESPREAD BELIEF THAT UNIX, AND THEREFORE MINIX, REQUIRES THE SUPPORT OF A MEMORY MANAGEMENT UNIT (MMU). PROVING THE OPPOSITE HAS BEEN ONE OF OUR DRIVING FORCES." (excerpt from Intro to Minix ST manual) You emphasize that MINIX ST is not secure and claim this is due to the lack of the MMU. I agree that MINIX ST is not secure but claim that this is not due to the lack of an MMU but due to the fact that Mr. Tanenbaum wanted to keep things simple. To support this note that MINIX is not particularly secure on the IBMs either even though they do have a (sort of) MMU. As for the security of other attempts at multiprocessing (eg. MX2), I have not tried any of them so I really can't comment on them. Finally, I agree with you that the Atari ST hardware is not meant for multitasking. My dissagrement is that I claim this makes multitasking difficult and inefficient (compared to a machine that does support it in hardware) BUT NOT IMPOSSIBLE. Let me close with the conclusion which I have been trying to get accross: 1) MULTITASKING IS USEFUL, EVEN ON A SINGLE-USER MACHINE 2) MULTITASKING IS POSSIBLE WITHOUT A GREAT DEAL OF EXTRA HARDWARE 3) MINIX AND MX2 ARE EVIDENCE THAT ATARI USERS WANT MULTITASKING 4) HENCE ATARI CORP SHOULD GIVE US MULTITASKING *WITH*THE*HARDWARE*TO* MAKE*IT*EFFICIENT. Steven W. Klassen Computer Science Major University of Waterloo
daveh@cbmvax.UUCP (Dave Haynie) (08/10/89)
in article <89080709104987@masnet.uucp>, david.megginson@canremote.uucp (DAVID MEGGINSON) says: > The advantage of multi-tasking is that every program would not have to > try to emulate every other program (note the plethora of programs with > file functions like copy and disk format built-into them), and that > different sorts of programs would not have to compete with each other, > but could come together into some kind of large, useful whole. That is basically what AREXX on the Amiga does for non-trivial cases. Certainly a single-tasking wordprocessor can include a minimal database function, or allow small specially written programs (Desk Accessories) to be called up for other peripheral functions during an editing session. But if a particular operation is needed often enough in the wordprocessor, it should be easily added to that word processor. You're not going to be able to convince the author of your favorite program, in most cases, to add in this feature that you use constantly unless it's likely to be needed by lots of users. Now move this to a multitasking system like the Amiga. The wordprocessor has only wordprocessor functions in it, and one extra goodie, an AREXX port. If I find I need a database function from within my wordprocessor on a regular basis, I can write a simple AREXX macro that'll use the real, full fledged database program, via it's AREXX port, from within my wordprocessor. All pretty transparent once the macro is written, as one might expect. Multitasking has been around for quite some time. It's really only now becoming extremely useful, rather than just handy, to users, thanks to user interfaces which make it far easier to manage separate tasks that UNIX-like job control, and thanks to inter-process communication mechanisms like AREXX, which let any program become a system resource that all other programs can take advantage of. -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Be careful what you wish for -- you just might get it
rob@kaa.eng.ohio-state.edu (Rob Carriere) (08/10/89)
In article <666@opal.tubopal.UUCP> alderaan@tubopal.UUCP (Thomas Cervera) writes: > And, If I'd decide to write a real nasty program to run under Minix, >the chance is 99% that I crash the WHOLE system with this program. Myself, >I am a Minix user and I think I know what I'm talking about. I'll gladly concur until you supply evidence to the contrary. :-) > Conclusion : Minix is a very nice software to use it for learning about >time sharing, but it's useless for a *secure* (as I said above) every day >multi(tasking|user) operation because it is definetely not reliable enough. >You WILL have this problem with all multi tasking systems running on an >unmodified ST. Yup. You will also have the _exact_same_ security problem with any task switcher on an unmodified ST. At the very least the taskswitcher must keep part of itself in memory. I can trash that from my program. You will have the same problem with a RAM-disk. This is not an argument against multitasking and for task switching because it applies with equal force to both. SR
leo@philmds.UUCP (Leo de Wit) (08/10/89)
In article <471@tw-rnd.SanDiego.NCR.COM> johnl@tw-rnd.SanDiego.NCR.COM (John Lindwall) writes: |In article <652@opal.tubopal.UUCP> alderaan@tubopal.UUCP (Thomas Cervera) writes: |> |> What's all this about MultiTasking on the ST ? You don't have a MMU (not |>really and I think that's the worst failure in the ST's hardware architechture), |>so you are definetely not able to run a *secure* multitasking on this machine |>even if you want to - basta. [] | |Amen to that! Amiga owners have suffered with the lack of an MMU. The |usefulness multitasking is a given, IMO. The security of Amiga's multitasking |is poor due to the lack of memory protection supplied by an MMU. Those of |you who agree multitasking is useful, and would like to see it on an Atari: |Demand it from Atari and demand MMU support as well. I think two issues are being confused here, the need for per process memory protection, and the possible to run processes 'simultaneously'. Why should memory protection be a hotter item when parallel processes are involved? In the current situation it is just as well feasible for instance by an application program to thrash the space of the shell it was invoked by. So if you insist on security, you should insist on it right now already. An MMU alone probably won't hack it; you will probably want a 680x0 (x >= 1) to be able to page in new memory (a 68000 doesn't maintain enough internal information to be able to restore correctly from a BUSERR). Leo.
leo@philmds.UUCP (Leo de Wit) (08/10/89)
In article <1989Aug4.173233.8259@sj.ate.slb.com> greg@sj.ate.slb.com (Greg Wageman) writes: [] |Typically, a task cannot be suspended in a multitasking environment |until one of two things happens: it makes an operating system call |which must wait for an external event (such as an "operation |completed" interrupt) and is then put into a "blocked" state by the |OS; or, in time-sliced OS's, its time quantum expires. Some real-time |multitasking kernels do not require time slicing, so blocking calls are |the only way a task switch ever occurs. Read for this moment for 'an operating system call' a GEMDOS call, for 'time quantum' a (number of) VBL interrupts (or other clock generated interrupts). | |The implication is that if the so-called "background" process is doing |something CPU intensive(e.g. an in-memory sort), it may not make a |blocking call for a very long time (i.e. several seconds). The user |will begin to type characters, generating an interrupt which will |unblock his foreground task. The OS will move the now-unblocked |foreground task to the "ready" task queue, but it *will not begin to |run* until the background task blocks (or its time quantum expires). |If the system clock is grainy enough (i. e. the clock "tick" interval |is very large), or a task context-switch is very expensive, or (yuck!) |both, hundreds of milliseconds will elapse between the user's keypress |and the resumption of execution of the foreground task. Thus, the |user will perceive a very sluggish response from the foreground task. | |The reference to a machine designed from the start for multitasking is |valid, because proper hardware design can minimize the expense of |context-switching, provide a suitably fine-grained system clock, and |include appropriate interrupt support for devices. Trying to |retro-fit multitasking into a machine not designed for it is at best a |frustrating job whose results may not justify the effort. The discussion about multitasking triggered my interest, so I decided to try some things out. It appears that context switching is easy if you do it at the moment of a GEMDOS call: all registers have been saved on either the stack or the basepage, so in fact all you have to do is check whether perhaps another process should continue (note the very small overhead). To be able to have more than one process running (detach a job), I made a small change to Pexec() so that a new process can be started, but the parent process is not waiting for the child to finish. If a process does a call that may involve some time, like reading a character from the keyboard (Cconin(), Cnecin()), this process only continues its call when there is a character available, so it will not unnecessarily block other processes. Implementing this scheme took only about a rainy afternoon, so you can't say the effort was that great. What I would like to add is a time-slice mechanism for CPU bound processes (no GEMDOS calls for a long time), based for instance on the VBL-interrupt. This is also easy: if the CPU was in user mode when the interrupt occured (no pending GEMDOS/(X)BIOS/GEM calls) and the current process has had its slice, save registers a la GEMDOS and run another process. The blocked reason that is kept with each process will tell the dispatcher how the interrupted process must resume when it is ready to. This program I'll make available through comp.[binaries,sources].atari.st within a reasonable amount of time (still to do some speed improvement, the time-slice handling, make it ROM independent and probably the replacement of C by assembler). Right now it is still wonderfully small, about 2 or 3 K. Leo.
alderaan@tubopal.UUCP (Thomas Cervera) (08/11/89)
In article <1066@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: >In article <471@tw-rnd.SanDiego.NCR.COM> johnl@tw-rnd.SanDiego.NCR.COM (John Lindwall) writes: >[...] In the current situation it is just as well feasible for >instance by an application program to thrash the space of the shell it >was invoked by. So if you insist on security, you should insist on it >right now already. Absolutely correct. But using a multi-tasking system this problem will multiply. >An MMU alone probably won't hack it; you will probably want a 680x0 >(x >= 1) to be able to page in new memory (a 68000 doesn't maintain >enough internal information to be able to restore correctly from a >BUSERR). But isn't there any software solution to that ? (I'm looking on primitive MMU versions on PDPs where the operating system does a part of context- saving work on failed EMT or TRAP recovery). The LSI11 processors are very much like the M68k family. Or is this really impossible on 680x0 ? (Remember, I'm only a dumb physicist :-) ) -- Thomas Cervera | UUCP: alderaan@tubopal.UUCP SysMan RKOpdp (RSTS/E) | ...!unido!tub!opal!alderaan (Europe) D-1000 Berlin 30 | ...!pyramid!tub!opal!alderaan (World) Motzstrasze 14 | BITNET: alderaan%tubopal@DB0TUI11.BITNET (saves $$$)
greg@bilbo (Greg Wageman) (08/12/89)
In article <1067@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: > >The discussion about multitasking triggered my interest, so I decided >to try some things out. It appears that context switching is easy if >you do it at the moment of a GEMDOS call: all registers have been saved >on either the stack or the basepage, so in fact all you have to do is >check whether perhaps another process should continue (note the very >small overhead). To be able to have more than one process running >(detach a job), I made a small change to Pexec() so that a new process >can be started, but the parent process is not waiting for the child to >finish. If a process does a call that may involve some time, like >reading a character from the keyboard (Cconin(), Cnecin()), this >process only continues its call when there is a character available, so >it will not unnecessarily block other processes. Will you be trapping these interrupts so that you can potentially unblock tasks waiting on them? >Implementing this scheme took only about a rainy afternoon, so you >can't say the effort was that great. What I would like to add is a >time-slice mechanism for CPU bound processes (no GEMDOS calls for a >long time), based for instance on the VBL-interrupt. This is also easy: >if the CPU was in user mode when the interrupt occured (no pending >GEMDOS/(X)BIOS/GEM calls) and the current process has had its slice, >save registers a la GEMDOS and run another process. The blocked reason >that is kept with each process will tell the dispatcher how the >interrupted process must resume when it is ready to. I must admit the idea sounds like it has merit. However it's easy to try something like this when blissfully unaware of the pitfalls. The biggest one I see is that GEMDOS itself is not written to be re-entrant. You will have to be careful when you implement time-slicing that you do not suspend a process while it is in the midst of a GEMDOS call. (You can accomplish this by setting a "critical section" flag when the trap into GEMDOS occurs. When the time quantum expires, and the critical section flag is already set, you set still another flag which indicates that the task should block when it exits the critical section. When it exits, you clear the "critical section" flag and the "block on exit" flag, and suspend it). Otherwise, another process making a GEMDOS call which uses the same data locations will trash the results of the other task's partially-completed call. There are probably thousands of such potential problems. I don't even want to think about the potential for trashing the disk due to simultaneous updating... Still, it sounds like fun to play with. Greg Wageman DOMAIN: greg@sj.ate.slb.com Schlumberger Technologies UUCP: ...!uunet!sjsca4!greg 1601 Technology Drive BIX: gwage San Jose, CA 95110-1397 CIS: 74016,352 (408) 437-5198 GEnie: G.WAGEMAN ------------------ Opinions expressed herein are solely the responsibility of the author.
johnl@tw-rnd.SanDiego.NCR.COM (John Lindwall) (08/12/89)
In article <1066@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: >In article <471@tw-rnd.SanDiego.NCR.COM> johnl@tw-rnd.SanDiego.NCR.COM (John Lindwall) writes: >|Amen to that! Amiga owners have suffered with the lack of an MMU. The >|usefulness multitasking is a given, IMO. The security of Amiga's multitasking >|is poor due to the lack of memory protection supplied by an MMU. Those of >|you who agree multitasking is useful, and would like to see it on an Atari: >|Demand it from Atari and demand MMU support as well. > >I think two issues are being confused here, the need for per process >memory protection, and the possible to run processes 'simultaneously'. >Why should memory protection be a hotter item when parallel processes >are involved? Because of the potential for a single user program to cause the termination of all the processes in the system. Consider: You are a user of the Spiffy multi-tasking-but-no- per-process-memory-protection Machine. You fire up a ray-trace. It'll finish in 12 hours so you start up a terminal program and download some cool PD software from a BBS. While thats all going on "in the background", you fire up your compiler and start writing a new program. You run your program and it has pointer error which causes random data to scribbled across memory. The machine crashes --- badly -- all of the processes on the machine terminate and the system reboots. On a machine with memory protection (OK and resource tracking) the MMU will prevent corruption of other processes address space, and the nasty process can be removed from the system cleanly. > In the current situation it is just as well feasible for >instance by an application program to thrash the space of the shell it >was invoked by. So if you insist on security, you should insist on it >right now already. > I'm all for system robustness for ANY system. My point is that when you introduce multitasking, memory protection is more important due to the potential to disrupt other processes. >An MMU alone probably won't hack it; you will probably want a 680x0 >(x >= 1) to be able to page in new memory (a 68000 doesn't maintain >enough internal information to be able to restore correctly from a >BUSERR). > > Leo. Sounds Good! But now you're wandering into the area of virtual memory and that's not what our original discussion was about. Thanks for the reply. ---------------------------------------------------------------------- John Lindwall johnl@tw-rnd.SanDiego.NCR.COM "Above opinions are my own, not my employer's" Health is merely the slowest possible rate at which one can die.
rex@otto.lvsun.com (Rex Jolliff) (08/12/89)
In article <62828@linus.UUCP> rachamp@mbunix (Champeaux) writes: >Now there's a point to debate. Do you really need memory protection on a >single user multi-tasking computer. On a multi-user computer, memory >protection is a necessity, since if one user's program crashes, you don't >want to bring down the 50 other users. On a personal computer, where cost >is an important factor, is it really necessary? (kind of sounds like the >question "Is multi-tasking really necessary?" doesn't it?) >It would, however, be really nice. >Rich Champeaux (rachamp@mbunix.mitre.org) I don't see why it should cost more than about $20 to implement a reasonable memory management scheme on a personal computer like the Atari ST or the Amiga. It would be real nice to have, especially for software developers. This kind of personal computer really doesn't need it though. I seem to crash each computer equally as often when writing code for them. It takes longer to reboot the Amiga though. Another advantage to a reasonably implemented memory protection/management scheme is that the code to relocate executables before they ran could be eliminated. Rex. -- Rex Jolliff (rex@otto.lvsun.com, {convex, texsun, mirror}!otto!rex) The Sun Newspaper - |Disclaimer: The opinions and comments in Nevada's Largest Daily Morning | this article are my own and in no way Newspaper | reflect the opinions of my employers. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
leo@philmds.UUCP (Leo de Wit) (08/12/89)
In article <1989Aug11.175942.6534@sj.ate.slb.com> greg@sj.ate.slb.com (Greg Wageman) writes: |In article <1067@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: [some stuff left out] |> If a process does a call that may involve some time, like |>reading a character from the keyboard (Cconin(), Cnecin()), this |>process only continues its call when there is a character available, so |>it will not unnecessarily block other processes. | |Will you be trapping these interrupts so that you can potentially |unblock tasks waiting on them? Not quite, but to the same effect. What in fact happens, is that before the process enters the real GEMDOS function (the handling of Cconin or whatever) but after its context has been saved on its basepage and stack, the system will look at what process to continue with (of course this could just as well be the same process). Processes that are waiting for some state change like a character from the keyboard becoming available, or the printer being ready to receive further data, are marked that way and will only be selected if the state they're waiting for changes (the test for the changed state is just a simple index comparision in most cases). Calls that can be safely assumed to complete within a reasonable amount of time are not marked waiting (although one could perhaps win something by switching out a process that wants to write to disk when the disk is not yet available). When no waiting processes can be served (no state changes) the other processes are searched for the least served one (processes have a priority and a 'serviced' number). A few problem calls remain: Cconrs(), which reads an entire line from the keyboard. One can at best test for the first character being available, but the user could still take indefinitely to complete his line. Shells that do command line editing, history completion etc. generally won't have a problem, since they typically process their input character by character. A solution would be to rewrite Cconrs() to be re-entrant (no problem since I recently patched Cconrs() to handle a history mechanism, command line editing and file name completion). [] |I must admit the idea sounds like it has merit. However it's easy to |try something like this when blissfully unaware of the pitfalls. The |biggest one I see is that GEMDOS itself is not written to be |re-entrant. Sure, but a) GEMDOS is not being re-entered and b) in a special way, GEMDOS IS re-entrant. After these stunning remarks, I'll have to make myself clear 8-): Consider a series of programs that call each other by a Pexec(), for instance a shell starts make, which starts a compiler, which ... Note that each of them only returns from their Pexec after the Pexec'ed program has finished. That program probably did a lot of GEMDOS calls ---> there you have your re-entrancy (in a special way). The whole trick is that, while one process cannot re-enter GEMDOS (it would at least trash registers left on the basepage for the restore of the previous call), multiple processes can very well all be in a GEMDOS call (they're not yet performing their function, only saved their state). |You will have to be careful when you implement time-slicing that you |do not suspend a process while it is in the midst of a GEMDOS call. [story about semaphores, critical sections left out] But the time-slicing (implemented yesterday evening!) only takes effect when the program was in user mode. This guarantees you're not interrupting any progressing GEMDOS/(X)BIOS/GEM call. Small and beautiful. In fact, my semaphore is the supervisor bit in the program status word! |There are probably thousands of such potential problems. I don't even |want to think about the potential for trashing the disk due to |simultaneous updating... If there is a problem with this scheme, the problem can be reproduced in the current (unmodified) TOS, so it was already there. As for simultaneous updating, each GEMDOS call is completed before the next is done. No trashing. |Still, it sounds like fun to play with. It sure is!! B.T.W. does that sound like an alpha/beta tester :-) ? Cheers, Leo. P.S. The current version screamed for job control, signalling etc. so that's being implemented right now (together with some system calls like signal() and kill()).
leo@philmds.UUCP (Leo de Wit) (08/12/89)
In article <675@opal.tubopal.UUCP> alderaan@tubopal.UUCP (Thomas Cervera) writes: |In article <1066@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: |> In the current situation it is just as well feasible for |>instance by an application program to thrash the space of the shell it |>was invoked by. So if you insist on security, you should insist on it |>right now already. | | Absolutely correct. But using a multi-tasking system this problem will |multiply. A so-called multi-problem system 8-) ? B.T.W. I don't see why. | |>An MMU alone probably won't hack it; you will probably want a 680x0 |>(x >= 1) to be able to page in new memory (a 68000 doesn't maintain |>enough internal information to be able to restore correctly from a |>BUSERR). | | But isn't there any software solution to that ? (I'm looking on primitive |MMU versions on PDPs where the operating system does a part of context- |saving work on failed EMT or TRAP recovery). The LSI11 processors are very |much like the M68k family. Or is this really impossible on 680x0 ? (Remember, |I'm only a dumb physicist :-) ) The problem is that for instance a page fault can emerge whilst in the middle of an instruction. Whereas the 68010, 68020 etc. store much information on the stack at a BUSERR (29 words if I'm correct), the 68000 only stores 7 words, which is not sufficient to resume each type of instruction. For instance: movem.l (a3),a2-a5 Since this instruction modifies the contents of a3, it cannot be resumed when a bus error occurs after a3 has been modified (and the instruction has not yet completed). Leo.
swklassen@dahlia.waterloo.edu (Steven W. Klassen) (08/12/89)
In article <62828@linus.UUCP> rachamp@mbunix (Champeaux) writes: > >Now there's a point to debate. Do you really need memory protection on a >single user multi-tasking computer. On a multi-user computer, memory >protection is a necessity, since if one user's program crashes, you don't >want to bring down the 50 other users. On a personal computer, where cost >is an important factor, is it really necessary? (kind of sounds like the >question "Is multi-tasking really necessary?" doesn't it?) >It would, however, be really nice. Here is a key issue in the multitasking debate: cost vs. performance. While it is true that you are never going to match the performance of a system designed (with hardware) for multitasking only through software, one can come up with some pretty good compromises. Minix is a good example of this, sure its not as secure as Unix but then again, security isn't as much of an issue on a single-user system as it is on a mult-user system. It seems reasonable to sacrifice some security in order to keep cost down and performance up. (Still it would be nice if we had the hardware to make it efficient, but since we don't we must do the best that we can with what we have.) As for the usefulness of multitasking, it extends not just to the end user (running lots of programs), but also to the programmer. Quite often in large applications it is useful to have portions of the system running in the background. Clearly it is more efficient and more secure to have this supported by the OS rather than requiring the program itself to include all the scheduling and security stuff. ie. I would benefit (as a programmer) greatly even if only a limited multitasking were allowed (system calls to provide low priority background processes). Users would benefit from faster running programs since the cpu would not have to be left sitting idle most of the time. Steven W. Klassen Computer Science Major University of Waterloo
leo@philmds.UUCP (Leo de Wit) (08/12/89)
In article <482@tw-rnd.SanDiego.NCR.COM> johnl@tw-rnd.SanDiego.NCR.COM () writes: |In article <1066@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: [] |>I think two issues are being confused here, the need for per process |>memory protection, and the possible to run processes 'simultaneously'. |>Why should memory protection be a hotter item when parallel processes |>are involved? | |Because of the potential for a single user program to cause the termination |of all the processes in the system. This is equally well possible in the current 'one-process-running-at-a-time' scheme. Note that there are already accessory-based editors, batch modem transfer programs, TSR print spoolers for the ST right now. |Consider: You are a user of the Spiffy multi-tasking-but-no- |per-process-memory-protection Machine. You fire up a ray-trace. [etc. good example left out] | |On a machine with memory protection (OK and resource tracking) the MMU will |prevent corruption of other processes address space, and the nasty process can |be removed from the system cleanly. I think you'll need a bit more than just an MMU for a secure system. S'pose your nasty process alters some system vector (applying patch 271 to SAFEDOS). A pity that the last bug was not yet removed... My point is, that a MMU is a probably undispensable ingredient IN AN OTHERWISE EXCELLENT SYSTEM. That safe system (which undoubtedly will have a notion of privileges, users) is what you should start with in the first place. B.T.W. what do you do when a thunderstorm is coming up, but your raytracer has yet to finish its last hour of calculations? Use a TMU :-) ? [] |I'm all for system robustness for ANY system. My point is that when you |introduce multitasking, memory protection is more important due to the |potential to disrupt other processes. I heard this one before and I still won't believe it, unless a proper argument is given. |>[about VM] | |Sounds Good! But now you're wandering into the area of virtual memory and |that's not what our original discussion was about. Thanks for the reply. You bought an MMU but you don't want VM? Gee, that would be the first reason I would buy an MMU for (and not for protection). As long as the filesystems used are single-user, not write protectable, I don't care much for safe core. Leo.
david.megginson@canremote.uucp (DAVID MEGGINSON) (08/12/89)
From what I've heard, Minix is very restrictive with memory. Each program is allowed a maximum of 64k, and there is not VM paging. A cute toy, but useless for anything but learning. --- * Via ProDoor 3.0R
david.megginson@canremote.uucp (DAVID MEGGINSON) (08/13/89)
MX2 already does a fairly good job of simple multi-tasking. What we need to be able to do is multi-task in GEM. Right now, the machine will crash because the GEM code cannot be reentred when it is being used (it uses global rather than local variables). To multi-task with real ST applications, you would have to at least save all of the internal GEM variables with every context switch. --- * Via ProDoor 3.0R
hoang@rex.cs.tulane.edu (Dzung Hoang) (08/13/89)
For those who would like to experience multitasking on the ST, I would recommend looking at minix ST available from Prentice-Hall for $79. It's a "mini-unix" operating system. Subscribe to comp.os.minix for more info. Dzung Hoang -- ----------------------------------------------------------------------------- hoang@comus.cs.tulane.edu hoang@rex.cs.tulane.edu hoang@comus.UUCP hoang@rex.UUCP tulane!comus!hoang tulane!rex!hoang -----------------------------------------------------------------------------
fgbrooks@crash.cts.com (Fred Brooks) (08/13/89)
In article <1069@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: >In article <1989Aug11.175942.6534@sj.ate.slb.com> greg@sj.ate.slb.com (Greg Wageman) writes: >Processes that are >waiting for some state change like a character from the keyboard >becoming available, or the printer being ready to receive further data, >are marked that way and will only be selected if the state they're >waiting for changes (the test for the changed state is just a simple >index comparision in most cases). Calls that can be safely assumed to >complete within a reasonable amount of time are not marked waiting I intercept the BIOS trap vector and add my own routine to do the BConin call. If nothing is waiting in the buffer then I swapout the current process , if a char is is the buffer it is passed on to the calling process and a countdown variable is set to say 100 so that when then next time the buffer is empty it won't swapout until it has checked the buffer a few times. >|I must admit the idea sounds like it has merit. However it's easy to >|try something like this when blissfully unaware of the pitfalls. The >|biggest one I see is that GEMDOS itself is not written to be >|re-entrant. > >Sure, but a) GEMDOS is not being re-entered and b) in a special way, >GEMDOS IS re-entrant. After these stunning remarks, I'll have to make >myself clear 8-): GEMDOS surely can be made re-entrant. Take a quick look at my MX2 source for an example. I admit my method is not perfect but it works 'sometimes'. >Cheers, > Leo. > >P.S. The current version screamed for job control, signalling etc. so >that's being implemented right now (together with some system calls >like signal() and kill()). I would like a copy if you are giving it away with source.
alderaan@tubopal.UUCP (Thomas Cervera) (08/13/89)
In article <1070@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: =In article <675@opal.tubopal.UUCP> alderaan@tubopal.UUCP (Thomas Cervera) writes: =| But isn't there any software solution to that ? (I'm looking on primitive =|MMU versions on PDPs where the operating system does a part of context- =|saving work on failed EMT or TRAP recovery). The LSI11 processors are very =|much like the M68k family. Or is this really impossible on 680x0 ? (Remember, =|I'm only a dumb physicist :-) ) = =The problem is that for instance a page fault can emerge whilst in the =middle of an instruction. Whereas the 68010, 68020 etc. store much =information on the stack at a BUSERR (29 words if I'm correct), the =68000 only stores 7 words, which is not sufficient to resume each type =of instruction. For instance: = = movem.l (a3),a2-a5 = =Since this instruction modifies the contents of a3, it cannot be resumed =when a bus error occurs after a3 has been modified (and the instruction =has not yet completed). I'm not that familiar with the 68000's hardware and pin configuration. But isn't there a pin telling the non-existent MMU 'shut up, I'm working on an instruction right now !' ? Sure, the MMU must be able to hold it's BUSERR signal back until the CPU drops this line and tries to fetch the next instruction. If this is possible, error recovery on BUSERR should not be a problem. -- Thomas Cervera | UUCP: alderaan@tubopal.UUCP SysMan RKOpdp (RSTS/E) | ...!unido!tub!opal!alderaan (Europe) D-1000 Berlin 30 | ...!pyramid!tub!opal!alderaan (World) Motzstrasze 14 | BITNET: alderaan%tubopal@DB0TUI11.BITNET (saves $$$)
hoang@rex.cs.tulane.edu (Dzung Hoang) (08/14/89)
In article <89081310545051@masnet.uucp> david.megginson@canremote.uucp (DAVID MEGGINSON) writes: >From what I've heard, Minix is very restrictive with memory. Each >program is allowed a maximum of 64k, and there is not VM paging. A cute >toy, but useless for anything but learning. >--- > * Via ProDoor 3.0R Minix for the IBM-PC's are restricted to 64K due to the PC's architecture. The 68000 in the ST does not have any such restriction so it can run programs larger than 64K. It is not "useless for anything but learning." Post a message in comp.os.minix and you'll see what I mean. I used to have an ST but now own an AT compatible. I wish I still have the ST (and a big hard drive) to run minix. Dzung Hoang -- ----------------------------------------------------------------------------- hoang@comus.cs.tulane.edu hoang@rex.cs.tulane.edu hoang@comus.UUCP hoang@rex.UUCP tulane!comus!hoang tulane!rex!hoang -----------------------------------------------------------------------------
bammi@dsrgsun.ces.cwru.edu (Jwahar R. Bammi) (08/14/89)
In article <89081310545051@masnet.uucp>, david.megginson@canremote (DAVID MEGGINSON) writes: >From what I've heard, Minix is very restrictive with memory. Each >program is allowed a maximum of 64k, and there is not VM paging. A cute >toy, but useless for anything but learning. >--- The restriction on memory is only on the Ibm-Pc version of minix. In ST-minix there is no such restriction. Its true that there is no virtual memory. IMHO it is a little bit more than a cute toy. -- bang: {any internet host}!dsrgsun.ces.CWRU.edu!bammi jwahar r. bammi domain: bammi@dsrgsun.ces.CWRU.edu GEnie: J.Bammi
leo@philmds.UUCP (Leo de Wit) (08/14/89)
In article <194@crash.cts.com> fgbrooks@.UUCP (Fred Brooks) writes: |In article <1069@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: |>[about avoiding block in read/write on slow devices] | |I intercept the BIOS trap vector and add my own routine to do the BConin |call. If nothing is waiting in the buffer then I swapout the current process |, if a char is is the buffer it is passed on to the calling process and a |countdown variable is set to say 100 so that when then next time the buffer |is empty it won't swapout until it has checked the buffer a few times. You'll have to be careful this BIOS call was not done from GEMDOS, I think. I'm interested to know how you save a process's state. |>P.S. The current version screamed for job control, signalling etc. so |>that's being implemented right now (together with some system calls |>like signal() and kill()). | |I would like a copy if you are giving it away with source. The signalling stuff has been implemented. Now of course add job control, so that a character typed from the keyboard (^Z or is that too overloaded in GEMDOS?) can stop a process. I'll have to add a notion of background/ foreground, so that a background process is stopped when it wants to use the console (read/write) and can be brought into the foreground. You can have a premature copy if you want that (undoubtedly with bugs); before I offer it to the sources/binaries groups I want to test it myself when it is complete (I'm already thinking about pipes / interprocess communication etc., so depending on whether this would come into the first release, it could take a while). Leo.
dbsuther@PacBell.COM (Daniel B. Suthers) (08/14/89)
In article <63138@linus.UUCP> rachamp@mbunix (Champeaux) writes: >From The Amiga ROM Kernel manual: > > Every task has an assigned priority and tasks are scheduled to use the > processor on a priority basis. The highest priority ready task is selected > and receives processing until: > [TEXT DELETED] > Task scheduling is preemptive in nature. The running task may lose the > processor at nearly any moment by being displaced by another more urgent > task. Later, when the preempted task regains the processor, it continues > where it left off. > >When a higher priority task becomes active, the running task is immediately >interrupted. After reading this a question popped into my head. If you are downloading in the back ground (it seems the most popular multi-task task) and running a action game in the foreground, do you set the download process to the highest priority to avoid losing data or do you just put up with longer download times and connect times so your joy-stick will be responsive? While I'm at it... What is a "ray trace" that most amiga users seem to want to generate them, and are willing to wait 2 or 3 days for the output??? The ray traces I've done have always completed over-night, and that's longer than I wish to wait for a pretty drawing. My idea of great uses for multi-tasking agrees with the UNIX system. Utilities such as UUCP, LP and cron are great. I almost never compile in the back-ground as it adds just that much more time before it's finished, and I find myself constantly checking to see if it's finished yet. Dan Suthers, Analyst, Pacific Bell
jerry@polygen.uucp (Jerry Shekhel) (08/14/89)
In article (Dzung Hoang) writes: >In article (DAVID MEGGINSON) writes: >> >>From what I've heard, Minix is very restrictive with memory. Each >>program is allowed a maximum of 64k, and there is not VM paging. A cute >>toy, but useless for anything but learning. >> > Minix for the IBM-PC's are restricted to 64K due to the PC's >architecture. The 68000 in the ST does not have any such restriction so it >can run programs larger than 64K. It is not "useless for anything but >learning." Post a message in comp.os.minix and you'll see what I mean. > > I used to have an ST but now own an AT compatible. I wish I still have >the ST (and a big hard drive) to run minix. > I've also had both the ST and the PC versions of Minix. The PC version's limitation is not 64K. A program may have 64K of code AND 64K of stack/data, for a total program size of 128K. This limitation is used for two reasons: it is reasonable for a teaching OS and most Minix utilities (MOST -- no 16-bit compress!), and it makes forking EXTREMELY fast and simple. Sure, you can run monstrous GNU stuff on ST Minix -- that is its strength -- unlimited program size. But try to run anything that forks a lot, like extracting programs from a shell archive, and you'll see the ST slow down to an unbelievable crawl, while my 8MHz AT zips along on the same job. And worse, try to run a program which forks and does not immediately exec(), and you'll be begging for an MMU! But just like the above poster, I sure wish I had a big hard drive for my ST Minix! --- +--------------------+-----------------------+-------------------------------+ | | Polygen Corporation | UUCP: | | Jerry J. Shekhel | Waltham, MA 02254 | {princeton, mit-eddie, | | | (617) 890-2888 | buita, sunne}!polygen!jerry | +--------------------+-----------------------+-------------------------------+
daveh@cbmvax.UUCP (Dave Haynie) (08/15/89)
in article <29201@pbhya.PacBell.COM>, dbsuther@PacBell.COM (Daniel B. Suthers) says: > After reading this a question popped into my head. If you are downloading in > the back ground (it seems the most popular multi-task task) and running a > action game in the foreground, do you set the download process to the > highest priority to avoid losing data or do you just put up with longer > download times and connect times so your joy-stick will be responsive? Assuming your connection won't time out on you, and all your actual byte grabbing is interrupt or DMA driven (as on the Amiga), it's pretty much a matter of personal choice. Or looking at it another way, at least when talking to a commercial network, you'll pay for a higher game score with longer connect times. It's probably not that simple, though. In many video games, the game itself is taking most of the CPU time, at least on a 68000 processor. So if your video game is at a priority higher than that of your download, you may starve the XMODEM or Kermit protocol program. To be safe, I'd keep the download at the same or greater priority than that of the game. Though on 68020 or 68030 Amigas, you rarely run into that kind of process starvation. > While I'm at it... > What is a "ray trace" that most amiga users seem to want to generate them, and > are willing to wait 2 or 3 days for the output??? The ray traces I've done > have always completed over-night, and that's longer than I wish to wait for > a pretty drawing. Lots of Amiga folks are doing pretty serious ray tracing. Part of the limits of what you're going to be tracing are based on what you have available to enter the image in the first place. Tools on the Amiga like Byte-by-Byte's Sculpt- Animate 4D allow some pretty serious drawings to be entered. It's not only a timing issue, either -- I have two friend heavily into ray tracing. One is currently hitting memory limits on a 17 megabyte system I've set up here at Commodore, the other already has some images that can't be rendered on a 25 megabyte system. These certainly aren't typical users, but even for smaller ray traces, what finishes in 20 minutes on a 68030 system might take 25-100 times longer on a 68000 system. > Dan Suthers, Analyst, Pacific Bell -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Be careful what you wish for -- you just might get it
johnl@tw-rnd.SanDiego.NCR.COM (John Lindwall) (08/15/89)
In article <1071@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: >In article <482@tw-rnd.SanDiego.NCR.COM> johnl@tw-rnd.SanDiego.NCR.COM () writes: >|In article <1066@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: > [] >|>Why should memory protection be a hotter item when parallel processes >|>are involved? >| >|Because of the potential for a single user program to cause the termination >|of all the processes in the system. > >This is equally well possible in the current 'one-process-running-at-a-time' >scheme. Note that there are already accessory-based editors, batch >modem transfer programs, TSR print spoolers for the ST right now. > This point is well taken, but does not negate the point that process protection is desirable (in my mind). >| [My (John Lindwall's) example of a single process crashing the machine] > >I think you'll need a bit more than just an MMU for a secure system. >S'pose your nasty process alters some system vector (applying patch 271 >to SAFEDOS). A pity that the last bug was not yet removed... My point >is, that a MMU is a probably undispensable ingredient IN AN OTHERWISE >EXCELLENT SYSTEM. That safe system (which undoubtedly will have a >notion of privileges, users) is what you should start with in the first >place. > An MMU can protect pages of memory that the system considers special. The system vectors could be marked as un-writable by user level processes. An attempt to modify the protected pages could be trapped and prevented. I agree that the capabilities of an MMU are best utilized when designed into a system as opposed to grafted in as an afterthought. Current users of Commodore's 68020/68030 boards have an MMU in the system which has minimal benefit to the system, because AmigaDOS was not designed to support an MMU. In fact the only use I see for it (in the Amiga at present) is in copying the OS ROM into fast ram for a speed gain. True use of the MMU comes when running an OS designed to use it (like Unix when that becomes available). I am using the Amiga as an example here not because I believe it is the ULTIMATE SYSTEM that Atari should emulate. I feel ST users and developers can benefit from examining the problems and shortcomings that the Amiga is seeing now that MMU's are being phased in as standard equipment. >B.T.W. what do you do when a thunderstorm is coming up, but your >raytracer has yet to finish its last hour of calculations? Use a TMU :-) ? > Well, here in Sunny California (tm) we don't get many of those! :) :) :) >|I'm all for system robustness for ANY system. My point is that when you >|introduce multitasking, memory protection is more important due to the >|potential to disrupt other processes. > >I heard this one before and I still won't believe it, unless a proper >argument is given. > So I assume (if you were using a multi-tasking system) that you would prefer NOT to have process protection? I do not see the logic in this. >|>[about VM] >| >|Sounds Good! But now you're wandering into the area of virtual memory and >|that's not what our original discussion was about. Thanks for the reply. > >You bought an MMU but you don't want VM? Gee, that would be the first >reason I would buy an MMU for (and not for protection). As long as the >filesystems used are single-user, not write protectable, I don't care >much for safe core. > Yes, VM is nice. In my day-to-day Amiga experience I do not run out of memory much. I DO experience agonizing crashes which kill all my processes. From this experience I developed the priority of process protection being more important. If VM were available, I'm sure I would enjoy it and make use of it. Thank you for this enjoyable discussion. I hope it can continue on the amiable and informative level that has been maintained all along. Looking forward to your reply. ---------------------------------------------------------------------- John Lindwall johnl@tw-rnd.SanDiego.NCR.COM "Above opinions are my own, not my employer's" Health is merely the slowest possible rate at which one can die. -- ---------------------------------------------------------------------- John Lindwall johnl@tw-rnd.SanDiego.NCR.COM "Above opinions are my own, not my employer's" Health is merely the slowest possible rate at which one can die.
johnl@tw-rnd.SanDiego.NCR.COM (John Lindwall) (08/15/89)
In article <1035@rex.cs.tulane.edu> hoang@rex.UUCP (Dzung Hoang) writes: > > For those who would like to experience multitasking on the ST, I would >recommend looking at minix ST available from Prentice-Hall for $79. It's a >"mini-unix" operating system. Subscribe to comp.os.minix for more info. > >Dzung Hoang OK thanks for the tip, but what many of us want, IMHO, is to run multiple ST programs simultaneously. Minix gives you a spartan Un*x-like environment, not a wonderful WIMP interface. Please correct me if I'm wrong. ---------------------------------------------------------------------- John Lindwall johnl@tw-rnd.SanDiego.NCR.COM "Above opinions are my own, not my employer's" Health is merely the slowest possible rate at which one can die. -- ---------------------------------------------------------------------- John Lindwall johnl@tw-rnd.SanDiego.NCR.COM "Above opinions are my own, not my employer's" Health is merely the slowest possible rate at which one can die.
johnl@tw-rnd.SanDiego.NCR.COM (John Lindwall) (08/15/89)
In article <968@otto.lvsun.com> rex@otto.lvsun.com (Rex Jolliff) writes: > >I don't see why it should cost more than about $20 to implement a >reasonable memory management scheme on a personal computer like the >Atari ST or the Amiga. I agree. So everyone send me $20 and I'll do it. :) :) :) >It would be real nice to have, especially for >software developers. This kind of personal computer really doesn't >need it though. I seem to crash each computer equally as often when >writing code for them. It takes longer to reboot the Amiga though. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Try using the Amiga warm-bootable ramdisk, or a hard drive :). Do Atari ST's have a bootable ramdisk, or even a ramdisk whose contents survive a warm boot? A friend of mine with an ST would like to know. Thanks! ---------------------------------------------------------------------- John Lindwall johnl@tw-rnd.SanDiego.NCR.COM "Above opinions are my own, not my employer's" Health is merely the slowest possible rate at which one can die. -- ---------------------------------------------------------------------- John Lindwall johnl@tw-rnd.SanDiego.NCR.COM "Above opinions are my own, not my employer's" Health is merely the slowest possible rate at which one can die.
joe@cbmvax.UUCP (Joe O'Hara - QA) (08/15/89)
In article <29201@pbhya.PacBell.COM> dbsuther@PacBell.COM (Daniel B. Suthers) writes: >After reading this a question popped into my head. If you are downloading in >the back ground (it seems the most popular multi-task task) and running a >action game in the foreground, do you set the download process to the >highest priority to avoid losing data or do you just put up with longer >download times and connect times so your joy-stick will be responsive? Believe it or not, the answer is neither. The actual I/O is processed by device drivers, in these examples the serial device and the gameport device. The drivers have higher-than-standard priorities. In the download situation, received characters are stored in a buffer until the application program gains control and "reads" them (burst them into the program). The joy-stick action results in events which are passed to the game program as messages. Consequently, the game program could be given higher priority if you wished without a noticeable degradation of the teleprocessing task. The serial device buffer can range from 512 - 16,000 bytes (user controlled). -- ======================================================================== Joe O'Hara || Comments represent my own opinions, Commodore Electronics Ltd || not my employers. Any similarity to Software QA || to any other opinions, living or dead, || is purely coincidental. ========================================================================
leo@philmds.UUCP (Leo de Wit) (08/15/89)
In article <483@tw-rnd.SanDiego.NCR.COM> johnl@tw-rnd.SanDiego.NCR.COM (John Lindwall) writes: |In article <1071@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: |[] | |This point is well taken, but does not negate the point that process protection |is desirable (in my mind). I would be the last one to deny that; what I meant was that a non-multitasking machine like the ST can benefit from process protection too. |> My point |>is, that a MMU is a probably undispensable ingredient IN AN OTHERWISE |>EXCELLENT SYSTEM. That safe system (which undoubtedly will have a |>notion of privileges, users) is what you should start with in the first |>place. |> | |An MMU can protect pages of memory that the system considers special. The |system vectors could be marked as un-writable by user level processes. An |attempt to modify the protected pages could be trapped and prevented. Any usable system will have to have a way to install (re-install) system vectors, switch to supervisor mode etc. In the current TOS each user program can do that. What I meant was that the system should have a notion of users with special privileges (root) so that one cannot inadvertently switch to kernel mode and do strange things. If you want to do something special, OK become root and then do your stuff (very careful), then go back being a normal user. This should be a hard fact in the system; it could prevent a lot of viruses. |>B.T.W. what do you do when a thunderstorm is coming up, but your |>raytracer has yet to finish its last hour of calculations? Use a TMU :-) ? |> | |Well, here in Sunny California (tm) we don't get many of those! :) :) :) Here in Rainy Holland (B.V.) we usually get them after a few sunny days (I shouldn't complain however - we had the best summer in years). |>|I'm all for system robustness for ANY system. My point is that when you |>|introduce multitasking, memory protection is more important due to the |>|potential to disrupt other processes. |> |>I heard this one before and I still won't believe it, unless a proper |>argument is given. |> | |So I assume (if you were using a multi-tasking system) that you would prefer |NOT to have process protection? I do not see the logic in this. No, what I meant was that I would prefer to have memory protection in both cases. I don't see a reason why it should be more important in the multitasking case. You can have lots of vulnerable processes in the other case as well. |Yes, VM is nice. In my day-to-day Amiga experience I do not run out of memory |much. I DO experience agonizing crashes which kill all my processes. From |this experience I developed the priority of process protection being more |important. If VM were available, I'm sure I would enjoy it and make use of it. From what I hear in this group, a lot of people DO run out of memory - even the ones with > 1 M memory. Accessories, TSR's, RAMdisks, disk caches all grab a (not to be ignored) constant part of your memory. Now try and run something like gcc (a known memory hog). Lots of people expanded their memory already. But IMHO the most important use for VM is not protection, not paging in additional memory when needed, but ... the processes being position- independent! Try to implement the UNIX fork() call, you know what I mean (also relocation becomes unnecessary, but that is a minor issue). | |Thank you for this enjoyable discussion. I hope it can continue on the |amiable and informative level that has been maintained all along. Looking |forward to your reply. Thank you too, me too, me too (in that order). Cheers, Leo. P.S. One noticeable difference between ordinary conversations and Usenet discussions is that the former resembles multitasking, the latter something like coroutines 8-).
fgbrooks@crash.cts.com (Fred Brooks) (08/15/89)
In article <1072@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: >|I intercept the BIOS trap vector and add my own routine to do the BConin >|call. If nothing is waiting in the buffer then I swapout the current process >|, if a char is is the buffer it is passed on to the calling process and a >|countdown variable is set to say 100 so that when then next time the buffer >|is empty it won't swapout until it has checked the buffer a few times. > >You'll have to be careful this BIOS call was not done from GEMDOS, I think. >I'm interested to know how you save a process's state. > I save the GEMDOS/BIOS stack for every process that's stored in the location pointed by the sav-vector in low memory. It's a tricky process and taking a look at my MX2 source will explain it better that I can here. fred
david.megginson@canremote.uucp (DAVID MEGGINSON) (08/16/89)
I did not realise that ST Minix had removed the 64k restriction. How can it handle a program that uses, say, 2 megs of data and 200k of code? I might be interested. Can you use UUCP with it? Does it allow a scheduler in the background? Sorry to put this here, but I have no access to Unix, so I can't get at any Minix groups. --- * Via ProDoor 3.0R
leo@philmds.UUCP (Leo de Wit) (08/16/89)
Sorry to bother who it might not concern, but due to a mailer problem I'll
have to try it this way.
Leo.
From phigate!hp4nl!hp4nl.nluug.nl!cs.utexas.edu!MAILER-DAEMON Wed Aug 16 09:56:41 1989
Received: by dts.philips.nl; Wed, 16 Aug 89 09:56:31 -0200
Received: by philips.nl; Wed, 16 Aug 89 09:31:43 +0200
Received: from [128.83.139.9] by hp4nl.nluug.nl with SMTP
id AA22560 (5.58.1.14/2.14); Wed, 16 Aug 89 08:49:38 MET
Date: Wed, 16 Aug 89 01:49:07 CDT
From: phigate!cs.utexas.edu!MAILER-DAEMON (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Posted-Date: Wed, 16 Aug 89 01:49:07 CDT
Message-Id: <8908160649.AA02583@cs.utexas.edu>
Received: from uunet.UU.NET by cs.utexas.edu (5.59/1.39)
id AA02583; Wed, 16 Aug 89 01:49:07 CDT
To: <@hp4nl.nluug.nl,@phigate:leo@philmds>
Status: R
----- Transcript of session follows -----
Unknown host: meadow
550 <meadow!bill@cs.utexas.edu>... Host unknown
----- Unsent message follows -----
Posted-Date: Wed, 16 Aug 89 07:58:25 -0200
Received-Date: Wed, 16 Aug 89 01:49:07 CDT
Received: from uunet.UU.NET by cs.utexas.edu (5.59/1.39)
id AA02571; Wed, 16 Aug 89 01:49:07 CDT
Received: from hp4nl.nluug.nl by uunet.uu.net (5.61/1.14) with SMTP
id AA05718; Wed, 16 Aug 89 02:48:54 -0400
Received: from phigate by hp4nl.nluug.nl with UUCP via EUnet
id AA22332 (5.58.1.14/2.14); Wed, 16 Aug 89 08:12:38 MET
Received: by philips.nl; Wed, 16 Aug 89 08:02:59 +0200
Received: by dts.philips.nl; Wed, 16 Aug 89 07:58:25 -0200
Date: Wed, 16 Aug 89 07:58:25 -0200
From: leo@dts.philips.nl
Message-Id: <8908160558.AA29843@dts.philips.nl>
To: meadow!bill@cs.utexas.edu
Subject: Re: Notes on multitasking
Hi Bill. In your letter you write:
|I really wish it would rain more in California.
Sometimes, when it's been good wheather for a long period (that is a
rare occasion here in Holland, but this summer was like this) I long
for a few dark and rainy days - ideal for a nice project.
|You know that when you are going to multitask programs with disk usage,
|things such as the DTA address, Fsfirst-Fsnext chains, current drive and
|directory, and probably several other things have to be saved on context
|switch. You may also have a problem with the OS's terminate calls.
Yes, I know (B.T.W. several people told me this; there seems to be both
a fairly large interest in this subject as general knowledge of the
traps and pitfalls). The strong point of my design is that it is
synchronized with GEMDOS calls (and for CPU bound processes there's a
different solution). GEMDOS calls, as you'll probably know, save their
registers on the current process's basepage and stack. As far as DTA
address, current drive / directory is concerned, this is also
information that is kept on the basepage with the process.
Fsfirst-Fsnext chains are kept in your disk transfer buffer (the
information to find the next is found from the first 20 bytes). This
buffer also resides within your process (and DTA, a pointer on the
basepage, points to it).
Terminate calls are no problem at all. Processes that run detached ('in
the background') get a special parent: a basepage in the multitasking
kernel itself which returns control to the dispatcher (that frees the
process slot). Ordinary processes just end the usual way (their process
slot will be taken again by the parent). I even implemented kill() and
signal() calls to be able to stop and restart or kill processes (even
coredump). Also alarm(), sleep(), and pause() have been implemented
(yesterday).
|I tried a number of methods for multitasking including Desk Accessories,
|VBI, and 200 Hz system timer - all before I found out about saving disk
|info. Maybe it would work better with this implemented.
You have to take great care when interrupting GEM, this is not built to
be multitasking. I use VBI for CPU bound processes; after a time slot
has been used up, and if the process is in user mode, it switches to the
dispatcher as through a GEMDOS call (the registers are saved on the
process's basepage and stack), since I know I'm not interrupting GEMDOS
right now.
|
|What we really need is a multi-tasking TOS 2.0 on ROMS (dream on - Atari will
|release it's TOS/Unix machine and then forget about ever multitasking TOS)
Sure, but like TOS 1.4 this can take quite a while; for the GEM part it
would mean a general redesign (the GEMDOS part, in all its simplicity, is
very easy to make multi-tasking; that's just what I did).
|Good luck - it should prove interesting.
It sure is; thanks for your interest & concern.
Cheers,
Leo.rex@otto.lvsun.com (Rex Jolliff) (08/17/89)
In a precious article, I write:
It would be real nice to have, especially for
software developers. This kind of personal computer really doesn't
need it though. I seem to crash each computer equally as often when
writing code for them. It takes longer to reboot the Amiga though.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In reply, johnl@tw-rnd.SanDiego.NCR.COM (John Lindwall) writes:
>Try using the Amiga warm-bootable ramdisk,
I admit this will help alot. Except when the machine crashes so hard
that it won't warmboot off the raddrive.
>or a hard drive :).
I wasn't being fair my Atari has a hard drive, the Amiga does not. But,
when I didn't have a hard drive for the ST, it still beat the amiga on
cold boots.
>Do Atari ST's have a bootable ramdisk, or even a ramdisk whose contents
>survive a warm boot?
Yes. There are at least two or three. I haven't had a need for a ramdisk
for a while now though, so I don't remember the names of any. as for warm
booting the ram drive, I never thought about doing that.
>John Lindwall johnl@tw-rnd.SanDiego.NCR.COM
--
Rex Jolliff (rex@otto.lvsun.com, {convex, texsun, mirror}!otto!rex)
The Sun Newspaper - |Disclaimer: The opinions and comments in
Nevada's Largest Daily Morning | this article are my own and in no way
Newspaper | reflect the opinions of my employers.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -cmcmanis%pepper@Sun.COM (Chuck McManis) (08/17/89)
In article johnl@tw-rnd.SanDiego.NCR.COM () writes: >Consider: You are a user of the Spiffy multi-tasking-but-no- >per-process-memory-protection Machine. You fire up a ray-trace. It'll >finish in 12 hours so you start up a terminal program and download some cool >PD software from a BBS. While thats all going on "in the background", you >fire up your compiler and start writing a new program. You run your program >and it has pointer error which causes random data to scribbled across memory. >The machine crashes --- badly -- all of the processes on the machine terminate >and the system reboots. This is used a lot as an example but it's specious. [Why use a nickel word when a dollar one will do :-)] Here is another perspective that might change how you "view" something like the above situation. Persons who argue "multitasking-but-no-per-process-memory-protection" [MBNPPMP] systems are no more or less useful than a "singletasking-with-Desk Accesories-or-TSR-programs" [SWDAOTP] are pretty much correct, but they might not see that they both have the same limitations. If you're desk accessory goes of into hilbert space you lose the system, if your sidekick TSR writes all over low memory for some reason you go out to lunch too. Note carefully the similarities with this situation to the one that John describes. So given all this massive similarity, one has to wonder "So why do it one way or the other?" The only difference, and it's a big one, is that writing, running, or starting a desk accessory or TSR type program is "different" than writing, running, or starting a regular run of the mill program. A MBNPPMP system has the same model for *all* programs so the distinction between which is the "main" program and which are the "accessory" programs goes away. If you want to use the Amiga as an example, you can think of the workbench screen as a giant desk accessory panel that lets you pick a desk accessory to start up. Yet, because all programs are the same to the system, there isn't any problem with starting up the same desk accessory twice. The benefits that this buy you are two fold. First, you don't have to "install" anything until it's needed. And secondly, because there are no special cases around the types of programs, as an author and as a user, you don't have to "know" what else has happened to the system to be confident of working. And these make the system incredibly flexible. I leave it as an exercise for the reader to define which is "better." :-) --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you. "A most excellent barbarian ... Genghis Kahn!"
leo@philmds.UUCP (Leo de Wit) (08/21/89)
In article <679@opal.tubopal.UUCP> alderaan@tubopal.UUCP (Thomas Cervera) writes: |In article <1070@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: |=[] |= Whereas the 68010, 68020 etc. store much |=information on the stack at a BUSERR (29 words if I'm correct), the |=68000 only stores 7 words, which is not sufficient to resume each type |=of instruction. For instance: |= |= movem.l (a3),a2-a5 |= |=Since this instruction modifies the contents of a3, it cannot be resumed |=when a bus error occurs after a3 has been modified (and the instruction |=has not yet completed). | | I'm not that familiar with the 68000's hardware and pin configuration. |But isn't there a pin telling the non-existent MMU 'shut up, I'm working on |an instruction right now !' ? | Sure, the MMU must be able to hold it's BUSERR signal back until the CPU |drops this line and tries to fetch the next instruction. | If this is possible, error recovery on BUSERR should not be a problem. I think you missed my point. The data pointed to by a3 could lay near a page boundary. For instance a2-a3 can still be fetched, but a4 must be read in from a not (yet) existing address (which causes a BUSERR). a3 has been modified, so you cannot repeat the instruction (you have to know the original contents of a3 to do that). You could hold back the BUSERR signal, but I don't know what good that will do to you. You still have to execute the instruction. Execution of the instruction causes the BUSERR, which kicks the BUSERR exception handler to page in the new memory, after which the instruction can be restarted at the point it was interrupted (reading a value for a4 in the sample case). 68010's and 68020's etc. store enough intermediate data to resume an instruction this way, 68000's do not. The whole point is that the BUSERR exception is just the means to trigger the paging event. Leo.
daveh@cbmvax.UUCP (Dave Haynie) (08/21/89)
in article <679@opal.tubopal.UUCP>, alderaan@tubopal.UUCP (Thomas Cervera) says: > =The problem is that for instance a page fault can emerge whilst in the > =middle of an instruction. > I'm not that familiar with the 68000's hardware and pin configuration. > But isn't there a pin telling the non-existent MMU 'shut up, I'm working on > an instruction right now !' ? Impossible. It's the fact that the 68000's working on that instruction that caused the page fault in the first place. Page faults are caused most often on a VM system when an instruction tries to access a virtual address that isn't currently in physical memory. This always happens in an instruction; where else do you think addresses are generated? The exception takes place, the OS brings up its VM manager which proceeds to fetch the missing page, then either continue the instruction (68010-68030) or retry the instruction (68040). The 68000 doesn't save enough context for either. Though back in the old days, a pair of 68000s could be hooked up to achieve this same end (Apollo is one company that used such a scheme). > Thomas Cervera | UUCP: alderaan@tubopal.UUCP -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy We have no choice. We are, after all, professionals.