XScale: Is Separate I and D Cache Appropriate for PC-Relative Variables?

"Tim Clacy" schrieb im Newsbeitrag news:3f586dc1$0$267$ snipped-for-privacy@news.dk.uu.net...

How do you get to this assumption ? As I observe it, GCC does some PC-relative adressing in the ldr instruction mainly to load some "constants", which are put by the compiler into .text segment (going in ROM).

The ARM9/XScale is a Harvard architecture, getting perfomance from simultaneously reading instructions and reading/writing data. And as I is mainly the readonly instructions in ROM/FLASH or a distinct RAM area and D is mainly the .data/.bss/heap in RAM there is little "wasting".

Arey you into self modifying code for AI ?

I feel like the amount of overlap can usually be ignored.

Raymund Hofmann

I should have written assembler instead of compiler, not that it really matters since the compilers I use can also place data in PC-relative pools. Besides, it doesn't have to just be constants; take the interrupt vector table for example.

That wasn't the reason why I posted but, as it happens, yes... kind of... but not for AI. I'm into binary vector switches; that is a branch that can go one of two ways and flip the junction over so that it would go the other way next time; this is one side of an an event latch. In other words, the most efficient context switch possible using only one instruction (OK, two because of these cursed split load-store beasts). But that's by the by... :-)

Cheers for chipping-in.

...oh, I forgot the original point :-) The reason for the post was that, in this particularly case, it would have been more useful to have a non-split cache since the flyby DMA doesn't work in the PXA processors and we have tens of Mega bytes to shift around. It's not the end of the world, just an uncomfortable straight-jacket.

You would probably feel far more straight-jacketed by how much your performance would be limited by not being able to fetch code and data in parallel when executing instructions on the CPU. It would simplify matters if the SA architecture (and I am assuming the XScale architecture, as well) had an "icbi"-type instruction, but having to execute a series of nops to flush the instruction cache isn't that much overhead relative to moving 10s of MB, certainly.

What if you're not executing out of RAM? Also, the how 'inefficient' it is is going to depend on program design. If your locals can all be stored in registers then having a cache located around the pc isn't going to help. Maybe a chip designer will kick in also, because I have a feeling that there may be architectural reasons for keeping the two caches separate.

variables,

end

In

when

is

there

Dingo. Hi. I'm aware of the benefits in traditional, sequential, single-thread code where code and local data are physically distant, but the post was with regard to PC-relative data.