El Tue, Apr 08, 2008 at 02:16:23PM +0100, Andrew Haley ens deleit�mb les seg�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@xxxxxxxxxx C. Jordi Girona 1-3 - 08034 Barcelona http://rbm.pc.ac.upc.edu ------------------------------------------------------------------------------- Listening: Hall of the king (Follow the blind) - Blind Guardian
Attachment:
signature.asc
Description: Digital signature
