These are the axioms and polemics of the system under construction here.
Wider applicability of these axioms is neither claimed or denied.

A computer is a bus.
 This is axiom 1 of Ha3sm. Thankyou Wilfred Bordouin, Rest In Peace. Sun
says "The network is the computer"(TM). They do realtime? I'm going with
Wilfred. There is much clarity obtained from "Who has the bus?" versus
"Who has the CPU?". Even on a PC AT the mere phrase "the CPU" is
hopelessly ambiguous. Time maps very nicely to one main memoryspace. In
other words, SMP is LAAETTR. There's one bus, and Ha3sm will concern
itself with one time axis. That maps well. I'm currently thinking PCI is
not "the bus", it's a burst service and other goodies on the bus, but the
bus is the memory data and address pins.

It's your computer.
 This is axiom 0 of Ha3sm. Somebody has to own a box. They might as well
act like the 0wner.

All programming systems are documentation.
 The only code that isn't documentation is binary machine code, object
code. Machine code is for machines; everything else is for humans. Thus as
of 2002 there is a tremendous opportunity in computing to get rid of
extraneous confusion, various informational middlemen, and achieve more
efficiency simply through better naming. This is why I'm so prone to fits
of neologistic frenzy. Computing is a young craft and the naming stinks.
Corollary to the above,

The simplest improvements are the biggest wins.
 osimplay started out as m4 macros for Gas that were straight 1:1
renamings on Intel x86 mnemonics and register names. That's still the
biggest win in osimplay, and it's huge.

Virtual memory is obsolete, and always was.
 The on-disc kind. I just don't get it, and never did. Prima-facie bad
idea, since magnetic core memory. People that write programs that don't
fit into existing resources need to fix thier code, not the OS.

SMP doesn't scale.
 Betcha those Sun boxen with the gaudy SPEC numbers are really LAN-in-box.
Betcha betcha betcha. And BESIDES, even if they are really just true SMP,
I'm not trying to be Sun.

Caches are for lame software.
 Linked lists don't cache well. The best caching mechanism yet devised is
a stack machine. Put it another way; caches depend on locality of reference.
That seems to me to imply an unsophisticated machine.

Stack machines are better than register machines.
 My stack machines have to run on register machines though. My OS will
port easily to stack machines.

Everything is not a file. 
 A device, maybe. Streams and blocks are fundamentally different. Making
one seem like the other is not the province of a kernel. Not mine anyway.
This is not _because_ Ha3sm will be a micro-kernel; this is _why_ Ha3sm
will be a micro-kernel. What does that say about the file abstraction?
It says it's a tad heavy, i.e. could be better factored.

Splitting files into streams and blocks is analagous to splitting the
return stack into a return stack and a parameter stack, as in Forth.  
It's wierd and inconvenient up front, but a huge simplicity win overall,
and a win that persists. Further splits are probably worthwhile, but in
the case of files et al. I don't see how yet. Signals, packets, dono...

Disc is cheap.
 Once I get rolling, expect some wacky filesystems. There's a lot of fun
to be had here in this era of near-free magnetic store.

An OS is a bus spec,
 then, based on the above. HA3sm then is a bus of some known address
width, "cell", with a data bus width of up to 2048 bits. The bus is
controlled by a synchronizer that provides a H3sm interpreter, and bus
access control features. The synchronizer also has a particular endianism
and complementing method, probably 2's complement, but these are
per-system constants.
