1
$\begingroup$

In a cache with byte addressing, the byte you want to load is selected using the block offset. But what if I execute a LW instruction and don't want a single byte but a full 32 bit word?

Is there some logic that selects whether you don't look at the block offset and just load the whole word (when you use a "load word" instruction) or you look at the block offset to choose the right byte (when you use a "load byte" instruction)?

$\endgroup$
  • $\begingroup$ Obviously, if the four bytes do not fit in the same cache line, the MMU will have to split the read. $\endgroup$ – Yves Daoust May 6 '15 at 18:25
  • $\begingroup$ But if they do? a cache block equals 4 bytes. $\endgroup$ – gilianzz May 6 '15 at 20:49
  • $\begingroup$ I don't see a problem. $\endgroup$ – Yves Daoust May 6 '15 at 21:00
  • 1
    $\begingroup$ There is some confusion about "byte addressing". Each byte can be individually addressed and modified, but the cache data bus may be wider than one byte. If you have a 32bits bus, a LW can be executed in 1 cycle. If you have a 8bits bus, the LW instruction will take 4 cycles to fetch each individual byte (actually, 32bits CPUs never have 8bits wide caches, they are too slow to be practical) $\endgroup$ – TEMLIB May 6 '15 at 21:15
  • $\begingroup$ So there is some logic that selects whether you don't look at the block offset and just load the whole word (when you use a "load word" instruction) or you look at the block offset to choose the right byte (when you use a "load byte" instruction)? $\endgroup$ – gilianzz May 7 '15 at 15:20
2
$\begingroup$

For nearly all major architectures, a cache line is 64 bytes wide. All memory transactions from your L1 cache all the way out to DRAM will use 64 byte lines. The only place where the byte address-ability comes into play is between the processor core and the L1 cache. It is common for L1 RAMs to be built with byte enables or some from of specification to a subset of the bytes from a 64 byte cache line.

Let's assume the interface from the processor to the L1 cache yields an address and a width (number of bytes). Suppose you want address 0xF002 and you want 4 bytes. The cache line is address 0xF000 (0xF002 & ~0x003f), the offset within the cache line is 0x0002 (0xF002 & 0x003f), and because you specified a 4 byte width you'd receive bytes 0xF002, 0xF003, 0xF004, and 0xF005.

Most processor/cache interfaces will only support common widths (1, 2, 4, 8 bytes), and basic architectures will force the addresses to be aligned (i.e., a 2 byte read can't start at an odd address). More advanced architectures will handle the misalignment in hardware (see MIPS unaligned load/store for a bad implementation). x86 allows unaligned loads and stores. Here is a short list of reasons unaligned memory accesses are bad:

Why unaligned access is bad

The effects of performing an unaligned memory access vary from architecture to architecture. It would be easy to write a whole document on the differences here; a summary of the common scenarios is presented below:

  • Some architectures are able to perform unaligned memory accesses transparently, but there is usually a significant performance cost.
  • Some architectures raise processor exceptions when unaligned accesses happen. The exception handler is able to correct the unaligned access, at significant cost to performance.
  • Some architectures raise processor exceptions when unaligned accesses happen, but the exceptions do not contain enough information for the unaligned access to be corrected.
  • Some architectures are not capable of unaligned memory access, but will silently perform a different memory access to the one that was requested, resulting in a subtle code bug that is hard to detect!

It should be obvious from the above that if your code causes unaligned memory accesses to happen, your code will not work correctly on certain platforms and will cause performance problems on others. from: https://www.kernel.org/doc/Documentation/unaligned-memory-access.txt

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.