[PATCH] cell spu offloading printf and friends

[Jeff Johnston]

jschopp wrote:
> Jeff Johnston wrote:
>> What about errno?  
> 
> Since errno is always returned in the same slot it is handled by the 
> helper function, see this line:
>  >> +    errno = ret->slot[3];
>

Missed that.

> 
>> What about the reentrancy struct which contains errno for the current 
>> thread?
> 
> The cell spu is single threaded, so I don't think it's necessary.  Be 
> happy to add a line if I'm wrong, which is not unheard of.
> 

Not at present.

>> Is there any storage allocated by any of the routines?  Who cleans it 
>> up?  
> 
> The only storage is allocated on the spu is on the stack and thus goes 
> away on function return.
> 
>> Are positional parameters supported by the printf family?  If not, do 
>> you need them for NLS?
> 
> I suppose I don't know what positional parameters are.  The only 
> supported locale on the spu is the C locale, publicly documented by 
> definition of the architecture.  In any case the parameters just get 
> shuffled around on the other side and currently are handled by glibc in 
> the end.
> 

So, if I understand correctly, you're punting functionality to another 
processor which has a full glibc on it.  If you have a glibc 
implementation then yes, you have positional parameter support and more.

>>
>> What testing has been performed?
> 
> This has all gone through our testing for the SDK 2.0 
> http://www.bsc.es/projects/deepcomputing/linuxoncell/  A number of 
> different groups tested that release in various ways.  I personally ran 
> the limited newlib test suite and the rather decent gcc testsuite on 
> it.  I also wrote a few custom testcases. Sony has been using these 
> patches too, and I'm sure they've done some amount of testing, because 
> they found the same bugs we did and offered similar fixes as we had done.
> 

Ok, that's what I was needing to hear.

>>
>> With all the questions I have, I am very doubtful about this being put 
>> into 1.15.0.
> 
> Well, I'll save myself the trouble of sending the follow on until we can 
> work out this one.  It's ultimately your decision what goes in or 
> doesn't.  But something to keep in mind is that everyone who actually 
> uses newlib on the spu will be using this patch if it is in or not.  The 
> current method is simply not viable for real use.
> 
> 

My questions have been answered.

-- Jeff J.