Primitive Objects¶

Methods¶

The C standard library provides some basic mathematical routines to perform simple operations:

void function(){
        float a = -1.5f;
        float b = fabs(a);
        float c = floor(b);
        float d = sqrt(c);
}

Through the compatibility with C, these routines clearly remain available in Loci. However, Loci revamps the primitive types to be Object Types:

void function(){
        float a = -1.5f;
        float b = a.abs();
        float c = b.floor();
        float d = c.sqrt();
}

These modifications turn the primitive types into object types from the developer’s perspective, even though the implementation is identical to C and there is therefore no performance penalty.

Semantics¶

Syntactically, the change is quite significant, but there is also a considerable semantic difference since primitive references can be interface types, and primitives can satisfy template requirements that are based on their methods. Unlike C++, and surprisingly even Java, Loci provides a neat way to integrate primitives with other object types.

template <comparable T>
class PairSorter(T first, T second) {
        static create = default;

        const T& first() const noexcept {
                return @first;
        }

        const T& second() const noexcept {
                return @second;
        }

        void sort() {
                if (@first > @second) {
                        // Swaps the two values; usually developers
                        // would use std::swap.
                        T tmp = move @first;
                        @first = move @second;
                        @second = move tmp;
                }
        }
}

class UserType(int value) {
        static create = default;

        int value() const noexcept {
                return @value;
        }

        compare_result_t compare(const UserDefinedType& other) const noexcept {
                return @value.compare(other.value());
        }

        // Or just use:
        //
        // compare = default;
}

void exampleFunction() {
        auto intSorter = PairSorter<int>(3, 2);
        intSorter.sort();
        printf(C"intSorter: %d, %d\n", intSorter.first(), intSorter.second());

        auto userSorter = PairSorter<UserType>(UserType(40), UserType(50));
        userSorter.sort();
        printf(C"userSorter: %d, %d\n", intSorter.first().value(), intSorter.second().value());
}

intSorter: 2, 3
userSorter: 40, 50

interface IntAbs {
        int abs() const;
}

void polymorphicFunction(const IntAbs& value) {
        printf(C"abs() value: %d\n", value.abs());
}

void exampleFunction() {
        int i = -1;
        int j = 0;
        int k = 1;

        polymorphicFunction(i);
        polymorphicFunction(j);
        polymorphicFunction(k);
}

abs() value: 1
abs() value: 0
abs() value: 1

Extending Primitives¶

int int_t::add_to_self() const noexcept {
        return self + self;
}

int function(int i) {
        return i.add_to_self();
}

Implementation¶

When a primitive method is called, Semantic Analysis sees the call as equivalent to any other call. On the other hand, CodeGen specifically looks for calls to primitive methods and emits them as individual instructions (e.g. add).

For example:

int function(int i) {
        return i + i;
}

There’s a call to int_t::add here, with some syntactic sugar provided by Operator Overloading, meaning Semantic Analysis sees something like:

Function(
        name: function,
        returnType: int,
        parameterTypes: [ int ],
        parameterVars: [ i : int ],
        code: Scope(
                ReturnStatement(
                        value: FunctionCall(
                                function: method(
                                        name: int_t::add,
                                        context: Var(i)
                                ),
                                arguments: [ Var(i) ]
                        )
                )
        )
)

However CodeGen recognises calls to primitive methods and knows to emit something like the following:

define i32 @function(i32) {
        %1 = add i32 %0, i32 %0
        ret i32 %1
}

(It’s not entirely that simple, because CodeGen has to be prepared for modifications to variable ‘i’, and hence must emit an alloca which will then be optimised out later, but the point is that no function or function call is emitted for the primitive method.)

As shown above it’s possible to use primitive types in a polymorphic manner (i.e. cast references to primitives to references to interfaces), and in that case vtable generation will produce a vtable for the primitive types, which will then involve actually emitting methods for the primitive. These methods are marked ‘alwaysinline’ such that if optimisations later turn virtual calls to primitive methods into direct calls, they will also then inline the method and hence produce code exactly like the above.

However you choose to use primitives you can expect the underlying implementation to always emit the best possible code given the circumstances. For example, if you use Templates across a Module boundary and pass a primitive type as a template parameter, you can expect the resulting code to use stack-based autoboxing of the primitive values.

If you want to improve on this it’s strongly encouraged to use Link Time Optimisation (LTO i.e. link modules together and then optimise the result), which will most likely inline away the templates and hence give you code like the above that operates directly on the primitive type, at the expense of losing the API boundary (which may be required e.g. if you plan to deploy one module as a shared library).

See also:

• Compiler Design
• Dynamic Dispatch
• Template Generators
• Vtable Generation