[Cbe-oss-dev] Comments and questions on SPU environment

[Arnd Bergmann]

On Monday 27 February 2006 15:11, Machida, Hiroyuki wrote:
> We have couple of comments and questions on current libraries on SPU side
> and released  documents. I sent these to open up discussion about SPU libs
> and documents.
> 
> - There are two libc; which should be used?
> One is newlib distributed as a part of SPU toolchain package and other is libc
> under "sample and library"  which is belonging to other package.
> libm (form newlib) and libmath (from  libc under "sample and library) have same
> issue. We guess that newlib is just prepared to build SPU GCC. Is it right?

The two C libraries have a slightly different scope. The one from
the "samples and libraries" package is optimized mostly for code
size, while the spu-jsre-newlib is more complete feature-wise but
adds more overhead in the size of the binary.
 
Actually, we are planning to do a third C library implementation, which
will use the linux system calls directly through the new kernel
syscall callback implementation. This spu-linux-newlib will contain
even more features (e.g. socket operations or ioctl) that are not
present in any of the others but will be strictly limited to
running on Linux as a host operating system.

> - "SPU C/C++ Language Extensions" doesn't define values.
> E.g. We realized  values for errno are not defined.
> We guess same issues are exist and need to define their values.

That is true, some aspects of the Language Extensions document are
not fully specified, iirc that includes compile-time constants and
structure layouts.

Of course, you can look in the source code to find out what the
right values are, usually it will be the same as on powerpc-linux,
but this is not how you are supposed to find out (e.g. someone
who wants to implement the helpers for another host operating system
should not need to look into GPL source code).

I suppose we should have some way to track bugs like these in a
publically accessible system in order to nail them down, currently
work on this is done mostly in IBM and the STIDC. 

> - C++ support
> According to "SPU C/C++ Language Extensions", we seem to have
> restrictions on C++. Do we need customize version of C++ lib which
> realize such restrictions and will replace libsdtc++ ?

no idea.

	Arnd <><