libraries and environments
Jonathan S. Shapiro
Thu, 7 May 1998 10:37:22 -0400
I find myself writing a depressing number of library routines that
take the same three or four capability registers as arguments. In
most cases, these registers hold things like the active domain key, a
schedule key, or a space bank key.
The register positions of these keys seem in practice fixed by
convention -- the constructor/factory sets things up a certain way,
and the process tends to leave them alone because it needs them
The dependency on these keys is so pervasive, and the practice of
passing them explicitly is so distracting, that I am considering
introducing the notion of a "library environment" -- a library can
document the set of capabilities that it expects will be sitting in
key registers and where those capabilities live, and is entitled to
assume that the caller will arrange this before invoking the library
For the moment, the capabilities I have in mind to include in the
"library environment" are as follows:
0 zero number key (hardwired)
1 constituents node key
2 domain key to self
3 schedule key
4 space bank key
31 resume key to domain caller
Most libraries will not require the last one, since in most cases they
do not return directly to the caller.
Applications that do not use such libraries need not maintain these
In cases where non-conventional choices of these values might be
desirable, the library interface can define an "extended" version of
the library routine, or the user can cook the environment
appropriately before performing the call to the library.
Does this seem unwise?
Would it be better to place the schedule key in a well-defined
constituent slot, on the theory that it is mostly used during startup
I am tempted NOT to include the space bank key, as the source of space
is something one might want to control carefully.