DIRECTORY CD, CDDirectory, HashTable; PWObjects: CEDAR DEFINITIONS = BEGIN 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]; GetLocationOfFirstInstance: PRIVATE PROC [abut: CD.Object] RETURNS [location: CD.Position _ [0, 0]]; 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]; CreateNode: PROC [geometry: LIST OF PlacedObject, properties: CD.PropList _ NIL] RETURNS [node: Node]; CreateNodes: PROC [table: HashTable.Table] RETURNS [nodes: LIST OF Node]; indirectClass: CD.ObjectClass; CreateIndirect: PROC [sourceObject: CD.Object] RETURNS [indirectObject: CD.Object]; lazyClass: CD.ObjectClass; CreateProc: TYPE = PROC [info: REF] RETURNS [obj: CD.Object]; CreateLazy: PROC [info: REF, createProc: CreateProc] RETURNS [newLazy: CD.Object]; RegisterClass: PROC [objectType: ATOM, expand: CDDirectory.ExpandProc, enumerateChildObjects: CDDirectory.EnumerateChildObjectsProc _ NIL, replaceDirectChilds: CDDirectory.ReplaceDChildsProc _ NIL] RETURNS [objectClass: CD.ObjectClass]; END. ώPWObjects.mesa Copyright c 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. 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). abut is assumed to be of class abutXClass or abutYClass. 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. Creates a new routing cell. Order of nodes is preserved in the sequence. Convenience function that takes a list (instead of a sequence) of PlacedObject as argument. 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. 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. Creates a new Lazy object. Implementors goodie Yes, it is perfectly legal to run this proc twice! All the defaults are the one you dream Κ“˜šœ™Jšœ ΟmœC™NJšœ:™:Jšœ0™0—J™Ibody™mJ™šΟk œ˜%J˜—šΟb œžœž œ˜Jšž˜—head™šœΝ™ΝJ™—Icodešœ žœ ˜šœ žœ ˜M™—MšΟnœžœžœžœžœžœ žœžœ žœ ˜_Mšœ˜šœ˜M™—š œžœžœ žœžœžœžœ ˜RMšœ8™8M™—š  œžœžœžœ žœ žœ˜dM™M™O——™ KšœΈ™ΈšœΒ™ΒJ™—šœžœ ˜M™—Mšœžœžœ ΟcE˜mšœ žœžœ˜Mšœžœ ‘˜Mšœžœžœžœ˜!M˜M˜—Mšœžœžœ ˜šœ žœžœ˜Mšœ žœ žœ˜Mšœ žœžœžœ˜.M˜—š œžœžœ žœžœ ˜GM˜—š  œžœžœžœžœžœ žœ ˜TMšœ™Mšœ,™,M™—š  œžœ žœžœžœ žœžœ˜fMšœ[™[M™—š   œžœžœ žœžœ˜IMšœO™OMšœ[™[MšœI™I——™šœƒ™ƒJ™—šœžœ ˜M™—š  œžœžœ žœžœ ˜SMšœ'žœžœ™D——™Kšœ₯  œžœŒ™ΛKšœ¨™¨K™wKšœΛ™ΛJ™šœ žœ ˜J™—Jš   œžœžœžœžœžœ ˜=š   œžœžœžœ žœ ˜RJšœ™——™š  œžœžœažœ8žœžœžœ˜νM™2M™&—J˜Jšžœ˜—J˜J™—…—²C