Linked by Thom Holwerda on Tue 8th Jan 2013 23:27 UTC
Windows So, a rudimentary jailbreak for Windows RT made its way onto the web these past few days. Open source applications were ported right away, and it was confirmed that Windows RT is the full Windows - it's exactly the same as regular Windows, except that it runs on ARM. Microsoft responded to the jailbreak as well.
Thread beginning with comment 548060
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: x86
by Alfman on Thu 10th Jan 2013 02:10 UTC in reply to "RE[4]: x86"
Alfman
Member since:
2011-01-28

WereCatf,

"So, basically you want Wine with machine-code translation. Too bad that it won't happen without Microsoft's help, as even Wine is still riddled with bugs after all these years."

This kind of project seems right up my alley in terms of my interests and abilities. I think it could be done without the need for "wine" at all as long as the ARM opcodes could implement the same calling conventions which exist on x86.

Most code doesn't self modify, and because of that it is possible to recompile the opcodes from one architecture to another architecture, which isn't far off from what qemu does. Inefficiencies arise because different architectures don't have 1 to 1 correspondence between opcodes, producing overhead. However if this were combined with a good code optimiser (like re-purposing the one in gcc or better yet icc), then you might even end up with emulation that can perform better than the original.

Anyone care to offer me a grant? Since I sure wouldn't have time to work on it unless I could drop my ordinary work and pay a babysitter.

Reply Parent Score: 3

RE[6]: x86
by WereCatf on Thu 10th Jan 2013 02:50 in reply to "RE[5]: x86"
WereCatf Member since:
2006-02-15

Most code doesn't self modify


I think you mean most simple applications don't self-modify. Most multimedia-related applications do make use of heavy optimizations where straight-up static translation doesn't work. On a similar note, straight-up translation wouldn't work for 64-bit applications at all.

But sure, I would love to see you prove me wrong, it'd be a very nice tool in the toolbox! Go ahead and explain more in detail of how you'd actually implement such a thing if you feel like it, as off-topic as it may be.

Reply Parent Score: 3

RE[7]: x86
by Alfman on Thu 10th Jan 2013 07:29 in reply to "RE[6]: x86"
Alfman Member since:
2011-01-28

WereCatf,

"I think you mean most simple applications don't self-modify. Most multimedia-related applications do make use of heavy optimizations where straight-up static translation doesn't work."

I don't really know what you are referring to here? Most games/multimedia apps would use SSE and the like, but they are still static as far as I know. Skype uses dynamic code extensively to obscure itself even to the point of incurring significant overhead during normal use, which is ridiculous. However that's an exception and not the norm. I'd be surprised to see many cases where the code in memory is not a mirror image of the executable/dlls.


"On a similar note, straight-up translation wouldn't work for 64-bit applications at all."

Why not? Are you talking about handling 64bit calculations? Can't ARM platforms handle uint64_t today just like 32bit x86 can? Aren't ints usually 32bit even on x86-64? It's mainly in the case of longs that 64bit arithmatic needs to be split up into multiple 32bit operations.

An observation is that 64bit longs are often used to store values that would fit in 32bits anyways, so we don't always need to touch the high bytes anyways. Take a look at 64bit pointers, they'll never point beyond 4GB on a 32bit ARM, so there's no need to handle it. The 32bit translated code would only need to detect overflow, and only then would it have to handle a 64bit variable and compile a 64bit code path.


"But sure, I would love to see you prove me wrong, it'd be a very nice tool in the toolbox! Go ahead and explain more in detail of how you'd actually implement such a thing if you feel like it, as off-topic as it may be."

That's kind of a vague request.
At a high level, every x86 code segment would have a corresponding ARM recompiled one that's generated either on the fly or maybe up front. In principal it's probably not much different from Java's JIT compiler w/bytecode, though x86 is obviously much less structured.

Having used decompilers (yay turbo debugger!), code alignment is tricky to get right - dumping code with the wrong offset produces garbage. But since we are actually running the code, we don't have to guess. Dynamic modifications to code pages would trigger faults such that we could invalidate/recompile the corresponding ARM translated code, however I really think we're talking about an edge case there. The ARM code could be cached between executions to avoid constant recompilation.

In order to save a lot of work on the ARM compiler/optimizer I would try to hook into GCC's optimizer directly or if I feel particularly hacky maybe even convert the x86 opcodes into C code and call the compiler that way.

Ideally the end result would be ARM code that would be very close to what we would have had if the original source were compiled for ARM instead of x86.

Reply Parent Score: 3

RE[6]: x86
by zlynx on Thu 10th Jan 2013 19:27 in reply to "RE[5]: x86"
zlynx Member since:
2005-07-20

I read about modules for LLVM to do this a while back.

The idea is to use LLVM, read the x86 machine code and "compile" it into the LLVM intermediate representation, then compile that into ARM or PPC or whatever.

Last I heard it worked pretty well on code compiled with GCC or LLVM, much less well on custom machine code, and it had some trouble determining the real byte sizes of some variables.

Still, it'd be a good place to start.

Reply Parent Score: 2

RE[7]: x86
by Alfman on Thu 10th Jan 2013 20:42 in reply to "RE[6]: x86"
Alfman Member since:
2011-01-28

zlynx,

"I read about modules for LLVM to do this a while back...Still, it'd be a good place to start."

+1!

Sadly I cannot actually afford to take on the project as an unpaid hobby, but this is the kind of CS stuff I had ambitions of doing when I entered the field. Screw you PHP \:(

Edit: what the heck is the emoticon for anger?

Edited 2013-01-10 20:45 UTC

Reply Parent Score: 2