Re: Can XMOS do occam?

[Larry Dickson <tjoccam@xxxxxxxxxxx>]

Thanks, Adam and Herman - there are a lot of interesting points here...

On May 1, 2010, at 1:08 PM, Adam Sampson wrote:

> Larry Dickson <tjoccam@xxxxxxxxxxx> writes:
> 
>> (1) Is there an occam compiler for the XMOS XS1?
> 
> Not yet. We've heard there are plenty of people who'd be interested in
> one, but none of us at Kent have the time to do it at the moment -- if
> we could sort out some way of funding it it'd be more practical
> (e.g. one of the EPSRC commercial development grants). It'd be trivial
> to get the Transterpreter (our portable ETC virtual machine) running on
> the XS1 architecture, of course, but the performance wouldn't match XC.
> 
> If you're curious, there are two ways we could get occam running
> natively on the XS1. The easier approach would be to use the existing
> compiler, and glue Carl's ETC-to-LLVM translator to XMOS's LLVM-to-XS1
> backend, translating the ETC communication instructions into the XS1
> equivalents directly. The harder approach would be to add an LLVM
> backend to Tock, our new occam compiler, which has been on the to-do
> list for a while, but would be a better option in terms of future
> maintainability...

The main thing I'm after is "priority 0" in the Transputer sense. I had understood that the Transterpreter did not offer this, but maybe I am behind the curve here. I love embedded processors where you can get at the ISRs at the top level of your program instead of burying them in drivers. Transputer PRI PAR code was the best example of this.

> 
>> Is the limitation on thread count real, or is it an artifact of some
>> software behavior?
> 
> It's a hardware limitation. There's no software scheduler yet (it's
> harder than it sounds, since one of the advantages of the pool of
> hardware threads is the low-latency response to events), so you're
> limited to 32 processes on an XS1-G4.

I don't see the difficulty, unless they are trying to be supermen and share the scheduler across hardware threads. Be a little unbalanced, do hw threads 0 through 31, and then a PAR inside hw thread 0 gives you thread 32, etc. If you're within a single hardware thread, surely you can use the Transputer's scheduling design which is simple and robust and pretty nice latency-wise.

> 
> (No idea about placement across multiple chips; it didn't when I last
> used the tools but they were working on it.)

This was completely and elegantly solved by Inmos occonf and their .PGM files, as long as there is a network booting worm.

> 
>> (4) A further point: I have been studying the RepRap 3D printer, and
>> have come to its Sanguino3G serial protocol definition, which has a
>> master controller (an Atmel-based Sanguino) driving several slave
>> controllers - and using polling!
> 
> We ported the Transterpreter to various Arduino boards including the
> Sanguino last summer, and a replacement for the RepRap firmware in occam
> is something that Matt Jadud was considering as a student project. It
> doesn't need XS1-grade computing power; the AVR is more than
> sufficient.
> 
> The existing RepRap firmware really is complete junk! The RepRap design
> generally is pretty awful... there are much better 3D printer kits out
> there if you're after one.

They've apparently abandoned the Java monster and are going to a simpler basket of little programs. I've only just put my toe in the water, but I did find the Arduino code, when expanded into assembly, reveals lots of nice easy-to-understand ISRs.

Larry

> 
> Here's a presentation I gave in January about occam on the Arduino and
> other AVR boards, with pictures of Matt's RepRap:
>  http://www.cs.kent.ac.uk/research/groups/plas/seminars/20100118-ats.pdf
> 
> Thanks,
> 
> -- 
> Adam Sampson                                         <http://offog.org/>
>