can x3 elite run x86 programs?

[a5cent]

However, in response to you:

If they only care about creating new hardware, then why are they even mentioning a software based feature that requires no changes to how hardware is made?

Your entire argument is based on the assumption that this feature is realized purely via software and that hardware is irrelevant. That is simply not true. Just the fact that OEMs can't use any old ARM chip already makes that clear. It must be a SoC from Qualcomm's Snapdragon series, and very specific model numbers at that. It will be the SD835 and maybe also the SD820 (IMHO unlikely), but no more. That makes it very clear that this feature depends on explicit hardware support. In that light it makes perfect sense to say: "that hardware is available now".

Those who have been here a while are fully aware that anything MS says must be parsed very carefully. You simply can't make assumptions about anything that isn't stated explicitly. All the reporting suggests WOA will be limited to the SD835. Until someone from HP explicitly states WOA is coming to the X3, it's safer to assume it won't.

Look, I don't really want to argue over whether or not WOA will be supported on the X3. You can believe what you want, I'll believe what I want, but nobody should expect WOA to be supported on the X3. If it eventually is, then that's great, but buying an X3 with that expectation could very well turn out to be a colossal waste of money.

That's all I really want to get across.

 

[Kogling]

Your entire argument is based on the assumption that this feature is realized purely via software and that hardware is irrelevant. That is simply not true. Just the fact that OEMs can't use any old ARM chip already makes that clear.

Yet this assumes old ARM chips can't be used due to hardware limitations rather than a practicality of performance?

64bit is probably a big player among other things, and ARM is a entirely different thing to the classic PC CISC computers we use - they have several branches different to each other with manufacturer adaptations - one ARM to another is apple to oranges to some degree.

No point in going in to massive debate on it, though I wouldn't expect there being a specifically implemented hardware function for the sake of x86 applications. Probably something daft like exploiting windows being 32bits on ARM and using the other half for x86 emulation layer.

Those who have been here a while are fully aware that anything MS says must be parsed very carefully. You simply can't make assumptions about anything that isn't stated explicitly.

I'm very aware of this as I have said - not sure if in this thread, the history with their RT tablets and false promises and complete abandonment I am far to aware as a surface 2 RT and Nokia 2520 owner.

Look, I don't really want to argue over whether or not WOA will be supported on the X3. You can believe what you want, I'll believe what I want, but nobody should expect WOA to be supported on the X3. If it eventually is, then that's great, but buying an X3 with that expectation could very well turn out to be a colossal waste of money.

That's all I really want to get across.

Not against that - I agree with you, though I am more inclined of it being introduced, assuming it actually gets released at all anywhere.

But for the lack of an x3 being used, I will also argue that it's irrelevant to it's potential, because MS simply wouldn't of have a reliable supply of development boards from HP to prototype on the x3 when they are likely going to be using dev board from Qual'.

 

[a5cent]

Yet this assumes old ARM chips can't be used due to hardware limitations rather than a practicality of performance?

64bit is probably a big player among other things, and ARM is a entirely different thing to the classic PC CISC computers we use - they have several branches different to each other with manufacturer adaptations - one ARM to another is apple to oranges to some degree.

Yes. Certain hardware based facilities for emulation (as Intel chips have had for years) and particularly for ISA transcoding (or whatever you want to call it) must be in place for this to work decently. It's definitely not just a matter of raw computational power.

With the exception of addressable RAM, 64 bit vs 32 bit is completely irrelevant to this problem. The ability for an x86 based program to make calls into an ARM based OS is achieved by using the same mechanisms MS used to enable a 32 bit program to make calls into a 64 bit OS. So while the translation mechanism is the same, it doesn't itself have anything to do with the "bitedness" of anything.

ARM also isn't as different as you think it is. Internally, all Intel x86 chips are based on RISC designs, just like ARM. It's been that way for over a decade now. Only the x86 decoder deals with CISC instructions, which is an advantage for Intel.

 

[Ivan05il]

Mentioning software possibilities to hardware makers is very important to MS, they are courting them to start making a new range of devices that they believe will be very attractive to consumers, because they combine an efficiency of ARM and full functionality of Windows. They are saying this is not that Windows RT crap nobody wanted. I think they should make it run apps from other platforms on it and they have a winner. It would run anything you threw at it.

 

[Kogling]

