Plain Assembly – Event triggers

I need to evolve my Event trigger mechanism.

Lets assume we want to control a robot with 2 electric motors – one left and one right. We are currently running forward with 1000 RPM and want to reverse with 10RPM.

Assign leftMotor.direction = reverse
Assign rightMotor.direction = reverse
Assign leftMotor.speed = 10
Assign rightMotor.speed=10

The issue is that as we make the first assign we also raise the event. This will cause the left motor to reverse at 1000RPM. The result is behaviour we did not intend during the update, so we need a mechanism that allow us to Control the event.

Object Motor
            uint32 direction
            uint32 speed
End

Event C OnCommand(Motor lm, Motor rm)

const Forward = 0
const Reverse = 1

Motor leftMotor,rightMotor

leftMotor.direction = forward
rightMotor.direction = forward
leftMotor.speed = 1000
rightMotor.speed=1000

Raise OnCommand(leftMotor, rightMotor)
...
leftMotor.direction = reverse
rightMotor.direction = reverse
leftMotor.speed = 10
rightMotor.speed=10

Raise OnCommand(leftMotor, rightMotor

“Event C” does in this example declare a C code event named “OnCommand” with 2 x Motor Objects as parameters. Rather than having event’s triggered automatically we raise them controlled. I have tried different syntax to do the same automatically, but I believe controlling this manually actually is a must.

The syntax is a draft – the usage of raise is in this example inconsistent With earlier examples, so I will need to work on that. I also notice that I forgot Assign on the assign statements – this was accidental, but I decided to leave it because I am considering dropping the need for Assign, Call and Raise in the Assembly syntax.

Plain VM – Distributed Processing

One of the key objectives with Plain is to support distributed systems. The mechanism to do so is at the core of the VM and this is one of the areas where the VM really makes sence.

We have already described objects – data structures that map into C code with Events. We have briefly mentioned that the same mechanism can be used to communicate with a different module – meaning that if you write to a register in one VM instance that becomes an event in a second VM instance – and the two modules communicate.

The beauty of this is that we can do that with easyIPC in the middle communicating between two Plain applications running on different devices – or even better between a C/C++, Java, C#, Python or any application with a easyIPC SDK and any Plain application.

The beauty about it is that it requires close to no extra coding except mapping up events. I need to work on adding syntax to support this, but it will work.

Plain Assembly – Data types

The VM is designed to control logic so everything is mapped into a 32 bit virtual register for simplicity. The assembly language support a large range of data types, but the VM will by default treat everything as a 32 bit register to keep it simple and fast.

The assembly language do however support a range of data-types:

Bit A single bit data-type that can be used to create bit-fields. Used in math it is treated as an unsigned integer.
Byte A byte is 8 bits.
Uint16 An unsigned 16 bit integer.
Int16 A signed 16 bit integer.
Uint32 An unsigned 32 bit integer.
Int32 A signed 32 bit integer.
Float32 A 32 bit floating point.
String A text string.
bool A boolean value that can be true or false.
Object Data structure used to create data-types based on existing data-types.
Enum A data-type that only allow a of constant values.

Arrays are supported for all data-types by adding [] after the variable name. Operations can use ranges as a[0..9].

Adding “packed” to a Object will force it to be bit-packed. This is designed to allow the VM to encode/decode bit-packed Messages etc.

As for other data-types we could also support double64, uint64 etc.

Plain Assembly – End

I just realized that I probably can optimize the assembly a little by introducing “End” as a single entry instruction. The reason is because we now use goto that are 2 entries. I can avoid the 2. entry by using the stack.

for x=1 to 10  
            nop
end

As “for” is an instruction it can create a ix to itself on the stack and as we reach “end” we treat that as a “goto ix”. The upside of this is that we suddenly have a 1:1 between assembly and actual instructions. I also believe this will be faster than using a goto – not that it matters.

if A = 1
            nop
elsif A=2
            nop
else
            nop
end

In this example we introduce “end” to replace the goto’s we only need to insert the ix for the next instruction located after “end”. in this case we would save 3 entries and be down to 10 + 3. The rule here need to be that we insert the ix if we execute the true block. The irony in this example is that we insert “end” before elsif and else, but not at the end statement.

So in short assembly that require a end will insert a ix on the stack that is removed by end as it jump to this location.

Plain Assembly – bloating factor

I will need to look more into the examples and high- and low-level syntax later, but I basically want the assembler to be almost a 3. generation language. What I will do next is to revisit the instruction set to see if we can improve this a bit. Looking at the previous examples I get the following number of 16 bit instructions used:

If example 12
For example 8
Assign example 9
While example 15
Loop example 2
Exit 1
Raise 10
Call 10
Return 1
Encode 4
Decode 4

This is not exact math, but this was 21 lines of high level code that caused 76 x 16 bit entries in our instruction array – and ca 23 actual instructions. Using that as an indication we can expect as many instructions as we have code lines and an average of < 4 x 16 bit entries per code line.

This means that I can expect a 50 line program to be ca 200 entries in an instruction array (or 400 bytes if you like). I need to analyze an actual module with data and map usage to verify this. This number will improve since data and mapping don’t create instructions.

Plain Assembly examples

I used a bit of space on If, so I will just quickly draft the rest of the instructions in High Level Assembly syntax and Low Level Assembly syntax assuing I need both – we can discuss the draft and possible changes later.

For loop

for A=1 to 10 step 1
            nop
end

Low Level Assembly:

start     for A=1 to 10 step 1, next end1
            nop
            goto start
end1

The for statement is 6 x 16 bit entries + 2 for the goto – 8 entries.

Assign statement

Assign is will parse an expression and create an executable table that compute that expression and store the result in a register run-time. This is expected to bloat a bit.

Assign A = B + C / D

The parser will convert this into an instruction consisting of op-code and an array of math intructions as follows:

op-code
R1=C/D 
A=B+R1

 Each table entry will take between 3-4 16 bit entries, meaning that the Assign is 7-9 entries in binary code. I will be more exact on this as I dig up some old code on this.

Low level assembly would be as follows:

             Assign R1=C/D, A=B+R1

While loop

A while loop contains an Expression that need an assign statement

While A+B/C > 1
            NOP
End

Low level Assemby example:

 while   Assign R1 = A+B/C
            ifgt R1, 1 next end
            nop
            goto while
end

 Loop statement

Not sure this adds any value, but it is a way to avoid writing goto. We can always remove it later.

High level assembly example

loop
            nop
end

Low Level assembly example

loop1   nop

            goto loop1

Exit

Exit is a single 16 bit instruction that terminate the module execution.

Raise & Call statements

These are identical in syntax, but with a different op-code since Raise do not create a return and Call does. Using Raise on a module is the same as exit with parameters.

High level assembly example

Raise Error(A1, A+B, C)
	or
Call MyFunc(A1, A+B, C)

Low Level assembly example

The assembly need to use assign to compute expressions into a list of registers that can be used as parameters.

Assign R1=A+B
Raise Error (A1, R1, C)

or

Assign R1=A+B
Call Myfunc (A1, R1, C)

Assign will in this case use 1 + 4 =5 entries. The Call/Raise will use 1 op-code + one for instruction to call and 3 for parameters = 5, so they do in effect use 10 x 16 bit entries.

Switch

Looking at the assembly I ditched switch for now!

Return

Single entry instruction.

Encode/Decode

Encode/Decode is intended for bit manipulation. Decode will read a bit and convert it into a 32 bit register, encode will read the register and write the bit Field.

Encode A:4:2 = B
Decode B = A:4:2

These are low level instructions using 4 entries each.

 

 

Plain Assembly example – IF

The list of instructions will need to be extended With low level stuff as I mature the VM and implement it, but lets start writing some code and assemble it into actual instruction. I need to do this for every instruction and Assembly trick we use – lets start with IF..ElseIf..Else..End!

Ifeg, ifneq, ifgt, ifls, ifgte and iflse are all instructions that that use 1 x 16 bit for the op-code , and 2 x 16 bit register values for values that needs to be compared. It will in addition need 1×16 for an goto false. If itself is NOT an instruction in this design as we use the Assembler to convert this into an Assign combined With one of the other instructions.

ElseElseIf and End are Assembler abstractions.

If A = 1
            NOP
ElseIf A=2
            NOP
Else
            NOP
End

The small example above implement a classic If..Elsif..Else..End as we know it from 3. generation Languages. I use NOP since it is a single 16 bit register op-code- easy to count. Let us look at the 16 bit instruction array:

1 IF A = 1 < ifeq op code>
2 < A register index>
3 < 1 register index
4 < next instruction index is 8>
5    NOP < nop opcode>
6 < goto opcode>
7 < goto instruction is 16>
8 Elsif A=2 < ifeq op code>
9 < A register index>
10 < 2 register index>
11 < next instruction if false is 15>
12    NOP < nop opcode>
13 < goto opcode>
14 < goto instruction is 16>
15 Else < nop opcode>
16 End

This produced a 15 x 16 binary code – 12 of these are code generated from our if statements. One consequence is that I needed to re-introduce the goto instruction.

My main concern with the example above is that I start removing myself too much from an instruction by instruction assembly. This creates a challenge as I want to disassembly the previous code. I would in reality need something like this :

Start IFEQ A,1, next elseif1 4
NOP 1
Goto end 2
Elseif1 Ifeq A,2, next else1 4
Nop 1
Goto end 2
Else1 Nop 1
End

I have done object oriented VM’s earlier – the IF on that was an array with sub-trees for expressions and sub-code. The entire if..elseif..else was a single instruction. This VM is different and closer to machine code. It don’t give the same effect – that said it was no way I could execute this on 15×16 bit using the OO one. Also the OO needs dynamic memory so it is not an option to use that design here.

The conclusion (for now) is that I extend my assembly to include “Next” on IFEQ etc and also add the GOTO and associated Label. The drawback is that we are getting to close to actual ARM assembly for my taste. I will continue on other examples and see if I get a better idea/syntax Down the line.

VM – Instructions

NOP No Operation. Used for test and to cover the 0 op-code.
For FOR Loop
Assign Assign operation. Takes an Expression and generate a Math calculation or logical evaluation.
While WHILE Loop
Loop Generic Loop
Exit  Terminate a process
Raise Raise an event. The same as calling a function without creating a stack Return entry.
Call Call a function and create a stack Return entry. A function can be PLAIN or C/C++ function.
Ifeq, Ifneq, Ifgt, Ifls, Ifgte, Iflse If statements. If takes an Expression and insert a Assign instruction to evaluate the Expression. All other compare two registers.
Switch Switch. Jump to one of many positions using a table.
Return Return from a Call.
Encode Encode a bit Field.
Decode Decode a bit Field.

32 x Servo/IO Hat

32xIOHat

New 3D model showing the right angle connectors and the updated “Servo” that now is renamed to 32 x IO Hat. I have done some mechanical changes and added a lot of protection electronics. As mentioned earlier this is my test ground for the VM and each channel have multiple capabilities – hence the “IO” rather than Servo.

  • 32 channel Servo Controller
  • 32 channel digital in
  • 32 channel digital out
  • 32 channel low resolution PWM
  • 2 channel analogue out
  • 12 channel analogue in
  • or any combination of the above

I have three Hat’s that will stack nicely

  • 16/32 channel IO (shown here)
  • 8x H-Bridge + 8 x IO
  • 5 port RS-485/CAN

I do in addition have the 7 x Stepper, but I am not happy with the connectors on that one. The 28BYJ-48 stepper motors comes with a 5-pin connector that is nice and exist as right-angle, but I can only manage 3 of these in stacked position – To be honest I am considering ditching this Hat design.

As we move forward I will add more hat’s and more distributed sensors and controllers to allow larger and more complex systems to be created. I want to create a few robots + I want to automate my home for the fun of it. But, all of this is worthless without an easier way to apply Distributed logic so I will continue to dig into the PLAIN concept for now.

VM-Event

I did earlier create named Event’s that could be called with a Raise statement. The last example created an Event digitalIn[2] where the “name” is a declared object register and the event is automatically called if C or PLAIN assembly changes that exact bit.

Event digitalIn[2]
            // ...
End

 I like the concept, of Automatic events, but I need to let the syntax mature a little. Is this event to be called before or after we change the bit? Is it to be called only on Write or also on Read? And what about parameters?

Event DI() On digitalIn[2..3]
            // 
End

The modified syntax above name the event to enable it to be raised or called, and it add the On keyword to allow allocation of automatic events.

Event DI() on digitalIn[2..3] After Write
            // 
End

This add the syntax After|Before Read|Write allowing us to control how it is called. Adding parameters is also straight forward since we have a name and a (). Parameters will either be the same as declared in the C implementation or none at all – need to work on this part.

Event On Ch4.AnalogueIn
            //
End

 The event above is however a challenge because it is connected to an ADC that very well might be sampled at 2.4Mhz. Any attempt on calling an event at that frequency will overload our MCU, so we need a buffer mechanism if we actually want to sample this fast, or add a filter on the ADC. A filter in this case is a max frequency and a threshold requiring a minimum change before it is raised as an event. These capabilities needs to be added to the C interface – I don’t think I want to control this on the Event declaration – not sure.