5. Concrete protocol

An Interpreter defines a concrete protocol which maps from the numeric value of byte codes (produced by a Compiler and stored in a Method) to an ordered set of functions defined in C++ which implement a (hopefully minimal) set of well known functions on those objects. Many concrete protocols are possible, but ColdStore natively provides the C-- Concrete Protocol in support of the C-- language.

Other concrete protocols can be used to map other interpreted bytecodes (e.g. Python, Java) to a set of interface functions which provide their functionality in terms of the underlying functionality provided by the Virtual Protocol.

5.1 C-- Concrete Protocol

C-- is a language which is modelled roughly on C++, and treated in detail elsewhere.

A Concrete Protocol is defined here which is sufficient to permit a byte code to be interpreted relative to a stack, to provide functionality defined by the C-- language, and translated by the C-- compiler.

5.2 C-- Object Operators

5.3 C-- Language Functions

Stack Functions

Slot pop(Error *&, size_t n=1)

Pops n items from the top of stack.

Slot push(Error *&, Slot)

Pushes 1 item onto stack.

Slot dup(Error *&)

Duplicates the top of the stack.

Slot rot(Error *&)

Swaps top() and under() on stack.

Slot top(Error *&)

Non-destructively returns the top of stack.

Slot under(Error *&)

Non-destructively returns the element under the top of stack.

Frame Functions

Complex stack operations are used to modulate the stack, and constrain its Segment endpoints to a subsegment of the whole stack, which then becomes inaccessable via the normal accessor/mutators.

• A current Frame index is maintained by the Frame object, relative to which index arguments, and return values, start. The Frame index can be pushed using startFrame and popped using endFrame.
• The current Stack endpoints are held in the implementation's List start property, and effectively constrain stack indices to be relative to the current start of stack. The Stack index can be pushed using pushFrame and popped using popFrame.

Generally, interpretation of an opcode will commence with a startFrame and end with an endFrame. When direct stack access by untrusted code is necessary, the start/endFrame can enclose a push/popFrame. These enforce the limits implied by the frame.

In interpreting object.fn(arg1,arg2,arg3), the compiler would emit a startFrame, then code to evaluate arg1..arg3, then code to evaluate the expression fn, then code to evaluate the expression object. It would then emit a pushFrame, arrange for the calling of object.fn, then a Method->retMethod to clean up the Method args, then a popFrame to remove constraints, and finally an endFrame to incorporate the function results back into the calling stack frame.

The frame index is intended to cope with the nesting of grouping operators like [] and (). The pushing and popping of frames is intended to be a scope-restriction device, preventing access by lower stackframes to the contents of enclosing stack frames.

All stack indices are interpreted relative to the current start of stack. The current start of stack is, however, an absolute index relative to the allocation Segment of the implementing Vector or List.