4 ms·

The article says this about it: > We could have a simple cycle timer switch on each core so that after the timer expires there an interrupt-like jump to a func

The article says this about it: > We could have a simple cycle timer switch on each core so that after the timer expires there an interrupt-like jump to a function to see what to do next. That jump would be perfectly synchronous since predicting the next jump can be done with 100% accuracy (or nearly 100%).

dmitrygr 5y ago
Cycle accurate? So now you can predict how long RAM latency is down to the cycle, refreshes and DMA be damned? Interrupt like? So what will you do? save context of this thread, load another...hm...sure sounds like what we already do
Taniwha 5y ago
In other words a timer interrupt - with saving of state and appropriate unwinding of pipeline state (abandoning half done or out of order instructions etc etc) Also the "do system calls by queuing requests to another CPU" is kind of at odds with "we don't need cache coherency"
- pjc50 5y ago
  Not necessarily; it's an interesting idea. Thanks to the branch predictor the CPU already has a virtual view of the instruction stream. If we tolerate a bit of latency, all we have to do is inject a "jump to ISR" magic instruction in the predicted stream. Rather like self-modifying code, except without modifying the code in memory, just at the instruction fetch point. State still has to be saved but that can be done with PUSH instructions in the ISR. > Also the "do system calls by queuing requests to another CPU" is kind of at odds with "we don't need cache coherency" Can be done with mailboxes/FIFOs, but yes this requires a dedicated design. And of course the CPU that does the call is then idle I think?
  - vyodaiken 5y ago
    Good explanation of my overly terse note. The current standard interrupt architecture imposes enormous latency and the synchronous timer could be more precise. The simplest implementation would just "fetch" jmp every N instructions (with N programmable) - just like voluntary switching but where the processor would volunteer the program.
    - Taniwha 5y ago
      You still need to save the PC and have a place to save it ....

dmitrygr 5y ago

Cycle accurate? So now you can predict how long RAM latency is down to the cycle, refreshes and DMA be damned? Interrupt like? So what will you do? save context of this thread, load another...hm...sure sounds like what we already do

Taniwha 5y ago

In other words a timer interrupt - with saving of state and appropriate unwinding of pipeline state (abandoning half done or out of order instructions etc etc) Also the "do system calls by queuing requests to another CPU" is kind of at odds with "we don't need cache coherency"

pjc50 5y ago
Not necessarily; it's an interesting idea. Thanks to the branch predictor the CPU already has a virtual view of the instruction stream. If we tolerate a bit of latency, all we have to do is inject a "jump to ISR" magic instruction in the predicted stream. Rather like self-modifying code, except without modifying the code in memory, just at the instruction fetch point. State still has to be saved but that can be done with PUSH instructions in the ISR. > Also the "do system calls by queuing requests to another CPU" is kind of at odds with "we don't need cache coherency" Can be done with mailboxes/FIFOs, but yes this requires a dedicated design. And of course the CPU that does the call is then idle I think?
- vyodaiken 5y ago
  Good explanation of my overly terse note. The current standard interrupt architecture imposes enormous latency and the synchronous timer could be more precise. The simplest implementation would just "fetch" jmp every N instructions (with N programmable) - just like voluntary switching but where the processor would volunteer the program.
  - Taniwha 5y ago
    You still need to save the PC and have a place to save it ....