CARBAYONIA ABSTRACT MACHINE

 

The overall architecture and instruction set of the Carbayonia abstract machine, which is the substrate of the SO4 operating system and the Integral OO System Oviedo3 is briefly described here.

Being an experimental research system, the instruction set, language and basic classes of the machine are not final, and subject to changes and evolution. Different prototypes exploring different research lines, while based on this same basic machine, can have different extensions and changes.

The following prototypes do exist:

  • The basic machine, which is the one mainly described here.

  • Persistence. Added persistent classes and basic classes for reflective directories, and a transparent persistent paging mechanism.

  • Protection. An extended machine with protection (added one instruction and some basic classes for testing purposes).

  • Distribution. Using a meta-object protocol, distribution capabilities have been added to the initial prototype.

  • Adaptable Concurrency and Computational Model based on Reflection.

Furthermore, and based on the experience of using reflection as a property of the machine to get flexible systems, a new machine designed from the ground up with computational reflection capabilities is being built (here, you can find more information).

 

Architecture of the Oviedo3 System: OO Abstract Machine extended by an OS

The common object model for the system intentionally follows the object model of the most popular OO methodologies. The goal is to take advantage of well-established OO concepts as well as carrying all the semantics of the object model (used in analysis and design phases) all the way to the implementation phase. The features the model includes are:

  • Unique object identity (used by references)

  • Encapsulation (object access only through methods)

  • Classes (which are also used to derive types)

  • Multiple inheritance (is-a) relationships

  • Aggregation (is-part-of) relationships

  • General association (related-to) relationships

  • Polymorphism and type checking including run-time checking

  • Exceptions

  • Concurrency

  • Persistence

  • Distribution and

  • Protection

 

The structure of the Carbayonia abstract machine

As in machines such as the Java Virtual Machine (JVM), actions upon objects are made by means of references (which also have a type) to them, never directly. Figure 1 shows the logical areas in which the machine is divided, which store classes (base classes are implemented primitively), instances and references. There is also a set of system references with specific functions.


Figure 1: Carbayonia Abstract Machine Architecture.

Principles of design for the machine

  • Raise of abstraction level with a pure high level OO instruction interface. The level of abstraction is raised homogeneously to the level of object orientation.

  • Reduced instruction set. Contrary to the Java Virtual Machine (JVM) and more like the initial spirit of the Smalltalk machine, the instruction set is reduced to the minimum necessary to express OO concepts. The instruction set provides declarative instructions that describe classes, constructed upon aggregate references (objects) and associated ones; and behavioural instructions for the body of the methods:

    • Method call (through references) and return.

    • Flow control: conditional and unconditional branches, and exception handling also.

    • Object management through references: creation and deletion of objects and references assignment.

  • Abstraction levels are not mixed. There is only one kind of objects, with no special primitive data types as in the JVM. The interface does not prescribe low level implementation structures such as a stack.

This has two benefits related to implementation. Firstly, implementations of the machine are easy to develop, as the machine and its instructions are kept very simple. Secondly, different optimisation and implementation techniques can be made under the level of the instruction set, with no externally imposed constraints, and without breaking existing applications.

 

Instruction Set: The Carbayón Language

The instruction set is very high-level, and independent of any internal implementation structure. It is expressed by means of an "assembler" language called Carbayón. The machine uses a compact description of "programs" written in this language (bytecode).

The unit of description is the class, which is used for structure (class declaration) and for behaviour (methods).

Declarative instructions. Class definition.

Class name, inheritance, aggregation, and generic relationships have to be defined, as well as methods. The pattern is:

Class Name
  Isa {Class}
  Aggregation {Name: Class;}
  Association {Name: Class;}
  Methods
    {Name ([{Class}])[:Class] }
EndClass

This diagram:


Figure 2: An UML Class Diagram.

will be expressed as

  Class Flower Isa Object
  Aggregation
    myStem: Stem;
  Association
    thePot: Pot;
  Methods
    flourish(Hour, Amplitude): Fragance;
    cut(Height);
  EndClass

  Class Rose Isa Flower
  Methods
    flourish(Hour, Amplitude): Fragance;
    decoreVase(Vase);
  EndClass

  Class Carnation Isa Flower
  Methods
    flourish(Hour, Amplitude): Fragance;
    decoreSuit(Suit);
  EndClass

