forums.ps2dev.org

d1mbu1b · Joined: 22 May 2008 Posts: 6

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.

jean · Joined: 05 Jan 2008 Posts: 489

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)

adrahil · Joined: 16 Mar 2006 Posts: 277

pspZorba · Joined: 22 Sep 2007 Posts: 156 Location: NY

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
_________________
--pspZorba--
NO to K1.5 !

d1mbu1b · Joined: 22 May 2008 Posts: 6

Thank you all for your insight and help. It sounds like the answer is:
use the sceFunctions.

jimparis · Joined: 10 Jun 2005 Posts: 1179 Location: Boston

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.

TyRaNiD · Joined: 18 Jan 2004 Posts: 918

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 :)