El Tue, Apr 08, 2008 at 02:16:23PM +0100, Andrew Haley ens deleità amb les següents paraules:
> Ramon Bertran Monfort wrote:
>> Well, 
>> first of all, thanks for answering.
>> 
>>> Why don't you just define main() correctly?  argv should be 'char **', 
>>> and envp should probably be 'char **'.  How can you possibly have an 
>>> envp that's a long long unsigned int?
>> 
>> If a follow the SDK3.0 programming guide, it tells me that the spe main 
>> function has three parameters: the spe id, and two pointers to application 
>> specific data. The last two are optional.
> 
> But you passed not a pointer but a long long unsigned int.  Why not pass a 
> pointer instead of a long long unsigned int, especially since that's 
> what the programming guide tells you to do?
> 

I've just used the same main signature that they use. I thought that they 
used that strange signature for something... Now, I've change the signature 
to the 'correct' one :

main ( int, char**, char**)

and the program seems to compile correctly. However, if I execute it, it 
fails. I get a 'bus error' when trying to do a dma_transfer from the 
address of the second parameter. So, I guess that this kind of 'implicit' 
casting do not like to the Cell runtime... it should be a uint64_t, as is 
stated in the programming guide. 

>> I can try to change the signature to the 'correctly' one ... but doing this 
>> will break the spe run-time probably. (I've to experiment with this).  
>> Anyway, sometimes I use three parameters witch is not allowed with the 
>> 'correct' strict signature.
> 
> g++ allows the third argument to be a pointer.
> 

Oups, sorry for my ignorance.

>> I know that there are workarounds for solving this issues, but I'm 
>> wondering if there is any gcc flag to relax this strict condition. It would 
>> be easy to port applications to gcc 4.3.0 such as the Cell application 
>> which changing the code is not as straightforward as the example shown in 
>> http://www.gnu.org/software/gcc/gcc-4.3/porting_to.html .
> 
>>> Also, what are the compiler options you're using?
>> 
>> I guess that does not matter. I'm using just 'spu-g++ -O2' for testing.
> 
> Ah, OK.  It seems that you have been caught by a version of gcc that treats 
> this as an error rather than a warning.  I'm not sure exactly when this 
> changed, but the current development version has a warning, not an error.
> 

Yes, the version is gcc 4.3.0 . I do not know if they relaxed this 
condition afterwards. I will try a newer version of gcc if this condition 
is relaxed. Do you know from which gcc version the error is just a warning 
again? 

> Andrew.

Thanks in advance,

Salut!

-- 
-------------------------------------------------------------------------------
Ramon Bertran Monfort                 Departament d'Arquitectura de Computadors
Telefon (+34) 93 4054033/54055             Universitat Politecnica de Catalunya
Fax (+34) 93 4017055                        Despatx C6-103/C6-221-9 Campus Nord
e-mail rbertran@ac.upc.edu                C. Jordi Girona 1-3 - 08034 Barcelona
                          http://rbm.pc.ac.upc.edu
-------------------------------------------------------------------------------
Listening: Hall of the king (Follow the blind) - Blind Guardian