To me this is one of the best news, and not because I care about ARM at all. Simply because it will make x86 code more ubiquitous (and I obviously have a special bond with it due to asm ).

I don't get people who think "emulated" x86 code must be very slow especially if assisted with special new instructions. First of all, managed code (i.e stupid Java and .NET) already runs on phones everywhere and is mandatory, so everyone is already running emulated code!! People just won't get this.

Yeah, there's some quirks for x86 code where it will be very slow compared to Java, like self-modifying code. Keep in mind, though, that those cases are exceptional. Usually happen once in a program at startup (copy protection, hand-coded optimization, etc), so while it will be slow, it's negligible. I don't know many programs (if any?) that does self-modifying code constantly.

Also, x86 is already emulated by any CPU in existence. It is a form of compact code that is good for "storage", not read directly by the CPU. Even x86 CPUs translate it to micro-ops etc.

To me x86 is far better than Java bytecode to begin with since it's already supposedly optimized + it can be ran by CPUs natively (if you need the absolute performance) while also being able to be emulated. This is the best news because it brings x86 to be in competition somewhat to Java. And I hope it's just the first step.

Also the best thing about x86 code is that it's compact. Yeah, I care about code size, unlike "speed", size can be measured and I have a special obsession with it. (in general, not like I care of last byte, but yeah... it's beautiful to look at small programs that do much). x86 should become the new "universal" code now

I don't get people who think "emulated" x86 code must be very slow especially if assisted with special new instructions. First of all, managed code (i.e stupid Java and .NET) already runs on phones everywhere and is mandatory, so everyone is already running emulated code!! People just won't get this.
(...)
Also, x86 is already emulated by any CPU in existence. It is a form of compact code that is good for "storage", not read directly by the CPU. Even x86 CPUs translate it to micro-ops etc.

I think it was Transmeta Crusoe that pioneered these ideas. Back in the day I was really impressed by how well it was doing it.

x64 code for low power device is a total waste and probably way harder to emulate as well. Only reason it would be there later maybe due to "marketing reasons" or "fashion statements". Obviously, getting it later makes it a better marketing statement you know.

I'm not sure I understand your point? I wasn't even talking about performance (although a 32-bit OS would use less RAM, so more available for caching, I guess it can count as "edge-case" performance).

Though, I don't know how they did the emulation. I guess a 64-bit emulation would be slower. The only reason 64-bit hardware is "just as" fast as 32-bit in normal cases (where you don't need > ~3.5GB addressing space on a app) is because of extra hardware specifically done for that task which wastes more power or transistors that could be used elsewhere -- however on a software emulation you cannot have "extra hardware", so the performance difference will be visible. Also 32-bit has fewer "ISA" registers to emulate, and ARM has more registers than x86, I know that emulators use all sorts of register caching hacks to improve emulated code performance (like Bochs does).

Where 64-bit is better than 32-bit, which is high-end apps that require a lot of RAM or processing power, such as video editing or 3D or whatever, in those cases this device is clearly the wrong tool for the job. I mean, why would you want to run high-performance task on a low-powered ARM processor that also emulates the code?

That said, I find the emulator as a good thing. It stops Java from being the only "portable" binary solution, since I despise it and I love x86. For most apps, the fact that they're emulated does not matter anyway. Java apps don't care much about performance either.

And frankly, I don't see why would an emulated piece of shit like Java be any different than emulated x86? Why doesn't anyone bitch about Java, but they do if x86 is emulated? (just check comments on articles about this emulator, lmao) Incompetence.

EDIT: Oh just reread what you said. The fact that the OS is 64-bit is a totally different matter than an app being x64, since we're speaking of apps here

PS: A lot of people hate the x87 FPU's "stack" layout, yet they have no problem with the fact that Java/C# are also compiled as stack-based languages in binary code. Talk about double standards.

Oh just reread what you said. The fact that the OS is 64-bit is a totally different matter than an app being x64, since we're speaking of apps here

Without a 64-bit OS, how could we run 64-bit apps natively?

While 64-bit apps generally are a bit bigger and need a bit more memory, they are more efficient than their 32-bit counterparts. Even entry-level / low-end devices, if 64-bit capable, can benefit from the performance gain of running 64-bit apps.

