Top Up Prev Next Bottom Contents Index Search

16.7 Class CGPortHole

Class CGPortHole is derived from class DynDFPortHole in order to support non-SDF dataflow stars as well as SDF stars. Methods related to Fork stars are described in a the section above on Resource Management .

In this section, we will categorize the members and methods of CGPortHole into four categories: buffer management, buffer embedding, geodesic switching, and others.

16.7.1 Buffer Management

A CGPortHole is connected to a buffer after resource allocation. A CGPortHole maintains an offset index into the buffer in order to identify the current position in the buffer where the porthole will put or get the next sample:

int offset; 
This is a protected member used for indexing into the buffer connected to this port.

The methods described in this subsection are all public:

unsigned bufPos() const; 
Returns offset, the offset position in the buffer.

virtual int bufSize() const;
virtual int localBufSize() const;
Both methods returns the size of buffer connected to this porthole. In the CGPortHole base class, they call the corresponding methods of class CGGeodesic. Recall that the second method returns 0 when it is a Fork output. If a porthole is at the wormhole boundary, both return the product of the sample rate and the repetition count of the parent star.

virtual void advance();
This method is called by CGStar::advance(). After the parent star is executed, we advance the offset by the number of samples produced or consumed. The offset is calculated modulo the buffer size, so that it is wrapped around if it reaches the boundary of the buffer.

16.7.2 Buffer Embedding

As a motivating example, let's consider a DownSample star. If we allocate separate buffers to the input and output ports, the buffer size of the input port will be larger than that of the output port. Also, we will need to perform an unnecessary copy of samples. We can improve this situation by allocating one buffer at the input site and by indicating that a subset of that buffer is the image of the output buffer. We call this relationship embedding: the larger input buffer is embedding the smaller output buffer, and the smaller output buffer is embedded in the larger input buffer. Unlike the Fork buffer, the sizes of input and output embedded buffers are different from each other. Therefore, we must specify at which position the embedded buffer begins in the larger embedding buffer. We use this embedding relationship to implement Spread and Collect stars in the CGC domain, without increasing the buffer requirements. For example, the output buffers of a Spread star are embedded in the input buffer of the star, starting from different offsets.

CGPortHole* embeddedPort; 
int embeddingFlag;
These are protected members to specify embedding relationships. The first one points to the embedding port which this PortHole is embedded in. The second member indicates the starting offset of embedding. The last member indicates whether this porthole is an embedding port or not.

The following are public methods related to embedding.

CGPortHole* embedded();
int whereEmbedded();
int embedding();
These methods return the protected members described above, respectively.

void embed(CGPortHole& p, int i=-1);
This method establishes an embedding relationship between this port and the argument port p. This porthole becomes an embedding porthole, and the argument porthole becomes an embedded porthole. The second argument specifies the starting offset.

void embedHere(int offset);
This method, when called on an embedded porthole, changes the starting offset its embedded buffer in the embedding buffer.

16.7.3 Geodesic Switching

In the specification block diagram, a PortHole is connected to a Geodesic. In code generation domains, we usually allocate one resource to the Geodesic so that the Geodesic's source and destination ports can share the same resource (Note that this is not a strict requirement). After resource allocation, we may want to alias a porthole to another porthole, and therefore associate it with a resource other than the allocated resource. To do that, we switch the pointer of the Geodesic to another Geodesic.

virtual void switchGeo(Geodesic* g);
virtual void revertGeo(Geodesic* g);
Both methods set the Geodesic pointer to the argument g. There is a flag to indicate whether this port has switched its Geodesic or not. The first method sets the flag to TRUE while the second method resets the flag to FALSE. Both methods are virtual since in derived classes we may need to redefine the behavior, perhaps by saving the original Geodesic, which is not the default behavior. The flag is queried by:

int switched() const;
If the Geodesic is switched in this port, we have to reset the geodesic pointer of this port to NULL in the destructor in order to prevent attempts to delete the same Geodesic multiple times. Also, we have to make sure that both ends of a Geodesic do not switch their Geodesic, in order to prevent orphaning the geodesic and causing a memory leak.

16.7.4 Other CGPortHole Members

Class CGPortHole has a constructor with no argument which resets the member variables. In the destructor, we clear the forkDests list and remove the pointer to this porthole from the forkDests list of the forkSrc port. All members described in the subsection are public.

CGGeodesic& cgGeo() const;
This method returns a reference to the Geodesic after type casting.

void forceSendData();
void forceGrabData();
These methods put and get samples to and from the Geodesic at the wormhole boundary. They are used when the inside code generation domain communicates by the wormhole mechanism.

16.7.5 CGPortHole Derived Classes

Class InCGPort and class OutCGPort are publicly derived from class CGPortHole. They are used to indicate by class type whether a porthole is an input port or an output port.

Class MultiCGPort is derived from class MultiDFPort. It has a protected member forkSrc to point to the Fork input if its parent star is a Fork star. It has a default destructor.

CGPortHole* forkSrc;
There are two public methods related to this protected member:

void setForkBuf(CGPortHole& p);
void forkProcessing(CGPortHole& p);
The first method sets forkSrc to point to the argument port. The second method sets the forkSrc pointer of the argument port to point to the forkSrc of this MultiCGPort.

Two classes are publicly derived from MultiCGPort: MultiInCGPort and MultiOutCGPort. They both have the following public method:

PortHole& newPort();
This method creates an InCGPort or an OutCGPort depending on whether it is an input or an output MultiCGPort.

Top Up Prev Next Bottom Contents Index Search

Copyright © 1990-1997, University of California. All rights reserved.