[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: multiple compilers

From: Christopher Hulbert
Subject: Re: multiple compilers
Date: Mon, 27 Aug 2007 18:35:43 -0400

On 8/27/07, Ralf Wildenhues <address@hidden> wrote:
> Hello Christopher,
> * Christopher Hulbert wrote on Mon, Aug 27, 2007 at 03:39:21PM CEST:
> > I'm starting to think about how to compile/link for the cell processor
> > using the autotools. My first thought was to configure for the PowerPC
> > processor, then override the C compiler for the SPU source files, but
> > that doesn't work. The only way I can see right now is multiple
> > configures or independently configured subdirectories. Would there be
> > any reason (except for the cell processor) for the libtool script to
> > have multiple-configured compilers for a single language? Then, based
> > on the compiler passed to the libtool command select one?
> I'm not sure I understand the problem enough at all, best to treat me as
> not having heard anything of the cell processor yet.
> Is it that compilation is done on the powerpc processor for code to run
> on the cell, and neither can execute code for the other?  So that would
> be just a normal cross-compile situation, where you pass --host and
> optionally also --build, and typically the cross compiler has a prefixed
> name.  If you then also need to execute code compiled for the $build
> system (the powerpc processor), then you will need two different libtool
> scripts, and for that you will need two different configure scripts.
> However, I have yet to see a package that needs to build shared
> libraries for both the $build and the $host system, except for
> compilers and other related toolchain stuff.  In which case I guess it
> helps to look at the (complicated!) build system GCC uses for bootstrap.

The cell processor has 2 different "architecture" cores. There's a
compiler for the PowerPC and a compiler for the SPU. The SPU image can
be embedded into the powerpc executable via a special command, or the
powerpc code can load the SPU image much the same way as dlopen. In my
case, I have a main driver function that will load the "shared" object
from the SPU and spawn off some threads onto these SPU cores. So, to
compile both the PPU and SPU binaries, I have to have a custom-written
makefile or two seperately configured directories.

So, I had some thoughts of libtool being configured for say 2 C
compilers. In the Makefile the rule for c -> lo passes --tag=CC $(CC).
If I could change $(CC) to another compiler say $(SPU_CC), libtool
could compile the SPU code with the SPU compiler and PPU code for the
PPU compiler.
Something like the following:

multibin_pd_cov_ka_cbe.lo: multibin_pd_cov_ka_cbe.c
--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES)
multibin_pd_cov_ka_cbe.lo `test -f 'multibin_pd_cov_ka_cbe.c' || echo

multibin_pd_cov_ka_spu.lo: multibin_pd_cov_ka_spu.c
--mode=compile $(SPU_CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES)
multibin_pd_cov_ka_spu.lo `test -f 'multibin_pd_cov_ka_spu.c' || echo

Of course, this situation is probably rare, dangerous, etc. But I
thought I'd throw out what I had thought of because maybe it is

Another thought I had was trying to figure out if there would be a
clean way to extend libtool to a general language. Then I could just
call the SPU code some other language and do it that way. Alas though,
custom Makefiles are probably not as bad as cleanly implementing
either approach :).

> Hope that helps.
> Cheers,
> Ralf

reply via email to

[Prev in Thread] Current Thread [Next in Thread]