 |
Faster than a speeding bullet: And still the champ ...
... at half the energy: Or, to paraphrase another cartoon, the cat tried but couldn't catch the bird. The IBM-constructed LANL Roadrunner (see disclaimer on name use) is still No. 1 on the Top500 Supercomputing Sites list, the ninth time in a row an IBM machine grabbed the top spot. At 1.105pflops, the LANL Roadrunner just beat out the Cray XT5 QC Jaguar (at 1.059pflops), the second plus-pflops machine. LANL Roadrunner also was roughly twice as energy-efficient as No. 2 (IBM took the energy effiency prize in the list -- the 20 top systems belonged to Big Blue).
Securing an energy future with performance
Grabbing the advantage through the ability to simulate: Besides cutting the cost of finding oil, the Repsol Kaleidoscope project is also hoping to demonstrate that the ability to rapidly develop and display complex simulations (like the company's doing with its Cell/B.E.-based system) can be the key to securing the world's energy future. Repsol just fired up its system to add some speed to advanced seismic imaging so the company can better visualize oil accumulations lying deep beneath the ocean floor.
Categories
: [ Cell | news ]
Nov 18 2008, 12:56:00 PM EST
Permalink
|
Games people play: PS3 in the "terrific" twos
November 17 the birthday: According to Sony Insider, there are nearly 17 million PS3 systems around the world. That's an installed base!
Categories
: [ Cell | news ]
Nov 18 2008, 12:53:00 PM EST
Permalink
|
Clear conference calendars: SC08 about fast networking
Going on right now: SC08 (November 15-21, Austin, Texas) is all about fast interconnects, including
- QLogic's quad-rate Infiniband switches based on a new ASIC with 36 ports running at up to 40Gbps.
- Alacritech's upgraded 10Gb Ethernet adapter card that can be used for partial offload of TCP/IP processing.
There's also a posting session by the LANL authors of "Entering the Petaflop Era: The Architecture and Performance of Roadrunner," plus scads of papers detailing programming and networking techniques to leverage a massively parallel, multicore system and that demonstrate practical uses of supercomputing power, from tire development to electron transport systems. It is a bonanza of knowledge!
Categories
: [ Cell | events | general | news ]
Nov 18 2008, 12:52:00 PM EST
Permalink
|
It came from the Lab: Non-genetic use for DNA
Turning DNA strands into fiber optical cables: ChalmersUofTech researchers want to praise their new technique because it allows them to easily convert strands of DNA into very small fibre optic cables. The key is assembling chromophores (molecules that absorb and pass light) in a chain. The group used a YO chromophore that has a strong affinity for DNA molecules -- it hungrily jams itself in between the basepair rungs of DNA strands. Just like that, you've got a 20nm long/1-2nm wide optical wire, the perfect size for microchip interconnects. They placed a molecule that would accept light on one end and one that would emit light at the other.
A downside is that in early testing, it shows the strands naturally transmit about 30 percent of the light received; also, since they are naturally replicating, precise positioning along the strand can't be acertained so variations could exist. On the extraplus side, though, if one chromophore gets damaged, another will naturally take its place so they are self-healing. Some uses: Artificial photosynthesis to replace solar panels, optical computers.
All the antimatter you can eat
Cooking with lasers: Lawrence Livermore researchers have a recipe for antimatter -- shoot an intense laser through a pinhead-size gold bit and whooosh! 100 billion particles of antimatter (positrons). The laser drives accelerated ions (loose electrons) through the gold where they interact with the gold nuclei. The interaction makes the electrons emit pure energy packets which decay into matter and antimatter. It's the concentration of energy and mass that produces the copious amounts of antiparticles -- researchers have done this trick before but they'd only tried it with thin sheets of gold and less-intense lasers.
Categories
: [ general | news ]
Nov 18 2008, 12:51:00 PM EST
Permalink
|
Conventional wisdom alert: Evolution just happens, man
Guess what? Evolution evolves: Princeton scientists looking at a group of proteins that help cells burn energy found something else -- evidence that evolutionary changes don't take place gradually and randomly under pressure from natural selection. In other words, the changes evolution engenders may be more directed than scientists originally thought -- but unlike "intelligent design," the "intelligence" comes from within the organism itself. (Intelligent design believers can stop reading now ... the group says this is not evidence of an exterior intelligence driving evolution; also, it is not evidence that the DNA itself is "thinking.")
What they are proposing is that evolution isn't as random as originally thought. They discovered that their electron transport chain proteins were self-correcting imbalance imposed on them via artifical mutation. A math analysis showed that these proteins were making tiny corrections all the time, pushing the organism to a more fit state.
Are semi makers really software companies?
Opinion: Software is the elephant in the room: Michel Genard thinks that if semiconductor manufacturers reinvented themselves as software-centric companies, they would be able to solve many of their biggest operational problems and to add the differentiating qualities to their individual organizations they will need to stand out in the future of the semi business. Genard says that if you examine semi industry constraints, you'll see that software glitches are the basis of most problems like product delays and budget overruns. Virtual software development could give a semi company a jump on the competition by allowing them to find and eliminate problems before they happen by working with their RTOS partners, long before the silicon is ready. (One product produced this way was the new Freescale QorIQ P4080 multicore processor.)
Categories
: [ general | news ]
Nov 18 2008, 12:47:00 PM EST
Permalink
|
Oddments: Zapping refuse
Heating your home with plasma-vaporized garbage:
We've discussed it before -- plasma gassification -- now it seems Florida's St. Lucie County and company Geoplasma are developing the first US plasma gasification plant to vaporize 1,500 tons of trash a day and product 60mW of turbine-spun electricity (50K homes worth of juice). The plasma involved is 10K degrees F (5,500ish C/5,800ish K).
For those without, fast Internet over powerlines
IBM and energy company rethink an old idea: IBM and International Broadband Electric Communications have agreed to have IBM install Broadband over Power Line (BPL) networks at electric cooperatives in the eastern US so IBEC can provide broadband services to underserved residents in rural America.
A step closer to the flying car?
New from the military mad scientist division: Darpa announces the Personal Air Vehicle Technology project, an attempt to build a working prototype of a two-to-four-passenger, military-suitable flying car that can drive on roads or take off like a helicopter. Darpa is shooting for 60/150MPH (land/air) with a flight time of two hours on a single tank. The group figures it'll need "morphing wings" for a smooth transition from road to sky; "optimized disk loading" propulsion (whatever that is); and strong flight control software (a wing and a prayer and a programmer?). At least actor Avery Brooks can relax -- he will probably get that flying car.
Categories
: [ general | news ]
Nov 18 2008, 12:44:00 PM EST
Permalink
|
Cell/B.E. Security SDK: Six programming examples
|
Cell/B.E. Security SDK: Six programming examples
|
INFObomb
|
|
A quick look at six programming examples in the Security SDK 3.0.
|
|
More INFObombs
|
|
|
|
|
|
The source code and makefiles for the samples associated with the Cell/B.E. Security SDK are
installed into the /opt/cell/sdk/prototype/src/examples/isolation directory. Each of the
samples has an associated README file. There is also a top-level README in the
src/samples/isolation directory introducing the structure of the sample code source tree. In
addition, there are a number of useful PDF documents in the /opt/cell/sdk/docs directory including
a programming tutorial.
Code specific to a given Cell/B.E. processor unit type is in a corresponding place within a given
sample's directory:
- sample's directory for code compiled for execution on the PPE.
- spu/ subdirectory for code compiled for execution on an SPE.
In this last installment on the Cell/B.E. Security SDK, we'll show where you can find six code examples to demonstrate using the Security SDK:
- Changing the default compiler.
- Synching the system root directory for recompiles (for simulator users).
- Demonstrating how a SPU program can perform file operations.
- Copying encrypted data and using system memory as a secure shared buffer.
- Copying Encrypted Data with Replay Protection.
- Demonstrating a fully encrypted SPU program.
Change the default compiler
In the /opt/cell/sdk/buildutils are some top level makefiles that control the build environment
for all of the samples; you'll also find make.iso.footer which controls the build environment for the emulated
isolated SPU.
The Cell/B.E. Security SDK samples are built using
/opt/cell/sdk/prototype/src/examples/isolation/Makefile; these samples are not built using
any makefile present above this directory (except make.iso.footer). All of the samples have their
own makefile, but the common definitions are in the top-level makefiles.
The build environment
makefiles are documented in /opt/cell/sdk/README_build_env.txt.
Environment variables in the /opt/cell/sdk/buildutils/make.env makefile are used to determine
which compiler is used to build the samples.
Synch system root
Building the libraries and samples copies output files into a special directory named
/opt/cell/sysroot. This directory has a very similar structure to a normal system root directory (that
is, /) and contains the usual subdirectories such as /bin, /usr, and /etc. Compiled binaries of
examples are deployed into directory
/opt/cell/sysroot/opt/cell/sdk/prototype/usr/bin/examples.
After logging on as root, this sysroot directory can be synched up with the simulator sysroot image
file using the install script with the synch task. The command is /opt/cell/cellsdk_sync_simulator
and is useful whenever a library or sample has been recompiled. This script reduces user error by
providing a standard mechanism to mount the system root image, sync the contents of the two
corresponding directories, and unmounting the system root image.
Perform file I/O
This example demonstrates how an SPU program can perform file operations (like creation, reading,
updating, deletion) using either POSIX or C99 functions. It is described in the code for the iso_fileio
sample provided as part of the SDK in the directory
/opt/cell/sdk/prototype/src/examples/isolation/iso_fileio.
Copy encrypted data
This example demonstrates how to use system memory as a secure shared buffer. The SPU
application encrypts a plaintext in LS and copies out the ciphertext to the system memory. It also
shows decrypt_in usage (example) where the SPU application copies the cipher text from the system memory
back into the LS and decrypts it. Code for this sample is located under
/opt/cell/sdk/prototype/src/examples/isolation/iso_enccopy.
Copy encrypted data (advanced)
Or, copying encrypted data with Replay Protection. This example is a more advanced version of the previous one; it uses the nonce to prevent replay
attacks on the data copied out. (Nonce, or number once used, is often a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks.) Code for this sample is located under directory
/opt/cell/sdk/prototype/src/examples/isolation/iso_enccopy2.
Fully encrypted SPU program
This sample demonstrates a fully encrypted SPU program; it uses additional variables in the
spu/Makefile:
ISO_ENCRYPT_SEC := ALL
ISO_KERN_KEY = /etc/pki/cell-spu-isolation/loader/loader.app_encrypt_key.public.pem
The variable ISO_ENCRYPT_SEC specifies which sections of SPU program image to encrypt; it can be set to
ALL or .text. The variable ISO_KERN_KEY specifies the public key to which SPU program image is
encrypted.
Code for this sample is located under directory
/opt/cell/sdk/prototype/src/examples/isolation/iso_encrypted.
Please note that with the publicly available Security SDK, cryptographic encryption is not being used
and thus the key is ignored by the SPE Secure Application build tool which simply XORs the
application image with a static value. In the CDA version of the SDK, cryptographic encryption is
used and the ISO_KERN_KEY is used in the process.
Taken from the Cell BE Security SDK v3.0 Installation and User's Guide. Download the SDK. Check out some reference guides in the Cell Resource Center SDK library.
|
|
|
|
|
|
ORIGINAL DOCUMENTATION | DOWNLOAD SDK |
SDK LIBRARY |
MORE INFObombs |
BACK to BLOG |
BACK to ZONE
|
|
|
Categories
: [ Cell | infobombs ]
Nov 17 2008, 12:00:00 PM EST
Permalink
|
Faster than a speeding bullet: LANL Roadrunner makes TIME Top Ten list ...
... of technology for 2008: Yes, the LANL Roadrunner (see disclaimer for name usage) is number 10 on TIME magazine's "Best Inventions of 2008" list:
On May 26, at 3:30 in the morning, a $133 million supercomputer nicknamed Roadrunner broke the long-sought-after petaflop barrier: 1 quadrillion calculations per second. Built by IBM for Los Alamos National Laboratory, Roadrunner will be used primarily to simulate the effects of aging on nuclear weapons. Next up: the exaflop barrier.
The other nine before LANL Roadrunner:
- The Retail DNA Test.
- The Tesla Roadster.
- The Lunar Reconnaissance Orbiter.
- Hulu.com.
- The Large Hadron Collider.
- The Global Seed Vault.
- The Chevy Volt.
- Bullets That Shoot Bullets.
- The Orbital Internet.
LANL Roadrunner takes a Tekne Award
A win for superior computing in Minnesota: IBM-Rochester received a Tekne Award for the LANL Roadrunner supercomputer (see disclaimer for name usage). Specifically, the company won the IT-Software & Hardware, Communications and Infrastructure award for the hybrid that is the first computer to break the petaflop barrier. (A Tekne Award acknowledges companies and individuals who have demonstrated superior technology advancement and leadership in Minnesota. There is no requirement that this superiority has to also manifest itself outside of MN, but it usually does.)
Catching up with LANL Roadrunner?
Is Cray closing in?: Oak Ridge National Labs just tested its newly installed AMD-based Cray XT5 supercomputer ("Jaguar") and it peaked out at 1.64pflops, just under the 1.7pflops peak for the Cell/B.E.-/Opteron hybrid LANL Roadrunner (see disclaimer for name usage), in essence making it the world's fastest computer for (non-military) science research.
Categories
: [ Cell | news ]
Nov 11 2008, 12:17:00 PM EST
Permalink
|
Design on a dime: Folding@home awarded for its good design
PS3 at heart of distributed, sharing system: The StanfordU Folding@home project has just grabbed the Japanese Ministry of International Trade and Industry's Good Design Award for outstanding design in industrial and consumer products. (Folding@home is a distributed PS3 network, chock full of Cell/B.E. processors and visualizer software, designed to let users share idle PS3 time with scientists studying protein folding.) According to the jury: "Analysis of proteins for the purpose of shedding light on diseases is just one example of solution design for social issues, a stance that indicates the direction that design should take in the future. Motivating the people who will be involved in these studies will be the key to success, but the program functions well as an idea for making participation in this project visible on a global scale."
Categories
: [ Cell | news ]
Nov 11 2008, 12:14:00 PM EST
Permalink
|
Games people play: Two perspectives on simulation performance
Per cost and raw performance: In the excellent ars technica thinkpiece "Putting the PS3's brain to work," Matt Ford details an article from the Journal of Physical Review E: Statistical, Nonlinear, and Soft Matter Physics ("Accuracy of the lattice-Boltzmann method using the Cell processor") that discusses the computer simulation transition from faster and faster single processors to large multiprocessing systems. The article compares how two Cell/B.E. systems -- the PS3 (best performance per cost) and an IBM QS20/QS21 blade server (best for raw performance) -- handles simulations. The group was trying to determine whether the Cell/B.E. processor's inability to accurately represent floating-point numbers caused a significant loss of precision in the simulations.
(Lattice Boltzmann is a relatively new simulation technique for complex fluid systems. Traditional methods solve the conservation equations of macroscopic properties -- mass, momentum, and energy -- numerically; LB models the fluid consisting of fictive particles and such particles perform consecutive propagation and collision processes over a discrete lattice mesh. Because of its particulate nature and local dynamics, LB has advantages in dealing with complex boundaries, incorporating of microscopic interactions, and parallelization of the algorithm.)
Categories
: [ Cell | news | papers ]
Nov 11 2008, 12:12:00 PM EST
Permalink
|
Trends and tradeoffs: YDL says hello to Fixstars Solutions
Terra Soft becoming part of Fixstars: Terra Soft Solutions (Yellow Dog Linux) and Fixstars (a company specializing in Cell/B.E. software) announced that Terra Soft has been bought by Fixstars and will be known as Fixstars Solutions. Many YDL users are acquainted (at least peripherally) with TSS's CEO Kai Staats; Staats will continue on as Fixstars Solutions's COO. The original Fixstars provided Cell/B.E.-based solutions in Japan using YDL, so the company thought it might be a good match to bring YDL development into the fold. The new company will continue work on Linux for the Power architecture with a primary focus on Cell/B.E. systems.
Categories
: [ Cell | news ]
Nov 11 2008, 12:10:00 PM EST
Permalink
|
Product watch: Toshiba's upscaling TV
Cell/B.E. speed makes HD TV prettier: Why are we talking about television? Because the heart of the Toshiba Regza 42ZV555D and 46ZV555D TVs -- the first "upscaling" TVs according to the company -- is the Cell Broadband Engine processor.
What's "upscaling"? HD TVs have something called an upscaler built in -- what it does is convert video that is shot at a different resolution to the screen to fit the screen (if you didn't, you'd get a small picture in the center of a big screen). The upscaling hardware:
- Stretches the picture to fit.
- Applies video processing to make the picture look as good as possible.
- Applies processing to convert standard-definition, interlaced pictures into progressive ones because LCD and plasma TVs can only display a progressive image. (With an interlaced image, you see the odd lines then the even ones; with a progressive image, you see all the lines sweeping left to right at the same time.)
Where does the Cell/B.E. processor come in? Faster processing, better quality.
Categories
: [ Cell | news ]
Nov 11 2008, 12:08:00 PM EST
Permalink
|
From the Cell/B.E. Architecture forum
This blog-based column looks at some of the more interesting problems and challenges posed recently in the Cell Broadband Engine Architecture forum.
jlabellan84 wants to know if SDK 3.0 apps will play nice with SDK 3.1: I have two questions about SDK3.1:
- Are there problems with backward compatibility? That is, will my applications developed in SDK3.0 run in SDK3.1? and my ALF applications?
- Is it possible to update my PS3 with SDK3.1?
[IBM SDK Service Administrator]: Yes, 3.0 applications will run on 3.1. While we have not done testing on PS3s, it should work the same as 3.0.
|
Can you answer this one? Does the PS3 Cell/B.E. support all of the Security SDK features? Answer.
|
redMoon started this in September 2008 when he asked for help to install SDK 3.0 on a PS3 with Fedora Core 8. There are now three forum pages of troubleshooting advice, including whether all the ISOs have been mounted (and how you tell); how to do some manual installation; device file name changes; why installing numactl and blas is important; the whys of using ppu-embedspu instead of embedspu; and more.
Can you answer this one? What's a difference between a get with barrier (GETB) and a get with fence (GETF)? Answer.
|
People still want to know more about how to install simulator.sdk on Ubuntu: Back in June, iamrohitbanga wanted to know a definitive solution to converting rpm files to debian so he could install the SDK simulator. jgrossm1 suggested IBM Cell SDK/SDK for Multicore Acceleration on Debian/Ubuntu HOWTO. mkistler suggested that "In my experience, the message error while loading shared libraries: libtcl8.4.so: cannot open shared object file: No such file or directory means that the loader could not find libtcl8.4.so when it is trying to load the shared libraries needed by the simulator executable. Is the directory containing libtcl8.4.so in your LD_LIBRARY_PATH?"
The latest in the saga from kauboyhere: I get the same error as mentioned by iamrohitbanga. I installed systemsim-cell 3.0 from its .rpm package using Alien, on Ubuntu 8.04; when I tried ../run_gui from systemsim-cell/run/cell/linux in the Terminal, I got the /opt/ibm/systemsim-cell/bin/systemsim-cell: error while loading shared libraries: libtcl8.4.so: cannot open shared object file: No such file or directory error, as mentioned earlier. I was able to locate the libtcl8.4.so file in my /usr/lib directory. Any solution? tcl8.4 and tk8.4 are installed already.
[choosyg]: I also had serious troubles converting the rpms to deb packages on Hardy, it seems to be a problem with alien/dpkg. Finaly i installed Gutsy and the very same script worked out well. Then i was able to install the simulator deb packages on Hardy and it works fine.
Now the simulatro works, but using spu-gcc failes with the following Message:
/opt/cell/toolchain/bin/spu-gcc -W -Wall -Winline -Wno-main -I. -I
/opt/cell/sysroot/usr/spu/include -I
/opt/cell/sysroot/opt/cell/sdk/usr/spu/include -O3 -c wavelet_spu.c
/tmp/ccxZAQnm.s: Assembler messages:
/tmp/ccxZAQnm.s:7: Error: alignment not a power of 2
/tmp/ccxZAQnm.s:11: Error: no such instruction: `hbrr .L8,printf'
/tmp/ccxZAQnm.s:12: Error: no such instruction: `stqd $80,-16($sp)'
/tmp/ccxZAQnm.s:13: Error: no such instruction: `il $80,0'
...
The same program/makefile workes fine on my Fedora 7 System with Simulator.
|
Can you answer this one? Is there any way to trace SPUs with C++ code? Answer.
|
Panajev2001a wants to know what environmental variable SPE_START_DEBUG does (in reference to gdb debugging).
[IBM SDK Service Administrator]: Information I found:
SPU_DEBUG_START and SPU_INFO were used to set the newly created SPU threads in a sleep state after creation. libspe2 then displayed a message how to connect to the SPU thread with spu-gdb via stderr. Today's combined debugger has different ways to attach to newly created SPU threads. For example GDB has a new command set spu stop-on-load [on|off]. With this set to on the newly created SPU thread is also stopped by GDB itself.
The code for SPU_DEBUG_START and SPU_INFO is still in libspe2 to support the libspe1-to-2 wrapper. So if you set these variables it should show the original behavior of stopping then SPU threads. But this is something that has not been tested (or supported) since the combined debugger was released.
|
Forum statistics for October 2008 Threads: 65 | Participants: 4,160 | Replies: 309 | % threads answered: 17%
|
Categories
: [ Cell | forums ]
Nov 10 2008, 12:01:00 PM EST
Permalink
|
Cell/B.E. Security SDK: APIs: PPE-assisted functions
|
Cell/B.E. Security SDK: APIs: PPE-assisted functions
|
INFObomb
|
|
A quick read on four PPE-assisted function topics in the Security SDK 3.0.
|
|
More INFObombs
|
|
|
|
|
|
PPE-assisted functions are SPE C library functions serviced by the PPE control plane processor in order to improve SPE functionality; we will look at these four topic areas:
change_ppuassist_buf_len.
Unsupported libc.a functions.
Unsupported libgloss.a functions.
Limited support libc.a functions.
Let's take a closer look at these functions.
A little description of PPE-assisted functions
PPE-serviced SPE C library functions are described like the following in chapter 4.1 of "Cell Broadband Engine SDK Libraries Overview and Users Guide":
SPE C library functions ... are serviced by the PPE control plane processor. These functions
have been provided to improved SPE functionality and should not be used for high-performance applications.
These subroutines all operate in the same basic fashion.
- The SPE constructs a local store image of the input and outout parameters.
- The SPE creates a 32-bit message consisting of an opcode and pointer to the local store parameter image array.
- The SPE executes a Stop and Signal instruction.
- The PPE detects the Stop and Signal.
- The PPE invoke a specialist to service the request according to the message opcode.
- The PPE services the requested function.
- The PPE returns results in the local store image array.
- The PPE resumes SPE execution.
- The SPE returns that results back to the caller.
The PPE services to support the standard function documented [in this document] have been incorporated in the SPE runtime
library libspe. As such, no special PPE programming need be done in order to facilitate these functions.
However, the implementation does not operate as described
when the application is executing in the isolation mode due to environment differences. Analogous
replacement functions for the SPE functions are provided in libisolation.a which work around
these differences and provide equivalent function. Note that restrictions described apply
only to PPE-serviced C library functions; SPE-serviced C library functions operate as normal.
The replacement functions make use of an auxiliary buffer which is located in the area of LS reserved
for system use (LS address range 0x3E000-0x3E0C0). The size of auxiliary buffer is initially 192
bytes, but the size may be changed using the change_ppuassist_buf_len function.
Buffer size can be set to no more than 8016 bytes, thus placing a limit on the combined size of function
parameters. This implies that it is not possible to fread()/fwrite() more than ~7900 bytes
at a time and it is not possible to printf more than ~7900 bytes of data at a time.
The size of auxiliary buffer must be at least as large as the sum of the following:
- 16 bytes,
- 16 bytes for each function parameter,
- for each string, array, or struct referenced, the size in bytes of the referenced item rounded up to
the next multiple of 16 bytes, and
- for
printf, fprintf, vprintf, and vfprintf, an additional 32 bytes.
For example, consider the function call
printf(“This is a %s call with %d parameters.\n”, “PPE-assisted call”,
(int) 3);
This call has three parameters -- two strings and one integer. The format string requires 48 bytes and the
parameter string requires 32 bytes. An additional 32 bytes are required for the printf function. The total
buffer size required for the call is
size of auxiliary buffer = 16 + 3*16 + (48 + 32) + 32 = 176 bytes
If size of auxiliary buffer was set to an insufficient value, a PPE-assisted call will terminate early with
errno variable set to ENOBUFS.
Developers must ensure that when invoking such a PPE-assisted call, they have no outstanding DMAs
with their source and/or destination overlapping with auxiliary buffer -- this is to avoid incorrect execution of a
PPE-assisted call and/or DMA.
PPE-assisted functions that are unsupported in emulated isolation mode will produce a missing link
error at application build time by using stubs which link to a non-existent function.
To use PPE-serviced calls in emulated isolation mode, libisolation.a must be linked after libc.a and
libgloss.a, but only after defining the symbol __send_to_ppe as being wrapped (redefined to
__wrap___send_to_ppe) at link time. Including make.iso.footer in the makefile will resolve the correct
linkage steps.
change_ppuassist_buf_len
The change_ppuassist_buf_len function sets the size of the buffer area to be used for PPE-assisted
functions. These are the functions that require assistance from code that executes on the
PPE. Parameters to the PPE code are passed using a buffer in the area of LS reserved for system
use (LS address range 0x3E000-0x3E0C0); results are returned using the same buffer. Since
this buffer competes with other uses for this reserved area of LS, this function can be used to set
the size of the buffer smaller when not needed or larger for larger parameters (for example, for large strings).
Minimum and maximum sizes buffer can be set to 80 and 8016 bytes. Value of 0 is
returned on successful change or -1 is returned on failure.
C specification
#include <libisolation.h>
int change_ppuassist_buf_len(unsigned int new_len)
Dependencies
None.
Unsupported libc.a functions
These 15 PPE-assisted functions from libc.a are not supported in isolation mode:
gets
fscanf
scanf
setbuf
setvbuf
snprintf
sprintf
sscanf
tmpnam
vfscanf
vscanf
vsnprintf
vsprintf
vsscanf
system
Unsupported libgloss.a functions
These 15 PPE-assisted functions from libgloss.a are not supported in isolation mode:
ftok_ea
mmap_ea
mremap_ea
msync_ea
munmap_ea
shmat_ea
shmctl_ea
shmdt_ea
shmget_ea
shm_open
shm_unlink
mktemp
utimes
readv
writev
Limited support libc.a functions
These four PPE-assisted functions from libc.a have limited support in isolation mode. This support
is limited as the types of arguments are determined by scanning the format string; if the format string is
wrong or does not match the argument types, then it is possible to leak information.
fprintf
printf
vfprintf
vprintf
An additional limitation is that conversion character %n is not supported. This is the conversion
character that makes *printf functions write back the number of characters written so far into original
parameter list.
Taken from the Cell BE Security SDK v3.0 Installation and User's Guide. Download the SDK. Check out some reference guides in the Cell Resource Center SDK library.
|
|
|
|
|
|
ORIGINAL DOCUMENTATION | DOWNLOAD SDK |
SDK LIBRARY |
MORE INFObombs |
BACK to BLOG |
BACK to ZONE
|
|
|
Categories
: [ Cell | infobombs ]
Nov 10 2008, 12:00:00 PM EST
Permalink
|
|
 |
|