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.