3 ms·
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 h
by 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 agoIt 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...