Cell SPU Architecture Manual
Chris Thomasson
http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/76CA6C7304210F3987257060006F2C44/$file/SPU_ISA_v1.11_4Oct2006.pdf
use the sync and dsync instructions for memory barriers... simple...
Chris Thomasson
news:vsydnTHKAdbV6vDY...@comcast.com...
>
> http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/76CA6C7304210F3987257060006F2C44/$file/SPU_ISA_v1.11_4Oct2006.pdf
>
> use the sync and dsync instructions for memory barriers... simple...
here is PPC arch manuals:
http://www-128.ibm.com/developerworks/eserver/articles/archguide.html
With the PPC and SPU arch docs, along with the assembler (e.g., GAS) in
Sony's GCC compiler collection for the Cell... You should be assembling
simple programs in no time...
;^)
Chris Thomasson
news:vsydnTHKAdbV6vDY...@comcast.com...
>
> http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/76CA6C7304210F3987257060006F2C44/$file/SPU_ISA_v1.11_4Oct2006.pdf
You can create a DMA abstraction with the channel instructions':
-----
rdch - load from specific channel
wrch - store to specific channel
rchcnt - load the read count from a specific channel
and the memory barrier instructions':
-----
sync - sounds like #StoreStore for mem
dsync - sounds like #StoreLoad for mem and channels
Any thoughts?
Chris Thomasson
> "Chris Thomasson" <cri...@comcast.net> wrote in message
> news:vsydnTHKAdbV6vDY...@comcast.com...
>>
>> http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/76CA6C7304210F3987257060006F2C44/$file/SPU_ISA_v1.11_4Oct2006.pdf
>
Actually...
> and the memory barrier instructions':
> -----
>
> sync - sounds like #StoreStore for mem
>
> dsync - sounds like #StoreLoad for mem and channels
the both kind of sound like #StoreLoad barriers... Humm...
Jan Vorbrüggen
> -----
>
> rdch - load from specific channel
>
> wrch - store to specific channel
>
> rchcnt - load the read count from a specific channel
>
Sounds like a transputer at the microcode level to me...
Jan
Richard
> http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/76CA6C7304210F3987257060006F2C44/$file/SPU_ISA_v1.11_4Oct2006.pdf
>
> use the sync and dsync instructions for memory barriers... simple...
>
I know I'm a bit out of touch, but is this normal in the real world
these days?
,----
| Bits are numbered in ascending order from left to right with bit 0
| representing the most-significant bit (MSb) and bit 31 the
| least-significant bit (LSb).
`----
Bit 0 the MSB?
Wow.
jsa...@ecn.ab.ca
> ,----
> | Bits are numbered in ascending order from left to right with bit 0
> | representing the most-significant bit (MSb) and bit 31 the
> | least-significant bit (LSb).
> `----
>
> Bit 0 the MSB?
>
> Wow.
Well, why not?
After all, byte 0 occurs first in memory, and byte 1 comes after that.
When I write this sentence, the successive letters go from left to
right. So if the "W" in When is stored in location 1265, the "h" in
When will be stored in location 1266, and so on.
When I wrote the number 1265, the 1, the *most significant* digit,
appeared on the left of the string.
This bit numbering, therefore, is entirely consistent with a
*big-endian* architecture. And the PowerPC is big-endian by default
(although it uses address modification, licensed from MIPS, to permit
little-endian operation as well). This makes sense, as it was produced
by IBM and Motorola working together. The IBM System/360 was
big-endian, and so was the Motorola 68000.
It's true that the PDP-11 started the little-endian fad which was
continued in some very popular chips such as the 6502, the 8080, and of
course the 8086 and its present-day successors. Hopefully, this
confusing fad will eventually blow over.
John Savard
dave
>
> http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/76CA6C7304210F3987257060006F2C44/$file/SPU_ISA_v1.11_4Oct2006.pdf
>
> use the sync and dsync instructions for memory barriers... simple...
>
Peter Dickerson
news:1164808962.7...@n67g2000cwd.googlegroups.com...
> Richard wrote:
>> ,----
>> | Bits are numbered in ascending order from left to right with bit 0
>> | representing the most-significant bit (MSb) and bit 31 the
>> | least-significant bit (LSb).
>> `----
>>
>> Bit 0 the MSB?
>>
>> Wow.
>
> Well, why not?
>
> After all, byte 0 occurs first in memory, and byte 1 comes after that.
>
> When I write this sentence, the successive letters go from left to
> right. So if the "W" in When is stored in location 1265, the "h" in
> When will be stored in location 1266, and so on.
Since when have characters been the same size as addressable units - Unicode
on a byte addressable machine or ASCII on a word addressable machine (say).
> When I wrote the number 1265, the 1, the *most significant* digit,
> appeared on the left of the string.
So, for 987 the 9 is the most significant and the digit numbering scheme is
value dependent.
> This bit numbering, therefore, is entirely consistent with a
> *big-endian* architecture. And the PowerPC is big-endian by default
> (although it uses address modification, licensed from MIPS, to permit
> little-endian operation as well). This makes sense, as it was produced
> by IBM and Motorola working together. The IBM System/360 was
> big-endian, and so was the Motorola 68000.
>
> It's true that the PDP-11 started the little-endian fad which was
> continued in some very popular chips such as the 6502, the 8080, and of
> course the 8086 and its present-day successors. Hopefully, this
> confusing fad will eventually blow over.
Whether you number fixed sized registers from the left (msb) or right is
mostly a matter of convention. However once registers can be extended from
32- to 64-bit, say, then the left to right numbering becomes a issue unless
registers are extended on the right. Also, for numbering from the right,
there is a fixed mapping between bit number and its integer value (assuming
binary coded integers) but for leftendian bit numbers the value changes with
datum size.
Ultimately it ia all irrelevant unless bit numbers are used dynamically
although picking one convention and sticking to it will be less error prone.
Peter
jsa...@ecn.ab.ca
> > When I write this sentence, the successive letters go from left to
> > right. So if the "W" in When is stored in location 1265, the "h" in
> > When will be stored in location 1266, and so on.
> Since when have characters been the same size as addressable units - Unicode
> on a byte addressable machine or ASCII on a word addressable machine (say).
Characters *may* be addressable units, such as ASCII on a byte
addressable machine, or characters in an IBM 1401 computer.
> > When I wrote the number 1265, the 1, the *most significant* digit,
> > appeared on the left of the string.
> So, for 987 the 9 is the most significant and the digit numbering scheme is
> value dependent.
Not really. Presumably 1265 might be stored as 00001265 and 987 might
be stored as 00000987, for example.
> Whether you number fixed sized registers from the left (msb) or right is
> mostly a matter of convention. However once registers can be extended from
> 32- to 64-bit, say, then the left to right numbering becomes a issue unless
> registers are extended on the right.
It's true that the bit whose value is 2^2 would change from bit 30 to
bit 62, but it's unclear why this is a problem.
> Ultimately it ia all irrelevant unless bit numbers are used dynamically
> although picking one convention and sticking to it will be less error prone.
When bit numbers _are_ used for actual bit addressing, then the bit
numbering needs to match the architecture - from the left if the
architecture is big-endian, and from the right if the architecture is
little-endian.
This is illustrated on my web site, on the page
http://www.quadibloc.com/arch/ar0301.htm
Also, if "picking one convention and sticking to it" is less
error-prone, that is a decisive argument in favor of the use of the
big-endian convention in those parts of the world using writing systems
derived from the Greek or Roman alphabets, Devanagari, or Chinese
characters. On the other hand, countries using writing systems derived
from that of Arabic - including Pakistan and Iran - or Israel, using
the related writing system of Hebrew are using the little-endian
convention *in daily life* whenever they write texts combining words
and numerals, and for them, therefore, little-endian computing would be
consistent.
John Savard
Chris Thomasson
news:1JCdnWNrYqW0AvDY...@comcast.com...
Weird! I can download this without registration; how many others can
download this? I only had to register to get my hands on the simulator.
FWIW, registration for a IBM ID is free. Took me less than a minute to
sign-up.
ammo...@cc.full.stop.helsinki.fi
> In comp.arch Chris Thomasson <cri...@comcast.net> wrote:
> This link is to a protected area. Registration is required for access.
The Cell documentation is also available via <http://cell.scei.co.jp/>,
which doesn't require registration. (The SPU ISA manual does however to
be one point release older than the one linked above.)
-a
Chris Thomasson
>
> use the sync and dsync instructions for memory barriers... simple...
Here is the Cell Broadband Architecture manual:
You can do atomic DMA operations that are analogous the LL/SC... You use the
following instructions
getllar - basically equal to LL reserved
putllc - basically equal to SC
So, you can use lock-free programming techniques all over the place in the
Cell BE. You can design high-performance lock-free synchronization
primitives to orchestrate some things... Neat.
;^)
P.S. --
For some reason I can download the SPU arch docs and the Cell BE arch docs
without signing up for anything... I only have to signup for the Simulator.
Can anybody else get the docs without signing up?
Weird...
Chris Thomasson
If you don't really like Assembly, then this document describes a library
that might be able to help you program the Cell in C:
This lib is included with the Cell SDK. Its fairly convenient.
Richard
> Richard wrote:
>> ,----
>> | Bits are numbered in ascending order from left to right with bit 0
>> | representing the most-significant bit (MSb) and bit 31 the
>> | least-significant bit (LSb).
>> `----
>>
>> Bit 0 the MSB?
>>
>> Wow.
>
> Well, why not?
Well, it just doesnt seem right.
2**n-1 and all that.
Ian Collins
--
Ian Collins.
Chris Thomasson
news:4t7907F...@mid.individual.net...
Get the simulator:
http://www.alphaworks.ibm.com/tech/cellsystemsim
http://dl.alphaworks.ibm.com/technologies/cellsw/CBE_SDK_Guide_1.1.pdf
?
jsa...@ecn.ab.ca
> quoting me:
> > Richard wrote:
> >> ,----
> >> | Bits are numbered in ascending order from left to right with bit 0
> >> | representing the most-significant bit (MSb) and bit 31 the
> >> | least-significant bit (LSb).
> >> `----
> >> Bit 0 the MSB?
.
> >> Wow.
.
> > Well, why not?
.
> Well, it just doesnt seem right.
> 2**n-1 and all that.
Certainly, when it comes to numbering hardware pins for, say, an A/D
converter, that indeed makes a lot of sense. As noted, though, if a
computer is big-endian, it should use the same convention for numbering
bits as it does in numbering bytes in multi-byte numbers, particularly
if the architecture might ever be extended to include some form of bit
addressing.
John Savard
wind...@gmail.com
that ordering is standard on ppc machines AFAIK (at least if you dont
switch on the little endian mode). making both byte-ordering and
bit-ordering bigendian is in fact good for bitprocessing applications.
the simplest example is to store allocations in a bitmap, or also a
mytical "putpixel" for planar displays:
68k code (big-byte, little-bit ordering):
move.l d0,d1
lsr.l #8,d0
and.l #%111,d1
not.l d1
bset d1,(a0,d0)
68k code assuming it had same ordering as ppc:
move.l d0,d1
lsr.l #8,d0
and.l #%111,d1
bset d1,(a0,d0)