|
From: Nicholas N. <nj...@ca...> - 2003-11-03 11:25:41
|
On Mon, 3 Nov 2003, Balaji Iyengar wrote:
> i am trying to modify cachgrind so it tells me the percentage of hits and
> misses attributable to a particular address range. I went through the code
> in cg_sim_gen.c and cg_main.c and have the following questions.
>
> 1. #define CACHESIM(L, MISS_TREATMENT)
> this macro is defined in cg_sim_gen.c and I am not able to determine
> where it is used
[~/grind/head5/cachegrind] grep CACHESIM *.c
cg_sim_D1.c:CACHESIM(D1, { (*m1)++; cachesim_L2_doref(a, size, m1, m2); } );
cg_sim_gen.c:#define CACHESIM(L, MISS_TREATMENT) \
cg_sim_I1.c:CACHESIM(I1, { (*m1)++; cachesim_L2_doref(a, size, m1, m2); } );
cg_sim_L2.c:CACHESIM(L2, (*m2)++ );
> 2. the function: void cachesim_##L##_doref(Addr a, UChar size, ULong* m1, ULong *m2)
> is defined as part of the above macro, how is the ##L## translated to _I1_ and _D1_
As Tom said, it's macro concatenation.
> 3. If I have to make cachegrind except more command line arguments such as
> the starting address and range, wher would i make these changes.
Look for variables named "clo_*" and "VG_(clo_*)" in the skins (eg.
Cachegrind, Memcheck) for example usage. They're fairly straightforward.
> 4. Also what would help is a general description of the sequence in which the
> functions are called, because at this point I am totally at bay and dont
> quite understand what is happening where in the code.
Which functions?
First of all, have you read the skin-writing guide? (Section 7 of the
manual).
Once you've done that, I would try modifying Cachegrind in very small
steps. Start by just inserting printf's in strategic places to work out
when different things occur.
However, I think for what you want, all you need is to adjust the
cachesim_##L##_doref function -- because you don't want to change how the
addresses accessed are passed to the cache simulation, but rather what's
done with those addresses within the simulation. You don't need to know
how Cachegrind is finding those addresses. But I can understand that you
might want to know how it does it.
> 5. Could somebody highlight a brief set of steps that is required to do this
> sort of thing (seggregate cache misses/hits depending on the address space in
> the memory )
It seems there's two parts to your problem. The first is getting the
stream of address reads and writes. The second is using them to simulate
the cache. Segregating the memory falls under the second, and shouldn't
be hard -- instead of having single global counters for hit and miss
counts, have a series of them, one per address range.
Hope this helps.
N
|