A write-through cache writes to memory every time you write to the corresponding cache item. A write back cache will just write to the cache (marking the dirty bit) and only "write back" to memory when it has to (when it is evicted from the cache) and only if the dirty bit is marked (meaning that the value was actually edited).

A write allocate cache will first bring the line into the cache before writing (in preparation to read/write it more later), while a write-no-allocate cache will simply perform the write directly to memory.

This comment was marked helpful 4 times.

EDIT: The address of x on the slide has been changed to 0x12345604. During lecture it was 0x12341234. Note that since the cache has 64-byte lines, the last 6 bits in the address give the line offset. Although I drew the 4 bytes of x starting at line offset 4, it should have been at offset 52, since: 0x12341234 & 0x3f = 0x34 = 52.

I changed the address to 0x12345604 to fix the problem.

This comment was marked helpful 0 times.

Here's my own explanation because some things were not clear to me:

If I read an address x, that address's data (and neighboring data in the same line) will be loaded in to the cache. If I then write data to address x, the cache's version of x's data will be changed. In a write-back cache, a dirty bit may be set if this write actually changes that data. When this data is evicted from the cache, if the dirty bit is set, the data will be written out to main memory. In a write-through cache, the data will be updated in the cache, and written to main memory right away.

In a write allocate cache, if I write to memory address x and x's data was not loaded into the cache by a previous read, address x's data will be loaded into the cache. In a write no-allocate cache, address x's data will not be loaded, and the write will go straight to main memory.

This comment was marked helpful 3 times.

As mentioned in lecture, write back is usually paired with write-allocate to maximize the possibility and benefit of a cache hit, and x86 processors use this policy.

This comment was marked helpful 1 times.

I have question: why in the graph it is 1000 instead of 0001? Is it because x is a variable in stack?

This comment was marked helpful 0 times.

Question: @TeBoring has a good question. Who can answer it?

This comment was marked helpful 0 times.

@TeBoring Linux running on x86 architecture are little-endian machines meaning that the least significant bit is actually in the left most position. The wikipedia article on endianness goes into a lot more detail about both main types.

This comment was marked helpful 1 times.

Given their respective definitions, it was described that the relationship between a write back/through cache and a write allocate/no-allocate cache is "not orthogonal". For instance, it is very unlikely that you will have a write-allocate cache that is not write-back.

This comment was marked helpful 0 times.

@miko: A better example is that a write no-allocate cache that is write-back doesn't make a lot of sense. This is the example I should have used in lecture. I suppose a write-allocate cache that was write-through is useful if you believe the write is a predictor for future reads.

This comment was marked helpful 0 times.

Question: If endianness is the reason, why are the bytes not 01 00?

This comment was marked helpful 0 times.

An int is 4 bytes in this case.

1 = 0x00000001 (Big Endian)

1 = 0x01000000 (Little Endian)

If we leave off leading zeros. We get [1 0 0 0].

This comment was marked helpful 0 times.

@markwongsk Each square represents a full byte. I notice that the Wikipedia article that Thedrick referenced states that the little-endian version of "03 E8" is "E8 03", but each of those pairs represents only a byte.

If we wrote each byte out in pairs, than the number 1 would be "00 00 00 01", and so the little-endian version is "01 00 00 00", which the slide rights out as "1 0 0 0"

This comment was marked helpful 0 times.

@gbarboza, @zwei: Thanks that makes more sense now :) Didn't realize we were omitting the leading zeroes but I guess it makes sense if we are viewing 32 bit stuff.

This comment was marked helpful 0 times.