Yes. Certain hardware based facilities for emulation (as Intel chips have had for years) and particularly for ISA transcoding (or whatever you want to call it) must be in place for this to work decently. It's definitely not just a matter of raw computational power

The ability for an x86 based program to make calls into an ARM based OS is achieved by using the same mechanisms MS used to enable a 32 bit program to make calls into a 64 bit OS. So while the translation mechanism is the same, it doesn't itself have anything to do with the "bitedness" of anything.

Not sure I get you here, as I don't recall anything particularly special on a 64 bit processor to "run" x86 programs from when I was into assembly programming.

86-64 was designed with backwards compatibility in mind, so for the most part, anything that was 32 bits wide was simply extended to 64bits. 32bit code just get truncated to 64bits from what I remember.

AFAIK WOW64 (which is the x86 into 64 layer for windows) is all to do with the OS (i.e. OS based issues). That's because an x86 program expects 32bit references and handles, so WOW64 converts /manages that bridge by interrupting those system calls and converting a 64bit handle to 32bit etc.

Thats how Windows chose to handle it and they called it WOW64 but it's not anything massively special and, presumably on 32bit windows or windows mobile (which is 32bit as of current), potentially not needed.

ARM also isn't as different as you think it is. Internally, all Intel x86 chips are based on RISC designs, just like ARM. It's been that way for over a decade now. Only the x86 decoder deals with CISC instructions, which is an advantage for Intel.

I can't say much about ARM to be honest as I have only ever skimmed over their architectures with little real interest and that was a few years back now.

I'm also on the AMD side of processors too, so I've only read their documentation. That's partially because they designed the x64 arch. in use today too.

However, whether "RISC" is implemented in a CISC or not is down to their architecture design and I'm unsure if it's RISC to the full definition. breaking a larger instruction set down to smaller chunks isn't necessarily anything to be too concerned about, and for a CISC, this is probably related to the VILW /superscalar architecture in order to execute multiple instructions in parallel at the same time which wouldn't be as possible with dedicated CISC instructions.

Almost everything is broken down smaller so that parts can be shared anyway.

So not quite sure of the "x86 decoder" you mention. It should all go through a "x86 decoder" because the op code is still an x86 instruction set, the CPU by design has chosen to break x instruction down in to smaller blocks (I think they call it a micro-Op dont they?), most likely to execute several compatible instructions at the same time.

 

[a5cent]

AFAIK WOW64 (which is the x86 into 64 layer for windows) is all to do with the OS (i.e. OS based issues). That's because an x86 program expects 32bit references and handles, so WOW64 converts /manages that bridge by interrupting those system calls and converting a 64bit handle to 32bit etc.

Thats how Windows chose to handle it and they called it WOW64 but it's not anything massively special...

64bit is probably a big player among other things,...
<snipped>
No point in going in to massive debate on it, though I wouldn't expect there being a specifically implemented hardware function for the sake of x86 applications. Probably something daft like exploiting windows being 32bits on ARM and using the other half for x86 emulation layer.

The ability for an x86 based program to make calls into an ARM based OS is achieved by using the same mechanisms MS used to enable a 32 bit program to make calls into a 64 bit OS. So while the translation mechanism is the same, it doesn't itself have anything to do with the "bitedness" of anything.

Not sure I get you here, as I don't recall anything particularly special on a 64 bit processor to "run" x86 programs from when I was into assembly programming.

Based on what I've quoted, this is what I understand your position to be (in my own words):

1. The 64 "bit'edness" of the ARM CPU probably plays an important role in emulating x86 software on ARM
2. You think x86 emulation involves something related to the "bitedness" of that ARM CPU which is daft (which would contradict the statement of it being important). You suspect that 32 bits of some 64 bit wide circuitry is involved, but what specifically you are referring to I have no idea. A CPU bus? A CPU register? It seems like you're unsure yourself.
3. You don't think WOW64 is central to Windows x86 emulation capabilities on ARM.

I think those positions are incorrect:

