3 ms·

these kinds of details about x64 and x86 make it so hard to build something from intel or amd docs. what do you use, what do you omit, feature and instruction w

these kinds of details about x64 and x86 make it so hard to build something from intel or amd docs. what do you use, what do you omit, feature and instruction wise. so many ways to do the same things.. it takes a lot of experimentation and measurements to see whats efficient and whats simple to implement etc. you can peek at nix and other osses but i suppose tbat defeats the purpose of the excersize :d. anyway, nice blog all in all =) always happy to see people translate more complex constructs into the basic instructions. helps understand a lot what the cpu is actually doing.

retrac 3y ago
As I'm sure most of us know, the x86 lineage goes back nearly 50 years. Many ideas that went nowhere, were taken as design decisions, and are forever etched in silicon. One of my favourite examples is the x86 task switching support. The 386 had everything needed to implement context-switching and multitasking -- in hardware. (That notion was in vogue, once. See the ICL 2900.) If you set up the right structure in memory, and turn on the hardware task switching, x86 processors will automatically context switch all of the registers in and out of that in-memory structure, at the appropriate privilege boundaries (interrupt, return from interrupt, etc.) So your kernel can switch between processes like this (more or less): mov next_proc_ptr, tr iret It also provides IO port protection - there's another table that lets you specify which ports the process can access, which the processor will examine, when an IO instruction is executed in user mode, presumably for something microkernelish. Now that's the good ol' CISC spirit. It's quite a complex feature and yet I'm not sure any OS ever used it.
- bombcar 3y ago
  Even if no OS used it I bet it has been used - the era of the 386 saw a decent amount of bare-metal specialized uses of the hardware. Some would nominally run on DOS, some didn’t bother with it at all.
- dist-epoch 3y ago
  > I'm not sure any OS ever used it When nobody uses such a feature is typically either because it has worse performance then alternatives or some missing feature. There have been many such cases in x86.
- PeterisP 3y ago
  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...
  - 3y ago
- userbinator 3y ago
  I believe iRMX, Intel's own OS for the 386, did use those features.
  - mrlonglong 3y ago
    Linux did use the TSS in its early days on the i386. I think they changed it because performance wasn't very good.
- jlokier 3y ago
  > It's quite a complex feature and yet I'm not sure any OS ever used it. They did. Linux used x86 hardware task switching and TR (task register) for years. See "struct tss_struct" and "switch_to" in older kernels. Linux also allowed userspace processes to get hardware-managed access to individual I/O ports using the per-task x86 I/O port bitmap, and to local segments using the x86 LDT which were useful for running 16-bit code in a 32-bit task. The hardware task switching was eventually changed to software task switching. By that time, software switching was faster, and it was always more versatile. This change removed the hardware-imposed limit on the number of processes and threads Linux could support. Here's a nice article about the evolution of task switching in Linux. https://www.maizure.org/projects/evolution_x86_context_switch_linux/ https://www.maizure.org/projects/evolution_x86_context_switc...
- sim7c00 3y ago
  i looked so long to implement hardware task switching only to find modern OSes decided it wasnt to be used. still not sure im onboard with that decicion haha. great example!! =)

retrac 3y ago

As I'm sure most of us know, the x86 lineage goes back nearly 50 years. Many ideas that went nowhere, were taken as design decisions, and are forever etched in silicon. One of my favourite examples is the x86 task switching support. The 386 had everything needed to implement context-switching and multitasking -- in hardware. (That notion was in vogue, once. See the ICL 2900.) If you set up the right structure in memory, and turn on the hardware task switching, x86 processors will automatically context switch all of the registers in and out of that in-memory structure, at the appropriate privilege boundaries (interrupt, return from interrupt, etc.) So your kernel can switch between processes like this (more or less): mov next_proc_ptr, tr iret It also provides IO port protection - there's another table that lets you specify which ports the process can access, which the processor will examine, when an IO instruction is executed in user mode, presumably for something microkernelish. Now that's the good ol' CISC spirit. It's quite a complex feature and yet I'm not sure any OS ever used it.

bombcar 3y ago
Even if no OS used it I bet it has been used - the era of the 386 saw a decent amount of bare-metal specialized uses of the hardware. Some would nominally run on DOS, some didn’t bother with it at all.
dist-epoch 3y ago
> I'm not sure any OS ever used it When nobody uses such a feature is typically either because it has worse performance then alternatives or some missing feature. There have been many such cases in x86.
PeterisP 3y ago
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...
- 3y ago
userbinator 3y ago
I believe iRMX, Intel's own OS for the 386, did use those features.
- mrlonglong 3y ago
  Linux did use the TSS in its early days on the i386. I think they changed it because performance wasn't very good.
jlokier 3y ago
> It's quite a complex feature and yet I'm not sure any OS ever used it. They did. Linux used x86 hardware task switching and TR (task register) for years. See "struct tss_struct" and "switch_to" in older kernels. Linux also allowed userspace processes to get hardware-managed access to individual I/O ports using the per-task x86 I/O port bitmap, and to local segments using the x86 LDT which were useful for running 16-bit code in a 32-bit task. The hardware task switching was eventually changed to software task switching. By that time, software switching was faster, and it was always more versatile. This change removed the hardware-imposed limit on the number of processes and threads Linux could support. Here's a nice article about the evolution of task switching in Linux. https://www.maizure.org/projects/evolution_x86_context_switch_linux/ https://www.maizure.org/projects/evolution_x86_context_switc...
sim7c00 3y ago
i looked so long to implement hardware task switching only to find modern OSes decided it wasnt to be used. still not sure im onboard with that decicion haha. great example!! =)