Computer code is very linear. It was designed for a single CPU to follow a list of instructions. Like a single track railway for only one train.

… if you don’t feel like reading this, here’s a video about it.

It’s also designed for humans. We communicate to computers via languages. Language is a single stream of information and it’s perfectly natural for us to have developed this method of communication with computers.

However, modern computers contain multiple CPUs and unless the software is specifically written to use more than one, most programs will only run on a single CPU. The end result is that most programs run no faster on the latest hardware than they did ten years ago. Moore’s law has failed at the application level.

Writing code for multiple CPUs is difficult and introduces a lot of complexity. As a result, most developers avoid it if they can. The problem is that multi-threading does not fit into the paradigm of language. It would be like describing an electronic circuit with nothing but words. It can be be done, but it’s so much easier drawing a diagram.

It may not mean much to the layman, but any electronics engineer will immediately be able to ascertain the function of a simple oscillator.

When organising large projects involving many people, project managers use Gantt charts. We use charts and diagrams for pretty much any complex design… except programming.

Admittedly, there have been many attempts to create such systems, but they are often specialised or limited. I wanted to create a system that, like traditional languages, could be used at low level and expanded infinitely to create complex functionality that could easily be integrated into any program.

I wanted it to address all of the issues that are now becoming apparent in the software industry: complexity; internationalisation; massively multi-threaded; portable across CPU architectures; truly customisable software; immune from the update wars. So I created KonneX.

KonneX works on the principle of a rail network system, delivering goods and products, to and from factories. Virtual CPUs carry their payloads from point to point, being created and destroyed according to demand.

The following image was created for a demonstration of a simple robot.

Each box represents a function. These boxes can have multiple inputs, like the arguments and parameters of conventional software functions. However, unlike conventional languages, each function can have multiple exits. These exits can alter the execution path in a similar manner to the if, case or switch keywords found in most programming languages. They are also used for errors that may or may not be trapped, according to the programmer’s choice.

From left to right, the program starts at the black dot with cyan border. The colours represent datatype. In this instance , black/cyan is the pointer to the robot data structure.

The data path splits three ways, creating three virtual CPUs (VCPUs) each with a copy of the pointer to the robot data structure. They travel simultaneously down the three tracks. The top and bottom path both reach small triangles. These are buffers, temporary stores of data, where the VCPUs die. The middle path reaches the box marked “Read Distance”. This is a previously defined function to read the distance from the robot’s ultrasonics. This function exits with a distance measurement, the data path turns blue to indicate that it now carries a numerical value. This then travels to the next box which compares the distance read to the pre-defined value “TooCloseCm”. There are three possible outcomes from this comparison. The distance could be greater, equal or less. If the distance is greater, the VCPU follows the top output up towards the upper of the two aforementioned triangles. It picks up the stored pointer and takes it to the next function which moves the robot forward one step. When complete, the virtual CPU heads for the exit and the function is complete.

If, on the other hand, the robot finds itself too close to an object, the VCPU heads down to the lower triangle, picks up the pointer and then creates two more VCPUs when the path splits again into three.

One VCPU heads off to the box marked “Turn to Opening”. This function requires two inputs, but has only received one, so the VCPU dies, leaving its pointer behind. The lower of these three new paths, goes to another triangle (buffer) stores the pointer and dies. The last one goes to the “Find Opening” functions which scans the robot’s ultrasonics back and forth looking for an exit. This function returns the angle of an opening, should it find one (the upper, blue output), or if it cannot find a suitable opening, reports an error through the lower black output.

If a suitable opening is located, the angle (as a numerical value depicted by the blue data path) the VCPU takes this value to the function “Turn to Opening”, where it picks up the previously dropped pointer and executes this function, before exiting.

Finally, should no suitable escape could be found for the robot, the VCPU exits though the lower (black) output, picks up the pointer from the buffer and executes the “Reverse and Turn” function, which sends the robot back the way it came and turns it 180°.

This is a very simple example of KonneX programming, but even in this example one can see that multiple threads are very easily created and synchronised. Admittedly, the threads in the above example don’t do very much, but the potential is there for parallel processing, such as in this following example from the same demo.

To be continued…

This project is still under development. Software takes time between earning a living. If you think KonneX is a good idea, please…