PDA

View Full Version : GO language & Hoare CSP Channels?



prof_braino
03-05-2012, 12:55 PM
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!

mindrobots
03-05-2012, 01:19 PM
Dear Professor Braino,

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/ (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!

Heater.
03-06-2012, 06:47 AM
I just stepped through Google "A Tour of Go".
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.

prof_braino
03-06-2012, 04:26 PM
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.

jazzed
03-06-2012, 04:41 PM
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.

GCC has a GO build target.

Heater.
03-06-2012, 04:52 PM
Jazzed,
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:)

jazzed
03-06-2012, 05:57 PM
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.

mindrobots
03-06-2012, 06:00 PM
From the GO FAQ:


Why is my trivial program such a large binary? The gc tool chain (5l, 6l, and 8l) only generate statically linked binaries. All Go binaries therefore include the Go run-time, along with the run-time type information necessary to support dynamic type checks, reflection, and even panic-time stack traces.
A trivial C "hello, world" program compiled and linked statically using gcc on Linux is around 750 kB. An equivalent Go program is around 1.1 MB, but that includes more powerful run-time support. We believe that with some effort the size of Go binaries can be reduced.



That would pretty much guarantee the impossible aspect of this pursuit! :innocent:

jazzed
03-06-2012, 06:11 PM
That would pretty much guarantee the impossible aspect of this pursuit! :innocent:

There you go ;) Clearly impossible now ;) I look forward to whatever Sal can conjure up.

mindrobots
03-08-2012, 12:20 AM
If anyone wants to play, gcc 4.6 and better have gccgo. It's on my Ubuntu 11.10 has it. I had to do a "sudo apt-get install gccgo" but then I was all like "Hello World!' with go!!

I hope this doesn't distract anyone from other pursuits.......... :lol:

prof_braino
03-12-2012, 12:50 AM
Next week, we are looking to have a prototype GO EMACS configuration, and a GO serial terminal. The target is to get the terminal program on the workstation to (interactively) talk to all 8 cogs at the same time.

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

Humanoido
03-12-2012, 06:13 AM
Next week, we are looking to have a prototype GO EMACS configuration, and a GO serial terminal. The target is to get the terminal program on the workstation to (interactively) talk to all 8 cogs at the same time.
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 SundayThere's a lot of value in getting this to work with the Propeller. As my schedule is currently at ELF proportions and I'm out in Timbuktu retrieving the EXO portion of the Big Brain, I see there's a lull in the development of new Propeller languages so I hope to see some step by step work with GO language. Can we get the GO on the prop so the prop IS the workstation?? Or is that what's already in mind?

prof_braino
03-12-2012, 05:07 PM
Can we get the GO on the prop so the prop IS the workstation??

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.

MGreim
03-12-2012, 05:46 PM
Hi,

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

Heater.
03-12-2012, 06:12 PM
That's odd. I did the quick tour of GO on the GO site and could have sworn it looked more like C than Pascal with CSP thrown in. Which of course was done a long time ago with parallel C for the Transputer chips. As such I find it an intriguing idea.

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.

prof_braino
03-12-2012, 07:38 PM
So i am just writing an serial interface from Erlang on ARM to PropForth (beneath others..)
Markus

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.

MGreim
03-13-2012, 08:35 AM
Heater,

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

mindrobots
03-13-2012, 09:48 AM
Heater,

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.

MGreim
03-13-2012, 05:44 PM
Sorry,

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

mindrobots
03-13-2012, 06:20 PM
Understood.

If it wasn't for non-mainstream tools, I wouldn't have any fun!! :lol:

I must go check out this mainstream Erlang language!! :smile:

rod1963
03-13-2012, 06:37 PM
Same here, if it wasn't for non-mainstream languages like Forth, Oberon and Delphi, working with micro's wouldn't be any fun. Let the suits in the cube farms have their Eclipse IDE's, STL's and gigabyte development systems.:smile:

Heater.
03-13-2012, 07:13 PM
I'm just having this exact same "resistance to anything weird" problem.

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.

prof_braino
03-14-2012, 02:01 PM
You might be noticing this effect:

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.

