5 ms·
Raising the abstraction level of the ISA and making more logic part of proprietary CPU microcode is exactly the wrong direction to go in for security. I'm not s
by catern 9y ago
Raising the abstraction level of the ISA and making more logic part of proprietary CPU microcode is exactly the wrong direction to go in for security. I'm not sure how the authors can possibly claim this will be beneficial for security. Thankfully, recent events (Meltdown and Spectre) have made the flaws in their philosophy abundantly clear.
>When considering the period of rapid evolution that microarchitecture is about to face with the end of lithography scaling, abstractions that are free from underlying microarchitectural influence are critical to minimizing future disruption.
Ironically completely accurate! If chipmakers can successfully sell us on super-high-level ISAs (moving the scheduler and hypervisor inside their proprietary chips, as this article seems to suggest), they will be able to lock us in and easily prevent any "disruption" of their business model.
The greatest advantage for innovation in ISAs in the past 20 years has been the development of Linux and GCC, which allow any new chip to get a huge amount of working software with relatively little porting effort. Moving more logic out of this open source software portability layer and into the proprietary chip will just make it harder to build new chips from scratch.
- skybrian 9y agoI don't think that's what they're suggesting. This is more about replacing most register references within opcodes with stack pointer offsets, for faster context switching. It only replaces the register-spilling part of a context switch, along with the register-allocation code in a compiler. It sounds a bit like SPARC, but more flexible? And not particularly difficult to port to.
- jcranmer 9y ago> It only replaces the register-spilling part of a context switch, along with the register-allocation code in a compiler. The compiler would still need to stack slot coloring. And, as I noted elsewhere, they also seem to suggest dropping memory coherency, which makes the stack here just a register file with single instructions that load and store the registers to memory.
- xf00ba7 9y agoThat's what I'm guessing too, something a bit like SPARC but more flexible. Seems you can get a data movement win if you don't mindlessly move the entire linux task struct on every swap.
- pjc50 9y agoI don't think that's what anyone is suggesting, and certainly not for secrecy or lockin purposes. > "We should instead consider how to be more helpful to the consumers of our interface. Looking upwards in the system stack, the first immediate consumers of the architecture abstraction are hypervisors, virtual machine monitors, microkernels, and operating systems. How might we provide acceleration of their operations? What might an architecture with a taste of hypervisor consist of? How might we provide easy-touse heterogeneous computation without forcing these software layers to continually adapt to our innovations" ARM actually has had some task-swich architecture assistance for decades - register bank switching. Like a very cut down hyperthreading. I think these days it's only used for FIQ.