undefined | Better HN

0 pointsTaniwha3y ago0 comments

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"

0 comments

pjc503y 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?

vyodaiken3y 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.

TaniwhaOP3y ago

You still need to save the PC and have a place to save it ....

j / k navigate · click thread line to collapse