Announcement

Collapse
No announcement yet.

Intel Publishes "X86-S" Specification For 64-bit Only Architecture

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    Originally posted by arteast View Post

    Like you said, it's a garbage collection. They are throwing out everything that isn't being used. Unfortunately, x86/MMX/SSE are all still in use by a 32-bit applications. Getting rid of these opcodes would hurt their userbase so they aren't doing it. As for emulating older instructions - surely they already do that; all these opcodes for all these SIMD families surely map to the same (maybe masked) uops going to the same vector-capable port, with x87 stack emulated by something like vector register renaming.
    x87, MMX, SSE and SSE2 are part of the amd64 specification such that they are no longer extensions. You cannot remove those and expect amd64 software to work.
    Last edited by ryao; 20 May 2023, 03:19 PM.

    Comment


    • #62
      Originally posted by ryao View Post

      Given that AMD and Intel cross licensed their instruction sets, this move is probably a gift to AMD more than anything else. Both of them are having trouble competing with ARM:

      The largest clouds will always have to buy X86 processors from Intel or AMD so long as the enterprises of the world – and the governments and educational


      Projections for upcoming ARM processors show much bigger leaps in competitiveness than either AMD or Intel currently have planned. If they do not do something to maintain some sort of advantage beyond backward compatibility, they will both be the next Cyrix.
      Funny enough, i have thought about this (cleaning the x86 cpus of legacy instructions) because of ARM, but per this article, how the announcements are worded, etc, I simply have a bad feeling of Intel trying something dirty against AMD, especially now, since it seems that they cant beat them without resorting to dirty tactics like before.

      Hell, I honestly think thay are still doing it, just look how Dell doesn’t sell any Ryzen powered devices on their business lines (Latitude, Optiplex and Precision) which are their high volume/money making lines.

      But i do hope that you are right!

      Comment


      • #63
        Originally posted by direc85 View Post
        x86 -- 32-bit
        x86_64 -- 32/64-bit
        x86s -- 64-bit
        8088 - initial PC, 16-bit, 8-bit memory
        8086 - 16-bit, 16-bit memory
        80386 - first 32-bit
        80586 (Pentium)- last 32-bit CISC
        AMD K5 - first AMD retooling of AM9000 RISC backend with x86-compatible frontend
        80686 (Pentium Pro/Pentium II) - 32-bit CISC ISA frontend, RISC-y backend
        AMD64 - AMD's first x86_64/x64
        Xeon/Pentium-4 with EM64T - barely got its own name, but Intel with 64-bit extensions to enter long mode

        This all started with a 16-bit (register size) cost-cut version of a CPU in an attempt for IBM to get into the personal computer space that arguably Apple, Atari, and Commodore had been in for several years already, and it hasn't been the original definition of CISC since the Pentium Pro/K5.

        Comment


        • #64
          Well this only removes 32-bit operating system support, since 32-bit mode in 64-bit will still be available. The problem is that it seems to cut all 16-bit support entirely, even for protected mode 16-bit?

          I am not talking about DOS. I'm talking about protected mode 16-bit apps, i.e. Windows 16-bit apps for example. You can use them with Wine.

          Comment


          • #65
            I wonder if they changed default encoding for instructions with 64bit operands. I think currently we need prefixes to indicate that, if processor is running in 64bit mode by default that might be unnecessary.

            Comment


            • #66
              Originally posted by PluMGMK View Post
              So it's finally happening…
              Haven't read the paper yet, but one of the headers seems to be about removing "32-bit Ring 0" (not Ring 3), which would mean exactly that…
              There's also a heading for "Removal of 16-bit and 32-bit protected mode" which, I think, means "Kill off the ability to run 32-bit x86 applications without some kind of emulation".

              Comment


              • #67
                Originally posted by Weasel View Post
                Well this only removes 32-bit operating system support, since 32-bit mode in 64-bit will still be available. The problem is that it seems to cut all 16-bit support entirely, even for protected mode 16-bit?

                I am not talking about DOS. I'm talking about protected mode 16-bit apps, i.e. Windows 16-bit apps for example. You can use them with Wine.
                There is work being done on it: https://www.gamingonlinux.com/2022/1...on-64bit-work/

                Comment


                • #68
                  Originally posted by skeevy420 View Post
                  Keeping hybrid CPUs around, which have never worked that well to begin with, just because some neckbeard doesn't want to upgrade from Windows 7 32-bit is idiotic. The neckbeard needs to update their environment and update their workflow to the new ways of doing things instead of holding the rest of the world back.
                  The guy who runs one of the Macintosh retrocomputing and abandonware communities I hang out in (I own a Power Mac G4 and have plans to get something capable of running System 7 and, maybe after that, a Macintosh SE) is a respectable IT guy (i.e. not a neckbeard) and he's currently in the process of deciding whether to upgrade from Windows 7 to Linux or to Apple Silicon. He hates Windows 10 and 11. (Both personally, and for the strife they've caused his customers with things like "Microsoft blue-screened all the machines by pushing a broken 'let's try to get those stubborn Windows 7 hold-outs onto Windows 10' upgrade in the middle of the night." or "All our label printers are broken. Zebra says Microsoft pushed a broken Windows 10 driver update and it's not their fault.")

                  I personally want to retain compatibility with high-end, demanding games where the developers assumed 32-bit support in Windows would be around for as "forever" as 16-bit was and so only made 32-bit builds.
                  Last edited by ssokolow; 20 May 2023, 04:06 PM.

                  Comment


                  • #69
                    I am no AMD fanboy but I suspect that if Intel does decide to go through with this, AMD may announce a new x86, 128-bit only, processor.

                    This probably wouldn't even be that difficult to do, SSE is already a 128-bit instruction set, AVX/AVX2 is 256-bit, AVX-512 is 512-bit and Intel was supposedly working on AVX-1024 in order to combat GPGPU, I say let's just skip right to a 1024-bit CPU.

                    Comment


                    • #70
                      Originally posted by ssokolow View Post
                      I personally want to retain compatibility with high-end, demanding games where the developers assumed 32-bit support in Windows would be around for as "forever" as 16-bit was and so only made 32-bit builds.
                      "High-end, demanding games" and "32-bit support" is a contradiction in terms. 32-bit only allows up to 4gb addressing, either am, or file size, I defy you to show me the "high-end, demanding game" that can run on a 32-bit OS with 4gb of ram.

                      Comment

                      Working...
                      X