prof_braino
03-21-2012, 07:17 PM
OK, I got my notes from last Sunday posted at:

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.

prof_braino
03-25-2012, 05:33 PM
The GO + EMACS setup instructions page has been corrected.

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.

kwinn
03-25-2012, 05:45 PM
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.


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."

prof_braino
03-28-2012, 03:02 PM
More correction to the Go set up instructions.

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.

prof_braino
04-01-2012, 04:12 PM
Go Version 1 came out this week. Moving up to the current version will add another week, so we might expect the PC GO to Propforth driver in two weeks from today, at the earliest.

CSP Channel Driver Requirements/Specification (High Level):


CSP channel maps to Propforth I/O channel, period.
Put a byte in GO channel, it appears in Propforth channel.
Put a byte in propforth channel, it appears in GO channel.



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.

jazzed
04-02-2012, 10:05 PM
Is it possible to use GO without forth ?

prof_braino
04-03-2012, 02:13 AM
Is it possible to use GO without forth ?

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.

Heater.
04-03-2012, 10:40 AM
prof_braino,

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.

prof_braino
04-03-2012, 02:43 PM
This is another area where it gets outside my expertise. BUT...

In PropForth, the MCS (Multi Channel Synchronous Serial) has demonstrated itself to be 100% reliable so far (between two prop chips). That is, the channel starts sending and receiving 96 bit packets at full clock speed. (Continuously, for several months, so far). When a character is dropped into the send side, it pops out the receive side. The minimalist error count mechanism has only counted errors when we did the "yank out the wire" test. Otherwise its always there and communicating.

Sal made a GO demo on the PC (internal prototype only) a couple weeks back, and it looked like it worked. He still has to futz with something to make it identical on XP and Ubuntu, but it should be ready for public viewing in a couple weeks and we can dissect it after he's done testing. Hopefully you can find errors and tell us where we've gone wrong and how to fix it. The goal is to make the interface definition such that any language prop implementation will be able to talk to any language PC implementation, at least regarding the byte transfer.

jazzed
04-03-2012, 05:07 PM
My question should have read: "Is it possible to use the GO implementation without having to learn forth?"

prof_braino
04-04-2012, 01:08 PM
Sorry, been sick last few days. Answer should have been, "YES, but you either have to use what somebody else wrote in forth as prop firmware, or implement CSP channels on the prop in PASM, or some other language."

prof_braino
04-08-2012, 06:11 PM
update GoSetUp section "configure EMACS to use go profiles"

http://code.google.com/p/propforth/wiki/GoSetup

EMACS will now use the currently open GO source code file name as the exe output file name.

Heater.
04-08-2012, 07:19 PM
Jazzed,

I am very sure that if you want your GO program to communicate with your Propeller it is not much different than using C or Pascal or Visual Basic. Just another language to talk down a serial link.

prof_braino
04-09-2012, 01:07 AM
Here is the plan for Go interface functionality. Its a little bit different than a regular serial link, in that there are multiple channels.
We will interface to propforth, but anybody could write a compliant CSP interface in any other development language.

1) Hardware: Two I/O pins are used; one pin for send, one pin for receive (more or less).
2) each pin supports 8 simultaneous channels (as of today), there are 16 I/O present, 8 pairs of two.
3) Each channel is full duplex 115K baud. It uses 8 data bits no parity and no stop bit, so uses a 10 bit transfer. Usable throughput is about 113k baud.
4) The PROTOCOL on each channel uses the full duplex. (I sent a byte, did you get it? Yes I did Now I'm ready for another), but to the user, one channel sends and another channel receives.
5) the transfer is synchronous continuous 96 bit packets. Drop a character in the channel, it jumps out the other side.
6) Each I/O channel also has a pointer to (another channel) where the data is to go. This is typically the input to a the propforth interpreter running on a cog, but it could be a dedicated assembler routine to do what ever. The result is we have an input, from a PC terminal command line, directly to a cog on the Prop.
7) We have 8 channels, so we can have 8 terminal sessions open at once, so we can talk to all 8 cogs at the same time. Each session runs at 115k baud. Just to reiterate, this is using 2 I/O pins.

