GP32 Memcpy Performance

[pea]

Hi there,

I have a strange problem with the performance of my sprite drawing routine slowing down whenever memcpy is copying from an odd numbered memory address. Are there any know issues with this?

You can download an fxe and image -
http://www.pea.co.nz/gp32/downloads/gpd_spritetest2.zip

The debug info is as follows:

pos x: x position of top left corner of sprite
pos y: y "
vis width: The amount of the sprite that is visible horizontally
vis height: " vertically
data offset: The first pixel of the rotated sprite data to draw
framebuffer offset: The first 'pixel' of the frame buffer to start drawing too.

The drawing part of the routine is:

// Draw visible pixels only
for ( yy=0; yy<vis_height; yy++ ){
  memcpy( framebuffer+frmbuff_offset, &canvas->data[data_offset], vis_width*2 );  
  data_offset += canvas->height;
  frmbuff_offset += ROT_LCD_WIDTH;
}

As you can see it copies vertical chunks of the rotated sprite data directly to the frame buffer using memcpy, and then steps through the sprite data to the next vertical chunk, and steps through the framebuffer to where the next line starts. It does this for all visible columns of the sprite.

Note: it copies 'vis_width*2' bytes, because each 16bpp pixel is 2 bytes

Problem is, when the y pos of the sprite is odd (e.g. -151, -149, -147) etc, this causes the 'frmbuff_offset' to be an odd number, which slows performance remarkably when scrolling left and right.

Any ideas?

 

[rattboi24]

I think it sounds like an alignment issue.

Could you possibly do something like this:

check for odd address
if (odd)
read first byte
read other words
read last byte
else
read all words

Sorry for shitty pseudo code, but yeah, that's what I think it should do.
In fact, I thought memcopy did this anyways...

Anyways, weird

 

[pea]

Actually, my description is a little incorrect -

The data offset is the offset of the pixel data, so the actual address is always even because each pixel is 2 bytes (e.g. data_off = 12345; address = x + 24690; // 12345*2)

This means that memcpy is slow if it doesn't start on a 4-byte boundary (or whatever its called).

Is this ARM related? I have heard of the 4-byte boundary thing before. Is there another function I can use that is optimised for ARM (rather than memcpy) ?

EDIT:
Here is a good article on this. Now I just need to write my own memcpy function optimised for the ARM9
http://www.embedded.com/showArticle.jhtml?articleID=19205567

 

[rov]

i see memcpy is slow when i made my blit system

check your alignement, if it's 4 byte aligned, copy by int, else by short
also check the size and copy multiple group of pixels

ex :

if(!((int)screen&3)) // 4 bytes aligned
{ if(size > 15)
   { int nb = size>>4; // how many group of 8 pixels to draw ?
      size-=nb<<4;
      while(nb--) { *screen++ = *data++;
                          *screen++ = *data++;
                          *screen++ = *data++;
                          *screen++ = *data++;
                       }
   }
   while(size) { *screen++ = *data++; size-=2; }
} else {
     // code for a pixel by pixel copy ...
}

where screen and data are int* to the data array and screen pointer

see how i do in gdl², it's for 8 bit but is the same method

 

[mr.spiv]

Without knowing the exact implementation of the used memcpy() but some ARM related facts:
1) load byte instruction has 2 cycle load-use interlock thus a load byte followed by a store byte using the same register causes 2 cycle "do nothing" period in CPU pipeline

2) same for half word & misaligned half word / word reads (misalignments cause reboot by default in gp32)

3) load word has only 1 cycle load-use interlock..

So if the memcpy() is any clever it checks the alignment and uses specialized routine for each case... or uses proper pipelining.

 

[pea]

yeah, but it doesn't - so I'll have to write my own. I have found an assembler routine which does several things:

1) Short blocks are copied byte by byte
2) Blocks aligned from the start byte are copied forwards in 32 byte chunks, the last few bytes are copied by themselves
3) Blocks aligned from the end byte are copied bacwards same as above

The only thing is that I have no experience with assembler on the GP32 so have no idea of how to compile it!!!

/*	$NetBSD: memcpy.S,v 1.3 1997/11/22 03:27:12 mark Exp $	*/

