Box86 0.2.6 / Box64 0.1.8 Released With Working Steam & Steam Play On Non-x86 CPUs

[linuxgeex]

The hardware acceleration for the x86 emulation is not custom instructions, but only a flag to switch to the strong memory model typical for x86 (no license from Intel needed for that, as that's in the expired parents of the x86 arch).

You're semi-correct about the memory model. You're right that they switched to little-endian. But they also switched to a 4K page table TLB, and they handle the x86_64 operand memory addressing modes, all of which are covered by expired patents. In fact all of the original x86_64 ISA and hardware operation is expired. And Apple also chose not to implement ISA beyond SSE4.2 which is also expired. That surprised me... I am getting older lol.

But I read that Apple actually added custom x86 emulation hardware/instructions. I can't find the reference, at least not yet. I will keep looking. I'm pretty sure it was on Anandtech, but no luck googling for it.

What I did find is that Apple added custom matrix acceleration instructions to their version of the ARM ISA on the M1. At the time they added it, ARM did not allow extensions to the ARMv8a ISA, at least not for normal non-trillion-dollar-licensees.

[linuxgeex]

I have some small amount of skepticism here, being as many early x86 patents have or will expire soon. Even x86_64 was announced as early as 1999.

It's worth noting that Stexar was developing their binary-translation x86-on-arm cores (project Denver) before they were bought by nvidia in *2006* and it was revealed in 2011. At that time there would have been no question that all of x86 was still strictly patented.

Good job researching Project Denver. Now finish reading the rest of Wikipedia, in particular the part with this supporting reference: https://semiaccurate.com/2011/08/05/...nver-based-on/

TLRD; x86/x86_64 is a moving target. Newer parts of it are patented every year. Any x86 implementation worth purchasing today needs to license patents from the last 20 years, ie AVX2, 5th level page tables. Intel and AMD's duopoly of x86 exists because Intel's licensing terms are extortive... but that is changing. As of 2021 Intel has opened up licensing of x86 so long as you use Intel's foundries. AFAIK nobody has taken them up on that offer yet.

BTW M1 doesn't emulate AVX, just SSE4.2. Considering that, their Cinebench CPU numbers are truly amazing.

[Developer12]

Also big news shortly after the M1 launch was the fact that M1 had specialised x86 / x86-64 emulation instructions and addressing modes. Which BTW they would have needed to license from Intel. Recall that Intel shut down NVidia's attempt to do the same with their Denver cores.

I have some small amount of skepticism here, being as many early x86 patents have or will expire soon. Even x86_64 was announced as early as 1999.

It's worth noting that Stexar was developing their binary-translation x86-on-arm cores (project Denver) before they were bought by nvidia in *2006* and it was revealed in 2011. At that time there would have been no question that all of x86 was still strictly patented.

[Ladis]

To be clear, ARM themselves dropped 32-bit instructions in the ARM-V9 ISA, and their hundred-series Cortex product lineup. Having an unused instruction decoder eating up silicon floorplan becomes an increasingly hard sell, especially when one of ARM's USP's is supposed to be the relative efficiency of their instruction decoder, lol... it's what all their fanbois call out as their benefit vs x86!

M1 is an ARM-V9 ISA core, so dropping 32-bit would merely be following ARM's lead.

Apple has a license from ARM to add proprietary extensions to their cores. This was big news a little over a year ago. Also big news shortly after the M1 launch was the fact that M1 had specialised x86 / x86-64 emulation instructions and addressing modes. Which BTW they would have needed to license from Intel. Recall that Intel shut down NVidia's attempt to do the same with their Denver cores.

The hardware acceleration for the x86 emulation is not custom instructions, but only a flag to switch to the strong memory model typical for x86 (no license from Intel needed for that, as that's in the expired parents of the x86 arch).

[linuxgeex]

On ARM, 32bit instructions are not a subset of 64bit. And Apple has to follow the rules of the ARM ISA. E.g. they can't add own instructions (as that would add fragmentation what each ARM CPU can do).

To be clear, ARM themselves dropped 32-bit instructions in the ARM-V9 ISA, and their hundred-series Cortex product lineup. Having an unused instruction decoder eating up silicon floorplan becomes an increasingly hard sell, especially when one of ARM's USP's is supposed to be the relative efficiency of their instruction decoder, lol... it's what all their fanbois call out as their benefit vs x86!

M1 is an ARM-V9 ISA core, so dropping 32-bit would merely be following ARM's lead.

Apple has a license from ARM to add proprietary extensions to their cores. This was big news a little over a year ago. Also big news shortly after the M1 launch was the fact that M1 had specialised x86 / x86-64 emulation instructions and addressing modes. Which BTW they would have needed to license from Intel. Recall that Intel shut down NVidia's attempt to do the same with their Denver cores.

[Ladis]

I was making an example of the difference between operating vs processor support.

I'm not even sure it's legal under the ARM ISA spec to make a processor that can't run 32-bit instructions, being a subset of 64 bit. It's definitely not possible on x86.

On ARM, 32bit instructions are not a subset of 64bit. And Apple has to follow the rules of the ARM ISA. E.g. they can't add own instructions (as that would add fragmentation what each ARM CPU can do).

[Developer12]

If apple cared about that, they'd have never switched from x86 to ARM in the first place.

Apple has never cared about long term compatibility. It's one of the primary things that makes them different from Microsoft.

I was making an example of the difference between operating vs processor support.

I'm not even sure it's legal under the ARM ISA spec to make a processor that can't run 32-bit instructions, being a subset of 64 bit. It's definitely not possible on x86.

[smitty3268]

Dropping it in their OS is one thing, dropping it in the ARM core is quite another. Windows doesn't let me run 16-bit DOS games anymore, but lots of modern hardware still boots DOS just fine.

If apple cared about that, they'd have never switched from x86 to ARM in the first place.

Apple has never cared about long term compatibility. It's one of the primary things that makes them different from Microsoft.

[Developer12]

Not all games / tools are there:
1. Here a Outer Wilds mod for VR:
https://awesomeopensource.com/projec...parta/nomai-vr

• Steam and SteamVR installed (even if you're using a non-Steam version of the game);

So you can get here the game outside of steam and the mod itself is installed in a mod manager also not inside of steam, yet it needs you to have steamvr installed to work.

2. https://git.dec05eba.com/vr-video-player/about/
Also requires steam(vr).
A small opensource tool that requires 1gb steam client to work... a abomination.

Is there even some sort of launcher VR tool, that is some sort of 3d desktop like a house or something that is available in Mixed reality launcher from MS or Steams house thing.

It would be nice to be able to use VR in linux without Steam I know there is some obscure tools with monado where you can use it professionally in blender and one other tool, but I talk more on the entertainment side.

VR is a poorly supported zeroth-world problem.

[Developer12]

AFAIK no. M1 doesn't support 32 bit ARM instructions. It's simply not implemented and SoC is only capable of running 64 bit ARM code. Even with 32 bit libraries it won't be able to execute 32 bit code. Apple completely dropped 32 bit support in their operating systems so it wouldn't make any sense for them to support it in their SoC.

Dropping it in their OS is one thing, dropping it in the ARM core is quite another. Windows doesn't let me run 16-bit DOS games anymore, but lots of modern hardware still boots DOS just fine.