About problem 4:In order to validate your cache simulator it is best to use the provided example input traces and try to match the provided stats and checksums. All necessary files are found under: /afs/ece/class/ece741/hw1/traces/small

Question:The first part of the problem is to translate the IA32 'REP MOVS' into Alpha. I just looked up REP MOVS in the manuel and it says: Move ECX bytes from DS:[ESI] to ES:[EDI]. However, the values for DS and ES are not given in the problem? (ECX, ESI, EDI are all given). Should we use 0 for both?
Answer: DS ans ES are segment registers that determine the offset at which a memory address starts. They are present in the x86 ISA because x86 ISA includes “segmentation” which is intended to protect different processes' memory spaces from each other. Every memory address is computed by adding the effective address (as computed based on the addressing mode of the memory instruction) to a segment base register (DS and ES in this case; CS when accessing an instruction in memory using the instruction pointer). As the Alpha ISA does not include segmentation, equivalents for DS and ES (and CS) do not exist in Alpha. Therefore, sure, you can use 0 for the values of DS and ES.

Question:In the caching problem, is the memory system byte-addressable or can we access only every 4 bytes? If I understood correctly this will influence the number of bits for the tag, line and word fields.
Answer:Assume a byte-addressable memory system. Yes, this would influence the number of tag bits. For example, in a 64KB 2-way set associative cache with 64 byte blocks your tags would be 17 bits long and you would require 9 bits to address each way of your cache. The remaining 6 least significant bits of the incoming address would be the byte offset within the 64-byte cache block.

Question:Could you please explain what is meant by “forced evictions due to inclusion”.
Answer:A forced eviction at the L1s can happen as a consequence of a block that is evicted from the L2 cache. Essentially every time you have an eviction at the L2 (clean eviction or a dirty writeback) you have to probe the L1s to check if this block is also stored in the L1s and evict it (to preserve the inclusion property). In particular, for dirty L1 blocks these are called “forced dirty evictions” and for clean L1 blocks they are called “forced clean evictions”. They are called “forced evictions”, because they are an artifact of maintaining the inclusion property. In other words if we did not require inclusion, these evictions would not be necessary.

Note on dirty bit: After processing a store reference that missed in the L1-D and hit in the L2 the dirty bit of this block in the L1 should be set to 1 and in the L2 it should be set to 0.

Comments on Flexus assignment: You need to make sure you have a clean .bashrc file before running Flexus. Scripts from other courses that are included in your .bashrc (e.g., ~ece447) need to be commented out.

Submission Instructions:

• Parts 1, 2 and 3 (problems and questions on papers) are due on paper and must be typed. No handwritten assignments will be accepted. The final submission for problems 4 and 5 will be done electronically. Copy all relevant files to the directory in /afs/ece/class/ece741/hw1/submission/ece_login (we have created this directory for you), where ece_login is your ECE username. The directory is unlocked until the deadline (beginning of class Wednesday morning) so you can make changes until then if you submit early. Please make separate directories for assignments 4 and 5.
• The games cluster is not visible from non-CMU machines. Try first to login to an ECE machine (e.g., alpha.ece.cmu.edu) and then ssh to the cluster.
• In order to be able to submit your files, you need to have write permissions on ECE AFS space. If you don't know how to get tokens for your ECE account you can login to an ECE machine and submit your code from there.