/*-
 * Copyright (c) 1997 The NetBSD Foundation, Inc.
 * All rights reserved.
 *
 * This code is derived from software contributed to The NetBSD Foundation
 * by Neil A. Carson and Mark Brinicombe
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 * 3. All advertising materials mentioning features or use of this software
 *    must display the following acknowledgement:
 *	This product includes software developed by the NetBSD
 *	Foundation, Inc. and its contributors.
 * 4. Neither the name of The NetBSD Foundation nor the names of its
 *    contributors may be used to endorse or promote products derived
 *    from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
 * ``AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
 * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
 * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
 * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
 * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
 * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
 * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 * POSSIBILITY OF SUCH DAMAGE.
 */

/* This was modified by Jay Monkman <jmonkman@smoothsmoothie.com> to
 *   save and restore r12. This is necessary for RTEMS.
 */
/* #include <machine/asm.h>*/

#define ENTRY(_LABEL) \
  .global _LABEL; _LABEL:
/*
.globl memcpy
memcpy:
*/
ENTRY(memcpy)
	stmfd	sp!, {r0, r12, lr}
	bl	_memcpy
	ldmfd	sp!, {r0, r12, pc}


/*
.globl memove
memmove:
*/
ENTRY(memmove)
	stmfd	sp!, {r0, r12, lr}
	bl	_memcpy
	ldmfd	sp!, {r0, r12, pc}
	


/*
 * This is one fun bit of code ...
 * Some easy listening music is suggested while trying to understand this
 * code e.g. Iron Maiden
 *
 * For anyone attempting to understand it :
 *
 * The core code is implemented here with simple stubs for memcpy()
 * memmove() and bcopy().
 *
 * All local labels are prefixed with Lmemcpy_
 * Following the prefix a label starting f is used in the forward copy code
 * while a label using b is used in the backwards copy code
 * The source and destination addresses determine whether a forward or
 * backward copy is performed.
 * Separate bits of code are used to deal with the following situations
 * for both the forward and backwards copy.
 * unaligned source address
 * unaligned destination address
 * Separate copy routines are used to produce an optimised result for each
 * of these cases.
 * The copy code will use LDM/STM instructions to copy up to 32 bytes at
 * a time where possible.
 *
 * Note: r12 (aka ip) can be trashed during the function along with
 * r0-r3 although r0-r2 have defined uses i.e. src, dest, len through out.
 * Additional registers are preserved prior to use i.e. r4, r5 & lr
 *
 * Apologies for the state of the comments;-)
 */


/*
_memcpy:
*/
ENTRY(_memcpy)
	/* Determine copy direction */
	cmp	r1, r0
	bcc	Lmemcpy_backwards

	moveq	r0, #0  	/* Quick abort for len=0 */
	moveq	pc, lr

	stmdb	sp!, {r0, lr}  /* memcpy() returns dest addr */
	subs	r2, r2, #4
	blt	Lmemcpy_fl4  /* less than 4 bytes */
	ands	r12, r0, #3
	bne	Lmemcpy_fdestul  /* oh unaligned destination addr */
	ands	r12, r1, #3
	bne	Lmemcpy_fsrcul  /* oh unaligned source addr */

Lmemcpy_ft8:
	/* We have aligned source and destination */
	subs	r2, r2, #8
	blt	Lmemcpy_fl12  /* less than 12 bytes (4 from above) */
	subs	r2, r2, #0x14         
	blt	Lmemcpy_fl32  /* less than 32 bytes (12 from above) */
	stmdb	sp!, {r4}  /* borrow r4 */

	/* blat 32 bytes at a time */
	/* XXX for really big copies perhaps we should use more registers */
Lmemcpy_floop32:	
	ldmia	r1!, {r3, r4, r12, lr}
	stmia	r0!, {r3, r4, r12, lr}
	ldmia	r1!, {r3, r4, r12, lr}
	stmia	r0!, {r3, r4, r12, lr}
	subs	r2, r2, #0x20         
	bge	Lmemcpy_floop32

	cmn	r2, #0x10
	ldmgeia	r1!, {r3, r4, r12, lr}	/* blat a remaining 16 bytes */
	stmgeia	r0!, {r3, r4, r12, lr}
	subge	r2, r2, #0x10         
	ldmia	sp!, {r4}  /* return r4 */

Lmemcpy_fl32:
	adds	r2, r2, #0x14         

	/* blat 12 bytes at a time */
