goldstein@delni.dec.com.UUCP (02/11/87)
Okay, just how tough a nut to crack is multi-tasking on the ST?
Hackers are hereby solicited. I'm a user, not a developer.
I don't want to learn 68000 machine language in order to figure
out what's going on in the ST. I've heard various rants on the
net about how you can't do decent multi-tasking on a 68k without
a hardware memory manager. Others claim it's possible, if a bit
tricky.
Here's what I've gleaned so far. I hereby solicit mavens to correct
me, add details, etc. The 68000 has numerous addressing modes.
Absolute addressing permits the entire 24-bit address bus to be
used, sans segmentation, but such programs are not relocatable.
(My RT-11 background reminds me of "background" .SAV files.) Other
address modes permit relocatable code, but the PC relative pointers
are only 16 bits wide, so these programs must be segmented a la
80-series programs. Macintosh progams are required to do this,
but ST programs aren't. (Developer's guidelines and all that.)
If this is true, then for multitasking to work, any given program
must be able to go anywhere in memory. This means that either the
program is coded/linked as relocatable (a pain if this means segmenting,
or just a useful guideline if it doesn't mean segmenting), or there
must be something in the O/S (image activator?) that actually mungs
all the absolute addresses in the image to fit the available memory
location. Could that be done reasonably, or would it be too complex?
One proposal (in the discussion of porting MINIX) said that you could
outswap each task (into memory, not physical disk) every time the
context swapped. That sounds a bit slow -- shuffling a good-sized image
into high memory might slow things down quite a bit, though a blitter
might make it reasonable! Plus you'd need enough memory for the
largest image to run in plus for all the images to outswap to.
On the other hand a 1040ST has an awful lot of memory.
I'd be very willing to pay a bit for, say, a cartridge that added
multi-tasking to the ST. If some hacker out there wrote a
p.d. program that added it, with GEM intact (not like MT-C Shell,
which provides its own environment), then he'd be a bit of a hero,
don't you think?
We'll save the discussion about stealing the whole screen, vs. using
a window for a program to run in, for later. (Desk accessories
seem to be the only ones that usually don't grab it all. I suppose
it's the efficiency of bypassing GEM, which doesn't do text too
well.)
fredjafischer@watrose.UUCP (02/13/87)
Regarding the question of multitasking on the ST without going to a whole new operating system, or even a new environment (a la MT-Csh): Has anyone had the opportunity to use DoubleDOS on the PC? It's really not a bad product, especially considering its price. It can be more accurately described as doubletasking, rather than multitasking, and what it essentially does is split the machine up into two PC's, dividing up the system memory between the two. You can fairly easily switch between foreground and background tasks... (BTW - does anyone know if the new (or old) MT-Cshell has the CTRL-Z capability of the BSD Csh? I'm thinking of buying it.) ... and the background task keeps executing (i.e., it's like the Kuma K-Switch, except the background thing keeps going). Anyone care to venture any opinions on how difficult this would be to implement? Why didn't Kuma go the one step further and make the background task a real background task? Is it that difficult? In my naiive viewpoint, it should be as "simple" :~} as knowing all of the GEM AES & VDI (as well as the GEMDOS) global variables, and swapping the values when the task gets blocked. No? Okay, what else is involved? Anyone know what DoubleDOS does? -- - Jonathan Fischer (jafischer@watrose) or: watmath!watrose!jafischer or: jafischer%watrose@waterloo.csnet or: jafischer%watrose@waterloo.csnet@csnet-relay.arpa
collinge@uvicctr.UUCP (02/15/87)
In article <8019@decwrl.DEC.COM> goldstein@delni.dec.com (Fred R. Goldstein dtn226-7388) writes: > > One proposal (in the discussion of porting MINIX) said that you could > outswap each task (into memory, not physical disk) every time the > context swapped. That sounds a bit slow ... No, no, no. You don't have to swap EVERY time you change contexts - only just after you fork and until you do an exec. Nearly always you exec immediately so you do one swap at most. One swap per exec doesn't seem exorbitant to me; in fact, I use a system that does things this way and it is quite successful swapping to disk. A RAM swap would work even better. The only case where you have to swap a lot is where you have both a parent and its child (which doesn't exec) executing at the same time. This basically doesn't happen - only in very rare cases and we can get around those, too, with little trouble. -- Doug Collinge School of Music, University of Victoria, PO Box 1700, Victoria, B.C., Canada, V8W 2Y2 decvax!nrl-css!uvicctr!collinge decvax!uw-beaver!uvicctr!collinge ubc-vision!uvicctr!collinge