4 ms·

The answer at 1:26:12 [1] about the belt being in fact a 'proxy' of the bypass network is very interesting. [1] https://youtu.be/D7GDTZ45TRw?t=5172 https://you

by fla 11y ago

The answer at 1:26:12 [1] about the belt being in fact a 'proxy' of the bypass network is very interesting. [1] https://youtu.be/D7GDTZ45TRw?t=5172 https://youtu.be/D7GDTZ45TRw?t=5172

signa11 11y ago
yeah well during mis-predictions, interrupts etc. undoing that entire state (of name-mappings, and re-create a different one perhaps) might not be easy. moreover, since it is running kind of a cycle ahead, it seems that this whole network, seems more like a cross-bar switch, for renames :)
- willvarfar 11y ago
  (Mill team) On a conventional register-based OoO interrupts require issue replay and this is a major source of complexity and budget. On the Mill, which is a "belt machine", interrupts are as far as the hardware is concerned just an involuntary function call; the Mill does result replay. Regards mispredicts the Mill has a shockingly short pipeline and mispredicts (where the target is in cache) is only around 5 cycles or so. The Mill has a novel prediction mechanism called transfer prediction as covered in this talk http://millcomputing.com/topic/prediction/ http://millcomputing.com/topic/prediction/
  - signa11 11y ago
    thanks for clarification, as well as the link to the talk !
  - nhaehnle 11y ago
    Any thoughts about debugger support on the Mill? It seems to me that this could be a bit of a headache. For example, the usual technique for breakpoints is to trigger an interrupt at the desired instruction, which then causes a context switch to the debugger process. How will the debugger be able to access all the bypass-network/belt/spiller data? My off-the-cuff thought is that since the spiller has a mechanism for dumping its state in memory anyway, there is probably (or should be) a way for software to force it to dump this state, which could be used by the debugger to read all the required data from a specified (probably model-specific) structure in memory.
    - willvarfar 11y ago
      Exactly. The OS can of course control who can debug what.
pests 11y ago
Yes, amazing. I've always wondered how the belt was implemented and it turns out its not a belt at all.
- vanderZwan 11y ago
  I think Godard actually explicitly said that in a Q&A of one of the very first lectures - although I have to admit at that point the finer details of the discussion were way over my head.

by fla 11y ago

The answer at 1:26:12 [1] about the belt being in fact a 'proxy' of the bypass network is very interesting. [1] https://youtu.be/D7GDTZ45TRw?t=5172 https://youtu.be/D7GDTZ45TRw?t=5172

signa11 11y ago

yeah well during mis-predictions, interrupts etc. undoing that entire state (of name-mappings, and re-create a different one perhaps) might not be easy. moreover, since it is running kind of a cycle ahead, it seems that this whole network, seems more like a cross-bar switch, for renames :)

willvarfar 11y ago
(Mill team) On a conventional register-based OoO interrupts require issue replay and this is a major source of complexity and budget. On the Mill, which is a "belt machine", interrupts are as far as the hardware is concerned just an involuntary function call; the Mill does result replay. Regards mispredicts the Mill has a shockingly short pipeline and mispredicts (where the target is in cache) is only around 5 cycles or so. The Mill has a novel prediction mechanism called transfer prediction as covered in this talk http://millcomputing.com/topic/prediction/ http://millcomputing.com/topic/prediction/
- signa11 11y ago
  thanks for clarification, as well as the link to the talk !
- nhaehnle 11y ago
  Any thoughts about debugger support on the Mill? It seems to me that this could be a bit of a headache. For example, the usual technique for breakpoints is to trigger an interrupt at the desired instruction, which then causes a context switch to the debugger process. How will the debugger be able to access all the bypass-network/belt/spiller data? My off-the-cuff thought is that since the spiller has a mechanism for dumping its state in memory anyway, there is probably (or should be) a way for software to force it to dump this state, which could be used by the debugger to read all the required data from a specified (probably model-specific) structure in memory.
  - willvarfar 11y ago
    Exactly. The OS can of course control who can debug what.

pests 11y ago

Yes, amazing. I've always wondered how the belt was implemented and it turns out its not a belt at all.

vanderZwan 11y ago
I think Godard actually explicitly said that in a Q&A of one of the very first lectures - although I have to admit at that point the finer details of the discussion were way over my head.