Lmemcpy_floop12:
	ldmgeia	r1!, {r3, r12, lr}
	stmgeia	r0!, {r3, r12, lr}
	subges	r2, r2, #0x0c         
	bge	Lmemcpy_floop12

Lmemcpy_fl12:
	adds	r2, r2, #8
	blt	Lmemcpy_fl4

	subs	r2, r2, #4
	ldrlt	r3, [r1], #4
	strlt	r3, [r0], #4
	ldmgeia	r1!, {r3, r12}
	stmgeia	r0!, {r3, r12}
	subge	r2, r2, #4

Lmemcpy_fl4:
	/* less than 4 bytes to go */
	adds	r2, r2, #4
	ldmeqia	sp!, {r0, pc}  /* done */

	/* copy the crud byte at a time */
	cmp	r2, #2
	ldrb	r3, [r1], #1
	strb	r3, [r0], #1
	ldrgeb	r3, [r1], #1
	strgeb	r3, [r0], #1
	ldrgtb	r3, [r1], #1
	strgtb	r3, [r0], #1
	ldmia	sp!, {r0, pc}

	/* erg - unaligned destination */
Lmemcpy_fdestul:
	rsb	r12, r12, #4
	cmp	r12, #2

	/* align destination with byte copies */
	ldrb	r3, [r1], #1
	strb	r3, [r0], #1
	ldrgeb	r3, [r1], #1
	strgeb	r3, [r0], #1
	ldrgtb	r3, [r1], #1
	strgtb	r3, [r0], #1
	subs	r2, r2, r12
	blt	Lmemcpy_fl4  /* less the 4 bytes */

	ands	r12, r1, #3
	beq	Lmemcpy_ft8  /* we have an aligned source */

	/* erg - unaligned source */
	/* This is where it gets nasty ... */
Lmemcpy_fsrcul:
	bic	r1, r1, #3
	ldr	lr, [r1], #4
	cmp	r12, #2
	bgt	Lmemcpy_fsrcul3
	beq	Lmemcpy_fsrcul2
	cmp	r2, #0x0c            
	blt	Lmemcpy_fsrcul1loop4
	sub	r2, r2, #0x0c         
	stmdb	sp!, {r4, r5}

Lmemcpy_fsrcul1loop16:
	mov	r3, lr, lsr #8
	ldmia	r1!, {r4, r5, r12, lr}
	orr	r3, r3, r4, lsl #24
	mov	r4, r4, lsr #8
	orr	r4, r4, r5, lsl #24
	mov	r5, r5, lsr #8
	orr	r5, r5, r12, lsl #24
	mov	r12, r12, lsr #8
	orr	r12, r12, lr, lsl #24
	stmia	r0!, {r3-r5, r12}
	subs	r2, r2, #0x10         
	bge	Lmemcpy_fsrcul1loop16
	ldmia	sp!, {r4, r5}
	adds	r2, r2, #0x0c         
	blt	Lmemcpy_fsrcul1l4

Lmemcpy_fsrcul1loop4:
	mov	r12, lr, lsr #8
	ldr	lr, [r1], #4
	orr	r12, r12, lr, lsl #24
	str	r12, [r0], #4
	subs	r2, r2, #4
	bge	Lmemcpy_fsrcul1loop4

Lmemcpy_fsrcul1l4:
	sub	r1, r1, #3
	b	Lmemcpy_fl4

Lmemcpy_fsrcul2:
	cmp	r2, #0x0c            
	blt	Lmemcpy_fsrcul2loop4
	sub	r2, r2, #0x0c         
	stmdb	sp!, {r4, r5}

Lmemcpy_fsrcul2loop16:
	mov	r3, lr, lsr #16
	ldmia	r1!, {r4, r5, r12, lr}
	orr	r3, r3, r4, lsl #16
	mov	r4, r4, lsr #16
	orr	r4, r4, r5, lsl #16
	mov	r5, r5, lsr #16
	orr	r5, r5, r12, lsl #16
	mov	r12, r12, lsr #16
	orr	r12, r12, lr, lsl #16
	stmia	r0!, {r3-r5, r12}
	subs	r2, r2, #0x10         
	bge	Lmemcpy_fsrcul2loop16
	ldmia	sp!, {r4, r5}
	adds	r2, r2, #0x0c         
	blt	Lmemcpy_fsrcul2l4

