OSes are frequently thought about and built in layers and/or rings. Ha3sm starts with a bus, which I sometimes represent in diagrams as a bisected circle in the center of a CPU diagram or similar. That's the conceptual nucleus of a Von Neumann Machine, and also of Ha3sm.
The 386 has two basic modes in this context, supervisor and application. This is quite a common distinction on commodity desktop CPUs, as it supports multi-user ala UNIX(TM), i.e. with users protected from each other. The 386 further supports 3 permission rings for intra-process layers, but this is less clearly settled upon in computing. Eschewing more than 2 rings is one of the main reasons UNIX was much more implementable than Multics, which lesson I will heed, at least initially with Ha3sm. Intra-process permissions look pretty silly to a Forth guy at first glance, but may well come in handy for such things as file servers not in the kernel, and for affording guest processes privacy from each other in the same basic ring.
The (I hope) obvious term then for the system components that enforce permissions is supervisor. Hardware alerts to permissions issues are the class of exception or surprise called offenses, and the reflex to an offense will probably always include a forced logout or disembark of the offending party, which discontinues the process. (disembark, you're off the bus.)
Ha3sm will be a cross between unix and AmigaDos in that interactive processes may exist in the kernel, allowing a user at the local machine console to operate interactively in 0wnerland, ring 0. Every 0wner process can see all memory. This makes interaction between 0wner processes seamless, implicit, and yes, crash-prone versus unix or similar. Much more fun, too.
Ha3sm and H3sm define abstraction layers. H3sm assumes a host. System stuff goes in the difference between H3sm and Ha3sm, the "a" for autonomous. Below H3sm will be Ha3sm. It would be nice if it was possible to write any runtime system feature in Ha3sm without resorting to an assembler. This means Ha3sm needs words for the base functionality of an entire OS, including the supervisory features and so on. The things that may be impossible as Ha3sm are boot-time things, at which time Ha3sm doesn't actually yet usefully exist. It will remain desireable to have certain features in pure assembly when running on non-Ha3sm hardware, i.e. existing CPUs.
Device drivers in Ha3sm have a handler part and a service part. The service is the part that requests a use of the device, and the handler is the software action for the device itself in response to an action of the hardware. I believe the handler is similar to a bottom-half of an interrupt handler in e.g. Linux. It should be possible to write and install such things interactively in Ha3sm. It should NOT be possible in H3sm. H3sm should use such things transparently, or not be informed of thier existance.
Ring 0 has 2 parts then? There's the Ha3sm stuff, and the sub-Ha3sm stuff. boot code may be sub-Ha3sm, perhaps certain crucial code like the default pulse, but then most things should percolate right up into Ha3sm. The point of this is that on all-Ha3sm hardware there would be no sub-Ha3sm at all. Can this be done without exposing the higher layers to the distinction between a processor and a process?
Ha3sm also strives for CPU-heterogeneity on one bus. This would seem to directly conflict with the preceeding paragraph. In existing designs it does, but some design decisions can resolve these two goals. H3sm can be available as an interpreter in ring 0, via the please class of submit event. In typical jargon, there's an in-kernel interpreter on a syscall, and that's where the portability layer is, and the interpreter is a H3sm. Processes can thereby use the system while running as whatever type of machine code is used by the active processor. Parameters to be passed from a guest process to ring 0 can be passed without any agreement between the rings on CPU architechture by passing said arguments in the already-established common knowledge of a process and the kernel, the processes guestroom addresses. A submit that sends numbers to the kernel with a submission can do so at process address 0.
Invoking an interpreter in the kernel for all submissions would be ridiculous. Thus a process may establish channels to other entities such as storage device drivers or services that will be expected to be used repetitively. This is analagous to file descriptors in unix, but the entities descripted will be somewhat different.
STILL AMBUGUOUS kernel ring supervisor guest party sublet echelon-processing