Re: Transputer Development System, 2006? (aka Sony PS/3 runs multi-core Linux)

[tjoccam@xxxxxxxxxxx]

> Hi Larry,
>
> The interpreter runs in userspace on the actual powerpc.  (the cell
> consists of one powerpc
> and 8 spu's - vector processing units).  The vector processing units
> themselves do not run
> any part of the linux kernel and are available for use by 'userspace'
> programs which run
> directly on the vector processors.  Essentially what the
> interpreter/runtime does is it provides
> scheduling and a few other things to occam code that is put on them.
>
> What you've described sounds like it could be a bug in gcc?  Could that
> be correct?

This is how I understand it: Our contractor was writing a Linux 2.6 RAID
driver, in which a necessary operation was finding quotient and remainder
of two 64-bit integers. He wasted a month (!) trying to trace the bug,
before he tested this divide and found that it always yielded zero, no
matter what the divisor or dividend were. Due to hardware shortcomings, a
true 64-bit integer divide had to be done by a function call, and the
kernel developers decreed that they would not allow a function call to be
used as an elementary operation (?), so the actual specification required
that the divide "operation" should be nulled out. As far as I know this is
still true - though it seems to me it should be illegal from the C
language definition point of view. The only solution is to search up all
divides in the source and replace them by explicit function calls.

>
> Please let me know if I answered your question, as I not sure that I have.
> Damian

Yes, this is at least a starting point. It seems to me that the real occam
is on the spus. The host is in a position more analogous to the PC in a
B008-based Transputer system. That minimizes the danger of dependency on
Linux, which I think would be almost as bad for occam progress as
dependency on OO, while at the same time making all the tools of Linux
available. Nice - although it would be good to make sure that, as close as
possible, the host code should ALSO be robust, well-behaving occam (this
was not done in the Inmos software for B008-based systems).

Larry

>
> tjoccam@xxxxxxxxxxx wrote:
>> Question: Would the proposed interpreter or TDS lookalike run in kernel
>> space or user space from the Linux point of view? I can see arguments
>> for
>> both. If in user space, it's probably easier to write and better
>> supported, but slow and subject to vagaries and lack of CSP robustness
>> of
>> the kernel. If in kernel space, it has to deal with weirdness like the
>> fact that the Linux 2.6 kernel compiler nulls out any division of 64-bit
>> integers (though this may not be true in the Cell; it was discovered, on
>> a
>> project I was working on, to be true in the X86 series).
>>
>> Larry Dickson
>>
>>
>>> Hello,
>>>
>>> Indeed I am working on getting occam-pi running on the cell.  Aside
>>> from
>>> yellow dog, I have read that redhats FC5 (with some cell specific bits)
>>> is downloadable from sony.  Thanks for the pointer to the Yellow Dog
>>> site, I am not the biggest redhat fan so when I do get around to it
>>> running
>>> yellowdog could be a viable alternative!
>>>
>>> I do agree though, the PS3 would be a great development system to have,
>>> once they start selling it in Europe.  It definitely beats the
>>> overpriced
>>> blade servers that IBM is selling....
>>>
>>> If I remember correctly the versions of the cell shipped for the PS3
>>> will have one or even two of the 'spu' vector processing cores disabled
>>> in the
>>> actual units in order to increase the yield when manufacturing the
>>> processors.  Still 6 or 7 cores is still nice to play with.
>>>
>>> I can't wait to get my hands on one.  For now it'll still just be the
>>> cell system simulator.
>>>
>>> Glad to hear people are interested though :).
>>>
>>> Cheers,
>>> Damian
>>>
>>> Matt Jadud wrote:
>>>
>>>> Hi Andrew,
>>>>
>>>> Damian Dimmich at is working towards this; he had a paper in CPA 2006
>>>> that explores just this issue, and has a working port of the
>>>> Transterpreter (a small, portable runtime for occam-pi) to the Cell.
>>>>
>>>> http://www.transterpreter.org/papers/dimmich-jacobsen-jadud-cpa-2006.pdf
>>>>
>>>> Running on top of Yellow Dog would be the easy way in; Damian is
>>>> exploring code distribution and code generation for multi-core targets
>>>> like the Cell, and (currently) has 9 separate instances of the runtime
>>>> environment on a single CPU.
>>>>
>>>> See the paper for more details; also, since Damian is on this list, he
>>>> might have additional comments or be able to address more specific
>>>> questions that you or others might have.
>>>>
>>>> Cheers,
>>>> Matt
>>>>
>>>> Andrew Delin wrote:
>>>>
>>>>> Team, I thought this was interesting.
>>>>>
>>>>> Why might we be interested in the release of Sony's PS/3 games
>>>>> console?
>>>>>
>>>>> Because it contains a multi-core Cell processor - and can run Linux.
>>>>>
>>>>> Fred and others - I am wondering if it is possible to release a KROC
>>>>> that targets this platform and takes advantage of the multiple
>>>>> processors inside the new Sony console. This would give a true
>>>>> parallel machine to run Occam-Pi. It could be used as a modern 'TDS'
>>>>> with several cores to run on.
>>>>>
>>>>> Nine cores is very tempting - and rather cheap. I understand the YD
>>>>> Linux distribution doesn't fully use all cores, but perhaps an
>>>>> Occam-Pi build could? If we can piggy back on the interest in Linux,
>>>>> perhaps we might get more interest in the process-oriented-design
>>>>> philosophy we've discussed on this group.
>>>>>
>>>>>
>>>
>>>
>>
>>
>>
>
>
>