Instruction Set

VOOM instructions are implementations of TOOL methods as described in section 3.2.2. VOOM instructions follow the same divisions as TOOL with the addition of explicit object support instructions (send, release, etc., implicit in TOOL). Primitive methods are simple implementations of logical and arithmetic functions. Built-in methods are complex instructions and are implemented as permanently stored routine codes. User-defined methods are responsible for object-oriented process activation and require special architectural design of queues, memory controllers and communication handlers.

Primitive methods in VOOM are represented by the same equivalent listing in TOOL. Arithmetic, logic, relational and memory operations are simply implemented by datapath operations involving the arguments of these messages. The messages are translated into VOOM instructions with one or two operands, and the result is returned to the accumulator (%1) or stored into a register or instance variable position in the object (STORE).

Control methods enable modifications in the instruction flow and operate on the program counter, testing the accumulator. The program counter points sequentially to instructions until a validated branching condition sets it to the value indicated by the argument. The RTN instruction can explicitly terminate the process, and/or just send a return message. If RTN terminates the process, the input message is scraped and the object is returned to main store, freeing the cache. When sending a reply message, RTN will fill in the link field with the sender field of the input message. This enables the system to track down and reactivate the suspended message waiting for this reply.

Apart from branching function, control methods are overloaded with process suspension facilities. Any control instruction other than RTN can implicitly suspend a process, if time slicing is required. When the execution is suspended, the input message is packed to the back of the inactive queue and a link to it is stamped in an outgoing message. This is a self reactivating message that restart the method to the interrupted state or to another state specified by a residual instruction.

Residual instructions are those that do not result in an immediate action, but set a state in the object. The residual instruction in VOOM is the SELECT method. SELECT modifies the mask field in the object header, establishing a pattern to be matched by reactivating messages. Apart from filtering messages, this residual instruction can force the method to resume at a different location than that expected at the moment of the suspension. This instruction is dedicated to the support of object-driven computational flow control.

Built-in instructions are dedicated to object management. Some object management functions can be highly complex and involve the description of non­ trivial algorithms. Here, a very brief description will be given, but further reference can be found in [Balou91J. The NEW method creates a copy of a template object

and packs it in a frozen message format. The identification is obtained from a system object reference allocator. The DELETE method will return the identification of the deleted object to the reference allocator for recycling.

REPLACE will use a frozen message to overwrite an existing object or method. REBIND will change the original allocation of objects. Messages will be relayed to the new destination by a shadow image of the object in its former node, until the reference allocator eliminates it, effectively rebinding the references in the original senders. REVIVE will just provide a context message for the reactivation of dead body method. This context message has a user format with an empty body.

User-defined messages are characterised in VOOM by the implicit generation of an explicit SEND instruction, inexistent in TOOL. Normally, this instruction builds up a message with user format. The two operands of this instruction are used to fill in the first and second records of the user message header, that are informations about the method. The destination object identification should be loaded previously to the SEND instruction. The object reference is normally retrieved through indirect access to the declared information stored in the object state. The body of the message is copied from whatever is in the % registers.

The SEND instruction is available in two basic modes: synchronous and asynchronous. Both modes associate the sender field in the message with the current context identification. This allows replies to both modes, but in the case of the asynchronous mode the reply will come through a future suspension of the method.

The synchronous variation will suspend the method immediately and all the protocol described in a branch suspension will take place. The difference is now that the reactivation message will be generated by another object. The whole mechanics of user messages depends on the cooperative activities of the three VOOM units, storing, transferring, binding and prefetching objects and methods for execution. A more detailed description of VOOM, explaining the role of each unit and discussing the architectural issues can be found in [Balou91].