8) There is an option to have more channels with a lower throughput and higher latency. The estimate is that 32 channels would have about 56k baud throughput. The target is 32 channels at 56k baud. This will allow the workstation to connect to many prop chips, so an application could span the cogs of multiple physical chips.

9) the Use model is
a) running complex applications on the workstation/PC and
b) running acquisition and control on the micro controller.
This use model allows deciding what processing is done at each level, on the PC or the micro controller.
Usually some level of filtering is performed near the sensor before data is sent to the PC.
The PC does some convolution, determines feedback ,control is sent back to the micro controller.
The micro controller can react very quickly, and the PC can handle long term stable processing.

prof_braino
04-15-2012, 03:39 PM
EDIT - deleted lame excuses

prof_braino
04-22-2012, 09:33 PM
FINALLY got it posted. Here is the long promised demo for CSP channels for GO on the PC and proforth on the prop.

The same PC side code should work with a CSP byte transfer implementation in any other language (PASM, C, BASIC, etc)

The same prop code should work with a CSP byte transfer implementation in any other language, Python, Erlang etc. But I don't know if anybody DOES a CSP byte transfer in any other language. I'll try to contact the Python CSP folks this week to see if they want to play. Also I'll ping MGreim and see if he's ready.

Please see the instructions at

http://code.google.com/p/propforth/wiki/GoSetup20120422

These (should) tell you to also download today's magic

http://code.google.com/p/propforth/downloads/detail?name=20120420mygo.zip&can=2&q=

Could somebody please test this out?

Thanks!

mindrobots
04-23-2012, 01:21 PM
Curses on you!!!

It works, IT'S VERY COOL and you can read more about it here. (http://forums.parallax.com/showthread.php?138399-Propforth-5.0-is-available-for-download&p=1092960&viewfull=1#post1092960)

Dang you!!

prof_braino
04-23-2012, 05:52 PM
Braino,
By the time you have chopped and changed languages at the PC end and then chopped and changed languages at the Prop/target end all you have left is a means of multiplexing many logical comms channels through a single physical link.

That is nothing to do with CSP as formalized by Tony Hoare and others. Please do not call it such.

From another thread: New information, and an contradicting opinion! Now we get interesting.

Sal tells me this is a "standard plumbing" to connect any processor process to any other processor's process, and this is the intent of CSP and this is what he's begun implementing.

Heater tells me I'm talking out my butt again. This can be true, as it often is; but is Sal's statement incorrect? Or am I just totally misunderstand the basic concepts again?