Lmemcpy_fsrcul2loop4:
	mov	r12, lr, lsr #16
	ldr	lr, [r1], #4
	orr	r12, r12, lr, lsl #16
	str	r12, [r0], #4
	subs	r2, r2, #4
	bge	Lmemcpy_fsrcul2loop4

Lmemcpy_fsrcul2l4:
	sub	r1, r1, #2
	b	Lmemcpy_fl4

Lmemcpy_fsrcul3:
	cmp	r2, #0x0c            
	blt	Lmemcpy_fsrcul3loop4
	sub	r2, r2, #0x0c         
	stmdb	sp!, {r4, r5}

Lmemcpy_fsrcul3loop16:
	mov	r3, lr, lsr #24
	ldmia	r1!, {r4, r5, r12, lr}
	orr	r3, r3, r4, lsl #8
	mov	r4, r4, lsr #24
	orr	r4, r4, r5, lsl #8
	mov	r5, r5, lsr #24
	orr	r5, r5, r12, lsl #8
	mov	r12, r12, lsr #24
	orr	r12, r12, lr, lsl #8
	stmia	r0!, {r3-r5, r12}
	subs	r2, r2, #0x10         
	bge	Lmemcpy_fsrcul3loop16
	ldmia	sp!, {r4, r5}
	adds	r2, r2, #0x0c         
	blt	Lmemcpy_fsrcul3l4

Lmemcpy_fsrcul3loop4:
	mov	r12, lr, lsr #24
	ldr	lr, [r1], #4
	orr	r12, r12, lr, lsl #8
	str	r12, [r0], #4
	subs	r2, r2, #4
	bge	Lmemcpy_fsrcul3loop4

Lmemcpy_fsrcul3l4:
	sub	r1, r1, #1
	b	Lmemcpy_fl4

Lmemcpy_backwards:
	add	r1, r1, r2
	add	r0, r0, r2
	subs	r2, r2, #4
	blt	Lmemcpy_bl4  /* less than 4 bytes */
	ands	r12, r0, #3
	bne	Lmemcpy_bdestul  /* oh unaligned destination addr */
	ands	r12, r1, #3
	bne	Lmemcpy_bsrcul  /* oh unaligned source addr */

Lmemcpy_bt8:
	/* We have aligned source and destination */
	subs	r2, r2, #8
	blt	Lmemcpy_bl12  /* less than 12 bytes (4 from above) */
	stmdb	sp!, {r4, lr}
	subs	r2, r2, #0x14  /* less than 32 bytes (12 from above) */
	blt	Lmemcpy_bl32

	/* blat 32 bytes at a time */
	/* XXX for really big copies perhaps we should use more registers */
Lmemcpy_bloop32:
	ldmdb	r1!, {r3, r4, r12, lr}
	stmdb	r0!, {r3, r4, r12, lr}
	ldmdb	r1!, {r3, r4, r12, lr}
	stmdb	r0!, {r3, r4, r12, lr}
	subs	r2, r2, #0x20         
	bge	Lmemcpy_bloop32

Lmemcpy_bl32:
	cmn	r2, #0x10            
	ldmgedb	r1!, {r3, r4, r12, lr}	/* blat a remaining 16 bytes */
	stmgedb	r0!, {r3, r4, r12, lr}
	subge	r2, r2, #0x10         
	adds	r2, r2, #0x14         
	ldmgedb	r1!, {r3, r12, lr}	/* blat a remaining 12 bytes */
	stmgedb	r0!, {r3, r12, lr}
	subge	r2, r2, #0x0c         
	ldmia	sp!, {r4, lr}