The semantics of aggregation mean that aggregated references point to objects that are created upon creation of enclosing object. Aggregated objects can not be deleted independently and are deleted when the enclosing object is deleted.

The semantics of association means that associated references do not initially point to any object, and it is the responsibility of the programmer to assign objects to this references.

Properties of Classes in Carbayonia

  • "Virtual" inheritance. Attributes from the superclasses are not just copied into class instances. An instance is represented by an instance graph keeping inheritance relations between nodes.

  • Multiple inheritance. Clashes are solved by using declaration order.

  • Exclusive use of methods. No operator overload do exist (as in 5+6, 5.add(6) would be used).

  • Exclusive use of dynamic binding.

  • No method scope. Method visibility (public, private, etc.) is not part of the model, and should be enforced by the compiler. The generic protection mechanism is more general and could be used for this if needed.

  • No constructors or destructors. Again it is delegated to language compilers (aggregation semantics are kept by the machine, though).

  • No method overloading. Just redefinition (overriding) is provided. Overloading could be easily implemented by language compilers (as Java).

 

Behavioural instructions. Method definition.

Behaviour is specified by defining methods, including the header (name, parameters and local references), and the body (a sequence of behavioural instructions).

The pattern is:

  Name ([{Class}])[:Class]
  [Refs {Name:Class};]
  [Instances {Name:Class};]
  Code
    Body
  EndCode

Refs (local references)

Local references are created upon method enter, and always have a type. They are used in the body to create, invoke and delete objects. Refs are not initially assigned to any object (free references).

Refs are deleted upon method exit. Objects created using Refs are not deleted upon method exit.

  Refs
    i: Integer;
    b: ClassB;

Instances

Instance references are managed by the machine. Objects for the Instances references are created automatically upon method enter and deleted upon method exit.

There is a special syntax to initialize objects from basic classes.

  Instances
    i: Integer(10);
    f: Float(3,5);
    s: String('This is a string');

Code

Body instructions end in ";", with a reduced set of less than 15 instructions.

 

Behavioural Instruction Set

Managing of objects through references.

There are instructions for linking references to objects (object creation and assigning), and for invoking methods and deleting objects.

Object creation:  New Ref

  • Creates an object of the type of the reference and points the reference to it.

  • An exception is thrown if creation can not be accomplished.

  • Aggregated objects are created.

  • Associated references are initially free (New can be applied upon them).

  • Instances of classes not known at compilation time can also be created.

Reference assignment:   Assign targetRef, sourceRef

  • TargetRef points to the same instance as sourceRef.

  • Parameter references are automatically assigned to object arguments.

  • An exception is thrown if target is not compatible.

  • Run time typecasting is used.

Method invocation:   Reference.[Scope:]Method({Reference})[:Reference]

  • Fundamental operation upon objects that is the main instruction used in method bodies.

  • Reference to object to invoke, method, parameters, reference to object that collects the returned object.

Encapsulation

  • The internal state of an object (enclosed aggregates and associates) can only be done by means of methods.

  • The actual object can be accessed using a self reference called this (this.myMethod(a, b);)

Object deletion:   Delete reference

  • Deletes the object pointed by the reference.

  • An exception is thrown if the reference is free, the object pointed was already deleted or deleting an aggregated is intended.

Flow Control.

Method exit:   exit

  • Local references and Instances objects are deleted.

  • The returning value may be assigned to the "rr" reference.
      assign rr,reference;
      exit;

Inconditional jump:   jmp label

Conditional jump

  • Conditionally jump depending on the result of a comparison.

  • JT refBool, label;
      Comparison with a boolean object; jumps if it is true.

  • JF refBool, label;
      Comparison with a boolean object; jumps if it is false.

  • JTD refBool, label;
      Compares and deletes a boolean object; jumps if it is true.

  • JFD refBool, label;
      Compares and deletes a boolean object; jumps if it is false.

  • JNull refBool, label;
      Jumps if the reference is null.

  • JNNull refBool, label;
      Jumps if the reference is not null.

