mboen@nixpbe.UUCP (Martin Boening) (08/07/89)
What's all this about NEEDING memory segmentation for Multitasking. You can
have Multitasking without memory segmentation. (Of course memory segmentation
helps a lot). Just look at several multitasking OSs for the ST, all running
without a REAL MMU: OS-9/68000, IDRIS, RTOS-UH/Pearl, MINIX-ST, Xinu,
(what else ?).
Of course, forking processes becomes slow, but not impossible (see MINIX-ST).
Also, one of your tasks may clobber another any time by writing into it's
memory (but that's more a problem of coding).
Multitasking essentially is the sharing of one major resource in a computer,
namely the CPU, among several processes by switching the process currently
running rapidly between several processes ready to run at the given moment,
thus making it appear as if each of these processes were being executed
concurrently. If you have the so-called round robin scheduling mechanism,
each ready process gets a time slice, and the more processes there are ready
to run, the fewer time slices each of them gets, so they apparently execute
slower and slower, the higher the load climbs.
Multitasking as such has nothing to do with memory protection (which is why
Xinu can be made to run on an LSI/11 [see D. Comer: Operating system design,
the XINU approach]).
I hope this convinces everybody that multitasking is possible (even if not
feasible due to lack of speed) on the ST.
Martin
PS: Everything I said above really only (barely) scratches the surface of
the matter.
Disclaimer: All of the above is my on opinion and does not express opinions
or company policy of my employer.
--
Email: in the USA -> ...!uunet!philabs!linus!nixbur!mboening.pad
outside USA -> {...!mcvax}!unido!nixpbe!mboening.pad
Paper Mail: Martin Boening, Nixdorf Computer AG, DS-CC22,
Pontanusstr. 55, 4790 Paderborn, W.-Germanyalderaan@tubopal.UUCP (Thomas Cervera) (08/13/89)
In article <415@nixpbe.UUCP> mboen@nixpbe.UUCP (Martin Boening) writes: >What's all this about NEEDING memory segmentation for Multitasking. You can >have Multitasking without memory segmentation. (Of course memory segmentation >helps a lot). Just look at several multitasking OSs for the ST, all running >without a REAL MMU: OS-9/68000, IDRIS, RTOS-UH/Pearl, MINIX-ST, Xinu, >(what else ?). > [...] >I hope this convinces everybody that multitasking is possible (even if not >feasible due to lack of speed) on the ST. {:-( Encore une fois: Multi tasking is possible but USELESS for every-day operation on a machine where every little bullsh*t program can trash important memory. You definetely CANNOT shrink a system's kernel PLUS working variables completely into 2048 bytes. BUT THAT'S ALL PROTECTED MEMORY YOU HAVE ON AN ST. Oh, sure, you could execute what's in the hardware registers. I don't want to think about wasted time during software debugging on a machine where ANY program can produce unpredictable and perhaps unreproductable reactions of ANY program running on it (INCLUDING THE OPERATING SYSTEM ITSELF) if it's not coded correctly. (Maybe your printer daemon crashes the system every time you print more than 42 asterisks). It is not neccessary at all that YOU are the source of this behaviour, some- one else who has written a program currently running in your system's background could be the cause ! Perhaps YOU WILL NEVER KNOW ! If you have an MMU and if your 'crash exception handler' is working correctly, only the nasty program will die WITHOUT affecting others. Because of that you can exactly determine what's going wrong there. Of course, this is not only relevant for multi tasking systems on the ST but for all multi-program environments on this machine (including TOS). BUT it's a matter of fact, that multi tasking means multiplying the probabilty of crazy system behaviour ! -- 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 $$$)
mboen@nixpbe.UUCP (Martin Boening) (08/15/89)
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 Wrong! The 64K limit applies to MINIX-PC only, on MINIX-ST you don't have that limit. I use mined with 300KB stack+malloc area, which is clearly more than 64K. I also use compress with 450KB stack+malloc area to get 16-Bit compression capability. And I use Gnu CC, which laughs in your face when you try to restrict it to 64K. Of coures the concept of VM in MINIX is rather underdeveloped. And of course there's no paging (I don't know if you could implement paging as a pure software solution). Naturally MINIX is intended MOSTLY for learning, BUT I wouldn't call it a toy. There are lot's of developments to improve it's performance. Martin PS: Maybe IDRIS will be shown at the Duesseldorf Atari Fair. Then I'll get a chance to look at it. I think it's a UNIX clone that actually is supposed to be used as a working OS. Then again, maybe I'll rather go for the Atari TT and UNIX[TM] (if it's there) -- Email: in the USA -> ...!uunet!philabs!linus!nixbur!mboening.pad outside USA -> {...!mcvax}!unido!nixpbe!mboening.pad Paper Mail: Martin Boening, Nixdorf Computer AG, DS-CC22, Pontanusstr. 55, 4790 Paderborn, W.-Germany
tainter@cbnewsd.ATT.COM (johnathan.tainter) (08/31/89)
In article <441@nixpbe.UUCP> mboen@nixpbe.UUCP (Martin Boening) writes: >And I use Gnu CC, which laughs in your face >when you try to restrict it to 64K. Gnu CC laughs in your face if you do anything of size on a machine less than 2MEG. :-( >And of course >there's no paging (I don't know if you could implement paging as a pure >software solution). Sure you can. You just have to implement an interpreter for the processor so you can predict which instructions will fault when you run them. The MC68000 can't handle page faults (no instruction restart or instruction continuation). Of course, this will slow it down a bit. Now if had a MC68010 then we would have a possibility, but that would have cost Atari another buck or two per unit and would have taken some rewriting of the code which they weren't competent to do at the time, nor did they have enough time to rewrite and get it out before the Amiga which Tramiel had just failed to snarf. Look at the system they did issue (shudder), which got two years of "not invented here" responses before they admitted they were going to fix some of the serious fatal bugs. >Naturally MINIX is intended MOSTLY for learning, BUT I wouldn't call it a >toy. There are lot's of developments to improve it's performance. Don't fork and do significant volume of work without doing an exec though. That will cost you big time. >Martin >PS: Maybe IDRIS will be shown at the Duesseldorf Atari Fair. Then I'll get >a chance to look at it. I think it's a UNIX clone that actually is supposed >to be used as a working OS. From my experience with Idris on another machine I say this: If given the choice of working on Idris or having your throat slit and salt rubbed in wound, take the latter! --johnathan.a.tainter-- att!ihlpb!tainter