xerox 19771201 Code Links Meeting free download

File name 19771201_Code_Links_Meeting.pdf

Inter-Office Memorandum To Distribution Date December 1. 1977 From John Wick Location Palo Alto Subject Code links meeting Organization SOD/SO XEROX XEROX SDD ARCHIVES I have read and understood Pages _________To _________ Revlewer _ _ _ _ Date_ _+O RIoolAFT ... Filed on: [MAXC]CODELlNKS1.BRAVO # of Pages _ _ _ Ref. ,-1.1 oS 00-- :'91- The Mesa Working Group met on Wednesday, November 30, 1977 to discuss the implementation of code links proposed in the following memo: Wick. External links in Mesa. November 29, 1977. The following revisions and additions to the proposal were discussed. Allocation of External Links We decided not to optimize access through imported frame handles (by putting them unconditionally in the frame instead of the linkage vector), and to therefore avoid splitting the linkage vector and complicating the BCD format and the UNNEW operation. It was felt that the improvement in code space for procedure calls was very small, and that most data access involved initialization, for which code space is not very critical. This should be revisited later, when we have more data on how imported frames are used. Initialization Code A proposal was made to allow identification of temporary (initialization or other deletable) modules in configuration descriptions. The idea is that when a configuration is instantiated, two separate segments are allocated for the global frames, one containing all the temporary frames and the other containing all remaining (permanent) frames. Word zero of the permanent segment would point to the temporary one (if any). The operation DElETE could be executed from any of the permanent frames (perhaps from outside the configuration?) and would do an UNNEW on each frame in the corresponding temporary frame segment. The binder should probably check that there are no bindings from permanent frames to temporary ones and at least issue a warning. It was not entirely clear how a series of nested configurations, each with its own set of temporary frames, should be handled (in general, a user of a configuration won't know if it has temporaries or not). A DELETE executed from within a nested configuration could be postponed until a delete at the outermost level is performed (which would apply to the entire configuration). Some method of identifying the outermost DElETE must be devised. An UNNEW on a permanent frame would then become illegal (or it could perhaps do everything except free th