Achieving maximum performance through migration of functions from software to microcode requires rethinking the linkage editing process. An object-oriented model of naming and binding clarifies the alternative abstractions available in naming and linking across the macro-micro machine boundary. Alternative abstractions for sharing micro-objects and for dynamic use of micro-objects are presented and their implementations discussed. The conclusions are based on actual implementations.>

Abstract The design of a portable, production‐quality dynamic microprogramming system is given. The system is an extension to UNIX; it allows multiple users easily to time‐share the writable control store on a Perkin‐Elmer 3220. Each process may have its own microcode support, known as a microimage; processes may share microimages. Microimages are managed either in an optional software cache in kernel memory or in user memory where they are subject to secondary memory swapping. The physical loading of the WCS is accomplished in on‐demand fashion in the sense that only the first attempt to enter control store during a given scheduling quantum can cause a WCS fault. Users are prevented from erroneously entering control store by separate management of the control store entry points. The paper provides sufficient detail to allow other UNIX and similar systems to adopt this approach. Performance effects of WCS contention add from about 0.5 to 1 per cent overhead to the jobs, and the use of vertical migration has improved job run times up to 50 percent. This system has been in use for over a year and provides the main support for ongoing research into vertical migration.

There are various ways in which programming languages may deal with the use of objects that have no value.They may or may not treat such uses as errors and may or may not trap such errors.The evolution from the preliminary version of Ada TM to the 1980 version and then to the 1982 version is a case in point.A basis for investigation resting on the desire for more reliable software is presented.Ways of declaring types with and without the value unassigned, derivations from such types, and the meaning of unassigned for composite types are all investigated.Static and dynamic assignment of the value unassigned are introduced, and the interaction of these with other design factors, especially unassigned composite objects, is detailed.It is shown that the typical dual view of composite objects, both as objects and composites of other objects, leads to inconsistencies in the dynamic treatment of unassigned composites and to significant implementation inefficiencies.