Intel Continues Prepping the Linux Kernel for X86S

15 points by jzelinskie 1 year ago | 5 comments
  • hyperman1 1 year ago
    I try to understand what stays and goes. I read this:

    https://www.intel.com/content/www/us/en/developer/articles/t...

    So all 16 bit goes away. 32 bit is still possible, but only in user mode. The OS is always 64bit. 32bit style segmentation goes. Insb/outsb goes.

    This doesn't seem so bad. 16 bit is almost always in emulators anyway. 32 bit user code can stay. Presumably OS page table magic can hide segment registers missing. We need to upgrade the OS, but user mode won't take much of a hit.

    I wonder how much they gain in practice. Probably a huge simplification in speed critical address calculation.

    Can't see them gain much by dropping ins/outs, but they probably won't be missed much anyway.

    I notice A20 already went away in 2008. Never noticed it go, it only caused misery.

    • lproven 1 year ago
      FWIW I tried to explain the background and context, including the now-forgotten 80376 CPU, when this was proposed last May.

      https://www.theregister.com/2023/05/25/intel_proposes_droppi...

      Yes. 80376, not 80386. Not a typo.

      • docandrew 1 year ago
        Hopefully this comes to fruition (with AMD on board too). I wonder if it might spur some more hobbyist OS research.
        • hedora 1 year ago
          What’s the practical advantage?

          It’s easy enough to flip an x86 into 64 bit mode at boot. Surely, slowing down emulation of 32-bit operating systems isn’t a win (and neither is forcing pointer heavy code to ~double its heap size in the rare cases where that matters).

          I guess it’ll save some transistors, but those are pretty much free these days.

        • voxadam 1 year ago
          Previousy: Intel Explores Transition to 64-Bit-Only X86S Architecture | 159 points | 9 months ago | 143 comments | https://news.ycombinator.com/item?id=36013257