main thread stack size question for slim et fat

[sauron_le_noir]

how can i have a main thead stack size depending of the hardware slim or fat
in the sdk the PSP_MAIN_THREAD_ATTR(attr) is defined has unsigned int sce_newlib_attribute = (attr)

where attr is the number of k allocate for the heap ?
when i start/load a user prx can i specify his heap size ?
for my pdf reader when it is a fat i must use a PSP_MAIN_THREAD_ATTR of 20000
(it limit the zoom capability on the fat) and for the slim i use PSP_USER_LARGE_MEMORY and PSP_MAIN_THEAD_ATTR of 30000
so 2 makefiles 2 eboot.bpb what i wish is determine the hardware of the psp
slim or fat., load a prx with a custom heapsize depending of the hardware test
is it possible ? and how can i do this ?

[J.F.]

You can't set the stack size depending on the hardware. You can only set it, period.

Code: Select all

PSP_MODULE_INFO("Program Name", PSP_MODULE_USER, ProgramVersion, ProgramRevision);
PSP_MAIN_THREAD_ATTR(PSP_THREAD_ATTR_USER);
PSP_HEAP_SIZE_KB(HeapSizeInKB);
PSP_MAIN_THREAD_PRIORITY(Priority);
PSP_MAIN_THREAD_STACK_SIZE_KB(StackSizeInKB);

Those are the things you can set. PSP_HEAP_SIZE_MAX() is just PSP_HEAP_SIZE_KB(-1). With the current newlib (libc), you can pass other negative values like PSP_HEAP_SIZE_KB(-512). That tells newlib to set up the heap to be all the PSP user memory EXCEPT for 512 KB. That is recommended as it allows you to make one binary that gives you all the memory on a Phat or Slim while still leaving some memory for threads and prxs.

As you can see, the function for setting the stack size only takes a size parameter and cannot be varied depending on the hardware. If you want two different stack sizes, you'll have to make two different binaries. That seems silly to me as you only need as much stack as needed for all local variables, which doesn't change with the hardware, only the program variable usage.

Most devs leave the stack size and priority to the default settings... they're good for nearly everyone. You MIGHT have to increase the stacksize depending on the app. I recommend you set the heap size via PSP_HEAP_SIZE_KB(-256);. I recommend you have these lines in the makefile:

Code: Select all

BUILD_PRX = 1
PSP_LARGE_MEMORY = 1

PSP_MAIN_THREAD_ATTR() MUST be PSP_THREAD_ATTR_USER to work in 3.xx, which is the only fw you should be writing for these days. That goes along with using PSP_MODULE_USER in PSP_MODULE_INFO().

EDIT: One more thing, use

Code: Select all

PSP_MAIN_THREAD_ATTR(PSP_THREAD_ATTR_USER|PSP_THREAD_ATTR_VFPU); 

if you use the vfpu in your app.

[sauron_le_noir]

with the extra 32 meg of the psp slmiyou can use a zoom at a higher level it break
on 1.5 on fat with 20000K and at 1.7 on slim with 30000K when you render
a pdf to a ARGB device it use a lot of memory.
So the program run on the 2 hardwares but with degratation for the zoom function on the fat.

can i use this

the xmb launch a program that detect the hardware it launch a EBOOT.BPB
with a stack of 20000 or a EBOOT.BPB with a stack of30000
this 2 EBOOT.BPB just start and load the same prx containing the code of the pdf reader
so yes just 1 code for the reader but depending on the hardware we launch 2 bootstrap program
So i must maintain just one source

[sauron_le_noir]

aka moonlight

Why don't you use PSP_HEAP_SIZE_MAX? It will already allocate max memory in both.
Anyways, you can change the hep before any malloc operations. In the file where you wrote PSP_HEAP_SIZE_KB, do in main function "sce_newlib_heap_kb_size = desired_size;"

no need to do all this stuff before any malloc you can change the heap kb size

[J.F.]

aka moonlight

Why don't you use PSP_HEAP_SIZE_MAX? It will already allocate max memory in both.
Anyways, you can change the hep before any malloc operations. In the file where you wrote PSP_HEAP_SIZE_KB, do in main function "sce_newlib_heap_kb_size = desired_size;"

no need to do all this stuff before any malloc you can change the heap kb size

