bson@rice-chex.ai.mit.edu (Jan Brittenson) (03/24/91)
I have two additions to make to James Cloos' and Dave Kaffine's postings (November 15, and November 16, 1990, respectively) on the composition of library objects. For clarification, a command number is the second of the two XLIB numbers, and is used to index the command within its library. The library is indexed by the library number, which is the first of the two numbers, and is used to locate the library. First, when allocating command numbers, the named commands must use the low end of the range, and the unnamed commands the upper. For instance, if the library is to contain two names commands "ONE" and "TWO", and in addition to that two unnamed commands, then the named commands must be commands number 0 and 1, and the unnamed commands 2 and 3. Second, the back pointers in the hash table are ordered by command number (for the named commands - the hash table is used for name translations), and of course only the named commands are included. The order of the back pointers (and, thus, the command numbers) decide in what order the commands appear in the LIBRARY menu. As I mentioned, the commands are ordered in the menu according to the back pointers. But they are executed by indexing the link table, so the two better match - or the keys will not match the functions, and if you, like I did, name commands for debugging purposes, then running the wrong code object may have disastrous results! Finally, I have a question which someone may be able to answer: when storing a library in a port, or attaching it, does it run a risk of getting split up and the different parts of it moved around independently, or will it be stored as one continuous chunk of memory? More specifically, can CODE objects in the library share subroutines and (potentially large) tables? I'm sure they're not going to get split up if in ROM ;-), but what about when they're in RAM? -- Jan Brittenson bson@ai.mit.edu