NAME

virtual_unit -- insert a unit as parameter in a circuit

PROTOTYPE

unitptr virtual_unit( int iArg, int* piIDesc, int* piIRefs, int *piODesc, int* piORefs)

ARGUMENTS

int iArg
position of referenced operand unit after host unit uHost of this virtual\_unit.
int* piIDesc
nr of mirrored input fields and their dimensions
int* piIRefs
field numbers of mirrored input fields of referenced operand [array entries correspond with piIDesc, 0-entry not used]
int *piODesc
nr of mirrored output fields and their dimensions
int* piORefs
field numbers of mirrored output fields of referenced operand [array entries correspond with piODesc, 0-entry not used]

DESCRIPTION:

The virtual_unit provides a mechanism to insert another unit (referred to as the operand of the virtual_unit ) in place of the virtual_unit's position within a circuit.

SELECTION OF AN OPERAND UNIT:

The operand of the virtual_unit will be the iArg-th ( iArg=1,2,.. ) successor unit of the virtual_unit's host unit. Whenever the virtual_unit is executed or adapted this operation will be carried out for its operand (even though it is located somewhere else). The same operand can be referenced by several virtual_units from different places. This provides a mechanism to use the same unit in different places. The operand is selected after each exec_unit or adapt_unit -call of the virtual_unit, therefore, the binding of an virtual_unit to its operand can be changed dynamically by requeuing the operand unit to a different position. A consequence of this scheme is that the virtual_unit is useless if its host is ROOT. It must always be a subunit of some container unit below ROOT.

BRIDGING SEVERAL LEVELS:

If the desired operand unit is several container levels outside, a corresponding number of virtual_units (one in each container) must be used, since each virtual_unit can bridge only one container level. In this case, usually it is of no interest to transport the interface values also into the input/output ports of the intermediate virtual_units. Therefore, NST allows to chose the intermediate virtual_units interface-less (0 inputs and 0 outputs), only the innermost virtual_unit must have its interface suitably defined for exchanging data with the outermost operand. The use of this simplification is strongly recommended, since it also saves the time that would be required to copy the interface data through each of the intermediate virtual_units.

NOTE:

Any unit that is selected as operand of a virtual_unit becomes `invisible'' for direct exec/adapt_unit calls (i.e., such calls will produce no effect). However, calls mediated through references by further virtual_units will remain effective. Thus, for each unit there is the alternative to exec or adapt it `normally'' or through virtual_unit-calls exclusively.

MIRRORING FIELDS:

The virtual_unit can `mirror'' some (or all) of the input and/or output fields of its operand. That means, that the virtual_unit will inherit some of the fields of its operand. When the virtual_unit is executed or adapted, data at the mirrored input fields will be transported to the corresponding input fields of the operand unit, then the operand unit will be adapted or executed, and any results at the operand's output fields will be transported back to any corresponding `mirrorred'' output fields of the virtual_unit. Thus, by mirroring the required input/output fields, an virtual_unit can insert the data transformation effected by the execution or adaptation of its operand unit at any location within a circuit.

OPERATORS:

Thus, a host unit that contains one or several virtual_units can use a subset of its successor units as parameters of its own circuit. Therefore we will call host units that contain virtual_units `operators''.

EXAMPLE:

virtual_unit(2,[2,5,-10],[0,2,1],[1,3],[0,0],uHost) will reference the second successor of uHost. The created virtual_unit will have 2 input fields of dimensions 5 and -10 that will `mirror'' the two input fields with field numbers 2 and 1 of the referenced operand (assuming that the operand has these fields and that the dimensions match. However, these conditions need only be satisfied by the operand later at run-time, not when the virtual_unit is created). Further, the created virtual_unit will have one output field with 3 pins, mirroring output field 0 of the referenced operand.

LOAD SAVE CONTROL:

The virtual_unit is invisible to the load_unit, save_unit and ctrl_unit calls, i.e., no file entries are produced or read, and no control calls are sent to the referenced operand. An exception are control calls issued by a ctrl_op unit: these are passed to the referenced operand, even if the reference proceeds via one or several virtual_units. [the non-effect of the control calls may be changed in later versions].

SEE ALSO:

neo

FILE

/amnt/loge/users/nistaff02/nistaff/rhaschke/nst7/man/../o.linux//../nstsrc/nst_stdr.c