Boost logo

Boost :

Subject: Re: [boost] Support for Cell processor
From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-10-13 16:13:17


On Mon, Oct 13, 2008 at 1:14 PM, Joel Falcou <joel.falcou_at_[hidden]> wrote:

> Several boost libraries compile without any problem on the cell BE
> processor in PPU and SPU mode like most of the preprocessor or
> meta-programming one.
>
> However, it's impossible to use any C++ code that include *any* part of std
> cause it makes the resulting binary too big for the spu linker.
> For some boost libraries, the std include is merely used for some optionnal
> display. For others, large parts of functionnalities is made useless.
>
> As I've been toying with this architecture for quite a bit now, I'm on the
> verge to patch my local boost with a way to detect compilation on
> Cell SPU and to remove inadequate include from some libraries.
>
> Considering the potential interest in supporting this architecture, would
> libraries developpers mind if I submit ticket with patches for this support
> integration when the actual pacthes is aimed at making the core of the
> libraries to be used on Cell BE SPU and to add things like #error or
> #warning that explicitely states that this library or features is disabled ?
> What's the current stance on adding new architectural support into boost ?

It is up to individual library developers to accept patches or not. But I
think you will find most developers are receptive if the patches are
complete and reasonable and don't have a lot of negative impact on the code.

>For some boost libraries, the std include is merely used for some optionnal
display.

I've toyed with the idea of proposing a standard BOOST macro form to deal
with that. Using the filesystem library as an example, BOOST_FILESYSTEM_LOG
would be used like this:

     #ifdef BOOST_FILESYSTEM_LOG
     # include <iostream> // needed only if logging enabled
     #endif

--Beman


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk