Design of sxgo

Sxgo constists of a core emulator library, a graphical UI and, alternatively, a set of Python bindings. This page describes the design of the core emulator. The implementation of this emulator revolves around a few main ideas:

• a class that emulates the state of an SX, with member functions for each SX instruction.
• a meta-programmed list of instructions
• using meta programming to create a binary decision tree of those instructions for use in an instruction decoder.
• precompilation of instructions into 'function pointers'.

I presume that the reader is familiar with the C++ programming language. Note that sxgo makes use of Template metaprogramming wherever suitable. Readers that are not familiar with MP may want to look through some of the examples in the wikipedia link...

Instruction Implementation

implementation of the SX emulator

The idea is to have one class that consists of an SX 'state' (ram, rom, special registers, program counter) and that implements the instruction set. See the snippet (of file sx_controller.hpp)below:

<source lang="cpp">

struct clr_fr { /*...*/ }; struct clr_w { /*...*/ }; struct mov_w_not_fr { /*...*/ }; // etc...

struct sx_controller_impl {

   // snip...
   // note that this is simplified source code, this does not set any 
   // flags yet.
   void execute( const clr_fr &, int arg_register)
   {
   	ram( arg_register) = 0;
   }

   void execute( const clr_w &)
   {
   	w = 0;
   }

   void execute( const mov_w_not_fr &, int arg_register)
   {
   	w = ~ram( arg_register);
   }

   // etc...

}; </source>

In C++ terms, this means that an implementation of the SX instruction set needs to model the Concept of SXImplementation. Where (informally) the concept of SXImplementation is any class that implements one of the following member functions for each of the tags that are in the SX instruction set. <source lang="cpp"> void execute( const tag &); void execute( const tag &, int arg); void execute( const tag &, int arg, int arg); </source> This concept is important, because as we shall see there are more models of this concept ('implementations of this interface') than just the sx emulator itself. We shall see that any class that models this concept can be used as the target of an instruction decoder, so that we can feed SX instruction words to a decoder and the decoder will call the correct overload of the execute function for such a class.

Alternative instruction implementations

Once we've decided the interface for SX instruction implementations, it becomes relatively easy to make different implementations. Sxgo defines several implementations, such as one implementation that does nothing more than return a string representation of the instructions (a disassembler), or one that 'compiles' instructions into a representation that will execute faster (a precompiler). All of these implementations can be fed through a single instruction decoder implementation.

Instruction set

Defining the SX instruction set boils down to two task: describing each SX instruction, specifically their bit patterns, and secondly compiling those instruction descriptions into a list of all SX instructions.

Instruction definitions

As could be seen in the previous Section, the implementation of the sx instruction set was all in terms of an execute method that is overloaded for several types, each type representing one instruction. Defining the instruction set becomes therefore a matter of defining a set of types, one for each instruction. These are the instruction tag types and the execute method is similar to a technique called tag dispatching.

In order to facilitate instruction decoding, the instruction types will be enhanced with information about their bit-patterns. This is in contrast with normal tag dispatching, where the tag types are completely empty types. The instruction list for sxgo can be found in sx_instruction_list.hpp and has the following form: <source lang="cpp"> // ... // define some operand (argument) types. struct register_ : masked_argument< 000011111> {}; struct bit_ : masked_argument< 011100000> {};

// ... // define some instruction word patterns struct clr_w : word< 000001000000> {}; struct add_w_fr : word< 0001110, register_> {}; struct sb_fr_bit : word< 0111 , register_, bit_> {};

// ... </source>

The code above encodes the following information:

operands (masked_argument<...>)

The code shows two operand types (there are more). In an SX microcontroller, operands are always encoded in the same position, registers are encoded in the least significant 5 bits of the instruction word and bit-positions (0-7) are encoded in bits 5, 6 and 7 of an instruction word.

word bit patterns (word<...>)

As can be seen above, the clr w instruction takes no arguments and is recognized by the bit-pattern "000001000000" (SX instructions are always 12 bit words). The add w, fr instruction takes one argument (the register, or ram location where the value can be found to add to the w register). Finally, the sb fr.bit instruction (set a single bit in a ram location) takes an 'fr' argument (the ram location) and a bit number. Note also that, although the bit number is more to the 'left' in the instruction word, the register argument is mentioned first for this instruction word.

Another way of describing this is, that the sb_fr_bit instruction codes an instruction word that looks like this: 0111bbbrrrrr, where