forums.ps2dev.org

Ok, I know... this is not truly ps2 development related (more mips gcc specific), but right now I'm just not sure whether those "problems" are not connected to ps2 more than I think they are.

Anyway, first question. Let's consider some simple code, that fetches word from memory address which is not always aligned (or even will be mostly unaligned).
The problem is, that with no optimizations (compiled with "ee-gcc -D_EE -G0 -g") and added debugging info this code gives me tlb load exceptions at the lwr (bad address). Checking the assembly, made the reason obvious. This code has been compiled into (simplifying):
Fine, so as I wrote, it's obvious why it leads to exception (register modified and then used again as base, which shouldn't happen unless specified). The funny part is that it doesn't happen when compiled with "-O2" or "-O3" (separate registers are used for base and source). Am I doing something wrong? Is this normal behavior? The same happens with other instructions (like lw/lh/lb/etc.).

I've came up with something like this, to overcome this problem when debugging.
But this one is less efficient (even with "-O3" it uses some additional daddu, and always stores the result on stack, then loads it again, where in previous version it was preserving the value in register across all the function.

Well, I think I can have two versions of this simple code (one for debug, one for optimized compilation)... but it doesn't seem like a good idea.

Now, I have to say I'm not very good at mips assembly (I have some experience with PSX), nor gcc specific stuff (mostly programming for w32, I'm using MSVS most of the time, with Visual c# recently more than anything else).

Second one: what is the cost of lwl/lwr swl/swr? Sure, I can do my own tests, but maybe someone already did (didn't find specific data). What I mean is, maybe it's just more efficient to use other methods. In this sample, the destination/source is not always word aligned but always halfword aligned, so it's quite easy to load/store it in the other way, like:
The third question is:

Do you know of an efficient way to convert 16bit (5:5:5:1) textures into 32bit (8:8:8:8) and vice versa? I've been able to come up with something like this (for 16b->32b, for the other just revers order and pack instead of ext):
It converts four pixels at time, so it's a little bit more efficient than what I've been doing to this time, and can be even better with unrolling up to four (16pixels at time, more gives no increase)... but is not what I would expect.

Thank you in advance.

ffgriever wrote:Anyway, first question. Let's consider some simple code, that fetches word from memory address which is not always aligned (or even will be mostly unaligned).
..
The problem is, that with no optimizations (compiled with "ee-gcc -D_EE -G0 -g") and added debugging info this code gives me tlb load exceptions at the lwr (bad address). Checking the assembly, made the reason obvious. This code has been compiled into (simplifying):

Code: Select all

#standard sp/fp stuff
sd $a0, srcdst_stack($sp)
lw $v0, srcdst_stack($sp)
lwl $v0, 3($v0)
lwr $v0, 0($v0)

Hi,
If I understand things right, you need to mark the output as earlyclobber (&) because the output registers are written before the input operands are no longer needed. Something like:

Aww... shame on me. Such an easy mistake. Still not get used to the gcc inline assembler. More, everything was clearly stated in the every gcc inline asm howtos. Must've left my mind behind.

Thank you.

(PS. the other qs still apply)

The IPU (Image Processing Unit) can do RGB32 to RGB16 (not the other way I believe) using the PACK command.

I've been using the IPU for color space conversion some two years ago but can't find the code,
otherwise I could have posted the relevant parts.

Thanks, but IPU is busy at the time. EE has still some idle time, that's why I'm using it to make some precalculations for next frame. Plus, as you wrote, IPU does support packing to 16bit only, not extending to 32bit (and I need to do both, sometimes even on quite large amount of data).