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, October 27, 1986 3:13:38 pm PST
This interface defines new classes of objects: low-weight abuts, low-weight imports, lazy-evaluated objects.
DIRECTORY CD, CDDirectory, HashTable;
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).
abutXClass: CD.ObjectClass;
abutYClass:
CD.ObjectClass;
CreateAbutProc: TYPE = PROC [subObjects: LIST OF CD.Object ← NIL] RETURNS [newAbut: CD.Object];
CreateNewAbutX: CreateAbutProc;
CreateNewAbutY: CreateAbutProc;
GetAbutSubObjects:
PROC [abut:
CD.Object]
RETURNS [subObjects:
LIST
OF
CD.Object];
abut is assumed to be of class abutXClass or abutYClass.
GetLocationOfFirstInstance:
PRIVATE
PROC [abut:
CD.Object]
RETURNS [location:
CD.Position ← [0, 0]];
To be removed soon
The location is relative to the [0, 0] of the abut in the CD coordinate system.
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 an $InstanceName property.
routingClass:
CD.ObjectClass;
RoutingSpecific: TYPE = REF RoutingRep; -- Type of routing.specificRef, 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];
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 $InstanceName property 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]
RETURNS [newLazy:
CD.Object];
Creates a new Lazy object.
Implementors goodie
RegisterClass:
PROC [objectType:
ATOM, expand: CDDirectory.ExpandProc, enumerateChildObjects: CDDirectory.EnumerateChildObjectsProc ←
NIL, replaceDirectChilds: CDDirectory.ReplaceDChildsProc ←
NIL]
RETURNS [objectClass:
CD.ObjectClass];
Yes, it is perfectly legal to run this proc twice!
All the defaults are the one you dream
END.