Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!haven!udel!princeton!phoenix!tbrakitz
From: tbrakitz@phoenix.Princeton.EDU (Byron Rakitzis)
Newsgroups: comp.sys.apple2
Subject: apple // and multitasking, perfect together! (??????????)
Message-ID: <14298@phoenix.Princeton.EDU>
Date: 6 Mar 90 19:40:57 GMT
Organization: Princeton University, NJ
Lines: 65

Intro: "NJ and you, perfect together" is some random slogan that Gov. Kean
and NJ advertisements use all the time. 

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.

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"!!!

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.

So far, I've decided on a few implementation details: following the
lead of the MIPS, all memory accessing instructions will be of the
load/store variety only (that is, all arithmetic, etc. instructions
must take registers or immediate arguments as their operands). There
will be 32 16-bit registers at the disposal of the kernel, and another
32 registers available for any particular process. (The registers will
actually be addresses in zero page---it turns out it's better to "hard
wire" some register-register instructions to operate on zero-page
addresses with X offset and to swap the registers in and out on
context switches than to operate on each process's registers directly
in high memory.) The machine will have a 32-bit address space, but
relative addressing modes will cut down on code size.

I know this sounds really freakish, but eventually it might be nice to
port gcc (so that it cross compiles) from VAX-->BISC (or any suitable
host where gcc already exists and runs). This is not as unreasonable
as it sounds, since the BISC architecture would not diverge far from
the standard (powerful) processors which we have at our disposal
today. It should not be too hard to tailor gcc, in other words. Of
course, BISC would run as slow as molasses on a cold Alaskan winter
morning, but that's another story. After gcc exists, then one can
easily write code for BISC and download it down and run it. The I/O
routines would be performed in native 6502, of course, but the
routines themselves would be blind to BISC programs; they would simply
execute an appropriate "call kernel" instruction. BOS (you guessed it,
"Byron's Operating System") will be written in GNU C, for the most
part, with the exception of the really critical parts, which could be
written in straight BISC.

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 :-). 
-- 
Just try taking your VAX down to Jiffy-Lube these days!
			
Byron "Bo knows parallel computational geometry" Rakitzis. 
				(tbrakitz@phoenix.Princeton.EDU)