events and responses

stuff with timing/bus access/synchronizer/system-wide implications

i.e. a synopsis of kernel words and routines. Not all events are code, but most responses are. "quoted" words are probably not code, but are useful terms. We descend in roughly highest-priority-topmost order. Probable code words are emphasized.

A computer is a bus. Ha3sm is in a sense a bus spec. It is multi-master, but 0wner-guest, not totally equal masterhood. 0wner is first responder to events. Ha3sm is CPU-heterogenous. System data and address bus widths, complementing style and endianism are per-system constants, and processes or coprocessors may have process-local "cell" sizes etc. A Ha3sm should be able to compile and run H3sm source for any present CPU, and a binary executable for any present CPU if said binary uses Ha3sm services in the appropriate format. I believe the SysV UNIX ELF loader header format is sufficient to handle the arbitration of this. A process "cell" larger than the system cell implies memory virtualized on mass store. The core of Ha3sm won't do that, but will provide all guest processes with a local secured 0-based address-space, a "guestroom". All 0wner processes see all system resources. I don't yet see how guest processes will need any direct access to IO devices.

tick -------> pulse

tick

A "tick" is a non-maskable interrupt. It is the only "event" that can be hard realtime. It is the only "event" that can be guaranteed a minimum "response" latency or periodicity. A "tick" isn't code, but the ticker controls are. The ticker is probably a clock. "ticker" controls can change the period. A one-time period modification is a "syncopation".

pulse

The pulse is the "tick" "response". pulse is the word that does the same thing for a "tick" that install does for other "event"s. Some default will have been initialized, making the OS a hard realtime OS. There's only one pulse routine in effect at a time. pulse code might well be callee-saves, and register-constrained.

surprise -------> reflex

surprise

A "surprise" is an asynchronous interrupt, i.e. an x86 IRQ or CPU error. It is external to the state of the CPU, or at least semantically so in the case of CPU errors like divide-by-0, and "surprise"s can build up if not handled, i.e. if reflexes must be queued. Should or could any reflexes ever be dropped? Should reflexes disallow reflexes?

reflex

"reflex"es may be callee-saves. They are the low level of device drivers. They may be installed. There will be names for particular reflexes mapped to particular interrupt vectors on x86.

submit -------> service

submit

A submit is a synchronous trap to the OS, i.e. a request for action to a higher priviledge level. A syscall, in other words.

service

There are two basic types of service...
please
is a process word that submits an ASCII string of Ha3sm text to the "synchronizer" and/or "supervisor" for permissions checking and possible serviceing. Two words that will definitely involve check are establish (a channel , see the following) and login a "process". A perms shortage in a please is not an offense. Checking perms on every Ha3sm word would be untenable. Hopefully there can be a small number of data structures holding permissions data. These will go on a device not accessible to guests, such as a floppy. Read-only perhaps.
channel
A channel is a "service" with some preestablished state shared between the "synchronizer" and/or "supervisor" and a "process", like a file descriptor, but factored into "streams" and "blocks". "Process" words arising directly from this categorization are read, write, send and recieve. preestablished stuff is stuff that will be repetitive and performance oriented. There may be other channels for signals, packets, etc. Dono yet.

sleep/preempt -------> switch

Two events causing the same response.
sleep
How a process pro-actively and synchronously relinquishes the bus for the rest of it's current time allotment.
preempt
A crucial duty of the synchronizer; cause switch at some interval so that no process monopolizes the system. Probably clocked. The clocking may want to account for the actual runtime the process has had, which will differ from real time intervals due to various events. This may be an option that might not be an option on the PC, since that is fighting the PC's utter lack of rythm kinda hard.

switch

Cause the current process to relinquish the bus and activate (awaken) the next process in the process ring.

offense ------> logout

offense
This is a class of CPU-generated semantically asynchronous interrupt. A permissions violation event in the course of process activity distinct from a denial of a please, such as a segfault. Process gets logouted. Get offensive and you're off the bus.
logout
Analagous to exit AND logout in unix, or unix kill in response to an offense.
instigators
Things that cause events have to be set up. Clocks need to be started, peripherals need commands, and so on. In other words, the reflex aspects of "device drivers" are the lower half, the defense, so to speak. In a full-blown Ha3sm the instigation will be via please initially, and then possibly due to a channel. Channels should be threads?
listeners
Ring-buffered input devices can multiplex. This means several processes can act upon thier output. Thus we can have a listen please request for an input stream device. The defense for the device, the handler, can then dispatch threads in several different processes if advantageous. This was well implemented in Amigados, but as threads only.