Somebody pipe in before I am shamed into deleting all my posts on the subject for the last several weeks. :(

Heater.
04-23-2012, 06:50 PM
Sal is right. This is standard plumbing. After all isn't that what networking and the internet are all about? Connecting disparat computer systems together.
However none of that has anything to do with CSP as it is formally described.
Is Javascript in your web browser talking to PHP in your server via HTTP requests CSP. No.

prof_braino
04-23-2012, 08:04 PM
Ok, now I'm confused. Do Python CSP and GO CSP fit the formal description? Or is it that communication to a micro controller cannot be considered CSP?

mindrobots
04-23-2012, 08:35 PM
I'm trying to sort this out and figure out what is what, also.

I haven't read Mr. Hoare's book (original or updated), so I can't quote from it. From the Wiki (sorry) page, CSP is a formal language that has influenced a number of "implemented" programming languages.

I would take this the same as Realtional Algebra is a formal language that has influenced a number of relational database managers and their supporting query languages.

I don't understand the formalism that elevates CSP beyond message passing between subsystems to accomplish a task - whether it is a central processing unit passing an address of channel commands to an I/O processing unit or a browser passing a request packet off to a server to have it fetch data while it goes on and does something else. If CSP as now defined by Hoare and others lends provability to parallel process messaging methods and a caluculus through which to further define and formalize theory, then that is wonderful.....for the Computer Scientists.

As an specific implementation, the GO/Propforth channel support seems to be a useful and functional way to extend the propforth channels that existed back onto a workstation. I look forward to experimenting with it as a way to mesh of interconnected Props running Propforth that are tied back to a workstation...to what end, I do not know. I'm also pondering goForth extensions to support "CSP" and also the Python/CSP implemention as other playgrounds. Whether or not I can formally prove it to be CSP isn't weighing heavily on me right now.

GO refers to them as "goroutines" and support of cummunicating processes. The line may be that it is inherrent in the language syntax and structure rather than implemented through libraries and external data structures.

I don't know, I'm not a computer scientist and generally not a very formal person.....and that I CAN prove! :lol:

prof_braino
04-29-2012, 05:04 PM
Sal is right. This is standard plumbing.
However none of that has anything to do with CSP as it is formally described.
Is Javascript in your web browser talking to PHP in your server via HTTP requests CSP. No.

Thanks to Heater. for bringing this up, I looked into this a little deeper. I discussed it with Sal, he tried to straighten me out. Let me try and express this properly:

The problem comes from using the term "CSP channels" as it can imply that it includes everything in Hoare's book. Hoare's book is very large and complex definition and includes a language to describe the constructs and techniques he's trying to get across.

The "channels" are synchronous communication channels between parallel sequential processes. What's important is that it's not just the CSP channels, its how we use them. "How to use them" is what the CSP book is about. More specifically, the Hoare book, as explained to me, is about dealing with multiple Finite State Automata. "How to deal with multiple FSA" is the majority of the book.

Propforth just implements channels, but not "how to use them".

The thing I have been referring to as "CSP channels" would more accurately be described as
-->> INTERFACING TO GO-CHANNELS. <<--
The same technique can be used to interface to other channels. It not meant to be a full blown CSP implementation.

Sal said he tried to discuss CSP channels with several folks over the years, but found he ended up spending too much time just deciphering each others understanding, and gave up. So he's not going attempt to explain it to me so I can explain it on the forum; the folks that understand it don't need explanation, and the folks that don't understand it aren't going to get it without reading the book. That's good enough for me, as I still get to use it, and there are too many other books I need to read first.

The bottom line is we can use these channels in many ways, depending on what the goal is. That is, we can stream data to and from the prop using synchronous channels.

----

I also contacted the Python-CSP author. When we get the interface properly nailed down and defined, she may take a look at it. Then we would get good idea of where this would fit, and if it might be useful someplace.

----

Development Progress:

Right now there is slow turn-around (doing synchronous over asynchronous, remember this is only development), it looks likes 60 characters per second per channel.

The protocol limits the speed. The first pass had an ACK for each character sent. Now Sal is working on a buffering scheme so there is one ack the whole buffer. All the channels share the buffer, the channel talking uses as much of the buffer as it needs. This should be transparent to us.

The plan is to take advantage of the WIZNET (spinerette) hardware, and do transfer over Ethernet. It should reside in 1 cog and be really fast. The function .str is optimized to generate the string in memory and spit out characters at assembler speed, so this part is ready. This will spit characters to the memory in the WIZNET. There will be a separate chunk of code to implement the channels for the WIZnet so it all fits in one cog. Sal is not 100% sure , but the cog should communicate equally well on local LAN or global lan. WITH proper buffer, should overcome latency issues. LAG stalls stuff, but buffer fixes it; instead of lots of .5 second delays compounded, the communications are just a .5 second out of phase. Nifty!

So Sal is working on the SERIAL buffering stuff. The plan is:
1) finish optimizing the unbuffered synchronous transfer
2) do a buffered synchronous transfer
3) put it on the wiznet

-- Possibly within two months.(!?)

prof_braino
05-06-2012, 07:10 PM
WE sent out a v5.1 BETA for fast serial today (Propforth-V5.1BETA-20120505.zip) to the propforth team and known users.

The default is going to change from 57600 baud to 115k baud in support of Go-channel development.

If anybody else else wants to play with the BETA please PM me with your email address.

Fast Serial will be standard in the public release containing automated testing support, which is targeted for v5.2 in August.

prof_braino
05-08-2012, 01:15 PM
We sent out 5.2 BETA to the team to fix issue 147

The default serial connection is now 230400 baud.

The GO-terminal command line interface is very snappy.

The GO-telnet interface is still synchronous over asynchonous with byte-ACK, so its still a bit slow, but you can open telnet sessions to all the cogs at once.

