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.