This is yeoman work, a mighty step forward, especially for demos. My quibble (and it's really with the Transterpreter) is, to quote you: "it is just not fast on a Raspberry Pi." I think I saw that coming after looking at some Transterpreter commstime results. I don't think it is an essential characteristic.
This is probably a lot of work, but would it be possible to revisit the Transterpreter? In the INMOS Compiler Writer's Guide, it shows the assembly commands coming in structured clumps, each corresponding to a very clear occam primitive. Since occam is such a flat language, it ought to be possible to go through output of the occam compiler and recognize these clumps, thus decompiling to the point of exposing the essential process and communication structure. This semi-source could then be implemented on the target using its native capabilities, once target-specific techniques are designed to do the short list of critical occam primitives. Maybe blocks of pure sequential code could even use LLVM, if it could be purified of its stackiness. It should certainly be possible to map a "PRI PAR" onto interrupt code.
I would expect that could give a speed improvement of tenfold or more. It ought to work especially well on chips like the XMOS and the Adapteva, whose primitives are already very close.
Larry
On Jun 27, 2013, at 9:10 AM, J.B.W.Webber <J.B.W.Webber@xxxxxxxxxx> wrote:
> Hi all,
> Thanks for the various pointers.
> Fred Barnes sorted me out, and as per what Ruth suggested (it was there in the documentation) :
> I had to create a transterpreter version :
> I used :
> ./build --with-toolchain=tvm --prefix=/usr/local/kroc
>
> So it has taken me more than a day, but Kroc is now up and running and compiling Occam and producing runnable code on the Raspberry Pi :
>
> jbww@raspberrypi ~/Src/Occam/kroc-git/Work $ occbuild --program hello.occ
> jbww@raspberrypi ~/Src/Occam/kroc-git/Work $ ls
> hello hello.occ hello.tbc hello.tce
> jbww@raspberrypi ~/Src/Occam/kroc-git/Work $ ./hello
> Hello, world!
>
> So the compilation from the Git sources works fine, it is just not fast on a Raspberry Pi.
>
> As I say, I would like to offer fully updated Raspberry Pi SD cards at low cost with the Linux OS etc, Aplc concise/agile array manipulation language and the Kroc Occam, complete will all pre-requisites, up and running with TightVNC, SSH and SCP.
>
> I already have a Raspberry Pi SD card with Linux OS + Apache Web Server + TightVNC + SSH + SCP, available on Lab-Tools :
> http://www.lab-tools.com/instrumentation/#RaspberryPi
>
> My hope is that people will join me in experimenting re making these tools work together. As and when we understand how to connect the Raspberry Pis together in Beowulf clusters, this would also be included on the SD card.
> Cheers,
> Beau
>
> -----Original Message-----
> From: Sympa,pkg125 [mailto:sympa@xxxxxxxxxx] On Behalf Of J.B.W.Webber
> Sent: 26 June 2013 18:40
> To: Bob Gustafson
> Cc: occam-com@xxxxxxxxxx
> Subject: RE: Transputer - schools
>
> Thanks Bob,
> I have asked for help : it is trying to determine the endian status (it is little-endian), but there are also comments about related bits in an m4 file, so needs someone who knows what they are doing.
> Cheers,
> Beau
>
> -----Original Message-----
> From: Bob Gustafson [mailto:bobgus@xxxxxxx]
> Sent: 26 June 2013 18:21
> To: J.B.W.Webber
> Cc: occam-com@xxxxxxxxxx
> Subject: Re: Transputer - schools
>
> This link might be useful:
> http://www.raspberrypi.org/phpBB3/viewtopic.php?f=66&t=44487
>
> On Wed, 2013-06-26 at 16:55 +0000, J.B.W.Webber wrote:
>> OK, the first attempt at a Kroc build (from source) for the Raspberry Pi has just failed (after a few hours) :
>> unsupported architecture armv6l
>> I will chase more.
>> Cheers,
>> Beau
>>
>> -----Original Message-----
>> From: J.B.W.Webber
>> Sent: 26 June 2013 16:35
>> To: 'Larry Dickson'
>> Cc: Richard Dobson; occam-com@xxxxxxxxxx
>> Subject: RE: Transputer - schools
>>
>> That sounds excellent.
>> I am, right now, part way through building the UKC Kroc installation on a Raspberry Pi - one that already has the aplc array software compiled and running on it. If this works :
>> I aim, with the permission of Peter and the Kent group, to add this to the list of software I will make available on pre-configured plug-in SD cards (with OS) for the Raspberry Pi, at a slight mark-up over the cost I will have to pay someone to sit there making copies of the SD card.
>> Cheers,
>> Beau
>>
>> -----Original Message-----
>> From: Larry Dickson [mailto:tjoccam@xxxxxxxxxxx]
>> Sent: 26 June 2013 16:28
>> To: J.B.W.Webber
>> Cc: Richard Dobson; occam-com@xxxxxxxxxx
>> Subject: Re: Transputer - schools
>>
>> Beau and Tony,
>>
>> I think "occarm" and channel-to-native mapping for Epiphany, etc, are great ideas. The key is to present something people can hack with - using "ordinary" tools with a little boost. Thus, occam functions (at least at first) as pseudocode. The hummocks in the path are:
>>
>> (1) establishing communication superstructure
>> (2) loading executable code
>> (3) assemble resources and start
>> (4) communicate and run
>> (5) shut down cleanly and return resources
>>
>> and communication channels/links should be EXTREMELY general so people can do real stuff.
>>
>> If anyone is interested, I am going to try to launch a Kickstarter project to do some of this. Go to
>>
>> http://www.LAZM.org
>>
>> and follow the "Kickstarter draft link". (It's not live yet, only a preview.)
>>
>> Larry
>>
>> On Jun 26, 2013, at 4:37 AM, J.B.W.Webber <J.B.W.Webber@xxxxxxxxxx> wrote:
>>
>>>
>>> -----Original Message-----
>>> From: Sympa,pkg125 [mailto:sympa@xxxxxxxxxx] On Behalf Of Richard Dobson
>>> Sent: 26 June 2013 10:17
>>> To: occam-com@xxxxxxxxxx
>>> Subject: Re: Transputer - schools
>>>
>>> On 26/06/2013 08:21, Tony wrote:
>>> ..
>>>>
>>>> Maybe what we need is "occarm" for the Raspberry PI?
>>>>
>>>>
>>>
>>> That would be a great thing to have. Of course the R-Pi already has a parallel processor in the form of the built-in GPU (in the Broadcom chip). Unfortunately there is little scope for programming it directly.
>>> Not exactly CSP-ready, but there are many important/interesting massively-parallel tasks which could be explored. If Broadcom could be persuaded to provide some low latency GPU-based FFT operations, and maybe a few other vector-based arithmetic ops, I am sure a phase vocoder could be got to run in real time on the R-Pi, with enough spare CPU to do some interesting things (such as pitch shifting) with it.
>>>
>>> Richard Dobson
>>>
>>> __________________________________________
>>>
>>> On 26/06/2013 08:21, Tony wrote:
>>> ..
>>>>
>>>> Maybe what we need is "occarm" for the Raspberry PI?
>>>>
>>>
>>> That would be great.
>>> For the Raspberry Pi and Adaptva Parallella we are talking standard Linux host - so presumably quite simple I would have thought.
>>> What will probably be significantly harder is porting Occam so it can say run in the Adapteva multi-cpu Epiphany chips.
>>>
>>> It is to Occam that I look for providing a "harness" in which to embed concise/agile array processing nodes.
>>> So questions arise :
>>>
>>> How difficult will it be to link the communication channels provided by such an Occam harness in a multi-core processor to the pipe input/output of the array processing nodes at each core ?
>>>
>>> How difficult will it be to use the communication channels in a Beowulf Cluster from Occam ?
>>> Cheers,
>>> Beau Webber
>>> www.Lab-Tools.com
>>>
>>>
>>
>>
>
>