MAX uses ALL memory, so any attempt to spawn threads will fail, leading to unpredictable behavior. While you can do "sce_newlib_heap_kb_size = desired_size;" before doing anything else in main, that's a poor hack compared to just using PSP_HEAP_SIZE_KB(-amount);. Only use the hack if you're on an old toolchain. On the new toolchain and SDK, use the negative heap size.

I believe moonlight stated that his toolchain is pretty old, so it stands to reason that he's using the hack. You have no excuse. :)

[sauron_le_noir]

thx Jf i've just recompile the entire toolchain with a fresh svn co
and yes with PSP_HEAP_SIZE_KB(-256) the homebrew work on both
psp fat and slim without having 2 builds
The limitation of the zoom remains on the fat when the zoom is > 1.5 i"ve a out of memory error.
Do you know what are the best switches for gcc to optimize the code generated for a psp

[J.F.]

Most folks use "-O3 -G0". Greater than O3 won't speed anything up. The -G0 avoids some small segment link errors, but can slow things just a smidgen. You might try it with various values like -G4 and see if it doesn't give any link errors. Another thing that might speed things up is "-falign-functions=64". That aligns all functions to the cache line size. These are all CFLAGS, by the way.

[sauron_le_noir]

agree but gcc is by essence a compiler design to run on different architecture so
some compilation flag wil generated overhead or even worse runtime errors

[Torch]

Can someone tell me what the default priority for a thread is?
I think its 11 but I'm not sure.

[J.F.]

DEFAULT_THREAD_PRIORITY is 32. That's in crt0.c.

[Torch]

DEFAULT_THREAD_PRIORITY is 32. That's in crt0.c.

If I use a priority above 13, my program doesn't even start and remains at a black screen. Its a replacement vshmain.prx.

At 13 it doesn't suspend. At 12 it works fine.

[jean]

That's probably because threading model of PSP software platform is non-preemptive. That means: every thread MUST know very well what it's doing and sleep every now and then.

[Torch]

That's probably because threading model of PSP software platform is non-preemptive. That means: every thread MUST know very well what it's doing and sleep every now and then.

So you mean Sony's coding is bad?

[jean]

So you mean Sony's coding is bad?

NO, i mean that cooperative model needs you to care of your code timings, not scheduler. In such a scenario, priorities alone mean nothing.... try putting some sleep in your code every now and then

[Torch]

So you mean Sony's coding is bad?

NO, i mean that cooperative model needs you to care of your code timings, not scheduler. In such a scenario, priorities alone mean nothing.... try putting some sleep in your code every now and then

It sleeps for 100*1000 in all the loops. Theres nothing much going on.

[J.F.]

You gotta be missing a sleep somewhere - the threads I make for Basilisk II are:

20 - the ticks thread
21 - the buffer fill thread
22 - the audio playback thread

It works fine, suspending and resuming and running just peachy.

[Torch]

You gotta be missing a sleep somewhere - the threads I make for Basilisk II are:

20 - the ticks thread
21 - the buffer fill thread
22 - the audio playback thread

It works fine, suspending and resuming and running just peachy.

Theres only one continuously running thread. Its a plugin actually.
It has only one loop, which reads the control input and sleeps for 100*1000 everytime.

Maybe it needs a priority of 12 to run properly because of the XMB/Game running in the background.

I've also used the Suspend Sysevent handler that adrahil showed me.

[J.F.]

You gotta be missing a sleep somewhere - the threads I make for Basilisk II are:

20 - the ticks thread
21 - the buffer fill thread
22 - the audio playback thread

It works fine, suspending and resuming and running just peachy.

Theres only one continuously running thread. Its a plugin actually.
It has only one loop, which reads the control input and sleeps for 100*1000 everytime.

Maybe it needs a priority of 12 to run properly because of the XMB/Game running in the background.

I've also used the Suspend Sysevent handler that adrahil showed me.

Quite possible. I don't really mess with plugins much. Other than helping on pikey, most of my work is on apps and the occasional library.

[Torch]

Quite possible. I don't really mess with plugins much. Other than helping on pikey, most of my work is on apps and the occasional library.

To avoid confusion -- I was referring to two of my programs without being very clear.

The 1st program is a replacement vshmain.prx which hence starts when the PSP is turned on. If I use a priority above 13, the program doesn't even start and remains at a black screen. At 13 it works fine but doesn't suspend. At 12 it works fine.

The 2nd program is a plugin with the loop thread priority at 12. It works fine at 12. At anything higher, it becomes really slow in the XMB/Games. It responds to button presses after a few seconds delay etc.