RuntimeSupportDoc.tioga
Carl Hauser, March 15, 1988
Carl Hauser, March 18, 1988 9:45:40 am PST
Portable Cedar Runtime Support Documentation
CEDAR 7.0 — FOR INTERNAL XEROX USE ONLY
Portable Cedar Runtime Support Documentation
Carl Hauser
© Copyright 1987 Xerox Corporation. All rights reserved.
Abstract: At the level of the RuntimeSupport package, the dependency tree of portable Cedar breaks the shackles of pure C and begins to resemble a Mesa-based system. Below this level, one finds the support for garbage-collected storage, for dynamically loading programs, and for lightweight processes all written in C or native assembly language. At this level, the Basics interface describes the layout of the machine as seen by Mesa programmers, the PortableCedarRuntimeSupport interface describes the contract between the Mimosa compiler and the runtime support, and SignalsImpl and friends provide the necessary support for Mesa SIGNAL and ERROR handling. The Process interface gives Mesa programs access to the process primitives implemented in CedarBoot. Finally, Checksum and ChecksumImpl are here just because they fit.
Created by: Carl Hauser
Maintained by: Carl Hauser <CHauser.pa>
Keywords: Basics, Signal, Checksum, Process
See Also: CedarBootDoc
XEROX Xerox Corporation
Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94304
For Internal Xerox Use Only
1. Introduction
See Abstract.
2. SIGNAL and ERROR support
Body
4. Checksum
Provides INLINE and callable procedures for computing 16 bit checksums of sequences of 16 bit words. The computed checksum should agree with what's computed in DCedar for the same sequence. This is important because these checksums are passed over the network.
Do we need a 32 bit checksum program for internal/PCedar only use?
5. Notes on porting PrincOps programs to PortableCedar
Basics (and the now non-existent PrincOps and PrincOpsUtils)
Basics now incorporates operations and descriptions that reside in DCedar's PrincOps and PrincOpsUtils interfaces. Programs using PrincOps or PrincOpsUtils must change for PCedar. If Basics doesn't have enough functionality to allow porting it needs to be extended or you need to look elsewhere. It will be very hard to make common source code versions of existing programs that use PrincOps or PrincOpsUtils.
Basics.LongNumber is attempting to promote new field names for the 32 bit cardinal, integer, and pointer variants. The old names are provided for applications that want to share source code between DCedar and PCedar. If there is another DCedar interface party at this level, we should try to standardize on the new names. Otherwise, we'll let the old names persist until the death of DCedar.
Signals and Errors
This is a fuzzy statement: the design of the PCedar signal handling machinery is intended to provide sufficiently similar semantics to the PrincOps design that programs using SIGNAL and ERROR in the usual ways will not be affected.
The PCedar design is actually somewhat more powerful than the PrincOps design and interacts better with INLINE procedures. The conservative approach to programming with the new design is to continue using common DCedar signal handling idioms. This will also be necessary to maintain source code compatibility between DCedar and PCedar.
The PCedar system uses dynamic handler establishment and is expected to be somewhat slower, relative to procedure call, than the DCedar mechanism.
Processes
The big news is that JOIN and Process.Detach are now implemented safely because the runtime uses enough bits for process IDs that they need never be reused. The language still treats them as unsafe, however. Programs that must be portable between DCedar and PCedar should continue to use the old style: treat all uses of JOIN and Process.Detach as if they were UNSAFE.
Checksum
The declaration of Checksum.ComputeChecksum had to change because PCedar POINTER variables have 4-byte alignment while DCedar POINTER variables have 2-byte alignment. In order to be able to compute checksums starting at positions with 2-byte alignment, another parameter is required giving the offset from a 4-byte aligned target. For a given sequence of 16-bit values, the DCedar and PCedar checksums are the same.
As currently implemented, the DCedar checksum computation is very, very slow. If you need fast checksums, please investigate replacing ChecksumImpl for us.