Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sunybcs!boulder!hassell
From: hassell@boulder.Colorado.EDU (Christopher Hassell)
Newsgroups: comp.sys.apple2
Subject: Re: apple // and multitasking, perfect together! (??????????)
Message-ID: <17861@boulder.Colorado.EDU>
Date: 7 Mar 90 05:57:09 GMT
References: <14298@phoenix.Princeton.EDU>
Sender: news@boulder.Colorado.EDU
Reply-To: hassell@boulder.Colorado.EDU (Christopher Hassell)
Organization: (Let's see, I'm positive <clang> .. I've <rustle> got ... )
Lines: 175

<14298@phoenix.Princeton.EDU> tbrakitz@phoenix.Princeton.EDU (Byron Rakitzis) 
....
# I was (am) thinking long and hard about implementing a multitasking
# operating system on the apple //. Let me state right away that I don't
# ever expect to accomplish anything useful with such an operating
# system; it would be way too slow. I just think it would be a neat
# thing to have around.

I think that with a proper amount of planning... any operating system can
actually do some decent work... because it is merely a STRUCTURE for
computation... and not reallllly meant to be the main job of the computer <to 
run stuff WITH operating system support>.

# A multitasking operating system implies the existence of a multi-user/
# permission structure in the hardware itself. That is, the processor of
# a multitasking machine must be able to differentiate between at least
# two modes, one "privileged" and the other "user". I know that the VAX
# has four levels of privilege, while the MIPS (in its RISC-like wisdom)
# has just two. The 6502 obviously has just one "mode"!!!

Again... as someone noted.. AAAALLLL that that reallly does is simply simply
provide the safety-net we talked about: stopping errant code.  If we give up
that... then everything else begins to come into focus .. as being possible.

# I was wondering how much fun it would be to at least get a program
# started on the 6502 which could *emulate* a more serious processor and
# then to build an operating system on top of that. I was not sure what
# to call this processor, and I was not even sure what kind of processor
# architecture I needed, so I ended up calling it "BISC" (Byron's
# Instruction Set Computer) since that is certainly what it is going to
# be.

Ahhhhhh... I dunno.  I don't think that the 6502 is allll that bad...
especially because also one can always benefit from adapting to the actual
machine.  Processor capabilities are never really the problem.... its just the
organization.. the virutal-memory... basically its the support that is the
problem.

My idear follows many things... and they're ALLLL oriented around smarter
compilers <again...something we DON'T have for the apple//>.  

SO... the things the apple DON'T have in hardware :  
	timed interrupts,
	protected modes and system-interrupts for them.
	virtual <and FAST> hardware-paged memory, or relative address-modes

There is actually something to be said for the actual philosophy in the
Apple... "make it all accessible and software will do the rest".

As for actually producing the above effects via the smartest compiler known to
mankind <almost>:

	For timed interrupts:
		<easily replacible and much better if someone HAPPENS to have 
			a clock :->

		One can compile around a break-point-table <literally> which
		gives positions in code where break-instructions can be quickly
		put and where the code can be restored after control has been 
		handed to the kernel. <for re-entry>

		Loops need at least one per iteration if they are long enough
		to be time-consuming.

	For protected modes:
		Check code <heavy compiler duties> for when it dereferences a
		pointer.. or accesses an array-element.  Add in error-checking 
		code specifically for this.  For pointers... it would be best 
		to just do an AND of the top-byte... detecting the page where 
		it points. <this is STILL faster than running pseudocode>

	For virtual-memory-paging:
		Yup... software would have to do... but but but.. again.. if 
		    all callpoints are recorded along with jumps etc.... <no 
		    software-defined jumps should be allowed except to points 
		    which are predefined and accessible> <tough 
		    type-checking!>... one could include little "guards" at 
		    jumps and stuff... (added code) which ask the kernel if 
		    the jumped-to part of the program is loaded in.

		    It would take alot of programmer-smarts to know where to 
		    allow the program to be split up <into pieces which can be 
		    run in memory one at a time... the compiler should then
		    install the protection to allow other pieces to be brought
		    in>.

		FORKING: For the wierd aspects of program-connecting... forks 
		    .... pipes... stuff like that... one should know 
		    BEFOREHAND which programs will be called in.. and load 
		    them in when the program is loaded in.  They would be a 
		    PART of the program-image itself.

		    The problem with forking in MANY ways is simply that it
		    treats entire programming sections as if they were
		    subroutines.  The disk-system is what suffers under this
		    folly ... but who's gonna argue if they can still make it
		    work fast enough. :->

		    If one doesn't know specifically which programs will be
		    called <a shell or something else> then the computer should
		    make reservations specifically to do its work there.

		STACKS: For dealing with program-stacks with many processes... 
		    its a good bet that the puny 256-byte stack won't handle
		    it.  The best way to do things .. then .. is to put
		    pointers on the stack for program-variables <with external
		    stacks for their variables> and let every procedure-call
		    actually put its own pointer on the stack... and take it
		    off when its done.  

			The 256-byte aspect of the stack would be VERY tough 
			to deal with in order to make sure things don't go too 
			far... but maybe it could be copied out when big
			changes occur <system/shell changes over to program>

	Memory-Management: Relocatibility and Code
		
		As everyone can guess... it would be a PAINFUL thing to have
		non-relocatible code.  

		A possible method is to "groom" the code for non-normal
		relocations for everything... by (ugh) MODIFYING it according 
		to another-compiler table of absolutes <maybe storing it in a
		certain form... and changing it to another address only if
		necessary>.  Then programmers would still have the speed of 
		absolute-direct operations.. but they needn't actually ask the 
		system constantly for where its variables go NOW.

		Otherwise..... code should be ALWAYS relocatible.. with
		branches instead of jumps.. and maybe even a standard single 
		"jsr" address with a loaded in branch/jump-tables just for 
		accessing a program's subroutines.  (one could leave the
		procedure-number as a plain byte after the call) <sound memory 
		hungry yet?>

	Otherwise... pointers should determine where everything goes and
	system-allocation could take care of the rest <programs would have to
	ask for their own EXPECTED allocation... in order to do any work>

OKAY OKAY... I know... a totally and utterly disGUSTING mess of self-modifying
code... 8-year compilation times and LOTS of time/memory simply for loading it 
in in the first place! <a hacker's dream>

But it could work (tm)......... :-> :-> :->.

# What does anyone think? Is this project stupid, or is it way cool? A
# CS friend of mine told me that my crowning achievement would be to
# boot up the apple // and then see the word

# login:

# on the screen :-). 

Sigh... There is alot to be said for your idea... esPECIALLY if it can encode
instructions better <in higher-level> so as to make programs themselves
smaller.  Maybe it could be the basis for MOST programs.. with only a few
allowed to actually be in assembly.

Why do I ALMOST sound like I'm serious.... maybe because I am??? <scary scary!>

# -- 
# Just try taking your VAX down to Jiffy-Lube these days!
# 			
# Byron "Bo knows parallel computational geometry" Rakitzis. 
# 				(tbrakitz@phoenix.Princeton.EDU)

Yo Kno BO Kno
Self-Modifying-Compiler-Intensive-Incredibly-Small-and-Inefficient-O/Ss.

All we need to do now is make device drivers!!!!!  <okay okay... keep them in
memory only because they're mostly ROMS!>

Beware... someday in your future may be:
	Apple //e UNIX v2.3  (around 1995)
### C>H> ### { uunet!rutgers!sunybcs , ncar , nbires } !boulder!tramp!hassell