Re: [microblaze-uclinux] another compiler oddity

[Yasushi SHOJI <yashi@xxxxxxxxxxxxxxxxx>]

Hi John,

At Tue, 17 Aug 2004 19:01:45 +1000,
John Williams wrote:
> 
> Hi Yashi,
> 
> Yasushi SHOJI wrote:
> 
> > one of my co-worker found this.  in a flat funciton, accessing block
> > ram is _slower_ thank dram.  if you make inner loop a function, block
> > ram is faster as i expected.
> > 
> > any thoughts?
> 
> Interesting...   You want to be careful with tests like this - there 
> could well be other factors.
> 
> AFAIK LMB/BRAM transactions are fixed at 2 cycles per access - it's 
> deterministic.  Similarly, a cache access (hit) will also be 2 cycles.
> 
> Did you disable the instruction cache for this test?  Because microblaze 
> cache is direct mapped, if you cross a particular power-of-two address 
> boundary (ie the physical cache size) you may end up thrashing the 
> icache, which would negatively impact the results.  The fact that you 
> got different results with inline code vs a function call might support 
> this interpretation.

well the test case is inline vs. flat.  not function.  I fist thought
this is something with cache.  I disabled i and d cache for test.

$ /var/inline
Elapsed time : 0.171622
Elapsed time : 0.143324

$ /var/flat
Elapsed time : 0.159957
Elapsed time : 0.228431

for both test, top line is for dram and bottom is bram.

> Also, how different were the results, and how repeatable?

I can reproduce any time. 100%.

did anyone see this? on DDR? I'll check assembly and hardware, if not.
--
        yashi
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/