Intel and AMD form advisory group to reshape x86 ISA
101–110 of 132 posts
Re: Intel and AMD form advisory group to reshape x86 ISA
#102This is hopeful. Whatever the ARM enthusiasts would like, x86 is going to stick around for a long time, and working together to evolve the ISA extensions in a more cohesive manner would go a long way. In particular, I'd really like AMD and Intel to get on the same page in terms of avx10 / avx512 support. Many people correctly note that avx512 support is not super relevant today, but this can be laid heavily at the fe…
>x86 is going to stick around for a long time It won't. Due to its licensing, x86 does not stand a chance against RISC-V. Especially not after Apple, Microsoft and others (e.g. Box64) have demonstrated ability to run x86 code elsewhere reasonably well, thus providing a clear migration path. These actions by AMD and Intel are seen as a desperate attempt to keep x86-64 relevant. As non-x86 hardware increasingly shows u…
I will wait for x86's doom, but it will take patience. After all, people have been saying it's dying and will be replaced by some RISC alternative for over 30 years now.
Re: Intel and AMD form advisory group to reshape x86 ISA
#103Earlier quoted context omitted.
> My big problem is Rosetta 2 doesn’t emulate AVX which more and more software uses. You can probably blame that on patents. Base x86-64, which includes SSE2, is old enough that all relevant patents have already expired (the x86-64 ISA documentation was first published by AMD 24 years ago, see https://web.archive.org/web/20000829042324/http://www.x86-64... ). Other ISA extensions are newer, and might still be threate…
Maybe patents are involved, but there's a bigger issue too: the Apple chips don't have support for the equivalent Arm instructions (SVE/SVE2) nor wide enough vectors in their SIMD units. Any AVX/AVX2 emulation is going to be dog slow, even if it isn't encumbered by patents.
Using QEMU instead of Rosetta 2 gets past this, since QEMU doesn’t seem to be afraid of those patents, but it makes everything else a lot slower
Maybe, if Apple made available a plug-in API for Rosetta 2, to enable plugins to emulate additional instructions. Then some open-source plug-in could implement the missing AVX instructions, but if Intel tried to claim Apple was infringing on the AVX patent, Apple could (truthfully) say “we have nothing to do with that plug-in, we just created the API it calls”
Another approach would be if Apple open-sourced Rosetta 2, and then a community fork could implement this stuff. I doubt Apple will do that though - I think they view Rosetta 2’s superior x86 emulation as a commercial advantage over other ARM laptop vendors (such as Qualcomm’s ARM Windows systems), and they’d likely view open sourcing it as giving away that commercial advantage
Re: Intel and AMD form advisory group to reshape x86 ISA
#104Re: Intel and AMD form advisory group to reshape x86 ISA
#105Earlier quoted context omitted.
>x86 is going to stick around for a long time It won't. Due to its licensing, x86 does not stand a chance against RISC-V. Especially not after Apple, Microsoft and others (e.g. Box64) have demonstrated ability to run x86 code elsewhere reasonably well, thus providing a clear migration path. These actions by AMD and Intel are seen as a desperate attempt to keep x86-64 relevant. As non-x86 hardware increasingly shows u…
It's exactly because of licencing that the situation with RISC-V is a world of proprietary SoCs with no consistency, as opposed to the open system that is an x86 PC. (That the ISA is or isn't open is trifling and matters to neither user nor kernel developer.) Essentially every single board requires its very own custom port of your preferred OS. I will wait for x86's doom, but it will take patience. After all, people…
Can you cite any sources for this? What makes you say this? Can you cite one (1) example?
I ask because it is entirely inconsistent with my experience with the available SoCs and their boards. They all implement the specs that were available at the time of design. Sometimes drafts out of necessity. And all of them use OpenSBI as their machine mode firmware.
This is false to the point it reads like FUD to me; It couldn't be further detached from reality.
Re: Intel and AMD form advisory group to reshape x86 ISA
#106Earlier quoted context omitted.
> All of the other cores from ARM or Qualcomm aren't as fast as the top Intel and AMD x86 I don’t think top cpu perf is relevant. I was working on some C code for science stuff inside Termux on a Pixel 7a, and would’ve been perfectly ok having that perf on a standard format laptop. I even noticed some branch prediction was better than x86. It’s more an issue that no one is making a decent arm in laptop format with nv…
> I was working on some C code for science stuff inside Termux on a Pixel 7a I don't want this to come across as rude or condescending, but who hurt you?
Re: Intel and AMD form advisory group to reshape x86 ISA
#107Earlier quoted context omitted.
The value of the ISA is the huge volume of existing software for it, including hardware drivers. The whole x86-using industry migrating away from x86 would be a multi-decade and costly process. In addition, this would just mean more competition for Intel and AMD, as they would lose the moat of their x86 know-how. Why would they do that?
For high-tier environments consider GNU/Linux and *BSD already ported. On the rest, for office tasks either they run on the browser, Java or C# or fast enough Win32 shims.
Re: Intel and AMD form advisory group to reshape x86 ISA
#108Everyone is commenting on "let x86 die" and I would agree if it was just about ISA. But the problem is that x86 has some-sorta-total-disaster-of-a-standard for peripherals and configuration (ACPI, UEFI and so on) and you can actually buy a computer that is compliant and will run Linux out of the box, even if with some glitches. ARM is a handful of totally incompatible SoCs and you are totally dependent on SoC integra…
What you wrote doesn't make any sense. Arm has DTB [1]. Most SoCs re-use a lot of hardware IP blocks and they require very little modifications to DTB files in the kernel and device drivers to get them working. PCIe and USB support discoverability so no issue from that side. Arm ecosystem is cleaner in my experience and learned from the mistakes of the past. Arm CPUs are still not as fast as high-end x86 chips, but i…
DTB only describes what blocks are present, if the kernel doesn't know what "crapvendor,lockinregulator" means it would not work. Vs ACPI that actually provides drivers, however crappy.
Re: Intel and AMD form advisory group to reshape x86 ISA
#109Everyone is commenting on "let x86 die" and I would agree if it was just about ISA. But the problem is that x86 has some-sorta-total-disaster-of-a-standard for peripherals and configuration (ACPI, UEFI and so on) and you can actually buy a computer that is compliant and will run Linux out of the box, even if with some glitches. ARM is a handful of totally incompatible SoCs and you are totally dependent on SoC integra…
>you can actually buy a computer that is compliant and will run Linux out of the box, even if with some glitches. Note that neither RISC-V nor aarch64 are any worse in that regard. If anything, they're doing much better platform standardization wise.
Re: Intel and AMD form advisory group to reshape x86 ISA
#110Earlier quoted context omitted.
For high-tier environments consider GNU/Linux and *BSD already ported. On the rest, for office tasks either they run on the browser, Java or C# or fast enough Win32 shims.
What about the rest of the software?