Mill Computing, Inc. Forums The Mill Architecture retire() question

  • Author
    Posts
  • Malcolm
    Participant
    Post count: 2
    #3122 |

    I’ve just discovered the Mill’s existence and am keenly watching through the presentation videos. The software pipelining video has raised some questions though, where I don’t quite see how your mechanisms achieve your objectives.
    Firstly, I think I see how None elegantly chews through most loop prelude issues (and NaR for epilogue). Absolutely lovely.
    The remaining issue seems to be ensuring that early loop body cycles issue data to the belt with the same shape as would be produced on subsequent iterations. And I don’t see how Dave’s Device accomplishes this.
    As described, retire took a single parameter causing extra Nones to be issued which pad the cycle’s belt contribution to the specified number.
    My first issue is: how do we know that the missing Nones are at the end of the cycle’s contribution? Suppose in the steady state 8 operations were to generate results b0-b7. On the first iteration only 5 did. Why can we assume that it was b3-b7 that generated results and thus padding b0-b2 with Nones is the right cause of action? How do we know that it wasn’t b0,b1,b4,b6, b7 generated and the Nones need to be slipped into the arbitrary subset b2,b3,b5?
    My second issue is that since operation latency depends on operand size, Nones must be decorated with a size (else it wouldn’t be clear when op(None, None) would produce its None output). How does retire know what size Nones it should use for padding?
    What advantages does retire give over some other mechanism for ensuring that the right None pattern is in-flight in the functional units at loop entry?

  • Malcolm
    Participant
    Post count: 2

    Apologies, I see this question is already answered in https://millcomputing.com/topic/pipelining/#post-1251

You must be logged in to reply to this topic.