[comp.sys.atari.st] Multitasking??

TCORAM@UDCVAX.BITNET (maroC ddoT) (12/22/87)

After reading all the stuff posted about multitasking, I feel like throwing
in my 2 cents.

How many people really (I mean REALLY) use true multitasking?
Some things that would benefit:  Downloading
                                 Compiling
                                 Ray Tracing....
All the above things would make life easier if run as a task (while you
can happily go and continue work elsewhere on the computer).

But.... Downloading can be effectively coded as a background task on
machines like the ST without need for true multitasking.  The same is not
true for compiling and number crunching. *sigh*

Well, let's consider context switching (like SWITCHER on the Mac):
        I am in a word processor (or editor-- where most programmers spend
        90% of their time). I want to compile my program, so I freeze the
        editor and 'switch' to the compiler (or shell that loads compiler)
        and compile the program, looking for errors.  I switch to a CLI
        to look for the files created by the compiler.  I switch back to
        the editor. (repeat 40 times or so).

How would true multitasking help?  I really don't want to go back to editing
while the program compiles. I have not even corrected the possible errors
the compiler has barfed on!  In the above situation, true multitasking really
doesn't make much a difference.

For Applications:
                Does my Spreadsheet really have to continue running along
                with my Wordprocessor? Do spreadsheet calculations take so
                long that I waste valuable time (time I could spend editing?).
                Would context switching do? Probally.

YES! There is a need for multitasking. But there are limitations on such a
small machine. The more you task, the slower each application runs...

On our VAX/VMS system, I do a lot of SPAWN/NOWAIT and batch jobs to do things
such as directory cleanups and SPSSX statistical calculations. I would die
of boredom if those things weren't done via tasking.

Give me a 4meg ST with a 68020, real memory management, VIRTUAL memory and
40meg mass storage and I can show you what real mutlitasking can do...

         _____________________________________________________________
        |                   maroC ddoT | Todd Coram                   |
        |         tcoram@udcvax.bitnet | tentib.xavcdu@maroct         |
        |                   remmargorP | Programmer                   |
        | retneC retupmoC cimedacA CDU | UDC Academic Computer Center |
        |_____________________________________________________________|

"Trust me, I know what I'm doing..."

bds@lzaz.ATT.COM (BRUCE SZABLAK) (12/23/87)

Frankly, if the BIOS was written re-enterantly, there would be
little difficulty in adding multitasking. It could be done for
those who use it, and those who didn't could ignore it.

So is it worth the effort making the BIOS re-entrant? Well, I know
that there has been some discussion in this group about the various
problems encountered in handling interrupts that would not have
been encountered in a re-entrant BIOS.

Consequently, a multitasking system is the logical outgrowth of a
good design.

koreth@ssyx.ucsc.edu (Steven Grimm) (12/24/87)

In article <39@lzaz.ATT.COM> bds@lzaz.ATT.COM (BRUCE SZABLAK) writes:
>Frankly, if the BIOS was written re-enterantly, there would be
>little difficulty in adding multitasking. It could be done for
>those who use it, and those who didn't could ignore it.

The ST's BIOS is re-entrant.  GEMDOS is not.  (I have a multiuser BBS
system to prove it...)  You just have to make sure that each task has
its own BIOS register save area.  That took me a while to figure out --
basically you switch the BIOS stack pointer in your task-switching
routine, as well as the user stack pointer and all the registers.
Multitasking on the ST is actually fairly trivial, as long as you don't
try to use Pexec() or Pterm().  I'm working on rewriting both of those
right now for the background Xmodem accessory in ST-Talk Professional.

+New! Improved! Now 100% Artificial-+-+-----------------------------------+
|#   #  @@@  ****  &&&&& $$$$$ %   %| |Steven Grimm                       |
|#  #  @   @ *   * &       $   %   %+-+ ARPA: koreth@ucscb.ucsc.edu       |
|###   @   @ ****  &&&&    $   %%%%%| | UUCP: ...!ucbvax!ucscc!ssyx!koreth|
|#  #  @   @ * *   &       $   %   %+-+     ______________________________|
|#   #  @@@  *  ** &&&&&   $   %   %| |     |"Let's see what's out there."|
+-----with NutraSour(TM)!  No natural colors or preservatives!------------+