Specification for Project Name: Enhancing the Portability of Lambda System Files Date: 9/22/88 Participants: K. Corbett, D. Saslav Est. Work: 3-4 days of programming per area (see attached), 2-3 days per system rebuild. Total 25 days (2 FTE over a period of 2-3 weeks). Project Status: In progress Purpose: This project is part of the effort to prepare for integration of the Falcon and Lambda computing environments. The process will enhance portability of current Lambda modules, thereby enabling subsequent movement to the Falcon. Justification: This step reduces the amount of time that will be spent in the Falcon debugging stage. By finding and fixing as many wide-spread coding incompatibilities as possible, we begin a systematic and consistent approach to porting these modules "as is". Recompiling and rebuilding the Lambda system becomes an opportunity to make gradual improvements toward the goal of portability. Description: This project will incorporate a variety of approaches to a system-wide search for non-portable code. (Non-portable, for the purpose of this project, means either "Lambda processor-dependent" or "obsolete ZetaLISP".) The LISP tools we will use include: % Compiler warnings from new (and improved) style checkers developed for this purpose; and % Tags Search and Edit Callers to find occurrences of more complicated cases. In addition, some file-by-file inspection may be necessary, in cases where the above tools are insufficient. The top priority will be cold-load files, since any portability improvements realized there will have the most benefit, soonest. For each module, the above tools will be used to isolate processor-dependent variable names and other incompatible constructs; functions or other callers which reference these variables will then be located and debugged, and any other constructs impeding portability revised or reworked. All documentation strings which refer to machine-dependent implementations will be reworded to accurately reflect the new portable implementations. The final stage of this project consists of a recompile-and-debug cycle for the entire system, eliminating any propagated problems or indirect incompatibilities generated by the first part of the process. When all such problems have been eliminated, a cold load band will be constructed; a successfully constructed cold load band will mark the completion of this project. Procedure: A list of known compatibility issues that can be addressed in this fashion is attached. The list will probably grow as development continues. Attachment: Areas of non-portable code 1) Byte specifiers, bitwise values, and enumerated types This part of the project entails a system-wide search for internal variables which rely on particular byte patterns. Included in this group are microcoded variables which have processor-specific implementation dependencies. Once found, a more portable interface must be devised, and all callers of these variables modified. Part of this sub-task, replacing constant values with calls to BYTE, can be partially automated. For more complicated cases, further specification is required; these cases include argument descriptors, FEFs, and DTP codes. 2) The ART-Q-LIST array type The ART-Q-LIST data type will not be supported on the Falcon. "Callers" of ART-Q-LIST (and any other data types that will not be supported) must be replaced with a more portable representation. ZWEI, and any other system modules that use ART-Q-LIST, must be modified. 3) WITH-STACK-LIST Stack lists will not be implemented on the Falcon; it is known that the current Lambda evaluator makes extensive use of stack lists. It must be determined whether any other modules rely on stack lists. 4) Microcode optimizations High-level functions which call microcoded routines directly should be modified to call equivalent LISP routines (if possible). LISP versions of microcode routines that are commented out of the sources will be tested and marked for Falcon target compilation. 5) Obsolete ZetaLISP, MacLISP functions The existing warnings against "old-style" ZetaLISP and "obsolete" MacLISP functions should be expanded, and calls in the system code should be weeded out. This is only necessary in places where the effort will improve the efficiency and/or portability of the code, or when the old features impose more work on the developers porting to the Falcon.