Re: [Gems-users] Strange Ruby statistics

["Daniele Bordes" <daniele.bordes@xxxxxxxxx>]

Hi Dan.  Frist of all, excuse me, but the trace file I wrote last time
was wrong; this is the correct trace file:

0x00000040  LD
0x00000080  LD
0x000000C0  LD
0x009000C0  LD
0x000000C0  LD
0x009000C0  LD

(Last time I was wrong, having confused 009000C0 with 00900040)


Well, I am nearly sure the allocation in L2 of  0x000000C0 is due to
the third reference.  Here there is the sequence of the first ten
"events" (that is, function calls) among issuing an address and
allocating it:

0x00000040  issue
0x00000040  allocated in L1
0x00000040  allocated in L2

0x00000080 issue
0x00000080 allocated in L1
0x00000080 allocated in L2

0x000000C0 issue
0x000000C0 allocated in L1

0x009000C0 issue
0x009000C0 allocated in L1

0x000000C0 allocated in L2

As you can see, it seems that the allocation of 0x000000C0 in L2
happens AFTER 0x009000C0 issue, but it is different from how the trace
file is organized; well, it seems to me very strange, because I made
some code modifications (for instance, triggerAllEvents before
processing a new reference) that I believe would have forced simulator
to completely perform all the actions due to an address reference
before issuing the next one. Perhaps, the allocation in L2 of
0x000000C0 is not due to the Load, but to the eviction in L1 of that
address just after 0x009000C0 allocation in L1 (remember that L1
associativity is 1), but should not the memory hierarachy be strictly
inclusive? And if not, why 0x000000C0 is not allocated in L2 but the
two previous addresses are allocated in L2?
Is there something wrong in my reasoning? Please, can you help me?

Sorry to be a nuisance.
Thank you very much.