[Question] Five questions on the Frontend about scarab HOT 2 CLOSED

Thank you once again for the good questions!

The code here is quite confusing, but I believe it is correct as is. Let me explain.

There are 3 functions which all play a roll in answering your question:

1. update_icache_stage
2. icache_issue_ops
3. packet_build

update_icache_stage acts as a state machine that tracks the state of the fetch unit. The state machine is controlled by a switch statement that implements the functionality for each state. For example, if there was an i-cache miss, then the state will be IC_WAIT_FOR_MISS and the function will do nothing until the cache miss has been satisfied. Whenever the state is IC_FETCH, the i-cache is accessed and if there is a hit, then we are ready to issue ops and the icache_issue_ops function is called. Note, icache_issue_ops is called from within a while loop that only breaks when break_fetch is not set to BREAK_DONT. This means that while update_icache_stage is only called once per cycle, icache_issue_ops can be called many times per cycle.

icache_issue_ops issues a sequence of consecutive ops to the decoder. These ops are all accessed using the same fetch address (ic->fetch_addr) and therefore must follow one another in memory. The fetch address is not updated after each op, but rather updated after each branch by the predictor as this is more realistic. icache_issue_ops continues fetching ops until it is interrupted by packet_build.

packet_build is responsible for detecting conditions that will "break fetch" for the current cycle. For example, if we have maxed out our issue width, then we cannot continue to fetch instructions in the current cycle and the packet will be terminated (i.e., break_fetch is set to BREAK_ISSUE_WIDTH).

The interface here is a bit confusing. packet_build returns two variables. The first variable is the value returned by the function. This is a message for icache_issue_ops that tells the function whether it should continue fetching or break out of its while loop and return to update_icache_stage. The second variable is break_fetch, which is a message to update_icache_state that tells the function whether it should continue fetching or break out of its while loop.

So with that, let's move on to your questions.

Q1: Doesn't line 247 make line 219 obsolete?
No. Line 247 does not set break_fetch, so it will not create a packet break (i.e., more instructions can and will be fetched in the same cycle).

Q2: Why isnt' the *break_fetch reason set in line 247?
Because we do not want branches to terminate fetch for the current cycle. We do, however, need to break out of icache_issue_ops so that ic->fetch_addr can be updated as a result of the branch instruction that was just fetched (Note that bp_predict_op updates ic->next_fetch_addr).

So line 247 is not a true packet break, it is just a message to update the fetch address. Line 219, on the other hand, will break fetch for the current cycle after a threshold of branch instructions have been fetched (simulating branch predictor bandwidth).

Q3: Branch prediction can be wrong so isn't it natural that this assertion fails?
Branch prediction can be wrong, but that is not what this assert is checking. The assert is checking that the PIN frontend fetched the op that the icache stage is expecting. The op the icache stage is expecting can either be on the correct path or the wrong path.

Q4: With fetch break on each CF instruction, the assertion in contrast never fails? Why?
This assertion fails when this line is removed because ic->fetch_addr has not been properly updated, so the next instruction provided by the PIN frontend is not the one expected by the backend.

Q5: Is it safe to just comment out the assertion above?
No, this assertion is useful for detecting errors in either the PIN frontend or the icache stage (the two must remain consistent).

Hope this all makes sense! Let me know if you have other questions.

Stephen

from scarab.

Hi Stephen,
wow! what an excellent elaborate answer.

I am running my own (trace-based) frontend which I guess is the reason why I am running into the assertion (Q3).

I believe there is an incompatibility between "--fetch_break_on_taken 0" and "--fetch_off_path_ops 1".

I assume that the bp mispredicts, expecting the pin frontend to deliver an off-path instruction. As my trace frontend cannot deliver off-path instructions, the assertion fails.

When I do "--perfect_bp 1" and "--perfect_btb 1" the assertion does not fail.

from scarab.