Linked by Thom Holwerda on Wed 5th Jan 2011 21:22 UTC
Hardware, Embedded Systems Just - just hold on a second. This is big: NVIDIA, maker of graphics accelerator chips, has just announced, during its keynote at CES, that it is developing a high-performance ARM-based processor together with ARM, targeted squarely at the desktop, server, and even high-performance computing markets. That Windows on ARM thing? NVIDIA referenced it multiple times! Update: Boom, and we have a press release. "NVIDIA announced today that it plans to build high-performance ARM based CPU cores, designed to support future products ranging from personal computers and servers to workstations and supercomputers. Known under the internal codename 'Project Denver', this initiative features an NVIDIA CPU running the ARM instruction set, which will be fully integrated on the same chip as the NVIDIA GPU."
Thread beginning with comment 456281
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: games
by lemur2 on Fri 7th Jan 2011 02:03 UTC in reply to "games"
lemur2
Member since:
2007-02-17

Wouldn't all games need to be 100% .NET (or java, python, etc.) to be compatible between x86 Windows and ARM Windows?

Aren't most games still written in C++?


One merely needs to take the C++ source code and compile it for the ARM architecture which one is targetting. One thereby produces an ARM executable binary, not an x86 executable binary, for the exact same game application.

x86/x86_64 does not have a monopoly on C++ code.

For example, most of Nokia's Qt code is written in C++. Qt is the basis of Meego Linux.

http://liliputing.com/2010/05/despite-intel-backing-meego-linux-to-...

http://www.engadget.com/2010/06/21/nokia-7-or-9-inch-meego-tablet-r...

Edited 2011-01-07 02:05 UTC

Reply Parent Score: 2

RE[2]: games
by BeamishBoy on Fri 7th Jan 2011 04:30 in reply to "RE: games"
BeamishBoy Member since:
2010-10-27

One merely needs to take the C++ source code and compile it for the ARM architecture which one is targetting. One thereby produces an ARM executable binary, not an x86 executable binary, for the exact same game application.


In theory, this approach should work fine. But in practice it's not going to be anywhere near as simple as that.

For instance, game producers could very well find themselves facing a situation in which they need to link their application against some third party library. If they've been linking to that library as an x86 binary, there's no guarantee that they'll be able to obtain corresponding binaries for ARM. Depending on the level to which they rely on that library, this could end up being a complete show stopper for many projects.

Reply Parent Score: 1

RE[3]: games
by lemur2 on Fri 7th Jan 2011 11:49 in reply to "RE[2]: games"
lemur2 Member since:
2007-02-17

"One merely needs to take the C++ source code and compile it for the ARM architecture which one is targetting. One thereby produces an ARM executable binary, not an x86 executable binary, for the exact same game application.


In theory, this approach should work fine. But in practice it's not going to be anywhere near as simple as that.

For instance, game producers could very well find themselves facing a situation in which they need to link their application against some third party library. If they've been linking to that library as an x86 binary, there's no guarantee that they'll be able to obtain corresponding binaries for ARM. Depending on the level to which they rely on that library, this could end up being a complete show stopper for many projects.
"

If true, this has nothing at all to do with either C++ or games, it is a completely separate issue.

Insofar as this issue itself goes ... I thought that the general rule on Windows was not to dynamically link libraries. That is to say, it wasn't advisable on Windows to simply expect another library of the correct version to already be installed on a system, so that one can link to it, but rather one included any required libraries within one's own application code (that is, typically all required libraries are statically linked for every application). In turn, this is the reason why the same number and complexity of Windows applications requires many times more disk space than Linux applications.

Reply Parent Score: 2