Lmemcpy_bl12:
	adds	r2, r2, #8
	blt	Lmemcpy_bl4
	subs	r2, r2, #4
	ldrlt	r3, [r1, #-4]!
	strlt	r3, [r0, #-4]!
	ldmgedb	r1!, {r3, r12}
	stmgedb	r0!, {r3, r12}
	subge	r2, r2, #4

Lmemcpy_bl4:
	/* less than 4 bytes to go */
	adds	r2, r2, #4
	moveq	pc, lr  	/* done */

	/* copy the crud byte at a time */
	cmp	r2, #2
	ldrb	r3, [r1, #-1]!
	strb	r3, [r0, #-1]!
	ldrgeb	r3, [r1, #-1]!
	strgeb	r3, [r0, #-1]!
	ldrgtb	r3, [r1, #-1]!
	strgtb	r3, [r0, #-1]!
	mov	pc, lr

	/* erg - unaligned destination */
Lmemcpy_bdestul:
	cmp	r12, #2

	/* align destination with byte copies */
	ldrb	r3, [r1, #-1]!
	strb	r3, [r0, #-1]!
	ldrgeb	r3, [r1, #-1]!
	strgeb	r3, [r0, #-1]!
	ldrgtb	r3, [r1, #-1]!
	strgtb	r3, [r0, #-1]!
	subs	r2, r2, r12
	blt	Lmemcpy_bl4  /* less than 4 bytes to go */
	ands	r12, r1, #3
	beq	Lmemcpy_bt8  /* we have an aligned source */

	/* erg - unaligned source */
	/* This is where it gets nasty ... */
Lmemcpy_bsrcul:
	bic	r1, r1, #3
	ldr	r3, [r1, #0]
	cmp	r12, #2
	blt	Lmemcpy_bsrcul1
	beq	Lmemcpy_bsrcul2
	cmp	r2, #0x0c            
	blt	Lmemcpy_bsrcul3loop4
	sub	r2, r2, #0x0c         
	stmdb	sp!, {r4, r5, lr}

Lmemcpy_bsrcul3loop16:
	mov	lr, r3, lsl #8
	ldmdb	r1!, {r3-r5, r12}
	orr	lr, lr, r12, lsr #24
	mov	r12, r12, lsl #8
	orr	r12, r12, r5, lsr #24
	mov	r5, r5, lsl #8
	orr	r5, r5, r4, lsr #24
	mov	r4, r4, lsl #8
	orr	r4, r4, r3, lsr #24
	stmdb	r0!, {r4, r5, r12, lr}
	subs	r2, r2, #0x10         
	bge	Lmemcpy_bsrcul3loop16
	ldmia	sp!, {r4, r5, lr}
	adds	r2, r2, #0x0c         
	blt	Lmemcpy_bsrcul3l4

Lmemcpy_bsrcul3loop4:
	mov	r12, r3, lsl #8
	ldr	r3, [r1, #-4]!
	orr	r12, r12, r3, lsr #24
	str	r12, [r0, #-4]!
	subs	r2, r2, #4
	bge	Lmemcpy_bsrcul3loop4

Lmemcpy_bsrcul3l4:
	add	r1, r1, #3
	b	Lmemcpy_bl4

Lmemcpy_bsrcul2:
	cmp	r2, #0x0c            
	blt	Lmemcpy_bsrcul2loop4
	sub	r2, r2, #0x0c         
	stmdb	sp!, {r4, r5, lr}

Lmemcpy_bsrcul2loop16:
	mov	lr, r3, lsl #16
	ldmdb	r1!, {r3-r5, r12}
	orr	lr, lr, r12, lsr #16
	mov	r12, r12, lsl #16
	orr	r12, r12, r5, lsr #16
	mov	r5, r5, lsl #16
	orr	r5, r5, r4, lsr #16
	mov	r4, r4, lsl #16
	orr	r4, r4, r3, lsr #16
	stmdb	r0!, {r4, r5, r12, lr}
	subs	r2, r2, #0x10         
	bge	Lmemcpy_bsrcul2loop16
	ldmia	sp!, {r4, r5, lr}
	adds	r2, r2, #0x0c         
	blt	Lmemcpy_bsrcul2l4

Lmemcpy_bsrcul2loop4:
	mov	r12, r3, lsl #16
	ldr	r3, [r1, #-4]!
	orr	r12, r12, r3, lsr #16
	str	r12, [r0, #-4]!
	subs	r2, r2, #4
	bge	Lmemcpy_bsrcul2loop4

Lmemcpy_bsrcul2l4:
	add	r1, r1, #2
	b	Lmemcpy_bl4

Lmemcpy_bsrcul1:
	cmp	r2, #0x0c            
	blt	Lmemcpy_bsrcul1loop4
	sub	r2, r2, #0x0c         
	stmdb	sp!, {r4, r5, lr}

Lmemcpy_bsrcul1loop32:
	mov	lr, r3, lsl #24
	ldmdb	r1!, {r3-r5, r12}
	orr	lr, lr, r12, lsr #8
	mov	r12, r12, lsl #24
	orr	r12, r12, r5, lsr #8
	mov	r5, r5, lsl #24
	orr	r5, r5, r4, lsr #8
	mov	r4, r4, lsl #24
	orr	r4, r4, r3, lsr #8
	stmdb	r0!, {r4, r5, r12, lr}
	subs	r2, r2, #0x10         
	bge	Lmemcpy_bsrcul1loop32
	ldmia	sp!, {r4, r5, lr}
	adds	r2, r2, #0x0c         
	blt	Lmemcpy_bsrcul1l4

Lmemcpy_bsrcul1loop4:
	mov	r12, r3, lsl #24
	ldr	r3, [r1, #-4]!
	orr	r12, r12, r3, lsr #8
	str	r12, [r0, #-4]!
	subs	r2, r2, #4
	bge	Lmemcpy_bsrcul1loop4

Lmemcpy_bsrcul1l4:
	add	r1, r1, #1
	b	Lmemcpy_bl4

 

[Palmic]

I am testing the asm code you have posted.

I 've tried to write a test similar to yours (scrollable canvas), and it seems (i'm not sure) that this memcpy code works like a charm !
With old memcpy : about 36 FPS, can drop to 16 with unaligned address.
Asm memcpy : about 40 FPS, can drop to 36.
So, it seems a quite huge improvement, to huge to be true...

That's why I would prefer that someone else confirm my impressions, maybe this is just luck, or my test that is really dumb!

 

[synkro]

@Palmic:

can you please provide a compiled version of that memcopy?!

 

[Palmic]

@Palmic:

can you please provide a compiled version of that memcopy?!

​

Hi synkro,

Ok so I've uploaded on my ftp http://palmic.free.fr/gp32/ all stuff needed to test this ASM memcpy.

You'll find a short main.c , which use Pea's gpd gif loading to draw a background larger than LCD screen. This project is done for Mirko'SDK , and I compile with GCC 3.4 .
I've put the compiled memcpy.o , and also the ASM source. You'll also find the final scroll.fxe and the test image, which needs to be in gpmm\gpdesktp\. Then you can run TEST_scroll , and move background with arrows key, reset by pressing A. I did not print debug info(except FPS), but the framerate seems more stable with ASM memcpy.

If you want to use this memcpy.o , just include it in your Makefile where you list objects files. In my Makefile this is done by "OBJS = main.o gpd_graphics.o memcpy.o".
Then, these .o are dependencies for my "all" target, and that is the cool point : gcc knows that, to produce memcpy.o, it must search for memcpy.c or memcpy.s. It finds the ASM source and compiles it alone to memcpy.o . So in fact compiling ARM ASM with gcc is really easy !

Now i'm wondering if the use of Mirko's setFrameBuffer fonction is a better solution for simple scrolling, because there is no memory copy, just the framebuffer pointer starting to the right point. Anyway this memcpy seems fast and could help to draw pre-rotated sprite.

 

[pea]

Thats great Palmic!

I'm sure that this version of memcpy could help all sorts of people get higher frame rates in their apps etc.

A note on just moving the framebuffer without moving memory - it won't work, because the data that is contained in the framebuffer must have all the visible pixels in one continuous 'row' - this in turn means that you can only play with the framebuffer location if your image is 240 pixels high exactly (and at least as wide as the LCD, so 340 pixels). You can then move it left and right by moving the framebuffer plus or minus 240 pixels at a time, but there is no easy way to move it up or down, as you will probably get a wierd diagonal effect instead!

 

[synkro]

Thank you Palmic!
Nice too see that some people take the long cold days for something useful

 

[pea]

"long cold days" ? In New Zealand it's 30deg celcius over christmas, and we have BBQs and go to the beach We are just used to it, but it must be strange for Northern-hemisphere visitors..

 

[synkro]

oki.. I tested it and some things bug me now...

It tested the new memcpy with a scrolling bg and some sprites (<50) at 66MHz. The only function using memcpy is the bg scrolling. compiled with the new one it is one frame slower than the old memcpy. Is there a way to use both in one prg to change between them on the fly? Can I force it to use the new memcpy? Is it maybe an issue with "-O3" cflag? the difference between both FXEs is 400bytes... ?! anyone else did a benchmark....

 

[pea]

How big are the other sprites? Perhaps the new memcpy works better only for larger images?

I'll do some benchmarking, and find out the optimum size to use each version of memcpy, and add this to the routine.

 

[pea]

Hi Palmic,

I have attempted to change the name of the asm function to 'fastmemcpy', so have replaced the following lines:

50: ENTRY(fastmemcpy)
52: bl _fastmemcpy

60: ENTRY(fastmemmove)
62: bl _fastmemcpy

102: ENTRY(_fastmemcpy)

But when compiling, I get the following error:

arm-elf-as   -o fastmemcpy.o fastmemcpy.s
fastmemcpy.s: Assembler messages:
fastmemcpy.s:50: Error: bad instruction `entry(fastmemcpy)'
fastmemcpy.s:60: Error: bad instruction `entry(fastmemmove)'
fastmemcpy.s:102: Error: bad instruction `entry(_fastmemcpy)'
c:\gp32_MrMirko\bin\make: *** [fastmemcpy.o] Error 1

Any ideas? As you can see, I renamed the file to 'fastmemcpy.s' also

 

[Palmic]

Well here are some remarks :

I have tried to compile the asm file, with original function names, with the command "arm-elf-as" , and the result was the same compilation errors (with original names of course).

Then i've tried with "arm-elf-gcc -c memcpy.S" and oh, no more errors !! So, maybe the problem is using directly arm-elf-as , i think we should not use it and let arm-elf-gcc call it when it is needed. I do not really understand why...

Also, maybe the ".globl" things are important, maybe they also need to be changed. And if it still does not work, you have to check with all global labels (like "memcpy:", "memmove:"...). Actually I wanted to test that but my GP32 seems to be haunted ! None of my previous tests work anymore, all i have is a blank background with the framerate, the nice woman doesn't want to appear on the background <_<

I will take a look to all theses problems but not before next week because of all end-year stuff... And next week i'll go back to school, damned studies . Good luck...

 

[pea]

hehe. Weird. Mine still works

With the asm memcpy I get a relatively steady 45 fps.

I can compile it ok with original names, if I change these I get the errors as I posted. Not sure about using arm-elf-ac directly, I don't think it is. My makefile is:

CC = arm-elf-gcc
LD = arm-elf-gcc
AS = arm-elf-as
AR = arm-elf-ar

PRG  = gpdesktop
ICON = gpdesktop.bmp
OBJS = gpdesktop.o gpd.o gpd_graphics.o gpd_windows.o memcpy.o

LIBS      = -L../lib -lmirkoSDK -lm
CRT0      = ../lib/crt0.S
LNKSCRIPT = ../lib/lnkscript
INCLUDES  = -I../lib.src/include
CFLAGS    = $(INCLUDES) -O2 -s -mtune=arm9tdmi

all:	$(OBJS)
	$(CC) -c -o crt0.o $(CRT0)
	$(LD) -nostartfiles -s -Wall -Wl,-Map,Test.map  -T $(LNKSCRIPT) crt0.o -o $(PRG).elf $(OBJS) $(LIBS)
	arm-elf-objcopy -O binary $(PRG).elf $(PRG).bin
	b2fxec -a Pea -t GPDesktop -b $(ICON) $(PRG).bin $(PRG).fxe

 

[Palmic]

I can compile it ok with original names, if I change these I get the errors as I posted. Not sure about using arm-elf-ac directly, I don't think it is.

Ok so you can compile with arm-elf-as without changing names.... My theory was based on line 44 and 45 : you can see a #define , which i think is a pure C pre-processor command like in every C file, so i thought that the asm file should first be pre-process by gcc, before the compilation.
But if it works with original names, then arm-elf-as seems to be able to pre-process the file too.
A brute force algorithm to be able to change names is : search and replace every *memcpy* by *fastmemcpy* :unsure: ...

 

[pea]

Yeah, I wondered whether I needed to change every instance, including those internal labels prefixed with 'L'...maybe I'll try it because I want to be able to use both versions of memcpy, and switch between them using function pointers (so only one compare is needed).

I also thought that maybe the names had to be 8 or less chars, but I tried different names (fastmc) and its still didn't work.