PWObjects.mesa
Copyright © 1983, 1984, 1985, 1986 by Xerox Corporation. All rights reversed.
Created by Bertrand Serlet, October 3, 1985 2:14:24 pm PDT
Bertrand Serlet, March 15, 1987 1:23:55 am PST
This interface defines new classes of objects: low-weight abuts, compact routing objects, low-weight imports, lazy-evaluated objects, and some goodies.
DIRECTORY
CD, CDDirectory, HashTable, Rope;
PWObjects: CEDAR DEFINITIONS = BEGIN
Abuts
Abuts differ from cells by the fact they contain a list of subObjects abutted one next to the other, and not a list of instances. There is more information in an AbutX (resp. Y): the order of subObjects is important and the leftmost (resp. bottommost) is the first one. Not all cells can be described with Abuts: for example the ones which have overlapping instances. There is no check that the cells abutted have compatible sizes (this check is made in PW). Origin for the abutted objects is the InterestRect. For abuts, the InterestBase is [0, 0].
abutXClass: CD.ObjectClass;
abutYClass:
CD.ObjectClass;
CreateAbutProc: TYPE = PROC [subObjects: LIST OF CD.Object ← NIL] RETURNS [newAbut: CD.Object];
CreateNewAbutX: CreateAbutProc;
CreateNewAbutY: CreateAbutProc;
EachSubObjectProc:
TYPE =
PROC [subObject:
CD.Object, pos:
CD.Position];
pos is relative to the [0, 0] of the abut
EnumerateSubObjects:
PROC [abut:
CD.Object, eachSubObject: EachSubObjectProc];
abut is assumed to be of class abutXClass or abutYClass.
returns position of a would-be after-last sub-object, relative to the [0, 0] of the abut
Routing Cells
Routing objects allow a space-efficient representation of routing areas. This representation also retains the node structure of the cell, and so is very time-efficient for extraction.
Expansion of a Routing object results in an ordinary cell, so that all processors for which time or space is not an issue do not need modification. All instances of the expanded cell have a copy of the properties of their node. This mechanism allows all instances of the expanded cell to carry the $SignalName property (understood by the extractor). For routing object, the InterestBase is [0, 0].
routingClass:
CD.ObjectClass;
RoutingSpecific: TYPE = REF RoutingRep; -- Type of routing.specific, when routing is of class routingClass
RoutingRep:
TYPE =
RECORD [
ir: CD.Rect, -- interest rect
nodes: SEQUENCE size: NAT OF Node
];
Node: TYPE = REF NodeRep;
NodeRep:
TYPE =
RECORD [
properties: CD.PropList ← NIL,
geometry: SEQUENCE size: NAT OF PlacedObject];
PlacedObject:
TYPE =
RECORD [object:
CD.Object, position:
CD.Position];
Position for object is relative to its InterestRect
CreateRouting:
PROC [ir:
CD.Rect, nodes:
LIST
OF Node]
RETURNS [routing:
CD.Object];
Creates a new routing cell.
Order of nodes is preserved in the sequence.
CreateNode:
PROC [geometry:
LIST
OF PlacedObject, properties:
CD.PropList ←
NIL]
RETURNS [node: Node];
Convenience function that takes a list (instead of a sequence) of PlacedObject as argument.
CreateNodes:
PROC [table: HashTable.Table]
RETURNS [nodes:
LIST
OF Node];
Creates nodes from a HashTable that maps names to their corresponding geometry.
Each key of table is of type ROPE; each value of table is of type REF LIST OF PlacedObject.
Each key is added as an $SignalName properties on the corresponding node.
Indirect
Indirect objects introduce one level of indirection, so that users can store properties both on indirect objects and their source. No new code is necessary for Indirects since they use the expand mechanism. The result of the expansion is never included in the directory, for the expanded cell might be already in another directory. They are used to implement low weight imports in PW.
indirectClass:
CD.ObjectClass;
CreateIndirect:
PROC [sourceObject:
CD.Object]
RETURNS [indirectObject:
CD.Object];
Creates a new IndirectObject. Returns NIL if sourceObject is NIL.
Lazy
Lazy objects are basically a way of avoiding the static creation of huge cells, by expanding them on demand. All the data structure contained in a Lazy object is a CreateProc returning an CD.Object, and the necessary parameters to apply to this proc, when it is really needed to expand this fake object into an ordinary CD object.
Lazy objects will permit the construction of huge circuits, if they are used so to generate basic bricks. They open the space/time compromise when generating geometry.
It is assumed that the info field contains no CD object, so that changing a cell has no consequence on the Lazy object.
It is also supposed that the createProc computing the geometry of the object is fast enough, so that there is no need to cache it. If it is not the case, the client can use a cache inside the createProc.
lazyClass:
CD.ObjectClass;
CreateProc: TYPE = PROC [info: REF] RETURNS [obj: CD.Object];
CreateLazy:
PROC [info:
REF, createProc: CreateProc, bbox, ir:
CD.Rect]
RETURNS [newLazy:
CD.Object];
Creates a new Lazy object.
It is assumed that: CreateProc[info].bbox=bbox AND CD.InterestRect[CreateProc[info]]=ir
Implementors goodies
CreateCell:
PROC [instances:
CD.InstanceList, ir:
CD.Rect ← [0, 0, -1, -1], name: Rope.
ROPE ←
NIL, properties:
CD.PropList ←
NIL]
RETURNS [
CD.Object];
This is the right way to create cells (it should be in CDCells!).
RegisterProp:
PROC [prop:
ATOM, copy:
BOOL ←
FALSE, flushOnEdit:
BOOL ←
FALSE]
RETURNS [sameAtom:
ATOM];
This goodie is to register a property which is an ATOM (instead of a REF), when you do not care about registering it many times, and so that it is easy to specify the copy proc. If the argument flushOnEdit is set to TRUE, all edits of a cell will provoke the dismiss of the property for that cell and all the cells that depends on it.
RegisterClass:
PROC [objectType:
ATOM, expand: CDDirectory.ExpandProc, enumerateChildObjects: CDDirectory.EnumerateChildObjectsProc ←
NIL, replaceDirectChilds: CDDirectory.ReplaceDChildsProc ←
NIL, interestRect:
CD.RectProc ←
NIL, drawMe, quickDrawMe, showMeSelected:
CD.DrawProc ←
NIL]
RETURNS [objectClass:
CD.ObjectClass];
Yes, it is perfectly legal to run this proc twice!
All the defaults are the one you dream
END.