1. The 64 "bit'edness" of the ARM CPU isn't that important. It's necessary because we need to run a 64 bit Windows OS, but it's not taking center stage. It's not a big player.
2. The 64 "bit'edness" of the Windows OS running on ARM also isn't that important. It's also necessary, but it's important primarily in the sense that it introduces WOW64 to the equation.
3. WOW64 was built to allow 32 bit x86 software to make function calls into a 64 bit x86 OS. According to Marry Joe Foley, WOW64 (or something conceptually similar) is what will allow 32 bit x86 software to make function calls into a 64 bit ARM OS. The important thing here isn't related to bit'edness, but the fact that WOW64 is a translation layer that mediates between software built for one CPU architecture when it's running on another. This is where part of the emulation magic happens.
4. WOW64 is actually more than it initially appears to be. I wasn't aware of this until recently myself, but apparently WOW64 already plays a role in allowing Itanium software to run on an x86 CPU, meaning that in addition to translating function calls, it also translates individual CPU instructions. That's the heart of any emulation solution! It seems likely that this is where x86 emulation on ARM will fit into the Windows OS architecture. If true, WOW64 is central to MS' emulation solution.

In addition to all that, I'm positive that none of this is possible without at least some direct hardware support. MS has already made clear that their x86 emulation capabilities on ARM are tied to very specific chips (e.g. Snapdragon 835) and won't work on just any ARM CPU. IMHO that is a very clear indication of direct hardware support being required at some level, otherwise this would be an ARM feature rather than being specific only to the Qualcomm Snapdragon series of chips, end even then limited to very specific models.

 

[Kogling]

The 64 "bit'edness" of the ARM CPU probably plays an important role in emulating x86 software on ARM

There's usually a fair bit of performance gain from 64bit architectures - usually more registers to play with, simpler memory addressing which in turn can promote speed. x86 emulation for all I know may be simply a matter of obtaining extra registers on the processors to manage the added overhead, that is however, a non specific hardware emulation requirement..

You suspect that 32 bits of some 64 bit wide circuitry is involved, but what specifically you are referring to I have no idea. A CPU bus? A CPU register? It seems like you're unsure yourself.

I don't think there is any "hardware" level feature for emulation that you're implying, hence, my suggestion that unless they are running 32bit windows on a 64bit architecture and somehow ingeniously exploiting the other half of the addressing range for x86 processes, I don't see how it's anything beyond straight forward emulation.

point is, hardware emulation unlikely.

You don't think WOW64 is central to Windows x86 emulation capabilities on ARM.

if the OS is 32bit (which our phones are, for example) they shouldn't need WOW64 (which stands for Windows 32 on Windows 64) because there is no "windows 64". It's mostly OS level translation for backward compatibility for applications that have already been compiled to expect 32bit based calls, headers and so on.

I'm sure there's more to it behind the scenes, and they can call it what they want and implement it how they want, but WOW64 largely revolves around bridging how 64bit OS handles things such as files, registries, handles and system calls and translates them to 32bit usable counterparts.

The 64 "bit'edness" of the ARM CPU isn't that important. It's necessary because we need to run a 64 bit Windows OS, but it's not taking center stage. It's not a big player

Depends, as said above, if 64bit opens up extra registers these may be necessary to provide reasonable emulation, so I dont see how 64 bit can be overlooked as a functional necessity. Sure, a 32bit counterpart could be made that had extra, but thats generally not the direction manufacturers generally aim towards.

WOW64 was built to allow 32 bit x86 software to make function calls into a 64 bit x86 OS. According to Marry Joe Foley, WOW64 (or something conceptually similar) is what will allow 32 bit x86 software to make function calls into a 64 bit ARM OS. The important thing here isn't related to bit'edness, but the fact that WOW64 is a translation layer that mediates between software built for one CPU architecture when it's running on another. This is where part of the emulation magic happens.

It's really not emulation in the sense most people will be looking at it as.

So It's not taking a instruction for lets say "add a with b" that was encoded for an x86 instruction set and translating it into the x64 instruction for "add a with b", the x86 application is running as per normal with it's standard x86 instruction encoding, but when it tries opening, for example, a file, since on windows all calls are identical but data structures /values have been extended to 64bit from 32bit, stack requirements change (i.e, some calls dont use the stack) then WOW64 needs to read in the "old school" variety and expand it into 64 bit then make the call to the OS function, and then vise versa for anything windows is sending back to the application.

This is from my understanding of it.

The only exception to this is Itanium, but that's not the standard architecture people would be expecting to be talking about for x64.

WOW64 is actually more than it initially appears to be. I wasn't aware of this until recently myself, but apparently WOW64 already plays a role in allowing Itanium software to run on an x86 CPU, meaning that in addition to translating function calls, it also translates individual CPU instructions. That's the heart of any emulation solution! It seems likely that this is where x86 emulation on ARM will fit into the Windows OS architecture. If true, WOW64 is central to MS' emulation solution.

