Proto Threads in a COG
Heater.
Posts: 21,230
OK here is the first ever report from a propgcc alpha tester. (Does that make me the alpha-alpha-tester?)
The creation of a C compiler for the Propeller has been discussed for many years on the Prop forum. Now we have three, ImageCraft's ICC, RossH's Catalina and now propgcc. (No I'm not counting my humble efforts with the Zog ZPU byte code VM running GCC compiled code).
Anyway, these discussions often included speculating about compiling C to native PASM to run in a COG. The consensus was usually that there is no point as there is "obviously" far too little space in a COG to do anything useful in C not to mention the fact that the instruction set does not support "essential" features required by C like a stack or pointers etc. (When I say "The consensus was..." I probably mean "I always had the opinion...")
So what happens. Well this is Propeller land where anything that is said to be obviously impossible is done before you know it and we now have GCC compiling code into native PASM to run in a COG.
Of course my first inclination was to find out how well GCC for the COG worked and if it had any practical use.
So first up is a Full Duplex Serial driver. As a little extra twist I used Proto-threads http://www.sics.se/~adam/pt/ to implement the TX and RX threads. See attachment which contains the driver and a simple LMM demo to scho chars back to a terminal at 38400 baud.
Note: Look for "HEATER" in that code for some comments on odd things I found as I went along.
Experience so far is:
1) propgcc easily compiles this into a COG with space to spare, uses 250 or so LONGS.
2) Interfacing between COG C and LMM C via a mailbox interface works easily.
3) Final speed is not up to much, only 38400 baud.
4) It turns out we have a JMPRET built in (taskswitch) that would be a much better way to implement this UARTs threads resulting in less code and more speed.
Upshot really is that compiling to native COG PASM can actually be practically useful. Of course even Proto Threads may be a bit heavy weight here but they have been shown to work and may be of use in LMM code.
The creation of a C compiler for the Propeller has been discussed for many years on the Prop forum. Now we have three, ImageCraft's ICC, RossH's Catalina and now propgcc. (No I'm not counting my humble efforts with the Zog ZPU byte code VM running GCC compiled code).
Anyway, these discussions often included speculating about compiling C to native PASM to run in a COG. The consensus was usually that there is no point as there is "obviously" far too little space in a COG to do anything useful in C not to mention the fact that the instruction set does not support "essential" features required by C like a stack or pointers etc. (When I say "The consensus was..." I probably mean "I always had the opinion...")
So what happens. Well this is Propeller land where anything that is said to be obviously impossible is done before you know it and we now have GCC compiling code into native PASM to run in a COG.
Of course my first inclination was to find out how well GCC for the COG worked and if it had any practical use.
So first up is a Full Duplex Serial driver. As a little extra twist I used Proto-threads http://www.sics.se/~adam/pt/ to implement the TX and RX threads. See attachment which contains the driver and a simple LMM demo to scho chars back to a terminal at 38400 baud.
Note: Look for "HEATER" in that code for some comments on odd things I found as I went along.
Experience so far is:
1) propgcc easily compiles this into a COG with space to spare, uses 250 or so LONGS.
2) Interfacing between COG C and LMM C via a mailbox interface works easily.
3) Final speed is not up to much, only 38400 baud.
4) It turns out we have a JMPRET built in (taskswitch) that would be a much better way to implement this UARTs threads resulting in less code and more speed.
Upshot really is that compiling to native COG PASM can actually be practically useful. Of course even Proto Threads may be a bit heavy weight here but they have been shown to work and may be of use in LMM code.
Comments
Thank you. Comming from you "cool" is quite an honour.
Thing is it's not quite cool enough. I feel the need for speed and the proto threads are too heavy duty. They have to go. With Erics latest optimization ideas we will get 115200 baud.
Thank you for submitting this. I have always thought that Cog C would be useful, so I'm thrilled that you attempted it and shared it with us!
I always thought that COG C would never be of use:)
But when I saw what had been done with propgcc, operating without a stack for example, it became a challenge I could not resist. With pleasantly surprising results.
Looks like Eric has some ideas to enable squeezing even more out of this.
Something I have used with both spin and catalina is reloadable cog code. But it is a bit complicated to debug because you need to write the pasm part in the spin tool, then compile it, then run the file through a program to convert it to a C array, then paste that array into a C program. Easy once it all works but a pain to write and debug.
I wonder if your method might end up a whole lot easier to use?
Can you load your code into a cog, then run it, then reload that code with different code?
And can you use inline pasm instructions?
Ha! Give someone a high level language and the first thing they want to do is get down to assembler:)
Yes you can put assembler instructions in line with GCC C code. I have no idea how to do it. The syntax to do it is not trivial and the resulting source is damn ugly. Also you have to be carefull you don't end up fighting with what the compiler thinks is going on. Better for someone more expert to describe how to do it.
However, for things that the compiler cannot generate code for, like waitpe etc, there are builtin functions that will generate the instruction required.
Have a look in the examples. I believe the builtin functions are defined in propeller.h.
What is it you would want to do with inline pasm?
Your cog code could of course be entirely written in assembler using the GCC gas syntax. I think one of the led toggling demos does that.
You can also use familiar PASM syntax. There is a toggle demo for that to.
I am working (when time allows) on kernel level threads; and while my original intention for them was for higher level code, it will be interesting how they may perform for code such as serial drivers.
Kernel threads are not part of the alpha release, as GDB support will be coming first