MobAccess.mesa
Copyright Ó 1992 by Xerox Corporation. All rights reserved.
-- Sturgis, March 1, 1990 10:12 am PST
Last tweaked by Mike Spreitzer on December 17, 1991 9:39 am PST
Coolidge, July 17, 1990 2:45 pm PDT
This interface is designed to provide access to Mob files for Cirio. There are two ideas. The first is that a Mob file need not always be in memory (or VM). The second is that various entries in the Mob files are represented by corresponding Cedar record structures.
Mob files are represented by MobCookies. Internal symbol table pointers (usually represented by relative pointers) are represented by pairs: <mobCookie, relPointer>. (These are actually opaque.) There will be a different pair type for each different relPointer type.
For each relative pointer type there are: (1) a Cedar record structure type, (2) a Make procedure that accepts pairs: <mobCookie, relPointer> and produces the appropriate opaque value, and (3) a Fetch procedure that accepts the opaque pair value and produces the Cedar record structure. The Mob files are moved in automatically, if not already in, during the Fetch procedures.
The general form of the Cedar record structures is to mimick the structure of a record type in Symbols. However, we replace an embedded (or tail) variant record by a REF to a non-embedded variant record. I believe that this makes construction and examination more convenient.
DIRECTORY
MobDefs USING[VersionStamp],
Rope USING[ROPE],
Symbols USING[Alignment, BTIndex, Closure, ContextLevel, CTXIndex, MDIndex, ProcClass, SEIndex, SpecialVarKind, VariableFlags],
SystemInterface USING[CirioFile];
MobAccess: CEDAR DEFINITIONS =
BEGIN
Errors
MobError: ERROR[msg: Rope.ROPE];
MobCookies
MobCookie: TYPE = REF MobCookieBody;
MobCookieBody: TYPE;
CreateMobCookie: PROC[f: SystemInterface.CirioFile] RETURNS[MobCookie];
GetFileForMobCookie: PROC [MobCookie] RETURNS [SystemInterface.CirioFile];
Version Stamps
ReadMobVersionStamp: PROC[mob: MobCookie] RETURNS[MobDefs.VersionStamp];
ReadSourceVersionStamp: PROC[mob: MobCookie] RETURNS[MobDefs.VersionStamp];
ComputeSourceVersionStamp: PROC[mesaSourceFile: SystemInterface.CirioFile] RETURNS[MobDefs.VersionStamp];
for the convenience of clients
this is adapted from [PCedar2.0]<MakeDo>CcDeps.mesa MobStampFromTime
Body Tables
The Cedar record structure
BTR: TYPE = REF BTRBody;
BTRBody: TYPE = RECORD[
link: BodyLinkRcd, -- ptr to sibling or parent
firstSon: BTH,
type: SEH, -- will be a record
localCtx: CTXH,
sourceIndex: CARD,
info: REF BodyInfo,
level: Symbols.ContextLevel,
class: Symbols.ProcClass,
extension: REF BTRExtension];
BodyLinkRcd: TYPE = RECORD[which: {sibling, parent}, index: BTH];
BodyInfo: TYPE = RECORD[
SELECT mark: * FROM
Internal => [
frameSize: CARD16
bodyTree: Base RELATIVE LONG POINTER, -- Tree.Index
thread: Base RELATIVE LONG POINTER], -- Tree.Index / LitDefs.STIndex
],
External => [
bytes, startIndex, indexLength: INT]
ENDCASE];
BTRExtension: TYPE = RECORD[
SELECT btrTag: * FROM
Callable => [
id: SEH,
ioType: SEH,
frameOffset: INT, -- offset in AUs from enclosing frame base
entryIndex: CARD16,
hints: RECORD[
safe, argUpdated, nameSafe, noStrings: BOOL],
entry, internal, inline, monitored, noXfers, resident: BOOL,
kind: BodyKind],
Other => [relOffset: INT]
ENDCASE];
BodyKind: TYPE = {Outer, Inner, Catch, Other};
The pair handles
BTH: TYPE = REF BTHBody;
BTHBody: TYPE;
The procedures
MakeBTH: PROC[mob: MobCookie, bti: Symbols.BTIndex] RETURNS[BTH];
BTHDetails: PROC [BTH] RETURNS [mob: MobCookie, bti: Symbols.BTIndex];
codedBtis appear in the text part of some DotOfile Stab entries.
MakeBTHFromCodedBti: PROC[mob: MobCookie, codedBti: CARD] RETURNS[BTH];
GetRootBTH: PROC[mob: MobCookie] RETURNS[BTH];
FetchBTR: PROC[bth: BTH] RETURNS[BTR];
GenCallableBodies: PROC[mob: MobCookie, for: PROC[callableBody: BTH]];
returns NIL if bth is root
GetParentOfBTH: PROC[bth: BTH] RETURNS[BTH];
used for indexing in MobDotOAccessImpl
GetCodedBTIFromBTH: PROC[bth: BTH] RETURNS[CARD];
Module Directory
The Cedar record structure
MDR: TYPE = REF MDRBody;
MDRBody: TYPE = RECORD[
stamp: MobDefs.VersionStamp,
moduleId, fileId: Rope.ROPE,
shared, exported: BOOL,
ctx, defaultImport: CTXH];
The pair handles
MDH: TYPE = REF MDHBody;
MDHBody: TYPE;
The procedures
MakeMDH: PROC[mob: MobCookie, mdi: Symbols.MDIndex] RETURNS[MDH];
FetchMDR: PROC[mdh: MDH] RETURNS[MDR];
GetMobForMDH: PROC[mdh: MDH] RETURNS[MobCookie];
GetMdiForMDH: PROC[mdh: MDH] RETURNS[Symbols.MDIndex];
Context Tables
The Cedar record structure
CTXR: TYPE = REF CTXRBody;
SimpleCTXR: TYPE ~ REF simple CTXRBody;
IncludedCTXR: TYPE ~ REF included CTXRBody;
ImportedCTXR: TYPE ~ REF imported CTXRBody;
NilCTXR: TYPE ~ REF nil CTXRBody;
CTXRBody: TYPE = RECORD[
seList: SEH,
level: Symbols.ContextLevel,
varUpdated: BOOL,
extension: SELECT ctxType: CTXType FROM
simple => [copied: ClosureCompleteness],
included => [
chain: CTXH,
module: MDH,
map: Symbols.CTXIndex,
copied: ClosureCompleteness,
reset, closed, complete, restricted: BOOL],
imported => [includeLink: CTXH],
nil => [],
ENDCASE];
CTXType: TYPE ~ {simple, included, imported, nil};
ClosureCompleteness: TYPE ~ Symbols.Closure;
The pair handles
CTXH: TYPE = REF CTXHBody;
CTXHBody: TYPE;
The procedures
MakeCTXH: PROC[mob: MobCookie, ctx: Symbols.CTXIndex] RETURNS[CTXH];
MakeStdCtxh: PROC[mob: MobCookie] RETURNS[CTXH];
...wherein standard types (INT, BOOL, ...) are defined.
FetchCTXR: PROC[ctxh: CTXH] RETURNS[CTXR];
GetMobForCTXH: PROC[ctxh: CTXH] RETURNS[MobCookie];
GetCtxForCTXH: PROC[ctxh: CTXH] RETURNS[Symbols.CTXIndex];
Semantic Entry Tables
The Cedar record structure
I have not attempted to maintain a distinction between various kinds of SERcds. This would lead to various difficulties at the SEH level. Thus, in constructing an SEH from an isei or a csei, I through away some predictive information.
SER: TYPE = REF SERBody;
SERBody: TYPE = RECORD[body: REF BodySE];
BodySE: TYPE = RECORD[
SELECT serTag: * FROM
id => [
extended, public, immutable, constant, linkSpace: BOOL,
idDecl: [0..7], -- used for declaration processing (MimExpr, MimStmt)
idCtx: CTXH, -- the context in which the identifier instance appears
idType: SEH,
idInfoAndValue: REF ANY, -- (one of FieldDesc, TypeDesc, BlockDesc, or ??)
hash: Rope.ROPE, -- the name associated with the entry
flags: VariableFlags,
special: SpecialVarKind,
ctxLink: SEH -- next identifer in the context
],
cons => [
align: Symbols.Alignment,
typeInfo: REF TypeInfoConsSE],
ENDCASE];
VariableFlags: TYPE = Symbols.VariableFlags;
SpecialVarKind: TYPE = Symbols.SpecialVarKind;
Following are the possibilities for the idInfoAndValue field
FieldDesc: TYPE = RECORD[
bitSize: CARD,
bitOffset: INT];
bitOffset is in bits from either the frame pointer or a record base
TypeDesc: TYPE = RECORD[
seh: SEH,
data: CARD]; -- not exactly when data is valid, at least for bound variant types it is the integer representation of the adjective for the variant. (or so the hardcopy document says.)
BlockDesc: TYPE = RECORD[
bth: BTH,
data: CARD]; -- not exactly sure when data is valid.
ConstVal: TYPE = RECORD[
value: CARD]; -- just the value, not the appropriate type, and only if fits in a word.
TypeInfoConsSE: TYPE = RECORD[
SELECT typeTag:* FROM
mode => [],
basic => [
ordered: BOOLEAN,
code: NAT15,
length: CARD16], -- in bits
signed => [length: INT],
unsigned => [length: INT],
real => [length: INT],
enumerated => [
range: CARD,
valueCtx: CTXH,
empty, sparse, painted, ordered, machineDep: BOOL],
record => [
length: INT, -- in bits
fieldCtx: CTXH,
bitOrder: BitOrder,
grain: NAT15,
hints: RECORD [
comparable, assignable: BOOL,
unifield, variant, privateFields: BOOL,
refField, default, voidable: BOOL],
packed, list: BOOL,
argument, monitored, machineDep, painted: BOOL,
linkPart: SEH], -- linkPart = NIL for notLinked in symbols
ref => [
refType: SEH,
counted, ordered, readOnly, list, var, basing: BOOL,
length: CARD],
array => [
componentType: SEH,
indexType: SEH,
packed: BOOL,
bitOrder: BitOrder],
arraydesc => [
describedType: SEH,
var, readOnly: BOOL,
bitOrder: BitOrder,
length: CARDINAL], -- in bits
transfer => [
safe: BOOLEAN,
mode: TransferMode,
typeIn, typeOut: SEH,
length: CARDINAL],
definition => [
defCtx: CTXH,
slots: CARDINAL, -- slots in interface record
named: BOOL], -- obsolete
union => [
caseCtx: CTXH,
tagSei: SEH,
hints: RECORD [equalLengths, refField, default, voidable: BOOL],
overlaid, controlled, machineDep: BOOL,
bitOrder: BitOrder,
grain: NAT],
sequence => [
parentType: SEH, -- will be a record cons
tagSei: SEH, -- will be an id
componentType: SEH,
packed, controlled, machineDep: BOOL,
bitOrder: BitOrder,
grain: NAT15],
relative => [baseType, offsetType, resultType: SEH],
subrange => [
empty: BOOLEAN,
biased: BOOLEAN,
filled: BOOLEAN,
rangeType: SEH,
origin: INT,
range: CARD],
opaque => [
id: SEH,
length: INT, -- in bits
lengthKnown: BOOL],
zone => [
counted, mds: BOOL,
length: CARDINAL], -- in bits
any => [],
nil => [],
unknown => [],
ENDCASE];
TransferMode: TYPE = {proc, port, signal, error, process, program, none};
BitOrder: TYPE = {msBit, lsBit};
this definition parallels that in [PCedar2.0]<Mimosa>Symbols.mesa
msBit => bit N is more significant than bit N+1 in a word
(PrincOps, Dragon, Motorola 680x0, IBM 360, Sparc)
lsBit => bit N+1 is more significant than bit N in a word
(PDP-11, VAX, Intel 80x86)
The pair handles
note: the following handle will be NIL if the corresponding sei is null.
further: We shall endevour to create only one of the following records for each sei. Hence the subsequent Fetch calls will only create a record once per sei.
However, since the interpretation of SE records, as they occur in Mimosa symbol tables, depends on how one reaches the SE record, we must carry some context information with the handles.
SEH: TYPE = REF SEHBody;
SEHBody: TYPE;
note that frame fields will include type declarations, constant declarations, as well as variable declarations.
We shall add other contexts to this list as time goes on.
The procedures
MakeSEH: PROC[mob: MobCookie, sei: Symbols.SEIndex] RETURNS[SEH];
codedSeis appear in the text part of some DotOfile Stab entries.
MakeSEHFromCodedSei: PROC[mob: MobCookie, codedSei: CARD, name: Rope.ROPE] RETURNS[SEH];
codedSeis appear in the text part of some DotOfile Stab entries.
GetCodedSeiFromSEH: PROC[seh: SEH] RETURNS[CARD];
FetchSER: PROC[seh: SEH] RETURNS[SER];
GetMobForSEH: PROC[seh: SEH] RETURNS[MobCookie];
GetSeiForSEH: PROC[seh: SEH] RETURNS[sei: Symbols.SEIndex];
IsLost: PROC[SEH] RETURNS[BOOL];
Is this an id SEH defined in the null context?
END.