5 ms·

Interesting! Can you explain why OSes don't use it? I'd expect that it would be more efficient than doing the same thing with different instructions.

retrac 3y ago
Originally, probably because it was inflexible. You have to use the in-memory layout required by the hardware, and you can't do anything not supported by the hardware. Later, it didn't get updated (probably because no one used it) so today it won't save things like the MMX and SSE registers, which makes it even less useful. It's certainly much faster today to use sequences of mov instructions. In practice, it's a block move of multiple registers to memory/cache. That's something any modern pipelined and microcoded processor will have specialized support for. What instruction or instructions generates that internal action, is largely beside the point.
- rep_lodsb 3y ago
  It didn't save the x87 FPU registers either, however a task switch set a flag in MSW / CR0 that caused a trap on the next instruction using these registers. The idea is that they are used infrequently, so it's better to only switch the FPU context when required. This is no longer so true today, however the Linux kernel for example doesn't use any floating point or vector instructions, in order to avoid having to save these registers on every system call or interrupt. The real inflexibility was scheduling (see my other comment)
  - lights0123 3y ago
    > the Linux kernel for example doesn't use any floating point or vector instructions it doesn't use them by default, but code that needs the FPU can call kernel_fpu_begin() to save those registers if needed. https://yarchive.net/comp/linux/kernel_fp.html https://yarchive.net/comp/linux/kernel_fp.html One big user is the AMD graphics driver: https://lore.kernel.org/amd-gfx/ee26b06b-f1a0-5a8f-388c-13c1072ae03e@amd.com/T/ https://lore.kernel.org/amd-gfx/ee26b06b-f1a0-5a8f-388c-13c1...
rep_lodsb 3y ago
It would only be more efficient if user mode tasks jumped directly to each other without any kernel involvement. This is actually possible, but probably useless except maybe some very specialized embedded applications. If you already have a privilege level change and pushing of registers on the stack, a hardware tasks switch just does useless extra work. One might think that since interrupts can switch tasks, you could set up a simple round-robin scheduler by hooking this mechanism up to the timer interrupt somehow, or have device drivers in separate tasks that become active when receiving an interrupt. But a "task state segment" on x86 is actually more like a pre-allocated stack frame, with interrupts creating a linked list of these. A task can't be reentered while it is active, and it is supposed to exit by returning to the previous task that was interrupted. Anything else requires software scheduling. The only reason to ever use this mechanism is for handling exceptions on a specially reserved stack (for example when the kernel stack overflows).
- fluoridation 3y ago
  Sound like it's a hardware implementation of cooperative multitasking.
toast0 3y ago
The way processors work, if the single instruction / automatic on interrupt etc method does the same things as do it yourself in your code version, about the only thing you're saving is instruction decode bandwidth and compiled code size. But that's usually not a large enough savings to matter. And then you get the inflexibility: There's a limited number of hardware task slots; I think you can pick which registers to save (or rather how many to save), but you always save all of them: a kernel syscall might be more judicious and only save the registers it uses (of course saving all registers if returning to a different task); it's hard to change because software must run on old and new cpus; etc. There's exceptions to the rule of thumb. Rep mov can be faster than doing it yourself. It's also quite possible for a combined operation to do two things at the same time rather than one after the other.

retrac 3y ago

Originally, probably because it was inflexible. You have to use the in-memory layout required by the hardware, and you can't do anything not supported by the hardware. Later, it didn't get updated (probably because no one used it) so today it won't save things like the MMX and SSE registers, which makes it even less useful. It's certainly much faster today to use sequences of mov instructions. In practice, it's a block move of multiple registers to memory/cache. That's something any modern pipelined and microcoded processor will have specialized support for. What instruction or instructions generates that internal action, is largely beside the point.

rep_lodsb 3y ago
It didn't save the x87 FPU registers either, however a task switch set a flag in MSW / CR0 that caused a trap on the next instruction using these registers. The idea is that they are used infrequently, so it's better to only switch the FPU context when required. This is no longer so true today, however the Linux kernel for example doesn't use any floating point or vector instructions, in order to avoid having to save these registers on every system call or interrupt. The real inflexibility was scheduling (see my other comment)
- lights0123 3y ago
  > the Linux kernel for example doesn't use any floating point or vector instructions it doesn't use them by default, but code that needs the FPU can call kernel_fpu_begin() to save those registers if needed. https://yarchive.net/comp/linux/kernel_fp.html https://yarchive.net/comp/linux/kernel_fp.html One big user is the AMD graphics driver: https://lore.kernel.org/amd-gfx/ee26b06b-f1a0-5a8f-388c-13c1072ae03e@amd.com/T/ https://lore.kernel.org/amd-gfx/ee26b06b-f1a0-5a8f-388c-13c1...

rep_lodsb 3y ago

It would only be more efficient if user mode tasks jumped directly to each other without any kernel involvement. This is actually possible, but probably useless except maybe some very specialized embedded applications. If you already have a privilege level change and pushing of registers on the stack, a hardware tasks switch just does useless extra work. One might think that since interrupts can switch tasks, you could set up a simple round-robin scheduler by hooking this mechanism up to the timer interrupt somehow, or have device drivers in separate tasks that become active when receiving an interrupt. But a "task state segment" on x86 is actually more like a pre-allocated stack frame, with interrupts creating a linked list of these. A task can't be reentered while it is active, and it is supposed to exit by returning to the previous task that was interrupted. Anything else requires software scheduling. The only reason to ever use this mechanism is for handling exceptions on a specially reserved stack (for example when the kernel stack overflows).

fluoridation 3y ago
Sound like it's a hardware implementation of cooperative multitasking.

toast0 3y ago

The way processors work, if the single instruction / automatic on interrupt etc method does the same things as do it yourself in your code version, about the only thing you're saving is instruction decode bandwidth and compiled code size. But that's usually not a large enough savings to matter. And then you get the inflexibility: There's a limited number of hardware task slots; I think you can pick which registers to save (or rather how many to save), but you always save all of them: a kernel syscall might be more judicious and only save the registers it uses (of course saving all registers if returning to a different task); it's hard to change because software must run on old and new cpus; etc. There's exceptions to the rule of thumb. Rep mov can be faster than doing it yourself. It's also quite possible for a combined operation to do two things at the same time rather than one after the other.