GO language & Hoare CSP Channels?
prof_braino
Posts: 4,313
Is anybody using the GO programming language?
http://golang.org/
Go appears to use the same communications channels as C.A.R Hoare's Communicating Sequential Processes (CSP).
PropForth also uses the same type of channels in the Multi-Channel Synchronous (MCS) serial comms.
The PropForth MCS makes is simple to connect one prop chip to another, the MCS channels make it pretty much transparent.
Maybe connecting to channels on a device running GO would be as easy?
The thought was to use the prop to talk to the sensors and actuators, and an external device for everything else (number crunching, user interface, database processing, etc). The external device could be anything from a Raspberry PI to a PC work station. If the external workstation were running GO, it might be easy to interface the two.
Google is using GO, and it seems that GO runs on most Linux, windows, and Mac.
If anybody is interested in experimenting or has experience with GO, please post!
Cheers!
http://golang.org/
Go appears to use the same communications channels as C.A.R Hoare's Communicating Sequential Processes (CSP).
PropForth also uses the same type of channels in the Multi-Channel Synchronous (MCS) serial comms.
The PropForth MCS makes is simple to connect one prop chip to another, the MCS channels make it pretty much transparent.
Maybe connecting to channels on a device running GO would be as easy?
The thought was to use the prop to talk to the sensors and actuators, and an external device for everything else (number crunching, user interface, database processing, etc). The external device could be anything from a Raspberry PI to a PC work station. If the external workstation were running GO, it might be easy to interface the two.
Google is using GO, and it seems that GO runs on most Linux, windows, and Mac.
If anybody is interested in experimenting or has experience with GO, please post!
Cheers!
Comments
Please stop this!!! Your ADD is contributing to and compounding my ADD with these interesting "side" pursuits you keep bringing up. I do not need to be shown more forks in the since when I come to a fork in the road, I do take it!
This is a very interesting question and avenue of pursuit, especially since I have a BeagleBone and Pandaboard just waiting for some Propellered friends to talk to.
The Python Microcontroller (http://pymcu.com/ ) caught my attention last week and distracted me....now this for further distraction.
Please, I implore you, for the sake of my remaining sanity, stop, stop this madness!!!!
No, I must GoForth and investigate!
I love it already.
A cleaned up C, a simplified C++, Javascript with sensible types,
And then also Communicating Sequential Processes. Wow!
Wish they could get that into the WEB browser instead of JavaScript. Then we could have clean channels back to more GO on the server end,
Now, if you could put GO on the Propeller and and have seamless integration through it's channels to GO on the PC that would be great.
I'm really glad you guys responded, I was hoping somebody smart would would help with some of the hard parts (which are all the parts that are not in forth).
Sal started work on this last weekend. As of now, it looks like the only to perform is to hook the channels on the prop to the channels in GO. For the time being the channels on the prop are in assembler (PropForth MCS optimized in assembler). As far as GO cares, its just another channel. So we think all that is needed is the GO on the PC set up to talk to this (these) channels) and the simple hardware interface. Sal is talking about starting with a plain old serial port interface (since I have mastered serial port on PC, IE "plug in the cable"); after that there could direct connection, depending on availability of GPIO on the server.
But, don't expect to much too quickly. We still have to work to do that builds to this, per mindrobots comment.
GCC has a GO build target.
Do you mean target?
I just read somewhere that there was a GO front end for GCC.
So now we have the Prop as a GCC backend the "Propeller is ready to GO"
Of course I have to state that this is all impossible, just to be sure it happens soon:)
My impossible scheduler is over-booked at the moment.
That would pretty much guarantee the impossible aspect of this pursuit!
There you go
I hope this doesn't distract anyone from other pursuits..........
The remaining issues is sorting out the forward slashes and back slashes in the files path names for windows and linux, the converters are automatically converting them the wrong way sometimes.
Hopefully we will have a result next Sunday
We need to be careful how we describe this or folks will be mislead. There are some things the prop is very good at, and some things its NOT so good at.
The prop is GREAT for talking to sensors and actuators, and possibly (via the channels) talking to other processors (that also talk over channels).
The prop in NOT so well suited for certain things like number crunching lots of floating point numbers, manipulating large databases, etc.
We have the infrastructure in place so we can have the functions we want so we USE the prop as if it were a teeny forth workstation (Jupiter ACE, etc), as long as we don't try to compare it to quadcore windows PC or Mac or Linux workstation.
In cases were we need real workstation power and capabilities, we want to be able to hang a linux box (for example) of sufficient power off a couple of empty pins.
Propforth already does make the prop the workstation (if you only want a terminal or a teeny workstation), but using something like the CSP channels, we can add any size workstation power to the prop application. Or viewed from the other perspective, add any sensors & actuators via the prop to the PC workstation. So in answer to your question, yes and no, its all about scaling the hardware to the requirements of the application versus trying to be all things to all people. Its all good fun.
i absolute agree ! I am just trying exact this for a smaller project. A spin loader for ARM i have published here some months ago.
Regarding GO: Its google ..so its sexy ok, accepted.
In principle its a Pascal or better Oberon with brackets instead of BEGIN ...END. I know Oberon is for amateurs and C for the real hardcore programmers, accepted.
A multiprocess interaction is handled in Oberon and specially in Erlang also for 20 years or so...
I don't like to start the 1289764th computer language discussion. I only want to point out that there is near nothing (friendly spoken) new in GO.
And if this would be a clever google - trick to bring the art of programming back to easy structures and concepts, then i will 100% agree and support it.
So i am just writing an serial interface from Erlang on ARM to PropForth (beneath others..) also in principal the same idea. Maybe i will switch to GO....
Markus
I was hoping they had thrown out all the old C cruft so I was disappointed to see that GO still has C style octal literals, gack.
This sounds great! We talked about Erlang a while ago, and did not necessarily decide against it. Sal likes Erlang and Go, both.
If you can get the CSP channels going, it should be no different for either. In fact it would be a good test that the interfaces are consistent.
thats the google-trick: at the first glance it looks like C but the truth is its Pascal, because C is for professionals and Pascal for old idiots ;-)
Its like Android, it looks like iPhone and its a Linux, because iPhone is for the cool guys and Linux for nerds...
Parallax does the same at the moment MHz and GCC are for all "real" programmers, and Spin and parallelism for the esoterics..
I understand it, because its quite hard to sell somethings, which is not mainstream.
Markus
Markus
Markus, your generalizations are a bit harsh, aren't they? I really don't believe choice of tools reflect on mental capacity or professional status.
yes a little bit of cynicism or sarcasm and and also, maybe mis-interpreting of a not native speaker...;-)
I absolute agree that the tools don't reflect the mental capacity! But i fear its better to tell nobody that you are using non mainstream tools...
ok, just my 5 cents or Euros ;-)
Markus
If it wasn't for non-mainstream tools, I wouldn't have any fun!!
I must go check out this mainstream Erlang language!!
I just installed a server that has a simple job of sucking data in, filtering it and pumping it out to the right place in as close to real time as you can get over the net. Turns out it works faster and uses less memory than the previous attempt that was written in C++ (STL, IDE and all.).
What is this magic "weird thing"? It's node.js and the Google V8 JavaScript engine running JavaScript on the server.
Never would I have believed that JavaScript could out pace C++ but there it is.
Now all I have to do is convince the powers that be that this is not a joke, is stable and is a long term supported solution.
Lucky me that I get a free hand to be experimental sometimes.
http://en.wikipedia.org/wiki/Tony_Hoare
Another quotation around the difficulty of creating software systems which are not overly complex states:
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.
end quote
The side effect seems to be that regardless of the power and cost of the platform, eventually the complicated method gets slower than the simple way on the simplest (necessary and sufficient to get the job done) platform. Its fun to think that "weird" is applied to simple and "normal" is applied to "overly complex to the point of strangulation". Its probably not exactly true, but still fun.
http://code.google.com/p/propforth/wiki/GoSetup
I think its pretty close, I have GO installed EMACS set up to run the session. I thought there would be an easy way to (permanently) change the strings for compile and run, but I didn't get that to happen yet. (Anybody has corrections, I will update the notes)
We did not get to setting up the CSP channels between GO and propforth on my rig yet, but Sal has it ready. Hopefully I will get in working and the notes posted sometime this week.
http://code.google.com/p/propforth/wiki/GoSetup
Please give it a try, see if you can compile the example Go programs. If you can get the context highlighting to work, and the program to compile, the workstation will be set up for the next step, the GO/Propforth Bridge.
Sal has an example Go-to-Propforth-Bridge using CSP channels. This is a prototype, so I can't post it or send it around yet. BUT, it totally works, the Windows XP DOS window [RUN: cmd] connects to Propforth (that is, stock unmodified Propforth 5.0 on a quickstart connected to a PC via USB virtual comport10), and we can use the DOS window command line editing functions. (Command history, arrow up and arrow down to scroll through previously entered commands, etc). The same should be true of lunix command shell, we may ask for a volunteer to test on linux interface.
Sal estimates about two weeks till a Go/Propforth Bridge routine for the PC will be available.
The default connection speed is 57600 baud. Right now 100k is a "sweet spot" for throughput and latency for the MCS. Sal will do more tests to figure if any bottlenecks exist and how they could be addressed. Of course, more prop chips can be added, and more cogs can be used for communications depending on bandwidth requirements. First thing that comes to mind is instead of one cog for communications, use three cogs, one for transmit, one for receive, one for protocol. Right now, it looks like the maximum throughput could be around 1 megabit per second, but we'd have to look at the latency. More on this as it develops.
OTHER LANGUAGES
Any other language on the workstation that supports CSP channels should work as well, the programmer only needs to implement the bridge program. Plan is to implement a TCP server in GO, so teraterm can be used to talk to all the cogs at once. The interface details will be posted on the propforth wiki when they are available.
Hopefully Markus will be able to implement an Erlang version. Sal has not used Erlang for years, so I suggested he NOT look at Erlang just yet, as it is not in the main scope. But Sal points out that there are a whole slew of things for which Erlang is great, so we are looking to forward to progress by Markus and the rest of the community.
Sal points out that C programs on the PC would also be a fine candidate for interfacing via CSP channels, but cautions me that this would require "expert" C coders rather than a "tourist" C coder, which eliminates me from direct coding participation. Hopefully somebody really smart will take an interest when the time comes.
WHERE THIS IS LEADING
The first benefit we expect to see is automated testing. The workstation is expected to initiate the entire regression test suite, log the results, and identify errors in a fraction of the time (several minutes) that manual testing takes (typically four hours minimum if Sal does it himself and nothing goes wrong). The automation would allow any developer to very quickly and completely test every change to ensure nothing "got broken". This is kind of a huge deal in itself, previously this capability has been insanely expensive when even possible.
Another benefit is the possibility of a change to data collection. Typically the connection between the sensor and the processor or the senors system and the processing system is proprietary or a one-off custom solution. Every application tends to reinvent this wheel or at least the first link in the tool chain.
The CSP channel interface should allow logging huge whacks of data on the prop, and streaming it up to the cloud for processing, for example, by a Google App. The connection from the sensor on the prop to the program on the workstation becomes transparent. If it works, this might be useful in some situations.
Its too early to claim success, but it looks imminent and interested folk might start preparing.
I like that. A very astute observation that applies to more than software designs. I would modify it slightly to read:
"There are two ways of constructing most designs: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."
Thanks to the folks that sent me questions and hints.
Anyone should be able use the instructions and duplicate our configuration.
This will get GO running on your Windows XP workstation, using EMACS. In addition to letting you play with GO and LISP, you will be able to use the CSP channels between GO and PropForth when the driver is ready in a couple weeks.
Please continue sending messages or post here if you encounter and problems or have questions.
CSP Channel Driver Requirements/Specification (High Level):
For the time being, we send and receive bytes, only.
Do we send longs? Not yet. ALL stuff is sent as BYTES.
GO does types, but propforth doesn't understand types.
So everything is bytes to propforth.
Maybe later we'll try other ways, but not for the time being. It is useful to minimize the number of unknowns.
Summary of High Level Requirement for CSP channel Interface:
CSP channels map to propforth I/O channels, they send bytes.
If you wish to set up a CSP driver from any language to propforth, this is what we start with.
If you wish to create a CSP compatible firmware for the prop using any other language, this would be a starting point before addi9ng more complex structures etc if you want to test and compare with our work.
Ultimately, it would be nice if any CSP language on the PC could talk to any CSP implementation on the prop, but we expect there will be differences base on the target application for each implementation. It still looks doable.
Sal is using Ubuntu VM and Windows XP for testing.
Should be. If you can implement CSP channels for the prop, and you have the PC side, it should be good to go.
The CSP channels are the focus. Propforth channels are very close to CSP channels, so they can interface nicely. Its easy to implement a CSP driver in GO, so this hooks up nicely on the PC side. Sal is making a Go version 1 CSP driver on the PC that should work with propforth or any other byte-transfer CSP channel firmware for the prop. After Sal gets the Go driver finished, we should be able to post a definition for the interface, then coding should be straight forward. As long as the interface is compliant, an implementation in any language should work.
Markus may try an Erlang CSP implementation, Rick found Python CSP channels. So we have a few examples on the PC side covered.
I was hoping someone would try GCC, Catalina, and PASM CSP channel implementations on the prop. There might not be enough room for fancy data types and structures. We're going to start with byte-only and see where that leads.
Have you catered for intermittent connections and errors?
My observation is that the CSP concept assumes that passing data through channels between processes is 100% reliable. That is to say you can treat it like passing parameters to a function and getting return results where you would not expect them to be lost or corrupted on the way.
It assumes that the sender and receiver are both alive at the same time. The receiver is just there and ready.
When CSP is translated to hardware as in the Transputer chip and Occam language or now a days with the XMOS devices and their XC language it assumed that the devices on both ends of the channels are powered and rest together and that the physical serial links are error free (As you would assume the memory bus from CPU to RAM is error free).
I'm not sure but I would assume the GO language makes similar assumptions about channel reliability.
When such devices are in different power domains, or reset at different times or the link is unreliable then special care must be taken above and beyond just moving bytes from channel TX to Channel Rx. Perhaps even at the application level.