Free Developement tools from XMOS

A short rummage around the Xcore site lead me to The XCore Open Source Project and the Xcore Github repo, which as an open source advocate, I found very encouraging.  I also noted the contributor's agreement  which goes beyond forking Github repos and allows developers to contribute more directly back to the company sources.  I see this as a sign that open source interest at Xcore is rather more substantial than the "throw code over the wall" kind of openness which is unfortunately common.

Which leads me to a couple of questions:

1. Is the impression I've gained above correct?
2. Are XMOS devices fully documented so that OSHW communities can develop around these devices and create their own complete toolchains to program them?

Question 2 relates to the uncomfortable situation we presently have with FPGA manufacturers, none of which provide complete programming information for their devices so that it has been impossible for the community to develop full toolchains for them.  This has effectively extinguished open source progress in that area.

If the answer is "Yes" to both questions then this is going to be of interest to many.

===

Addendum:  I had asked about unit availability earlier too, but the answer was right here at Farnell UK, 6 different devices all in stock!  Excellent!

Morgane they contributed quite heavily at one point to the OSHUG guys and attended several of their meetings that I unfortunately missed

There are several guys doing some 3D printer stuff using the XMOS rather than Arduinos.

Also I've found the content of the Xcore site to be very good .. my only issue was the number of parked or stale projects that I spotted  as I was looking for similar stuff that I was doing at the time.

Morgane they contributed quite heavily at one point to the OSHUG guys and attended several of their meetings that I unfortunately missed

There are several guys doing some 3D printer stuff using the XMOS rather than Arduinos.

Also I've found the content of the Xcore site to be very good .. my only issue was the number of parked or stale projects that I spotted  as I was looking for similar stuff that I was doing at the time.

John Alexander wrote:

 

Morgane they contributed quite heavily at one point to the OSHUG guys and attended several of their meetings that I unfortunately missed

I noticed the XMOS talk listed on the OSHUG event calendar, but when I looked on Youtube earlier today I couldn't find a video of that presentation.  I'll look deeper tomorrow.

I've been examining technical details of the XMOS architecture in the last few hours and I'm getting excited --- this device family really is a pretty close descendant of the transputer, as claimed!  For anyone with background in that golden age of parallelism "done right", all I/we can say is "It's about time!!!".  The transputer was so far ahead of what anyone else was doing with parallelism in the 80's that it probably fell out of the Tardis.

It's no surprise that XMOS is so strongly related to the transputer of course, since David May is the XMOS CTO.  He has many interesting documents and presentations on his personal website, worth checking out.

Multiple cores, inter-core links on-chip and between chips, hardware thread scheduler ... this is where we should have been for the last 40 years.  I hope it takes off and remains this time, and we don't have to wait yet another 40.

Regarding my questions, the sense I'm getting from the technical documentation is that these devices are completely open.  Hopefully XMOS Support will confirm my question #2 some time, but so far I'm very hopeful that these are devices that the OSHW + FOSS community can support fully.

And finally I'll end with a beautiful quote from David May, unrelated to XMOS but exactly reflecting what lots of us have said in various threads:

David may wrote:

 

"Software efficiency halves every 18 months, compensating for Moore's Law."

So true.  

Ha yes agreed, thanks for the link to David's site.

For the longest time they were more accurate about the Cores thing i.e. your single CPU would have up to 8 threads and a hard realtime scheduler.

You could have up to 4 real CPUs on each Package giving you 32 threads.

However with every one gone core crazy they felt it better marketting to call each context a core so all of a sudden your chips can suppport 8-32 cores remember bigger is better