Re: [RFA][3/5] New port: Cell BE SPU (the port itself)

["Mark Kettenis" <mark dot kettenis at xs4all dot nl>]

>  Hi Mark,
>
>  thanks for looking at the port!
>
> > First, "spu" doesn't occur anywhere in config.guess.  Is this a name the
> > community agrees on?  I understand it stands for Synergistic Processor
> > Unit,
> > and it seems a bad idea to me that's a fairly generic term.
>
>  "spu" cannot occur as host architecture, therefore it is not in
>  config.guess.
>  It is, however, in config.sub as a target architecture, and the recently
>  committed binutils patch uses it (as does the proposed GCC patch and all
>  the
>  previously released toolchain packages for Cell, both for Linux and the
>  PS3).

Ok,

>
> > >  	* config/spu/spu-cell.mt: New file.
> > >  	* config/spu/spu.mt: New file.
> >
> > Two .mt files?  I think spu-cell.mt should be renamed spu.mh.
>
>  Since spu is never the host architecture, spu.mh would not get used.
>
>  The situation is a bit unique here: The spu debugger is itself a PowerPC
>  binary and runs on the PowerPC side of the Cell, but it debugs code
>  running
>  on the SPU side, so it would be a "cross" configuration.  On the other
>  hand,
>  the debugger makes use of special host operating system facilities (ptrace
>  plus the spufs file system) to control the SPU inferior -- in this aspect
>  it looks like a "native" configuration.

I think *is* a native configuration.

>
>  I've tried different ways to integrate this scenario into the GDB
>  configure
>  structure, and what I've come up with appeared to me to be the most
>  straight-
>  forward way.

I think it is fundamentally wrong to put native-dependent code in a .mt
file.

>  This means I leave GDB's notion of "host" as auto-detected (i.e.
>  powerpc64),
>  which means that GDB does not configure as a "native" target (since target
>  != host).  However, the target-dependent files for the spu target actually
>  include the spu-linux-nat.c file which installs itself onto the target
>  stack
>  and provides the "native" debugging capabilities that way.

I think that what you really want is a Linux powerpc native configuration
that can debug both normal powerpc code and spu code.  That'd mean adding
spu-linux-nat.c to config/powerpc/linux.mh.  But I suppose that doesn't
really work right now.  But could we make that work?

> > I also think SPU_NUM_CORE_REGS is a bad name.  I first thought
> > this had something to do with core files.
>
>  Agreed, I've renamed it.
>
> > May I suggest SPU_NUM_VEC_REGS.
>
>  Since the SPU ISA calls them "general-purpose registers" (and it's a bit
>  less to type), I'm now using SPU_NUM_GPRS.  OK?

Personally I'd prefer something that follows the SPU_NUM_XXX_REGS pattern,
but that's not terribly important.

Mark