How do you convert a hex number to a decimal value in java? Like for example 408ed4.
I used Integer.parseInt( ..., 16 ) where ... is the string containing the number in hex format.
> java CacheSim -s 256 -w 1 -l cc1-short.din address=408ed4, tag=16526, slotNum=212 miss on address 408ed4 address=10019d94, tag=1048989, slotNum=148 miss on address 10019d94 address=408ed8, tag=16526, slotNum=216 miss on address 408ed8 address=10019d88, tag=1048989, slotNum=136 <=============== address=408edc, tag=16526, slotNum=220 <=============== why does address occur twice here?
Because address 10019d88 is a write "1" and is not in the cache, it does not generate a miss nor a hit (it is just added to the cache with dirty bit = true). So, no "miss on address ..." nor "hit on address ..." message is generated and the program just proceeds to process the next line (address=408edc) in the .din file.
if im doing a write instruction and i get a hit with the dirty bit = 0
the tag doesnt change but do i change the dirty bit = 1?
also if im doing a write instruction and i get a hit with dirty bit = 1
the tag doesnt change and i keep the dirty bit as 1?
Yes if you have a write address, then you always set the dirty bit to 1 for the entry in the cache where the write address is stored. Once a dirty bit is set, it is not reset until a new address is stored in that entry (whereupon the eviction of the dirty old address generates a miss).
I was wondering what is the definition of the hit ratio. From samples.txt,
it seems that
hit ratio = (# of hits) / [(# of hits) + (# of misses)].
But I'm wondering if it should be
hit ratio = (# of hits) / (# of memory traces),
where "# of memory traces" is the number of lines in a trace file.
We are using the first definition, but one could easily argue for the second one too. In many cases, the two are the same. However, in our case, because we are using a block size of one, we can avoid going to memory to fetch the address in the case of a write (with a block size larger than one, we have to fetch the entire block before writing the one address into the cache because otherwise the other entries in the block would be incorrect). Since that does not count as a hit (the address is already in the cache) nor as a miss (memory access is required), it changes the stats. Also, we are counting writes to memory (when a dirty entry is evicted from the cache) as misses, which may or may not be accurate depending on the connection to memory. If it is a standard bus, then the write to memory ties up the bus and no reads can be started until the write is finished. If the next memory address is not in the cache, then reading it would have to wait until the write is finished. On the other hand, if the next few addresses are already in the cache, then the write does not affect performance at all.
Thanks. But my question was:
(lines 170--172 in sample.txt)
address=40a320, tag=16547, slotNum=32
miss on address 40a320
miss (eviction) on address 408f20
why miss (eviction) on address 408f20 occurs even though the dirty flag
of the slot is false (because there is no "write" on address 408f20 in cc1-short.din, but only "instruction fetch". When a memory address is evicted
from the cache and the dirty flag is false, should I count it as a miss?
Thanks for pointing out the second error (hopefully that's the last one :-). I neglected to reset the dirty bit to false when I put something new into the cache that evicted a dirty entry but was not also a write. I have corrected samples.txt.
I got different results from those in samples.txt. ...
Thanks for pointing out the error. I was mistakenly printing the address of the new entry rather than the address of the evicted entry. I have corrected the error in samples.txt and also added printing the address (in hex), tag (in decimal) and the slotNum (in decimal) for every address that is read in from the .din file.
It would be very helpful for us to have reference simulations, to check our results. Maybe we can find it somewhere at the web?
Please check samples.txt for results for cc1-short.din using -s 256 and -w 1, 2 and 4 and both -f and -l. The sample results also print out "hit on address ..." whenever there is a hit, "miss on address ..." whenever there is a read (0 or 2) miss and "miss (eviction) on address ..." whenever there is a miss due to evicting a dirty address. You might want to add similar print statements to your code for debugging purposes, but be sure to comment them out before submission.
Am I to assume "1" label (write data) is nethier considered a hit or miss?
If the write address is already in the cache, then it should be counted as a hit. If it is not in the cache, then it is neither a hit nor a miss (the miss is counted later when the address is evicted from the cache).
when there is a:
2 430d70
According to dinero format, 2 = instruction fetch? Do I ignore it?
Same question for:
0 1000acac
Do not ignore any of the memory trace data. A label of "2" (instruction fetch) and a label of "0" (read data) both followed by a hex memory address means that your cache simulation program should look for that memory address in the cache. If the memory address is found in the cache, then you have a hit. If it is not found, then you have a miss and that address should be added to the cache, possibly replacing some other memory address already in the cache. If the other memory address that is evicted from the cache is "dirty," then another miss is generated. A label of "1" (write data) is handled in a similar fashion as the "0" and "2" labels, except the "dirty" bit in the cache entry for that address is set to true. Also, a "1" label (write data) does not generate a miss if the memory address is not already in the cache because the write does not have to go to memory to read that memory address' contents before writing the new value into the cache (the actual memory contents are not updated until that memory address is evicted from the cache and if the program ends before eviction, then that memory address' contents are never updated and so no miss is ever generated).
As for:
1 7fff00ac
I'm suppose to figure out the slot and tag. Could you give an example of
figuring out the tag and slot for 7fff00ac?
First you have to figure out the total number of slots in your subcaches. Because your assignment cache only stores the tag and no actual data, this is just the size (the -s flag) divided by the associativity, which is given by the -w flag (an N-way set associative cache). For example, an 4-way 8k cache would be -w 4 -s 8192, which gives 8192 / 4 = 2048 slots in each of the 4 subcaches. Then the slot index of 7fff00ac = 2147418284 in decimal is 2147418284 % 2048 = 172 and the tag is 2147418284 / 2048 = 1048544.