cache aware programming

Hi all,

I am using PowerPC on Virtex II Pro. The whole program is bigger than the cache, I suspect though that most of the times only a portion of the code is used that would fit into the cache. Is there a way I could ensure that this part of my code is so compiled that it could be all loaded into the cache at a time? I welcome any sugestions.

Regards, e.

Reply to
eascheiber
Loading thread data ...

The cache should work this out for itself. No need for you to tell it.

Cheers, Jon

Reply to
Jon Beniston

If you are using gcc then have a look at -fprofile-arcs and -ftest-coverage command line options, they might help you out

Hans

formatting link

Reply to
Hans

If you're worried about tag collisions preventing your code from all being cached, the easiest way to avoid that would be to make sure the cachable part is all contiguous.

One way to do this in the GNU toolchain is to make a custom link script with a block like (nb you need an entire link script around this!):

.text : { *(cache) *(.text) }

Then you can use __attribute__ ((section ("cache"))) to put functions there (you can hide that in a macro) (it goes between the return type and the function name). You can turn that around and have a 'rare' section and move that out to leave the rest close together.

--
Ben Jackson

http://www.ben.com/
Reply to
Ben Jackson

Hi,

I am using __attribute__ ((section ("ppath"))) and __attribute__ ((longcall)) now in my program. The relevant linker script part looks like this:

MEMORY { SDRAM_64Mx16 : ORIGIN = 0xF0000000, LENGTH = 0x01FFFFFF plb_bram_if_cntlr_1 : ORIGIN = 0xFFFFC000, LENGTH = 0x00003FFF }

/* Specify the default entry point to the program */

ENTRY(_boot) STARTUP(boot.o)

/* Define the sections, and where they are mapped in memory */

SECTIONS { .vectors : { __vectors_start = .; *(.vectors) __vectors_end = .; } > SDRAM_64Mx16

.text : { __text_start = .; *(.ppath) *(.text) *(.text.*) *(.gnu.linkonce.t*) __text_end = .; } > SDRAM_64Mx16

After compilation I run powerpc-eabi-objdump and I get:

0 .vectors 000020c4 f0000000 f0000000 00000110 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .text 0000e6e8 f00020c4 f00020c4 000021d4 2**2 CONTENTS, ALLOC, LOAD, CODE 2 ppath 0000001c 00000000 00000000 000000f4 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 3 .rodata 00000906 f00107ac f00107ac 000108bc 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .fixup 00000014 f00110b4 f00110b4 000111c4 2**2

My question is why is ppath at 0x00000000 when this address should not be mapped in the SDRAM?

Actually I would have liked to have the ppath section directly after or before all other code, so that maybe __attribute__ ((longcall)) shouldn't even be necessary.

Regards, e.

Reply to
eascheiber

Ok guys,

I think I got it, it should be: *(ppath) without the dot and I won't see section ppath in the output :).

Regards, e.

Reply to
eascheiber

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.