http://repo.m5sim.org/wiki/index.php?title=Unaligned_memory_accesses&feed=atom&action=historyUnaligned memory accesses - Revision history2024-03-29T13:02:01ZRevision history for this page on the wikiMediaWiki 1.29.2http://repo.m5sim.org/wiki/index.php?title=Unaligned_memory_accesses&diff=2160&oldid=prevGblack at 01:04, 12 July 20072007-07-12T01:04:56Z<p></p>
<table class="diff diff-contentalign-left" data-mw="interface">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr style='vertical-align: top;' lang='en'>
<td colspan='2' style="background-color: white; color:black; text-align: center;">← Older revision</td>
<td colspan='2' style="background-color: white; color:black; text-align: center;">Revision as of 01:04, 12 July 2007</td>
</tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l1" >Line 1:</td>
<td colspan="2" class="diff-lineno">Line 1:</td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div>I believe real hardware takes care of memory alignment by issuing two loads or stores if necessary from the same instruction in the load/store queue. The result is combined after the data gets back as part of the load/store and things continue. That doesn't seem to fit very well with m5 which assumes aligned accesses and causes problems if it receives something else. ptlsim handles things by having two different versions of every memory operation which do the low and high portions of an access and then glue it together. <del class="diffchange diffchange-inline">There are probably complications </del>there <del class="diffchange diffchange-inline">with goofy </del>segmentation <del class="diffchange diffchange-inline">and paging</del>, and <del class="diffchange diffchange-inline">it doesn't seem like it would be very accurate performance wise</del>.</div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>I believe real hardware takes care of memory alignment by issuing two loads or stores if necessary from the same instruction in the load/store queue. The result is combined after the data gets back as part of the load/store and things continue. That doesn't seem to fit very well with m5 which assumes aligned accesses and causes problems if it receives something else. ptlsim handles things by having two different versions of every memory operation which do the low and high portions of an access and then glue it together. <ins class="diffchange diffchange-inline">One problem with this method is that instead of a single memory operation "stuttering", </ins>there <ins class="diffchange diffchange-inline">would be two operations taking up twice as many resources. Also, if </ins>segmentation <ins class="diffchange diffchange-inline">happens at the address translation step</ins>, <ins class="diffchange diffchange-inline">figuring out what part of a memory operation should be done in each step is harder to predict. Segmentation to align unaligned addresses </ins>and <ins class="diffchange diffchange-inline">unalign aligned addresses</ins>.</div></td></tr>
</table>Gblackhttp://repo.m5sim.org/wiki/index.php?title=Unaligned_memory_accesses&diff=2138&oldid=prevGblack at 21:15, 13 June 20072007-06-13T21:15:25Z<p></p>
<p><b>New page</b></p><div>I believe real hardware takes care of memory alignment by issuing two loads or stores if necessary from the same instruction in the load/store queue. The result is combined after the data gets back as part of the load/store and things continue. That doesn't seem to fit very well with m5 which assumes aligned accesses and causes problems if it receives something else. ptlsim handles things by having two different versions of every memory operation which do the low and high portions of an access and then glue it together. There are probably complications there with goofy segmentation and paging, and it doesn't seem like it would be very accurate performance wise.</div>Gblack