[PTLsim-devel] Few Issues with Unaligned Access

Tue Mar 13 14:11:26 EDT 2007

Hi,

Currently in the simulator once an unaligned access is detected the
faulting uop and all uops following it are annuled and fetching begins
from the rip of the faulting uop. Although the uop.origop->unaligned is
set to 1, but in the fetch stage it is not detected, as this time the
fetch() will try to get the uop from a newly decoded basic block
starting with the rip of the faulting uop. 
So, this uop reaches issue(), again detects unaligned access, again sets
uop.origop->unaligned to 1. Fetching again begins from the faulting
uop's rip, but this time fetch() recognizes the uop as unaligned.

So, our quick solution to the problem is by introducing to fields in
FetchQueueEntry structure. 
a) Basic Block RIP
b) the basic block index of the SOM uop of each uop.
This would help in resetting the current_basic_block_rip field and
current_basic_block_transop_index respectively. Hence, no new basic
block will be translated and unaligned access will be detected during
fetch() the first time.

Also, Matt I had mentioned few months back on taking speculative action
during issue for unaligned leads to splitting perfectly aligned loads
into 3 uops. So, in different runs of we get different number of loads
and stores. It also increases the number of uops. To tackle with this we
have moved the unaligned access action to commit stage to ensure that
number of uops being committed is correct and same for different runs.

Consider not unaligned action to commit, there is an interesting
observation. In the function check_and_translate if we move unaligned
access check in end, then also incorrect speculative uanligned detection
is reduced by a huge factor, in some cases no incorrect speculative
uanligned acces is generated.

We can also think of a predictor for unaligned access.

regards,
abhishek 