Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!amdcad!lll-crg!caip!daemon
From: DEC.BANKS@MARLBORO.DEC.COM@caip.RUTGERS.EDU
Newsgroups: net.micro.amiga
Subject: Re: AmigaDOS
Message-ID: <1149@caip.RUTGERS.EDU>
Date: Sat, 1-Feb-86 12:30:30 EST
Article-I.D.: caip.1149
Posted: Sat Feb  1 12:30:30 1986
Date-Received: Sun, 2-Feb-86 05:49:00 EST
Sender: daemon@caip.RUTGERS.EDU
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 48

From: Dawn Banks <DEC.BANKS@MARLBORO.DEC.COM>

   Perhaps some of my comments on AmigaDOS have been slightly misconstrued.
When I compare AmigaDOS to OS-9, it's as constructive criticism, and not an
announcement that AmigaDOS is no good because "it isn't OS-9".  In any case,
while I think that the Amiga software is pretty worth while, I also think
that some properly placed constructive criticism may help make the product
better in the future.  Certainly, you could probably find as many misfeatures
of OS-9 as exist in AmigaDOS, but overall, I think the Amiga could learn a
few things about multitasking from OS-9.

   To reiterate my favorite feature of OS-9's multitasking:  I think the way
OS-9 handles multiple invokations of a task to cause much less overhead.  On
the 6809 version of OS-9 that I've used, all tasks are compiled as position
independent code (an exceedingly easy thing to do on a 6809), with all "own"
storage pointed to by the "U" register.  Thus, when a program is loaded into
memory, no relocation need be performed, and when the task is started, all
that needs to be done is allocate the storage (which includes the stack), and
point U and S at it (and the direct page register), fixup the internal OS-9
data structures, and start the task.  Another invokation would simply 
allocate another storage area, and use the same code segment.  All of this
happens implicitly, without the programmer needing to make any special 
allowances.  This provides the following features:

* Running multiple copies of something doesn't cost you twice for the code
  segment.

* locking a code segment into memory (by incrementing the use count) achieves 
  precisely the same effect as putting it into RAM: on the Amiga, with the
  exception that when you run it, you aren't carrying around two copies of
  the program in ram, as you would be on the Amiga

* Even if the segment isn't locked, running a second invokation happens a lot
  faster, because nothing needs to be read from disk.  This happens more often
  than you might think, most notably with the OS-9 shell.

* library segments can be shared (as with the Amiga), but nothing special needs
  to be done to declare them as libraries, which can save the programmer some
  time.

What all of this boils down to is that (what I think is) the major failing of
the Amiga is its resource utilization.  Sure a 40 meg hard disk and 8M of
RAM would certainly mask the problem, however, I'm still not sure why I should
be finding myself running out of resources so often on a machine with 512K of
ram and two 880K byte floppies.

But, I still like the Amiga and its operating system A LOT.
   --------