Notice that we can do the same with the current release, v5.03, although communication is on the current release is 57600 baud and a bit too slow to really play with. Of course this only affects the Go-telnet experiment; the rest is still crazy fast.

Please send me a PM with email if you want the BETA emailed to you, I try to answer requests as I receive them.

prof_braino
05-08-2012, 05:01 PM
Please try to telnet to my quickstart running GO-channels at 71 (dot) 201 (dot) 87 (dot) 230 (port) 4000

It should allow connections on cog0 through cog5.

Try running the word
cog?
or if you have lots of time the word
words

mindrobots
05-08-2012, 05:17 PM
Word up!

I got COG3, it's like the old teletype days!! I have plenty of time to read things as they go by.

'words' is good for a leisurely afternoon!

The terminal screen next to your is connected locally at 230400 - the difference is noticeable! :lol:

prof_braino
05-14-2012, 06:20 PM
Sal gave an update yesterday:
- buffered stuff works under windows 4 - 32 channels; 4 channels faster
- the release will include the the original source incremental steps from optimizing forth to assembler.
- tests with 8 channels yield around 1500 cps per channel, up from 200 around cps unoptimized
- Automation beats on the serial ports. Applied assembler optimization on fast load, GO can overrun channels
- possible course for development:
* Its easy in forth to implement a "subset" application language with just a few functions;
* just a few things in a demo like drivers for steppers and servos so its easier to learn and use

- Sal is thinking about a "lead app" to show off CSP channels and go. While some folks understand CSP thoroughly, some of us just know enough to think it might be a cool idea. So Sal is trying to come up with a an inexpensive project to show off how it can be used. Lead app should do-
* multiple inputs
* multiple outputs
* bunch of conflict states with data flow.
* maybe a robot? lots of ins and outs and complex interactions.
* Inexpensive, simple mechanics.

So the first candidates might be:
* Biped, balance bot; four servos and an accelerometer or other sensor
* laser etch-a-sketch, two servos and a cheap laser pointer to draw persistence of vision pictures on a surface
* hypersonic "sound from ultrasound" audio projection

We're open to suggestions. The key parameter is it should be cheap enough that anybody could try it.

The material presented so far is going to be integrated into propforth in support of regression test automation. After this post, I think the discussion will shift back to the propforth thread until some non-forth CSP material comes up. I'm hoping for someone to do C or PASM on the prop to implement that channel interface, and for Python and Erlang implementation of channel interface on the PC. This would be able to happen once the full interface is defined, possibly in the next propforth release.

mindrobots
05-15-2012, 01:52 PM
Prof_B,

Any of those projects sound like fun, useful, recreatable efforts. Balance-bots are always fun to play with.

I'm still thinking basic infrastructure and tools. With all the recent activity with wireless, it doesn't seem like wireless CSP channels should be too far down the road.


When I sit down and do it, my BeagleBone is going WiFi and it has FTDI support and Python, so it's certainly a target for the PC side of PropForth/CSP.
The Spinneret can expose channels to the IP world.
PropForth to PropForth mcs channels using CSP is certainly an option.
Multi-Prop PropForth clusters are certainly on my radar.


Yesterday, I fell down this rabbit hole again for a while.

I've got the PyCSP modules loaded and the examples are running. I went with PyCSP instead of python-csp because it is more portable, and is implemented as importable python modules. Python-csp is implemented as its own version of the Python interpreter, which may or may not be a good thing when it comes to managing the CSP stuff.

So, now I need to learn now this CSP stuff works and what it means to this project. There two different sets of documents which share the same concepts and some syntactical candy but there are differences in the implementations. Some things you read about that look interesting were in the old implementation and then changed in the current implementation. Nothing major, just something to be aware of.

For remote processes, one of the "future enhancements" is the concept of "remote evaluators" which fit really well in what we're trying to do with the PC and the Propeller. The channel could be opened up between a PC process and a remote COG under this model. It seems to fit better than the other CSP models and channel connectivity options. This is where I'm headed for now.

Since I've been talking the impossible IDE for PropForth:

I now have PyCSP
a Python based terminal program
a Python based Tiny Forth skeleton ('0 >con' from your PC to connect to a PropForth session?)
PropForth with high-speed channel support (mcs)