Exceptions:   Handler label;  ...  Throw;

  • Ease debugging and maintenance, with a more robust user programming. Run Time Type Information helps instructions detect incorrect use throwing exceptions.

  • Handler specifies where to continue execution upon an exception throw (exception handler)

  • Throw throws an exception (a reference called exc is used to hold a throwed object that can be used to explain the exception)

Example Method:

  // insert: inserts a reference into a list
  insert (ob:Object)
  Refs
    nodo, tmp:nodoDoble;
  Instances
    one:Integer(1);
  Code
    num.add(one);
    New node;
    node.setData(ob);
    JNull current, emptyList;

    // There are elements left
    node.setLeft (current);
    current.getRight(): tmp;
    node.setRight(tmp);
    current.setRight(node);
    tmp.setLeft(node);
    Assign current, node;
    Exit;

    emptyList: // No elements left
    Assign current, node;
    current.setLeft(current);
    current.setRight(current);
    Exit;
  EndCode

 

Basic Classes

They are always present (conceptually) in the classes area of the machine, and are the basic blocks for the construction of user classes. A user class is created using other aggregated and associated classes, which, in turn are created using other classes, etc. This recursion ends when arriving at basic classes.

However, from a user point of view, they are no different from any other classes.

The root of the class hierarchy is the Object class.

There are currently basic classes for booleans, integers, floats, strings and arrays. Other basic classes could be added for development and test reasons.

Object

  Class Object
  Methods
    getClass(): String; //Name of my class
    getID(): Integer; //My ID
    isa(String): Bool; //Am I compatible with this class?
  EndClass

Bool

  Class Bool
  Methods
    setTrue();
    setFalse();
    and(Bool);
    or(Bool);
    not();
    xor(Bool);
  EndClass

Integer

  Class Integer
  Methods
    add(Integer); //add myself to other integer
    sub(Integer);
    mul(Integer);
    div(Integer);
    set(Integer); //Initialize to an integer
    setF(Float); //Initialize to a float
    equal(Integer): Bool; //Am I equal?
    greater(Integer): Bool;
    less(Integer): Bool;
  EndClass

Float

  Class Float
  Methods
    add(Float);
    sub(Float);
    mul(Float);
    div(Float);
    set(Float);
    setI(Integer);
    equal(Float):Bool;
    greater(Float):Bool;
    less(Float):Bool;
  EndClass

String

  Class String
  Methods
    set(String);
    setI(Integer); //Init with an integer
    length(): Integer;
    get(Integer,Integer): String; // Gets substring
    insert(String,Integer); //Inserts substring
    delete(Integer, Integer); //Deletes substring
    getChar(Integer): Integer; setChar(Integer,Integer);
    equal(String): Bool;
    greater(String): Bool;
  EndClassless(String): Bool;

Array

  Class Array
  Methods
    setSize(Integer); //Change array size
    getSize(): Integer;
    setRef(Integer,Object); //Insert at position
    getRef(Integer): Object; //Get object at position
  EndClass

Array implements a vector of references (objects). The size of the array can be dynamically changed.

 

Transitory Elements of the Machine

Additional functionality for the integral object oriented system such as Input/Output and concurrency would be provided for an operating system built upon the machine. However, the machine as described would not be useful until the OS were finished. So some transitory support for this elements was built into the machine. This would probably be an area where future changes would be made (as it indeed happened).

The intended phases in the development of the machine are depicted in this figure:


Figure 3: Develoment of the Carbayonia Abstract Machine.

Information about these transitory elements can be found in the respective documents cited at the beginning. For example, classes for concurrency (Semaphore) and I/O (Stream, ConStream, FileStream) are described in the documentation for the basic prototype.

The situation as of beginning of 2001 is as described in the before-mentioned documents, prior to the development of a final consolidated version. However, we are considering the possibility of using a new reflective machine that is being developed with the insight gained while building the Carbayonia Abstract Machine.

 

See Also