This is indeed emulation on the instructions - x86 onto itanium, not aware of the other way around though. and by all accounts because it lacks the "backwards compatibility" that AMD64 for example has on a hardware level, is less efficient, as it's translating instructions (emulating) by software at the instruction level,

 

[a5cent]

There's usually a fair bit of performance gain from 64bit architectures

No Kogling. At least in the consumer space that is simply not true. Upgrading to a 64 bit CPU+OS, in itself and isolated from everything else that a newer chip design might have improved upon, does very little in regard to computational performance. Typically absolutely nothing. The best way to prove this to yourself is to take a 64 bit CPU and benchmark the 64 bit and 32 bit versions of the same OS (the 32 bit version can't exploit any of the 64 bit extensions). Unless you force a situation where you require more than 3.5GB of memory, you'll be hard pressed to notice any difference at all.

Most of the software you run on a Windows PC is still 32 bit software, meaning it can't exploit any of the supposed advantages of a 64 bit CPU. This is after 64 bit CPUs have being available for more than a decade. Why? Because re-targeting a program to a 64 bit architecture leaves you with multiple installation packages that increases the likelihood of people having installation issues, without it providing any practical benefit (that includes no benefit to performance).

I think the overwhelming majority of people on this site would tell you the same thing. Take this thread for example:

http://forums.windowscentral.com/windows-10-mobile/447924-when-64bit-os-coming.html

if the OS is 32bit (which our phones are, for example) they shouldn't need WOW6

Ehem... except full Windows 10 on ARM won't be 32 bit! It's already been confirmed by MS that it must be the 64 bit version, precisely for the reasons I mentioned. None of that was speculation on my part. I didn't do a good job of clarifying which parts of my post are speculation and which are already confirmed facts. The parts about WOW64 being involved in emulation and translation are already confirmed for example. I have trouble making sense of most of your statements, but it's probably not worth arguing over.

How exactly emulation works I don't yet know. I've been trying to find out but MS is as tight lipped as ever. However, it's suspicious that the impression you are getting seems to be the exact opposite of the impression I'm getting. Mind sharing your sources? In particular it's stuff like this that appears to go against everything I've read so far:

So It's not taking a instruction for lets say "add a with b" that was encoded for an x86 instruction set and translating it into the x64 instruction for "add a with b", the x86 application is running as per normal with it's standard x86 instruction encoding,

If the instructions are not being translated from x86 to ARM, then would you mind explaining what you think is executing those instructions (hint: they mean absolutely zilch to an ARM CPU)?

 

[Kogling]

No Kogling. At least in the consumer space that is simply not true. Upgrading to a 64 bit CPU+OS

x64 on a PC means more registers than it's x86 counterpart, and the case is the same for ARM by the looks of it.

So an ARM (64bit) processor would (potentially) emulate an x86 application more efficiently because it doesn't need to use the stack as much by keeping as much as it can in registers. An emulator for x86 on ARM (32bit) would have less registers to play with, and therefore be more restricted due to higher memory usage.

AFAIK the move over to x64 made most windows calls become "fastcall" over "stdcall" which, depending on the architecture is generally faster.

The best way to prove this to yourself is to take a 64 bit CPU and benchmark the 64 bit and 32 bit versions of the same OS (the 32 bit version can't exploit any of the 64 bit extensions

So to be clear x64 doesn't emulate instructions from x86 to x64, it runs the code natively.

On an ARM, regardless of 32bit or 64bit, the x86 instruction has to be converted to native ARM instructions. ARM64 would have more registers to play with for a start to make it more feasible, as indicated above.

You can't treat ARM's x86 emulation the same as x64, since x64 IS native execution via backwards compatibility in the architecture.

Ehem... except full Windows 10 on ARM won't be 32 bit! It's already been confirmed by MS that it must be the 64 bit version, precisely for the reasons I mentioned

which isn't my point, it's speculative on the basis that emulation requires 64bit processors. The idea is you compare the feasibility of x86 emulation on a 32bit ARM vs 64bit ARM. 64bit ARM has a clear advantage on usable registers alone.

Hence my original point, older 32bit ARMs probably couldn't emulate x86 because the lack of registers meant a significant loss of performance having to constantly swap out.

.The parts about WOW64 being involved in emulation and translation are already confirmed for example.

it really doesn't matter what is doing the emulation.

WOW64 is software, therefore WOW64 = software based emulation. Software is emulating it whether they make it part of WOW64 or call it WOW-ARM64 or potato.

Being WOW or not doesn't change anything. It's still software emulation. WOW64 is just better for developers i guess? and its still true to it's name.

How exactly emulation works I don't yet know. I've been trying to find out but MS is as tight lipped as ever.

I'm only going on my knowledge of assembly programming which includes reading AMD processor specifications (the one for people wanting to make OSes and drivers) and also microsoft's documentation on x64 programming, which included WOW64.

but: "how does WOW64 emulate x86" into google.

How Windows 64-bit Supports 32-bit Applications | Gizmo's Freeware
"Under Windows 64-bit, 32-bit applications run on top of an emulation of a 32-bit operating system that is called Windows 32-bit on Windows 64-bit, or WOW64 for short.* WOW64 intercepts all operating system calls made by a 32-bit application.

For each operating system call made, WOW64 generates native 64-bit system calls, converting 32-bit data structures into 64-bit aligned structures. The appropriate native 64-bit system call is passed to the operating system kernel, and any output data from the 64-bit system call is converted into a format appropriate for the calling application before being passed back."

--------------
this is basically converting standard call to and from fast call, and 32bit values to and from 64bit.
------------
Lesson 2. Support of 32-bit applications in the 64-bit Windows environment

"Different processor architectures have a bit different WoW64. For example, the 64-bit Windows version developed for Intel Itanium 2 processor, employs WoW64 to emulate x86 instructions. This emulation is rather resource-intensive in comparison to WoW64 for Intel 64 architecture, because the system has to switch from the 64-bit mode to compatibility mode when executing 32-bit programs

WoW64 on Intel 64 (AMD64 / x64) does not require instruction emulation. In this case the WoW64 subsystem emulates only the 32-bit environment through an additional layer between a 32-bit application, and the 64-bit Windows API"

---------------------
Some of the earlier Itanium had x86 hardware support, all the modern ones are purely software emulation as far as i can see.

If the instructions are not being translated from x86 to ARM, then would you mind explaining what you think is executing those instructions

The x64 is backward compatible with x86 as part of the architecture. All the x86 parts (registers, etc) are just widened to 64bits.

the irony is the x86 is backwards compatible with the previous 16bit architecture of DOS? days. When a x64 CPU is booting up, it's in the 16bit mode, the bootloader enables the A20 gate, thus enabling 32bit mode, then from 32bit mode it switches to long mode (if my memory serves me right) and then you have access to 64bit processor functions.

ARM would need x86 instruction translated into ARM native code.

My point above was to try (further) stress that WOW64 on an x64 is native x86 execution and only serves as a windows API translation. Itanium is a special case where it does actually provide emulation of the x86 instruction sets.

x86 on ARM would need the x86 instruction set to be emulated.

but this all boils down to the fact that it's done via software in WOW64, not hardware, and if you exclude the Itanium special case, instruction set emulation is entirely different to the main bulk of what WOW64 does on standard computers.



So to clarify, x86 on ARM needs emulation. Emulation on windows with x64 (not ARM) as of current is only for system calls (excluding itanium) whereas ARM will be requiring x86 instruction emulation.

Reading, decoding and translating of x86 into ARM is likely to need the use of many CPU registers to make it within reasonable performance levels. ARM64 bit has more registers at hand, therefore one of the defining characteristics of support of x86 emulation is a 64bit processor.

my 2 cents

 

[a5cent]

You answered pretty much every question I had, except for the one that I would have been most interested in ;-)

You initially said that x86 instructions are not translated to ARM instructions, but now it seems you're saying something else, so I'm going to assume we now agree that x86 instructions on ARM must be translated before they can be executed.

 

[a5cent]

Reading, decoding and translating of x86 into ARM is likely to need the use of many CPU registers to make it within reasonable performance levels. ARM64 bit has more registers at hand, therefore one of the defining characteristics of support of x86 emulation is a 64bit processor.

Okay, I think I see where our misunderstanding stems from. In a nutshell, you think the critical factor, in terms of emulating x86 on ARM, are the number of registers a CPU has. In that context you repeatedly referred to 64 bit CPUs, when what you actually meant was the ARMv8 ISA, particularly the part that specifies the requirement for more registers. Having more registers and having wider registers are just two different things that aren't necessarily related. That's what threw me off.

ARM could theoretically also design an ARMv7.5 ISA which supports more registers than ARMv7, but remains a 32 bit architecture. That would likely also provide everything required to emulate x86 on ARM in the way you envision it. We will no doubt see many revisions of the ARMv8 architecture, some of which will also specify the requirement for more registers, long before we see a shift to 128 bit CPU architectures. That is a more realistic example of how the number of registers specified by an ISA can change without bi'tedness of the CPU architecture being affected. You munched all that together which made it hard to understand what you were getting at.

Anyway, I still completely disagree with your assessment. We could start arguing technical details, but I don't think that is even necessary. If the number of registers was the primary factor, then MS' x86 emulation on ARM would work on any newer ARM CPU! All ARMv8 compliant CPUs must have the exact same number of registers! If that number was the primary factor, then there would be absolutely no reason to limit this emulation capability to very specific ARMv8 chips (specifically Qualcomm Snapdragons), but MS has made it very clear that it is limited in that way! I think that is already almost as good as proof (not 100%, but close) that this requires at least some hardware support beyond what is specified by ARMv8.

I suspect WOW64 is simply the software interface that allows us to exploit those additional hardware capabilities. This last part is my own personal speculation. Everything prior to that is not speculative.

 

[EuroKnuter]

My hat is off to both a5cent and Kogling for having this discussion in front of me (us). Often I feel like I want my 5 minutes back when reading through threads - not this time. I have learned more / been given food for thought in this conversation than most other threads I've read in the last 2 weeks combined. *bow*

Again, my thanks to you both for well thought out discussion in a civil and pleasant format. Kudos!

 

[Kogling]

Okay, I think I see where our misunderstanding stems from. In a nutshell, you think the critical factor, in terms of emulating x86 on ARM, are the number of registers a CPU has

Registers are just a simple example, but they are certainly very useful for such a task.

ARM could theoretically also design an ARMv7.5 ISA which supports more registers

Most definitely, which is what I also said. But generally manufacturers are down the road of 64bits when they have a large amount of registers. By the time you need x registers, you probably need 4+GB memory so.. yeah.

. If the number of registers was the primary factor, then MS' x86 emulation on ARM would work on any newer ARM CPU

In theory you can emulate generally anything, but performance can take a rather big hit when done via software. Registers are great because memory hits can be massive.

They would also be reading data but converting it to code, so there's likely some big memory related costs here. Not sure how ARM is on that point. MS do this with C# so am sure they are quite capable at doing realistic emulation on an instruction set.

But no one else is offering x86 support on ARM, and they are working in partnership with Qualcomm /Snapdragon to get PCs going with ARM chips, not that other ARMs couldn't?. That's nothing more than a partnership in terms of supply, not an alteration of die design. Maybe Microsoft got some say in how they wanted certain things, or certain performance targets to make emulation more feasible, but I'm not inclined to believe there's a dedicated x86 bit of transistor magic going on in there.

They are not inclined to make it work for any other ARM manufacturer chip even if the capability is there. Supporting hardware for every scenario doesn't seem to be Microsofts intentions with the "mobile" market. Take continuum. If software runs too slowly for your PC, you either dont use it, buy a better programmed one or upgrade right?

But with MS, they are specifically denying "mobile software" they deem as not "running at an acceptable performance level". I dont see how this is any different to them refusing to enable continuum on older phones, or putting W10 on older devices like the Nokia 2520.

Its the same thing with IoT. Windows run on raspberry pi, yet we have the edison from intel that runs x86 and there's no window IoT build for it (last time i checked) and that's just because intel just need to make the drivers for it and.. wont.

Snapdragon does not sell exclusively to Microsoft, the 820 and no doubt 835 will be on phones for android too, and I don't think their clients with 80% market share will be too happy that a 2% market share company is getting exclusive hardware feature access (phone market anyway, which I know isn't exactly the same as the ARM pc side of things.)

I also just don't see what the problem of software emulation is. We've only just recently started seeing affordable, mainstream devices with decent speeds, screen sizes, external display support and high RAM. It really wouldn't be that great of an investment to make x86 apps run on a toaster. Now is not the case.

edit: and by all accounts x86 apps on ARM is already available for linux:
https://eltechs.com/product/exagear-desktop/