Thanks for your replay, Avadh.
I know that 'transfer' function wakes up the waiting instruction by
invalidating tags[operand]'s bit. However, 'find_sources' function already
has invalidated the bit even in case that its operand's state was
'bypassing' base on my understanding.
=================================================
if likely (source_physreg.state == PHYSREG_WAITING) {
uopids[operand] = source_rob.get_tag();
preready[operand] = 0;
operands_still_needed++;
} else {
// No need to wait for it
uopids[operand] = 0;
preready[operand] = 1;
}
==================================================
This is the portion of 'find_sources' function. The function thinks all
operands are ready except the operands which are waiting state. So I think
the conditional check should be changed to '(source_physreg.state ==
PHYSREG_WAITING || source_physreg.state == PHYSREG_BYPASSING)'.
Is there anything I miss-understand?
Thanks
Hanhwi
2012/9/27 avadh patel <[email protected]>
>
>
> On Tue, Sep 25, 2012 at 1:19 AM, hanhwi jang <[email protected]> wrote:
>
>> Hi,
>>
>>
>> I have a question on instruction issue timing.
>>
>> As I know, to issue instruction, instruction should be ready by reading
>> its operands from physical register or bypass logic, but marss seems to
>> issue instruction not ready.
>>
>>
>> In my understand, marss check instruction ready bit in dispatch time
>> first using find_sources() in dispatch stage, and then it wakes up the
>> waiting instructions using broadcast () in transfer stage. However, the
>> problem is that find_sources () sets preready bit if operands' state is not
>> PHYS_WAITING, and doesn't capture operands' bypassing state.
>>
> As a result, instruction can be issued although its operands are on bypass
>> logic but not arrived target cluster. This seems to work fine in case that
>> forwarding latency is 0.
>>
>>
>> My question is "what happens if forwarding latency is longer then 0?". I
>> think it could problem, but I'm not 100% certain, so i want to know my
>> question is correct.
>>
>>
>> In the pipeline, once an instruction complete's its execution, physical
> register changes state to bypass. Now based on code in 'transfer' function
> in ooo-pipe.cpp, in next cycle data of that register will be forwarded to
> issue queue using 'broadcast'. In same cycle, an instruction will be
> issued given that FU is available. In total we simulate 1 cycle delay
> between complete of previous instruction and start of another instruction.
>
> In this scenario when we increase forwarding latency, it will delay the
> 'broadcast' and issue queue tags will not be updated until forward latency
> + 1 cycle. So based on my understanding of the code (remember this code is
> from PTLsim), higher latency will be simulated in forwarding logic.
>
> - Avadh
>
>> Thanks.
>>
>> Hanhwi
>>
>> _______________________________________________
>> http://www.marss86.org
>> Marss86-Devel mailing list
>> [email protected]
>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
>>
>>
_______________________________________________
http://www.marss86.org
Marss86-Devel mailing list
[email protected]
https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
