Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!dillon
From: dillon@ucbvax.BERKELEY.EDU (Matt Dillon)
Newsgroups: net.micro.amiga
Subject: Amiga OS
Message-ID: <11581@ucbvax.BERKELEY.EDU>
Date: Tue, 28-Jan-86 14:29:37 EST
Article-I.D.: ucbvax.11581
Posted: Tue Jan 28 14:29:37 1986
Date-Received: Thu, 30-Jan-86 05:23:39 EST
Organization: University of California at Berkeley
Lines: 80
Keywords: OS


	Yes, well, with UNIX, you DO have to re-link the kernal to get new
device driver's.  Why?

	(A) The device driver's are not process
	(B) process or not, it would be rather a mess adding driver's to
	a running system due to the VM, and the fact that it would have
	to be a dynamic allocation.

	However, for a small non-MMU/VM system like the Amiga, device driver's
can be added, deleted, etc....  even if they WERE NOT processes.  I didn't say
that the OS should have been UNIX, just that in my opinion a more UNIX-like OS
would be an improvement over the current OS. 

	Perry S. Kivolowitz is absolutely correct in his assessment of my
concerns.  Although the Amiga's OS may work well for the system's programmers,
writing useful applications are rather difficult.  However, I do see a
partial solution to the problem.  

	Hide the OS.  Hide the OS?  Make yourself a library with such things
as chdir(), directory search routines, generic open/close (even to the
point of adding non-blocking I/O, if possible, and select, if possible)
which handle serial, parallel, disk and screen devices.  You could also
rewrite the C startup and exit routines to open/close/deallocate everything
when you leave.

	But there are problems which cannot be hidden:

	(A) Slow loader... so slow that having lc1 in the ram disk doesn't
	significantly reduce load time.

	(B) Badly put together time-slicing (especially w/ disk seeks)

	(C) SSLOW linker... no random libraries AT ALL

	(D) The Disk device make no attempt to optimize disk write's or read's
	by sorting requests by track.  Neither does it process incomming
	requests properly.  If you executed one program, then executed another 
	while the first was loading, the disk reads a sector from the first,
	seeks to the second, reads a sector, seeks to the first, etc... Thus
	it takes nearly 20 times as long than if you loaded the to programs
	in sequence. THIS IS A MAJOR FAILING!

-------------

	There was a discussion a while back on OS9, where it was boasted
the TEXT portion of an executable (i.e. the code), was sharable when
several of the same program was running.  The only way I can see this
happenning is:
	(A)	An MMU or MAP hardware
	(B)	Some register, say A5, containing the 'base' of static data,
		and all static references made by adding this base to the
		offset and doing an indirection.

	It occur's to me, that (B), the only possible choice for the Amiga,
would slow down static fetches quite a bit.  Currently, all static fetches
are made through the absolute address mode.  It is interesting to note that
static fetches take much longer than stack fetches:

	Absolute Fetch long	:12 clock cycles
	Rel. Stack fetch	:8 clock cycles

	It also occur's to me that method (B) above would be faster than an
absolute (static) fetch for the first 32K.  The disadvantage, of course, is
that beyond 32K you cannot use the d(An) addressing mode, and must 
resort to two instructions, in which case the fetch would take much longer
than 12 cycles. (NOTE: 4 cycles/memory fetch)

	I also noticed that lattice doesn't seem to do simple optimizations
like OR's to memory  (i.e. it moves to d0, then Or's, then moves back).. or
am I wrong?

------------
	oh yah... George Robbins from CBM made a comment that UNIX's require
about 1Meg of memory and at least 20-40 Meg HD's.  I agree (though I
prefer at least 2 Meg and 100Meg HD).  Consider that in a very short time,
say a year or two, 100 Meg HD's and  8 Meg Ram will be available at the same
cost as 20Meg HD + 640K ram is today.

						-Matt