forums.ps2dev.org

[mICrO]

I figured that memcpy implementation on the SDK isn't working very fast. Seems to work like coping BYTE per BYTE. So, I get low frame rate when I copy a huge amount of data.

These could be for many reasons, what the best approach its could be implements something similar in MIPS assembly, using something like x86’s MOVSD. The problems it’s that I know x86 and z80 assembler, what none of MIPS, either how to do it inline in gcc compilers, and those assembler templates.

I check RIM source code, and I found that the author used a custom memcpy function coded in inline MIPS assembler. This function seems to copy WORD per WORD; so, it's doubling speed

I try to use it, but doesn't work, as I would like.

The source code comments are in Japanese, so I couldn't read it, as well.

I know how to code inline x86 assembler in Microsoft visual c++, and I code a function that does what I want in inline x86 assembler, using MOVSD for copying DWORD blocks, and reusing some register to copy rest of data with MOVSB.

Any one could help me?

Maybe it’s time to learn some MIPS assembly and inline assembler in gcc.

Here it's my x86 code, that I would like to replicate in PSP:

[mrbrown]

I've checked in a change (1513) to Newlib to remove the PREFER_SIZE_OVER_SPEED define that prevented the optimized versions of memcpy() and friends from being used. Note that you have to link with newlib (-lc) after rebuilding it with `toolchain.sh -n'. The optimized memcpy() will transfer data in 16-byte blocks if it can, then fallback on copying data 4 bytes at a time, then fall back on a MIPS unaligned word store failing that.

You can find the source to this memcpy() in newlib/libc/machine/mips/memcpy.c in your unpacked Newlib 1.13.0 source.

[ector]

Nice one mrbrown.

Oh and mICrO, your x86 code may have been optimal on the 486, but since the Pentium other methods are much faster than rep movsd, especially for block sizes over a few hundred bytes.
_________________
http://www.dtek.chalmers.se/~tronic/PSPTexTool.zip Free texture converter for PSP with source. More to come.

[mICrO]

First of all , thanks MrBrown, greets news, I'm rebuilding newlibc, leater I'll check perfomance, I checked optimize version of memcpy and looks great.

ector: The x86 implementation it's was only for show how it's could be do in PSP faster, moving 64 bits blocks, becouse early I don't know any MIPS assembly, and I need to explain what I thinks its faster.

As you know nowdays x86 cpu have faster data transfer opcodes, since MMX or SE. In fact I don't use any replacment for memcpy in x86, platform because its well optimized ;-)

I was doingin a workarround, I learned how to do MIPS inline asembly in gcc, and some MIPS assembly as well, I try to do something relate to using simple ld / sd, then some addiu and bnez to loop, to perform 64 bits copy, and the 8 bits for residual part, and seens that will work well, but when I check the optimize version of memcpy looks will do almost the same, then I stoped my asm optimization :P

So, I will peform some test, but seems that I don't need any MIPS assembly, this time , thumbs up :)

P.E.: I tested and works much faster than before, I spect that many people get increase of speed in they application, memcpy its really used every where. So, update newlibc/sdk (don't forget to get last toolchain from svn, includes newlibc patch changes) and rebuild your sources.
_________________
mICrO^NewOlds
ja_medina at hotmail dot com

There is no such thing as a moral or an immoral book.

Books are well written or badly written.
(Oscar Wilde)