1/1

|
How does a CPU store byte in memory with 32-bit granularity?
by BAndViG on Oct 26, 2013 |
BAndViG
Posts: 6 Joined: Mar 2, 2013 Last seen: Oct 23, 2015 |
||
|
How does a CPU store byte in memory with 32-bit granularity?
Hello all, I�m a newbie in computer architecture field with an initial level of self-education based mostly on Hennessy�s books. Perhaps, I read the books not attentively enough, but I still have got the topic question. I could imagine the following options: 1) Each time a CPU stores a byte it have to read appropriate 32-bit word from memory, replace the byte of interest and store the modified 32-bit word. 2) A CPU issues store command through a bus with a marker (for example, the Wishbone could have special signals to support the feature) of size to be stored. Then memory controller performs actions mentioned above. 3) A Cache controller (L1 or L2) with activated �Write Back/Write Allocate� policies performs the actions. It looks like for �Write Through/No Write Allocate� policies the combination of option #1 (for �write hit� case) and #2 (for �write miss�) has sense. Does a common approach exist? Which way is used in OpenRISC SoC? Thanks |
|||
|
RE: How does a CPU store byte in memory with 32-bit granularity?
by MichaelA on Oct 31, 2013 |
MichaelA
Posts: 3 Joined: Jul 3, 2013 Last seen: Feb 1, 2019 |
||
|
Will assume from your statement, 32-bit granularity, that there exists only a single memory write control signal. This situation would be abnormal if the computer/processor was intended to support byte write operations. With such a processor, it would be more appropriate to implement the memory, whether cache or otherwise, in a manner that supported the selecting and writing of bytes into memory in a single operation.
If the memory subsystem of your computer only supported 32-bit write operations, then the operations you described would all be appropriate solutions. Unless your processor speed is substantially faster than the access speed of your external memory, a cache is not an effective use of your resources. Caches should be reserved for those situations where the access time to external instruction/data memory is much slower than your internal instruction execution rate. Even then, if the processor supports byte write operations, then the cache should support byte write operations directly into the cache memory. With either a write back or a write through policy, the result to be written to memory should be taken from the cache after any byte writes have been made. In this manner, the external memory can be made with a single write strobe. In other words, the potential memory read-modify-write penalty is avoided altogether. The situation you described is not a situation that would normally encountered in mainstream memory implementations, particularly if the processor supports byte operations. If the processor does not support byte operations with its instruction set, then the matter is moot because the processor would need to do the byte operations programatically. |
|||
|
RE: How does a CPU store byte in memory with 32-bit granularity?
by BAndViG on Nov 17, 2013 |
BAndViG
Posts: 6 Joined: Mar 2, 2013 Last seen: Oct 23, 2015 |
||
|
Will assume from your statement, 32-bit granularity, ...
Thank you, Michael. I have also explored some additional materials and found that my question sounds quite specifically. It looks like the widely use approach is that a core provides data format thought specified interface and the memory subsystem have to care about correct storing process. |
|||
1/1