While 64-bit apps generally are a bit bigger and need a bit more memory, they are more efficient than their 32-bit counterparts. Even entry-level / low-end devices, if 64-bit capable, can benefit from the performance gain of running 64-bit apps.

Oh how I wish that were actually true. Only some applications can realise any performance gain from 64-bit. Also in the ARM CPUs 32-bit instructions are a lot more efficient than 64-bit because power to the higher bits is gated. ARM recommends to use 32-bits where possible, and only use 64-bits when needed.

I don't get your question? You can't run x86 code natively on ARM, doesn't matter the OS.

YONG wrote:

While 64-bit apps generally are a bit bigger and need a bit more memory, they are more efficient than their 32-bit counterparts. Even entry-level / low-end devices, if 64-bit capable, can benefit from the performance gain of running 64-bit apps.

Stop confusing efficiency with performance.

How can redundant calculations be more efficient? It is physically impossible. Heck there's even 8-bit embedded CPUs purely for efficiency purposes.

As for performance, that's a tricky beast though I don't believe the marketing bullshit. Google "claimed" 64-bit Chrome is up to 25% faster, yet in all benchmarks when tested it was even 2-3% slower sometimes and just as much a bit faster in others. So it's pure marketing. Anyway it wasn't really performance I was talking about, considering it's emulated, it doesn't make much sense to focus on it.

Even so, in emulations 32-bit will most likely be faster, unless you intend to run an application that requires 64-bit operations obviously (math apps for instance). Because like I said there's no "extra parallel hardware" to do it, since it's software. The "less" stuff (bits etc) you have to emulate, the faster the operations in general.

You can build a hardware to do 256-bit additions just as fast as 8-bit additions. You can also use software to utilize that hardware to perform 32 8-bit additions at the same time as one 256-bit addition, making 8-bit CPU emulations 32 times faster for such operations, if you can parallelize them enough. Using SIMD and such hacks. It's pretty basic stuff. You can also store 32 8-bit registers into only one register on your host, if you were to emulate such a CPU.

It won't always be the case, but you get the point.

Anyway none of this has anything to do with efficiency. Redundant calculations for pointers when the app doesn't even use 1GB of addressing space is pure waste in terms of efficiency.

Then, how come such an emulation is not supported by those new processors?

That makes no sense? You asked if it can run natively without a 64-bit OS. But nothing here is native. Of course any CPU can emulate a 64-bit CPU, with varying degrees of success/acceptable performance. Even an 8-bit CPU can. But this isn't even about a full-on virtual machine -- it's about emulating applications. None of it will be native, but the entire thing is not native. The CPU is ARM, and it needs to run x86 (or in your case x64), none of which even CAN be native.

YONG wrote:

Maybe we should go backwards and start reusing 32-bit processors.

Nope. That is not enough. We should go back to 16-bit processors directly.

What kind of logic is that?

Well you're the one who wants efficiency (power saving I mean) and hate old laptops cause they're not efficient -- so you should be definitely pushing for 16-bit CPUs and using lightweight features etc if you truly cared, instead of all the bloat nowadays (all that wasted processing for little gain, insane high resolutions too). (also there are loads of 8-bit/16-bit embedded CPUs where efficiency matters, just not in casual marketing devices, but under-the-hood)

But that has nothing to do with the topic. It's about the ability to emulate a different 32-bit processor mode for applications. Not sure why you even bring the CPU into the discussion. Emulator is software so the OS CPU doesn't matter in the slightest. All that matters is the emulator -- the software itself -- and how efficient it can emulate the target CPU based on the OS it is built on (but with enough effort, it can be built on any CPU).

In this case we speak of emulating applications, not an OS. Because it's not a virtual machine.

You ask a wrong question and even though I got it wrong (I thought you were aware it was a software emulator in the first place), the answer was very relevant. You must be one of those defensive people who think that not getting the answer he wants makes it irrelevant or invalid; i.e. can't accept reasonable facts.

Why doesn't X provide Y? Because there's no need for Y when X has only Z and would also complicate/make X slower or less efficient (efficient in terms of power consumption, just to be clear, since I don't want to go into "weasel words" again with performance) (software solution, you know).

"Irrelevant argument" indeed. The other half of the post (the marketing stuff) was just my opinion of what might be Microsoft's next step if this turns out ok, but I doubt that's what you had issues with? I didn't imply it wasn't just my opinion.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou can attach files in this forumYou can download files in this forum