Posted in TVM scheduling on September 12th, 2011 by williaz – Be the first to comment
To create multiple TVMs I initialize multiple contexts in the wrapper (initially using pthreads). This presents many challenges because if I were to naively create four TVM, for example, I would have four independent runtimes and a single occam program would actually be run four times in parallel. To handle this the initial thought was to have certain pointers in each context point to the same thing as the original context. While doing this we decided to initialize the contexts as they are need, moving the creation of new contexts to within the scheduler so when something was added to the scheduling queue a new thread was created. Because thing are only added to the queue when parallel occam processes are created this prevents waist by not creating extra TVMs until they are needed.
Currently I have run into several problems in my attempts to do the above mentioned steps. The first issue is with getting the pointer in the context to point to the right thing. Currently I create one context and then every time a new context is created I set the pointers of the new context equal to those in the old context. While in theory this should work, I clearly have some implementation issue. The code which does this is below.
Because the code to create a context is in the wrapper but I am now creating new contexts in the scheduler the function for starting a context but be available. To handle this I created a new pointer in the context (which is available to everybody) which points to the function that needs to be called. However I am having similar trouble with this aspect of the code.
Where ea is an array of pointers to execution contexts (ea reserved for firmware)
122 ea->spawn_hook = ea[n]-> spawn_hook;
123 ea->spawn_hook = run_multicore;
run_multicore is a function defined above these lines and spawn_hook is a function (pointer) defined in the execution context struct.
However if I print the value of the pointers they are different. I have a similar problem with int and other pointers within the context struct. But because the pointers being shared across contexts refer to dynamic location, for example as the queue changes state all the pointers must change, I need to be able to set and forget them and know that all contexts will be pointing to the right place at all times, which I thought was the whole point of pointers. This question may demonstrate my clear lack of understanding when it comes to the see language and any comments or thoughts people have are warmly welcomed.
Posted in Uncategorized on September 12th, 2011 by williaz – Be the first to comment
At the highest level a TVM is a very simple program. All it does is fetch the next tvm byte code (TBC) instruction from memory, call the corresponding c function, and increment the instruction counter. The whole system has several parts, one of these is the wrapper, which is the connection between the tvm and the current system. In the code a TVM is essentially just an execution context, which is a c struct initialized in the wrapper. The execution context holds pointers to many things including the instruction pointer, pointers to the scheduling queue, pointers to workspaces in memory, as well as many other necessary components. Once a context is initialized, which includes setting a pointer to the TBC in memory, the transterpreter enters a loop with with a given context and begins the fetch, call increment cycle.
Posted in TVM scheduling on September 6th, 2011 by williaz – Be the first to comment
Greetings Internet, as an undergraduate student at Allegheny College I am required to undertake a senior thesis project. I have hijacked this blog to share with you what I am doing so that you too can enjoy the roller coaster that is software development.
The goal of my project is to implement a multicore scheduler for the process oriented programing language occam (and occam-pi). Currently occam is run on a portable virtual runtime based on the transputer. This run time, implemented in c, is called the transterpreter and consists of one or more transterpreter virtual machines or TVM’s. Despite the massively parallel nature of the occam language the current Transterpreter is a single execution thread with no support for sharing work over more then one core of a processor. My work will replace the current scheduling algorithm with one designed for process oriented programing on multiple cores.
I will implement the scheduler in three steps, the first step will create an environment to work on the scheduler using posix threads (pthreads). I will create multiple TVMs running on different threads, in this way I can simulate the different cores by scheduling processes to the different TVMs. This first step will also give me time to get acquainted with the system and force me to learn some of the ins and outs of the transterpreter.
The Second step will be to implement the scheduler it’s self, which is a wait-free work stealing algorithm developed by Carl Ritson. Ritson’s current scheduler uses CCSP which requires access to native libraries so in this step I will port his scheduler to the transterpreter using the pthreads I set up in the first step rather then CCSP or other non-portable implementation tools.
While pthreads are completely portable they are also very heavy relative to other lower level processes, for this reason the final step will be to eliminate the use of pthreads and instead use LLVM which stands for low level virtual machine. The idea is that a program compiled for LLVM can run on any architecture which has an LLVM back end. Using LLVM will provide portability without forcing us to use higher level less efficient methods of implementation (such as pthreads).
Posted in arduino, occam-pi, PWM on October 19th, 2009 by Radu – Be the first to comment
The last implementation proved to be very slow, so an obvious improvement was to eliminate the ticker; i.e. the dependence on the clock for synchronization. By removing the ticker process we ensure that PWM will run as fast as the virtual machine is. Here is the updated diagram:
PWM in Software (No Clock)
When tested, this implementation runs quite a bit faster – the LED actually gives an impression of dimming. But upon plugging a speaker into the same pin we get a definite “buzzing” noice, when the desired effect is more like a nice sound. Hence, still not fast enough. It is therefore time to read the Arduino data sheet and find out how to do it in hardware.
Posted in arduino, occam-pi, PWM on October 19th, 2009 by Radu – Be the first to comment
In this post I will be referring to Pulse Width Modulation as PWM, which you can read about more here.
Since before I started working on this project I did not know anything about PWM, I did a bit of reading on-line and without getting into too much technical detail I started coding it as it first came to mind. The graph below is what I came up with.
PWM in Software
The diagram abobe shows five parallel processes:
- ticker controls the rate at which sine, and saw and control operate. It also dictates the rate at which control operates, although not necessary;
- saw and sine are just two oscillating functions, the difference being that sine has a constant increment, while saw has its increment dependent on the level you want to do PWM; since they have different increment / decrement rates, they intersect at rates dependent on the level you pass to saw;
- control reads the values from saw and sine and if they crossed sends a signal to switch;
- switch upon receiving a signal flips the power on or off.
This implementation, even though very ugly, does what it is supposed to do, almost. By almost I mean it modulates the pulse, but the modulation is not fast enough to give an impression of dimming an LED. That is, the LED appears to just blink at a fast rate, but to actually achieve PWM as it is supposed to be, we would need a much faster virtual machine.
Posted in arduino, occam-pi on September 28th, 2009 by Radu – Be the first to comment
As the title might suggest, this post is about me getting familiar with the Occam concurrent programming language and the Arduino.
Occam runs on the Arduino by means of the Transterpreter VM. So my first little project was to get the development environment set up, get the code to cross-compile, and write a little blink program that would cause an LED to…, well, blink. Here is a process diagram:
Not a terribly complicated exercise, but got my feet wet. So, tick is being awakened by the system every ms milliseconds at which point it sends a signal to toggle. Upon receiving it’s signal, toggle flips the level it has on record and sends it to led. Then led just does a digital write on the pin it monitors. This is the magic of blink.