Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!jarthur!spectre.ccsf.caltech.edu!tybalt.caltech.edu!toddpw
From: toddpw@tybalt.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2
Subject: Re: apple // and multitasking, perfect together! (??????????)
Message-ID: <1990Mar8.012055.3726@spectre.ccsf.caltech.edu>
Date: 8 Mar 90 01:20:55 GMT
References: <14298@phoenix.Princeton.EDU>
Sender: news@spectre.ccsf.caltech.edu
Organization: California Institute of Technology
Lines: 137

tbrakitz@phoenix.Princeton.EDU (Byron Rakitzis) writes:

>I was (am) thinking long and hard about implementing a multitasking
>operating system on the apple //.

I did a lot last year, I came up with some novel ideas, but the homework
cruch has kept me from getting anywhere substantial. My idea was first to get
a load-time self-linking development system going, and then to figure out how
to extend to it do run-time linking, loading, and multitasking.

>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.

Where's your ambition? I want a cheap text editor, term program, and assembler
all available at the same time. I can think of too many uses for just the
editor and term program once protocol transfers or macro-type features are
supported.

On the contrary, I don't think it would be too slow, unless your overhead was
atrocious, and I have faith that that is not a problem. The 6502 machine state
is pretty damn small, but unless you use a 65816/802 then your stack and zero
page management overhead is murder (this can be avoided by setting a large time
slice, but that may produce yucky interactive response). I think that the best
way to accomplish such a system is to find some method of writing low-context
programs that use software conventions to avoid the problem.

>A multitasking operating system implies the existence of a multi-user/
>permission structure in the hardware itself. That is, the processor of

Bull. The hardware system only comes in when you try to implement a real system
for real programs which are not proven. If the software is restricted enough to
allow things like interrupts, context switches, etc., to operate properly and
efficiently, then you don't need a lot of hardware (a timed interrupt is sort
of required, but many common expansion cards can be used to to accemplish this)
to make the system work.

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

That's if the CPU model is the only programming model you have. Code which
is handed all of its pointers, or drivers which must be used to access the
hardware, provide a 'priveliged' mode by the virtue of the fact that they are
the only code which may execute these instructions, since no one else may
count on the hardware addressses, etc., that the drivers contain and isolate.

The entire Mac O/S uses this principle, and compatibility problems on new Macs
are primarily due to violations of it. (The Mac O/S should have made everyone
else run in 68000 user mode from the start, but that's another issue.) 32 bit
clean is a coding standard developed by Apple to avoid these problems.

>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.

You're not giving the 6502 enough credit, either: you can write very good
programs on the 6502 -- IF you exploit its full capabilities, which NO ONE
really does these days. The Atari 2600 game designers often used the X reg
as a data stack pointer into zero page, and since you can perform almost
any zero page operation on zp,X it makes a great place to store counters and
other saved information like pointers which must be preserved across subroutine
(ok, function) calls.

>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

The 6502 already does this if I am not mistaken.

>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.)

Hey, that's how the Sweet-16 interpreter worked... Only it had one set of
16 16-bit registers and they were fixed at zero page 0-$1F.

>The machine will have a 32-bit address space, but
>relative addressing modes will cut down on code size.

Now you've got a (still vaporous) 65832 but with more registers.

>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

I see why it would be slow. Forcing one CPU architecture to emulate another
always seems to do this.

>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:

Well, I'd rather boot up and see something better than 'login', like
a nice banner and some soundsmith music while the O/S loads in seconds from an
EPROM disk.

You've got the right idea, though, but I still think it would be better to
write a good native 6502 compiler (I have low opinions of the currently
available efforts, you see) and to port everything over with that. The drivers
and ML portion of the O/S would of course have to be written in 6502 but how
much of unix is really machine code?

(Personally I'd like to see an O/S that is like unix but more micro oriented,
not in terms of addressing space or number size, but in terms of the needs
it is written to address, like interactive response time, graphics and sound,
simplicity, and above all efficiency so it will fit on the machines we want it
to run on and be reasonably fast. O/S tasks don't have to hog a heck of a lot
of CPU, but improperly written code always will.)

I see the Apple as a simple and efficient machine, and I'd like a real O/S that
sees those as design principles. Unix comes very close but has some compromises
I don't like, the worst of these is how generic it is. I realize that that is
a major strength of unix but I bet we could improve on it by just handling
special cases properly. That doesn't make much sense unless I give an example:
I want to be able to identify the hardware through the O/S so that I can take
direct control without crashing the system, and this means locks and
arbitration so that programs using the hardware directly can avoid trampling
on each other.

How feasible does this sound? I'm convinced it's possible, but haven't had the
time to develop any concrete applications of it :(

Todd Whitesel
toddpw @ tybalt.caltech.edu