flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Heap > Win10 on Snapdragon supports x86-32 emulation out of the box

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
Trinitek



Joined: 06 Nov 2011
Posts: 257
Win10 on Snapdragon supports x86-32 emulation out of the box
Post 10 Dec 2016, 17:01
View user's profile Send private message Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 6917
Location: ˛                              ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣ Posts: 6699
quite amazing!

afaik, any system/pc/laptop/tablet which utilize SSD even with intel atom/celeron runs pretty smooth under windows 10,

i am aware the whole system is under emulation but still quite hard to compare without any benchmark,

x86 probably become default software container in future, like cubeos
Post 11 Dec 2016, 10:58
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 815
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 Razz).

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 Smile

Wonderful Christmas Gift just as info for nerds like me Razz
Post 11 Dec 2016, 16:51
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6588
Location: Kraków, Poland

Furs wrote:
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.
Post 11 Dec 2016, 16:58
View user's profile Send private message Visit poster's website Reply with quote
Trinitek



Joined: 06 Nov 2011
Posts: 257
Video of a live demo of an ARM64 Snapdragon board: https://www.youtube.com/watch?v=oSXUDKpkbx4&feature=youtu.be

The guy demos x86 MS Office, Edge, and 7-Zip
Post 20 Jun 2017, 13:38
View user's profile Send private message Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 6917
Location: ˛                              ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣ Posts: 6699
really great alternative i think, greater if this gonna bring down intel processor and oem motherboard price significantly, Embarassed eg, i5 price down to celeron price, Laughing
Post 20 Jun 2017, 15:35
View user's profile Send private message Reply with quote
YONG



Joined: 16 Mar 2005
Posts: 8000
Location: 22° 15' N | 114° 10' E
Just x86-32 emulation? How about x64 code?

Rolling Eyes
Post 21 Jun 2017, 03:06
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 815

YONG wrote:
Just x86-32 emulation? How about x64 code?

Rolling Eyes

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.

Even the demo'd OS has only 4GB RAM, I'm sure you need x64 apps. Rolling Eyes
Post 21 Jun 2017, 11:26
View user's profile Send private message Reply with quote
YONG



Joined: 16 Mar 2005
Posts: 8000
Location: 22° 15' N | 114° 10' E

Furs wrote:
Even the demo'd OS has only 4GB RAM, I'm sure you need x64 apps. Rolling Eyes

My entry-level Chromebook also has only 4GB of RAM. Since the CPU supports x64, the OS is 64-bit. And the overall performance is excellent.

Wink
Post 21 Jun 2017, 12:22
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 815
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). Confused

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 Wink

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.
Post 21 Jun 2017, 14:16
View user's profile Send private message Reply with quote
YONG



Joined: 16 Mar 2005
Posts: 8000
Location: 22° 15' N | 114° 10' E

Furs wrote:
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 Wink

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.

So, my question remains: How come x64 emulation is not supported?

Wink
Post 22 Jun 2017, 04:24
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15153
Location: GW170817

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.

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.
Post 22 Jun 2017, 08:01
View user's profile Send private message Visit poster's website Reply with quote
YONG



Joined: 16 Mar 2005
Posts: 8000
Location: 22° 15' N | 114° 10' E

revolution wrote:
... 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.

That may be the real reason behind the lack of x64 emulation in the new processors. Thanks for your input.

Wink
Post 22 Jun 2017, 08:24
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 815

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

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. Wink

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.
Post 22 Jun 2017, 11:22
View user's profile Send private message Reply with quote
YONG



Joined: 16 Mar 2005
Posts: 8000
Location: 22° 15' N | 114° 10' E

Furs wrote:
You can't run x86 code natively on ARM, doesn't matter the OS.

That's why an emulation for x64 code would be very helpful. Right?

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

Wink
Post 22 Jun 2017, 12:28
View user's profile Send private message Visit poster's website Reply with quote
YONG



Joined: 16 Mar 2005
Posts: 8000
Location: 22° 15' N | 114° 10' E

Furs wrote:
Stop confusing efficiency with performance. Wink

You are good at playing with words, aren't you?

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? Rolling Eyes

Wink
Post 22 Jun 2017, 12:35
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 815

YONG wrote:
That's why an emulation for x64 code would be very helpful. Right?

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

Wink

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? Rolling Eyes

Wink

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). Wink (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.
Post 22 Jun 2017, 14:41
View user's profile Send private message Reply with quote
YONG



Joined: 16 Mar 2005
Posts: 8000
Location: 22° 15' N | 114° 10' E

Furs wrote:
You asked if it can run natively without a 64-bit OS.

I was not asking; I was challenging your arguments.

I asked a simple question: How come those new CPUs provide only emulation of x86, but not x64?

But then you made lots of irrelevant arguments like the demo's OS has only 4GB of RAM. Anyway.

revolution has already provided a sensible answer.

Wink
Post 23 Jun 2017, 02:02
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 815
The CPU doesn't provide any emulation, Microsoft's OS (software) does.

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.
Post 23 Jun 2017, 10:35
View user's profile Send private message Reply with quote
YONG



Joined: 16 Mar 2005
Posts: 8000
Location: 22° 15' N | 114° 10' E

Furs wrote:
You ask a wrong question.

No, I do/did not. My question has always been about the reason behind the lack of support of x64 emulation. You just shifted the focus to something else, such as 32-bit versus 64-bit. Anyway.

Wink
Post 23 Jun 2017, 10:51
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >

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


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.