o If the instruction format assumes the memory address length not less than 4 octets, 2-octet address is located in the last octets. The first 2 octets must set to zero. o If instruction is the member of a chain and it has the less length of the memory address, than it is defined for the node - it is considered, that the base-displacement addressing is used. If the value of the memory base is not assigned for the chain - instruction is erroneous. o If the instruction is not the member of a chain and has the length of memory address less, than it is defined for the node, it is considered, that the abbreviated address is used. The complete address length must be received by padding in front of it the necessary number of zero-value octets. o In all other cases, the instruction is erroneous. Complete 128-bit memory address writes in operands in the 16-octets field. The reason of using of the complete address is that the additional information, using by the memory control subsystem in the node, may contain in its field FREE (see section 2.1). If the FREE of the complete address is set to zero, it is recommended to use local address in operands. Operands field has a length, which is an integral number of 32 bits. The alignment is making by padding, if necessary, of the zero-value octets at the end of the field. Header fields of the instructions not defined in the formats description are used according to the description from section 3. The instruction of the transfer control JUMP, CALL, CALL_BNUM and CALL_BNAME may contain the information about VM of the sender. If VM type and VM version of the sender are contains in the instruction, the call parameters are formed in a format VM of the sender. Else, the call parameters have format defined by VM of the addressee. The code is always connected with of specific VM. All instructions of the protocol work with binary data and do not provide operations of formats transformation.
OPCODE = 130/131 ; For length of the length field of 2/4 octets. OPR_LENGTH = 1/2/3/5 ; Depends on address length. Operands: 2/4 octets: The length field. The number of the required data in octets. 2/4/8/16 octets: The memory address of the required data. The instruction DATA, containing required data, is sent in reply to it. If the data cannot be sent, the instruction RSP with the non- zero basic return code, comes back.
Extension headers: _DATA - Contains immediate data. This header is present only, if the data does not contain in operands. At address length of 2 octets the data length must be 2 octets. In all other cases, address length must be not less than 4 octets and data length must be multiple of 4 octets. The data must not be sent simultaneously in operands and in the extension header. The instruction RSP is sent in reply to the instruction WRITE. The zero basic return code defines normal executing.
Operands: 2/4/8/16 octets: The memory address for compared data. 2 - 262136 octets: The immediate data for the comparison. At the address length of 2 octets the data length must be 2 octets. In all other cases length of the address must not be less than 4 octets and the data length is multiple to four octets.
145/146 ; Correspondingly the CALL not containing and containing the information about VM. OPR_LENGTH = 2 - 65535 ; Depends on inclusion of the information about VM, address length and parameters length. Operands: 2 octets: The VM type of the sender. If OPCODE=143/145 this field is absent. 2 octets: The VM version of the sender. If OPCODE=143/145 this field is absent. 4/8/16 octets: The address of memory, where is necessary to transfer control. 2 octets: The number of 32 bit words in the call parameters field. 4 - 262134 octets: The immediate data are the parameters of a call. On the reception side the processing of the instructions of a control transfer occurs as follows: o The memory address is checked. If it has erroneous value, the negative response RSP is sent. At this stage, the correctness of parameters of a call may be also checked up. o If the memory address and the parameters of a call have correct value, the positive response RSP is sent for the instruction JUMP. The transmitting side considers the instruction JUMP executed after receiving response. o For response of an execution of the instruction CALL the instruction RETURN is sent. The instruction RETURN may contain the returned values. If there is an exception condition in a thread of control created by the CALL instruction, the instruction RSP with a non-zero basic return code is sent instead of RETURN.
For the positive response on the instruction MVCODE, the instruction ADDRESS, for negative - RSP with the non-zero basic return code is used. The code transferred on the instruction MVCODE, may be executed by the instruction JUMP or CALL.
The extension headers: _DATA - Contains an executable code. This header is present only, if the code does not contain in operands. The executable code is the transparent buffer with the binary data for the protocol. The format of this field is defined by the VM and it must contain all the information necessary for the loader VM of the addressee, including parameters of a call. The code must not simultaneously be sent in operands and in the extension header. The answer to the instruction MVRUN is formed similarly to instruction CALL. It is not necessary to release memory allocated for a code by this instruction. The memory must deallocate the VM.
section 7). 6]. As against RPC, UMSP allows immediately to address memory on remote nodes and to send the pointers in parameters and returned values. The UMSP object is identified by the 4-octet number. The values are divided into the following ranges: I -> %x00000000 - 1FFFFFFF are assigned for standard objects II -> %x20000000 - 3FFFFFFF are assigned for users objects III -> %x30000000 - 4FFFFFFF free IV -> %x50000000 - DFFFFFFF transient V -> %xE0000000 - FFFFFFFF reserved The objects from a range I must be definite, as standard, and the specifications of their interfaces must be published. The protocol does not suppose the private or not described interfaces of standard objects. The objects from a range II must be registered, but the specifications of their interfaces may be optional published. These numbers are applied in cases, when it is required to exclude the probable conflict of systems of the different manufacturers.
The range III can be used freely. The objects accessible on these numbers may be created statically or dynamically. These objects can have any interfaces. All objects, concerning ranges I, II and III, is common for all jobs on the node, including zero-session. Their interfaces are accessible to all tasks on the node, depending on parameters of authentication. The range IV is intended for objects created dynamically within the framework of one job. These objects are the isolated associative memory of the job. The access to these objects must be granted only for one job. The zero-session has no access to these objects. The protocol grants the access to the data of object, as to the continuous segment of memory. The memory of objects may be overlapping or no overlapping with flat local memory of the node. The offset field is used in the instructions of work with the data of object. The offset rules writing are similar to the local address rules writing. The address memory length of the node, definite for the UMSP protocol, limits the maximal data size of one object. The instructions definite in the given section, allow to work with associative memory with the theoretical limiting size on one node - 2^96 (7,9 * 10^28) Byte. In addition to the number, the object has the version, 2 octets length, and realization, 2 octets length. The protocol requires obligatory compatibility from bottom-up for all realizations of one version of object. The publication of new realization of standard object may contain only added interfaces. If for the sender of the instruction the version and/or the realization of object do not play any role or is unknown, the instruction may contain zero fields of the version and realization of object or only zero field of realization. The zero field of the version and non-zero field of realization are not allowed.
OPCODE = 192/193 ; For length of the field of length 2/4 octets. OPR_LENGTH = 3/4/5 ; Depends on length of the offset field. Operands: 4 octets: The number of object. 2 octets: The version of object. 2 octets: The realization of object. 2/4 octets: The length of the required data in octets. 2/4/8 octets: Offset required data from the beginning of object in bytes. At length of the length field of 2 octets the offset length must be 2 octets. In all other cases, length of the length field and offset length must be not less than 4 octets. The instruction DATA, containing the required data, is sent for reply to instruction OBJ_REQ_DATA. If the data cannot be transmitted, the instruction RSP from the non-zero basic return code comes back.
At length of a field of 2 octets offset the data length must be 2 octets. In all other cases the offset length must be not less than 4 octets and the data length is multiple to 4 octets. The response to the instruction OBJ_DATA_CMP is described in section 6.2.3. section 6.2.3.
Operands: 2 octets: The VM type of the sender. If OPCODE=202 this field is absent. 2 octets: The VM version of the sender. If OPCODE=202 this field is absent. 4 octets: The number of object. 2 octets: The version of object. 2 octets: The realization of object. 4 octets: The number of the called procedure. 4 - 262128 octets: Parameters of the call. The processing on the reception side is made similarly instructions CALL (see section 6.3.1). section 6.3.1). The names may have the procedures of the objects belonging to ranges III and IV. The procedures of the objects belonging to ranges I and II must not have a name on the UMSP layer. They must have the number only.
for deallocation of dynamic resources. The specified requirements impose essential restrictions on these objects. The protocol does not impose any restrictions on objects from the range IV. Unique key identifying object on node, is number of object. To objects from the ranges, III and IV the name may be assigned. The objects from range I and II must not have names on the UMSP layer. Within the framework of one task must not be two objects having one number or one name.
The zero values of the version and the realizations of object means, that the object have no these values. It is possible to register the name of object simultaneously with its creation. The name contains in the _NAME extension header. All objects created upon the instructions NEW and NEW_SYS must be obviously deleted. VM must automatically delete all dynamic objects, created and not deleted by the task, at the end of the task.
must have the unique names for all tasks on the node. The protocol allows receiving the number of object by the name and the name of object by the number.