[_CDMiwok_01_]<cedarcommon2.0>Cirio>MobAccess.mesa!6

MobAccess.mesa

-- 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.