4 ms·

Well for one, Apple transitioned from ppc->intel REALLY well with Mach-o binaries and Rosetta. Using a vm/jit isn't the only way to handle architecture changes

by mitchty 15y ago

Well for one, Apple transitioned from ppc->intel REALLY well with Mach-o binaries and Rosetta. Using a vm/jit isn't the only way to handle architecture changes. In addition it doesn't remove the need to handle kernel changes/etc... that the vm itself runs on. Nor does it mean that the vm and all of its underlying assumptions are valid on a new instruction set. It took java a fair amount of time to run fast on multiple architectures, I doubt .NET will fare any better. When Windows actually manages to (again, it ran on alphas/mips/ppc and something else back in the 4.0 days) run on more than one platform I might partially buy into .NET being "portable" across windows releases and architectures. But I suspect a fair amount of things will have to change or move to new apis. Similar to Microsofts go it alone 64bit model in Windows, another architecture in the fray will force things into spaces they didn't originally expect. Basically, I don't trust anything coming out of Microsoft until they deliver the goods. Apple has shown they can handle multiple platforms transparently, and without the need of a vm/jit. Which can help out things like battery life with caches/etc... http://en.wikipedia.org/wiki/Mach-O http://en.wikipedia.org/wiki/Mach-O http://en.wikipedia.org/wiki/Fat_binary#NeXT.27s.2FApple.27s_Multi-Architecture_Binaries http://en.wikipedia.org/wiki/Fat_binary#NeXT.27s.2FApple.27s... http://en.wikipedia.org/wiki/Rosetta_(software) http://en.wikipedia.org/wiki/Rosetta_(software)

blinkingled 15y ago
From CES2011 The technology demonstration included Windows client support across a range of scenarios, such as hardware-accelerated graphics and media playback, hardware-accelerated Web browsing with the latest Microsoft Internet Explorer, USB device support, printing and other features customers have come to expect from their computing experience. Microsoft Office running natively on ARM also was shown as a demonstration of the full depth and breadth of Windows platform capabilities on ARM architecture. I dont think there is reason to doubt Microsoft on API compatibility which i s what this ultimately boils down to. Windows recently ran on IA64 BTW. .NET helps but Win32 in itself is proven enough to need little more than just a recompile for porting.
- mitchty 15y ago
  I was thinking more along the lines of C/C++ WIN32 api and things like 64bit calling conventions etc... that might not remain quite the same on ARM.
  - blinkingled 15y ago
    There is no such issue. You dont seem to understand what you are talking about. Look up ABI. They couldnt possibly port software as big as the OS itself and MS Office / Oracle DB to Itanium without having stable C/C++ and Win32 ABI/API.
    - mitchty 15y ago
      Ok fine I'm a retard.
      - marshray 15y ago
        Yeah everybody knows there's no way a C API from Microsoft could ever be a leaky abstraction. Lol.
        mitchty 15y ago
        Or that there's no way the win64 calling conventions weren't influenced by win32. But in fact their 64bit abi on x86_64 was in fact derived from their 32bit calling conventions. http://stackoverflow.com/questions/4429398/why-does-windows64-use-a-different-calling-convention-from-all-other-oses-on-x86 http://stackoverflow.com/questions/4429398/why-does-windows6... Correct me if I'm wrong, but there is an exact case of where 32bit windows on x86 directly influenced 64bit. This is what I'm talking about when I talk about other 64bit platforms may not behave the way Microsoft expects. And this directly influences c/c++ register allocation. Though I will state, what Microsoft did for its fastcall on 32bit windows and 64bit is rather ingenious in that the same call can work on both platforms.
        15y ago
FxChiP 15y ago
You keep saying "without using a vm/jit" like it's something Apple did, but in reality, Rosetta is a JIT and not every Mac OS X binary for PPC was a Universal one (which, incidentally, caused a few problems when Rosetta's translation wasn't up to par, either). Also, .NET is "portable" not just across Windows releases, but through the work of Mono large portions of it also work on Linux, and on other architectures via Linux as well -- so presumably, anywhere Mono or Microsoft's official .NET are compiled, .NET will run so long as no weird x86- or binary-specific things (like P/Invoke) are done. There are other problems with Mono, however, but those are for another discussion.
- mitchty 15y ago
  This is true that Rosetta is a JIT, but my point was more that the Mach-O binary format allows for multiple architecture binaries, therefore somewhat obviating the need for a jit. The only use Rosetta served was running cross architecture binaries. Mono also doesn't run the full .NET stack, e.g. think the Netflix drm components, so I can't quite consider it cross platform. Cross platform windows wise sure, but that isn't saying much.

by mitchty 15y ago

blinkingled 15y ago

From CES2011 The technology demonstration included Windows client support across a range of scenarios, such as hardware-accelerated graphics and media playback, hardware-accelerated Web browsing with the latest Microsoft Internet Explorer, USB device support, printing and other features customers have come to expect from their computing experience. Microsoft Office running natively on ARM also was shown as a demonstration of the full depth and breadth of Windows platform capabilities on ARM architecture. I dont think there is reason to doubt Microsoft on API compatibility which i s what this ultimately boils down to. Windows recently ran on IA64 BTW. .NET helps but Win32 in itself is proven enough to need little more than just a recompile for porting.

mitchty 15y ago
I was thinking more along the lines of C/C++ WIN32 api and things like 64bit calling conventions etc... that might not remain quite the same on ARM.
- blinkingled 15y ago
  There is no such issue. You dont seem to understand what you are talking about. Look up ABI. They couldnt possibly port software as big as the OS itself and MS Office / Oracle DB to Itanium without having stable C/C++ and Win32 ABI/API.
  - mitchty 15y ago
    Ok fine I'm a retard.
    - marshray 15y ago
      Yeah everybody knows there's no way a C API from Microsoft could ever be a leaky abstraction. Lol.
      - mitchty 15y ago
        Or that there's no way the win64 calling conventions weren't influenced by win32. But in fact their 64bit abi on x86_64 was in fact derived from their 32bit calling conventions. http://stackoverflow.com/questions/4429398/why-does-windows64-use-a-different-calling-convention-from-all-other-oses-on-x86 http://stackoverflow.com/questions/4429398/why-does-windows6... Correct me if I'm wrong, but there is an exact case of where 32bit windows on x86 directly influenced 64bit. This is what I'm talking about when I talk about other 64bit platforms may not behave the way Microsoft expects. And this directly influences c/c++ register allocation. Though I will state, what Microsoft did for its fastcall on 32bit windows and 64bit is rather ingenious in that the same call can work on both platforms.
        15y ago

FxChiP 15y ago

You keep saying "without using a vm/jit" like it's something Apple did, but in reality, Rosetta is a JIT and not every Mac OS X binary for PPC was a Universal one (which, incidentally, caused a few problems when Rosetta's translation wasn't up to par, either). Also, .NET is "portable" not just across Windows releases, but through the work of Mono large portions of it also work on Linux, and on other architectures via Linux as well -- so presumably, anywhere Mono or Microsoft's official .NET are compiled, .NET will run so long as no weird x86- or binary-specific things (like P/Invoke) are done. There are other problems with Mono, however, but those are for another discussion.

mitchty 15y ago
This is true that Rosetta is a JIT, but my point was more that the Mach-O binary format allows for multiple architecture binaries, therefore somewhat obviating the need for a jit. The only use Rosetta served was running cross architecture binaries. Mono also doesn't run the full .NET stack, e.g. think the Netflix drm components, so I can't quite consider it cross platform. Cross platform windows wise sure, but that isn't saying much.