.........mix well and leave on your computer for a few days.......who knows what might happen!

For anyone that wants to play along that isn't thrilled about GO (I couldn't handle half-learning ANOTHER language) or Python or Erlang (assume it has CSP-esque channel support) or OCCAM, there is a Java based CSP implementation (JCSP (http://en.wikipedia.org/wiki/JCSP)) and a C++ based implementation ( C++CSP). I'm finding more as I hunt around for information. It may not all be "pure" CSP but most are from University environments and do discuss their shortcommings and practical applications when held up against true CSP algebra. Of course, I'm not doing it for the academics or provability of CSP theory.

CSP-esque channel implementations in other Propeller languages would be interesting to see. serialCSP.spin or cspchannel.c, anybody?? (Of course, if you modeled the protocol after the PropForth mcs, then Prop to Prop CSP wouldn't be so impossible. :smile:

So, what's your excuse??? It's only your free time!!

prof_braino
05-15-2012, 05:11 PM
Wireless: Sal knows something about wireless, like what the technologies are, how they work, what they cost, and their protocols. (He knows a bunch). So far there are several candidates, but none have hit the sweat spot of low cost, high acceptance, and straight forward interface (for Sal's purposes). Wireless/radio are in the list, and will be added when something changes. The first thing to expect in this direction is "packet radio" which I haven't mentioned yet as I have done no investigation. It might be right after the "Go-Lead-application", if anybody expresses interest.

Thanks for the tips on the other language options, this is the intent, but Sal and I don't have bandwidth to lead. The next public release should have enough detail so anybody with CSP supported can reproduce the PC end of the MCS interface.

Most of the stuff I think you are describing should be doable once the automation infrastructure is nailed down.

To Folks watching: MCS is similar to Beau's high speed serial, differences being MCS is in FORTH and assembler and includes the protocol. Anyone comfortable with Beau's stuff could implement support once the interface is nailed down. I'm looking forward to serialCSP.spin or cspchannel.c becoming interesting to folks next release.

prof_braino
05-21-2012, 01:25 AM
This is a new test:

Please try to telnet to my quickstart running GO-channels at 71 (dot) 201 (dot) 87 (dot) 230 (port) 4000

It should allow connections on cog0 through cog3.

Try running the word
cog?

or if you have lots of time the word
words

Now notice that running
words is very fast; faster than it used to be on a single channel direct connection.

COG6 now uses 1K of its RAM to buffer the channel communications. Fewer channels would go slightly faster, and more channels would go slightly slower, but they are all pretty much the same speed. It seems dependant on the number of CPU's in the host computer (the pc in my lab that the quickstart is talking through).

Hopefully, we can get some numbers this week. the guessimate is about 2000 character per second per channel using 8 channels, which is a little bit better than pre-CSP channels for a single channel. We can configure for 8, 16, or 32 CSP channels over a single serial connection.

This demo is still synchronous over asynchronous, so even though its faster than it used to be, it is still slow than its going to be when we use ethernet hardware.

mindrobots
05-21-2012, 12:22 PM
I tried your site this morning (just now) and got a "Connection Refused" - maybe I hit your maintenance window! :)

I loaded up the new PropForth and the new GO code and everything worked fine with my C3 and having the GO host on Win7 (I5 - 4 processors indicated). It was faster with the gomuxterm access. Telnet into it from the Win7 laptop as well as my Fedora laptop. I can collect numbers over the next couple of days, if you can give me process to follow. I can host the Prop on various systems ranging from Netbook to i7's if we think that will make any difference. I just need to install Go on the ones that are lacking!

Glad you are making progress - my resources have been diverted for a while.

prof_braino
05-21-2012, 01:06 PM
It did not log your connection attempt.

I can access from my android phone (with wireless off, so it goes through the phone company) and I can see the outside IP address, so I think it should work.

Sometime today I should be able to put up the format for the data Sal is looking for. Lots of projects active today!

mindrobots
05-21-2012, 01:18 PM
Must be a corporate firewall issue.

I just accessed your Go channeling Propeller from telnet on my iphone via the 4G network - ok, that's just pretty darn cool!!

mindrobots
05-21-2012, 04:33 PM
I'm playing with the new code as I enjoy a quiet deskside lunch and have a question:

when I do cog? ro see what's gogin on, I get this:



Prop0 Cog3 ok
cog?
Cog:0 #io chan:1 PropForth v5.0 2012JAN09 14:30 0 0(0)->6(0)
Cog:1 #io chan:1 PropForth v5.0 2012JAN09 14:30 0 1(0)->6(1)
Cog:2 #io chan:1 PropForth v5.0 2012JAN09 14:30 0 2(0)->6(2)
Cog:3 #io chan:1 PropForth v5.0 2012JAN09 14:30 0 3(0)->6(3)
Cog:4 #io chan:1 PropForth v5.0 2012JAN09 14:30 0
Cog:5 #io chan:1 PropForth v5.0 2012JAN09 14:30 0
Cog:6 #io chan:8 MX_SERIAL 6(0)->0(0) 6(1)->1(0) 6(2)->2(0) 6(3)->3(0) 6(4)->6(4) 6(5)->6(5) 6(6)->6(6) 6(7)->6(7)
Cog:7 #io chan:1 SERIAL 7(0)->6(8)
Prop0 Cog3 ok


...and I can open up 4 session to COG0 through COG3. Is it possible to make COG4 and COG5 available for general use via the mux channels? We seem to have lost them somehow. there I/O isn't linked anywhere but they are still running the interpreter and haven't been tasked to run a word like COG6 and COG7. The mux channels that should be theirs are looped back to themselves.

Just a curiosity...and of course, it's always good to have all the Cogs you can get!

prof_braino
05-21-2012, 10:42 PM
...and I can open up 4 session to COG0 through COG3.

Is it possible to make COG4 and COG5 available for general use via the mux channels?

We seem to have lost them somehow. there I/O isn't linked anywhere but they are still running the interpreter and haven't been tasked to run a word like COG6 and COG7.

The mux channels that should be theirs are looped back to themselves.

For this BETA and the tests, it hard wired for cog0-cog3 to channels for the tests.

COG4 and COG5 are not assigned, you can use these to talk to peripherals and use the channels to communicate with the PC.

There will be support o change all this when the 5.3 public release comes out.

prof_braino
05-21-2012, 11:05 PM
To any folks following progress:

The CSP channels work is now being discussed in the main propforth 5.0 thread.

http://forums.parallax.com/showthread.php?138399-Propforth-5.0-is-available-for-download&p=1099766&viewfull=1#post1099766

The CSP channels (or Go-channels if you think this does not include enough of the rest of the CSP book yet) is being rolled into the regular propforth kernel support and is in BETA test now. Each of the multiple channels looks like its faster than the single channel used to be; the optimizations to the serial driver more than make up for 8 to 32 channels sharing the serial line. This is still BETA and synchronous over asynchronous, when the Go-Channels support is moved to the Ethernet hardware it is expected to get appropriately faster.

prof_braino
05-25-2012, 01:15 AM
One last bit that is specific to CSP channels.

We started collecting numbers from the beta testers on throughput.

http://code.google.com/p/propforth/wiki/PF521BETAthroughput

It might be that the number of CPU's on the workstation incrementally affects throughput; and the number of channels has a sweet spot around 8 or 16 channels from the prop side. The beta supports up to 32 channels at this time, this may be adjusted as we get more data. We might have more data by the weekend.

You can telnet to my rig and run the tests on workstation with 1 CPU and 32 channels on the prop.

Telnet to 71 201 87 230 : 4000
hit control C

If nobody else is running the tests, the menu should come up and allow you to run the tests with various parameters.

mindrobots
05-30-2012, 03:43 AM
For anybody playing at home, trying to wrap your head around GO, this might help - only $3.03 for your Kindle

http://www.amazon.com/The-Way-Introduction-Programming-ebook/dp/B0083RVAJW/ref=tmm_kin_title_0?ie=UTF8&m=AG56TWVU5XWC2

mindrobots
06-04-2012, 01:48 PM
I've added a performance file for 2.5gHz I5 running Win7 with 8 channels to the wiki.