No, thank goodness, but not for lack of trying[1]! The I2O group seemed to favour channel I/O on the grounds that it was an excellent way to sell more proprietary hardware and restricted access to specifications. Fortunately they were not successful in simultaneously making the x86 world more proprietary and more expensive all at once.
I didn't know about that one. Sounds like a failed implementation of the concept. A better one that someone told me about recently was some embedded products combining a good CPU with a weaker one (eg Cortex M0) that absorbed & queued interrupts to preserve real-time properties. Sandia did something similar in SSP processor. lowRISC is experimenting with their minion cores.
So, I think there's still potential. Especially given the formal verification and security strategies for I/O programs were often different in academic literature than algorithmic ones. Specialized hardware might facilitate improving their security or availability in provable way.
Comments
No, thank goodness, but not for lack of trying[1]! The I2O group seemed to favour channel I/O on the grounds that it was an excellent way to sell more proprietary hardware and restricted access to specifications. Fortunately they were not successful in simultaneously making the x86 world more proprietary and more expensive all at once.
[1]: https://en.m.wikipedia.org/wiki/I2O
I didn't know about that one. Sounds like a failed implementation of the concept. A better one that someone told me about recently was some embedded products combining a good CPU with a weaker one (eg Cortex M0) that absorbed & queued interrupts to preserve real-time properties. Sandia did something similar in SSP processor. lowRISC is experimenting with their minion cores.
So, I think there's still potential. Especially given the formal verification and security strategies for I/O programs were often different in academic literature than algorithmic ones. Specialized hardware might facilitate improving their security or availability in provable way.