Please give me guidance on how to write portable code for the PSP.
What are the trade offs between using the sceFunctions() and posix calls?
I see a pthread wrapper and what looks to be a posix complaint socket library, but file and serial IO use the sceFunctions().
Do macros exist for fopen and open or are they the independent of the sceIoOpen functions?
Does select work on file descriptors other than sockets like posix?
Since pspsdk is primarily supported on cygwin I assume most of the developers here are used to a posix environment. So, How do you cope with learning all new libraries?
NOOB disclaimer: I know nothing about PSP. Starting to port my code today. I have pspsdk and psptoolchain installed and compiled.
What is the most stable/reliable CFW?
Thanks for all you help in advance.
portability question (posix and sce/psp)
Short answer: who can say?? :)
Long answer: I'm using heimdall's win32 pspsdk under xp/vista and 3.90 M33 on PSP side; SDK gets updated every week, and personally i know no better idea than to put all platform dependant code in an HAL (that's not a killer computer, but an achronym for "Hardware Abstraction Layer") replacing only HAL when porting is required. First time it's double effort, but then you gain back everything (if your project is large enough....nobody would do things this way to do something small or something _very_ specific to a platform)
Long answer: I'm using heimdall's win32 pspsdk under xp/vista and 3.90 M33 on PSP side; SDK gets updated every week, and personally i know no better idea than to put all platform dependant code in an HAL (that's not a killer computer, but an achronym for "Hardware Abstraction Layer") replacing only HAL when porting is required. First time it's double effort, but then you gain back everything (if your project is large enough....nobody would do things this way to do something small or something _very_ specific to a platform)
All of what you call "posix calls" - which actually are newlib ones - will call the sce functions anyway.What are the trade offs between using the sceFunctions() and posix calls?
Well, there is no such thing as "posix compliant" for Sony. It's just good for us they use the same *kind* of functions. (divine inspiration?)I see a pthread wrapper and what looks to be a posix complaint socket library, but file and serial IO use the sceFunctions().
See above :)Do macros exist for fopen and open or are they the independent of the sceIoOpen functions?
Not really related to PSP, but from what Sony implemented in the sceIOFileMgr, no.Does select work on file descriptors other than sockets like posix?
Reading the headers and looking at the samples? When you know what you want to do, the libraries you use don't really matter. And the PSPSDK is primarily supported on Linux. It is by mere chance that cygwin can make it work...Since pspsdk is primarily supported on cygwin I assume most of the developers here are used to a posix environment. So, How do you cope with learning all new libraries?
Get one from the 3.xx series. People would say that 1.5 is stable and good, but you can't live in a dreamworld for your whole life. If you want to be compatible with Phat AND Slim, get something along the lines of 3.90 which features a cool NID resolver (something you should not care about but which actually helps you a lot :P).NOOB disclaimer: I know nothing about PSP. Starting to port my code today. I have pspsdk and psptoolchain installed and compiled.
What is the most stable/reliable CFW?
I hope my answers are helpful and correct :)
I would add that if you write code for a small project you don't really have to take care of PSP specifities.
But as soon as you have a bigger project you will have to take care of them like
- understanding kernel and user mode/memory partition (which are not at all current !)
- the fact you have to take care of the heap and stack size since you don't have as many ram as on a PC
- be able to do syscall etc
and finally the lack of documentation...
but people here willl help you, if you start by searching before in the previous threads (Read the Previous Fucking Threads!), you can find lots of samples in the SDK as well.
And adrahil is wise in saying that you shouldn't develop on the 1.5 kernel
But as soon as you have a bigger project you will have to take care of them like
- understanding kernel and user mode/memory partition (which are not at all current !)
- the fact you have to take care of the heap and stack size since you don't have as many ram as on a PC
- be able to do syscall etc
and finally the lack of documentation...
but people here willl help you, if you start by searching before in the previous threads (Read the Previous Fucking Threads!), you can find lots of samples in the SDK as well.
And adrahil is wise in saying that you shouldn't develop on the 1.5 kernel
--pspZorba--
NO to K1.5 !
NO to K1.5 !
Thank you all for your insight and help. It sounds like the answer is:
use the sceFunctions.
use the sceFunctions.
I will. Hopefully, I don't get punted to the hall of shame on my first post.pspZorba wrote:but people here willl help you, if you start by searching before in the previous threads (Read the Previous Fucking Threads!), you can find lots of samples in the SDK as well.
I'd suggest the opposite and that you use newlib where possible, and only switch to sce* functions when you need something unsupported by newlib, or need more control or performance. There's a lot of work we put into newlib to make things behave like you'd expect on a typical POSIX system -- for example working around specific bugs in the sce* functions.
I wholeheartedly agree with jim here, and as a bonus newlib tries to emulate select over both file descriptors and sockets (where it would only be available on sockets directly) but that will only work if you the posix/bsd sockets style apis as they have to trickery at the backend to duplicate the types. That is also why with those apis you can use normal read/write/close on sockets even though the underlying OS code doesn't support such operations.
The only place I would highly recommend NOT using the libc/POSIX/newlib stuff is in kernel modules, always use directly supported kernel functions there, and recode anything which isn't implemented that you need :)
The only place I would highly recommend NOT using the libc/POSIX/newlib stuff is in kernel modules, always use directly supported kernel functions there, and recode anything which isn't implemented that you need :)