The reference to (p3,sdc) should lead here and this note on data mufflers is a recent note on the same subject of allowing but limiting data flow from a ‘confined’ world.
The section Composition of Factory is an example of a style of Keykos specification. The idea is to give names to all of the parts of some sort of object (factory here) wherein that object may differ from other objects of the same sort, or may differ from time-to-time in the same object. The only parts named here are those whose state is pertinent to understanding the relevant state of the object. It provides a principled way to speak of the logical state of an object. Often the abstract parts so named correspond to actual implementation details, but not always.
The spec refers to a “complete factory” where some later writing refers to “sealed factory”. Same thing; Sorry. A complete or sealed factory never gains holes.
Three of the factory components involve special purpose factory logic. Their purpose emerges in details of factory orders. The broken reference to “getseg” described a feature of the binder which would include instructions in its sensory yield. The newly created domain would obey these instructions to create the complex memory trees that the binder could describe. These instructions were in a special language and were interpreted by factory code which the newly created domain would obey. This meant that neither the interpreter nor the interpreted code needed to be trusted for confinement, as it ran already confined.
Keys to Factories
One might think from this description of four kinds of factory keys that all four were created at some point for each factory. Our style of speaking, however, is like the following: “There is an IEEE floating point number that represents 13275849388.” We can safely say this even though it is possible that no one has ever computed this number. A floating point number is the state of a floating point register at a point in time. A key is the state of a slot at a point in time. Saying where such keys come from is a mere convenience. I have a hard time finding out where various Java objects arise from the documentation.
A fetcher key to a factory is a small hack to overcome the limitation of 16 general purpose factory components. It was almost never needed.
A statement such as “Some factory creator keys convey rights to recall builder’s keys.” says that there are two sorts of factory creator keys. {Notes in curly brackets are conveniently repeated information that can be deduced more accurately from other information. I.e. this is not the definitive source. This is a convention from the Algol 68 manual.}
In “FC(i+j,((4,hcl));PSB,FDC,SB ==> c;BK)” the text between “FC(” and “==>” represents the message sent to FC. The text between “==>” and “)” represents the response message from FC. The text before the semicolon represents the data and the text after represents the keys within those messages.
The “i+j” is always between 0 and 3 inclusive. This follows from the following statements that i is either 0 or 2 and j is either 0 or 1. Nascent factories have a limit on the number of holes. I do not now understand the significance of i; the text seems garbled. Factories use a KID for holes when they are required to hold more than 16 holes. Otherwise they merely use a node. Few factories needed the KID. The notation “((4,hcl))” denotes a 4 byte string comprising a 32 bit integer whose value is hcl.
FCC - A Factory Creator Creator
The purpose of the dual rank creator plan is so that some factories can share a brander and so yields of different factories with the same domain creator can access each other’s parts. The obvious alternative to this design is for one factory to yield domains of different behavior.
The builder’s factory key is a blunt instrument used to populate the factory with components which the factory yield will use. The most interesting call on the builder’s key is “complete factory” which limits what subsequent components may be added thenceforth and returns two factory keys, mainly the requestor’s key.
Requestor’s key
The Requestor’s key is the tool of the user of the .program within the factory. Sending the message (n;PSB,M,W,EXIT) to the requestor’s key (for suitable n) starts the factory in motion to yield one new product. This message is most likely composed by a call invocation on the factory key. The EXIT key is a resume key to the invoker in this case. The special components play their role at this time. Special actions occur when .keeper or .program are factories; they are called to produce the corresponding object for the new domain. The builder could cope without these special services but it is much more efficient to put this hack in the factory. Part of the special logic for the address segment is legacy for early support of the C language.
The domain’s general key slots come equipped with a few useful initial keys. Note the exit key provided by the caller of the factory resume key. It is the new confined domain, obeying code provided by the builder, that may, or may not, return to the requestor. Talk of ordinals is a legacy holdover.
The 4341 was a mid-range 370 in 1980. It was much less than 1-MIP.
The order “compare discretion” would be issued to a trusted factory, of known provenance, passing a requestor’s key to a factory of suspicious origin. Factory holes impact the discretion of factories.