Microsoft mulling 128-bit versions of Win8, Win9
-
This appears more to be concerned with Windows Server (i.e., Windows NT 7) which of course would be Windows 8. Cause how many consumer or non-server-class machines use an Intel Itanium processor? Mind you, these IA-64 processors are hella expensive. A Consumer OS I cannot see a need for going to 128 bits, but for a server OS defiantly.
Let me see. Where have I heard something like that before? Oh yea, Bill Gates once questioned why anyone would need more than 640k of memory. I used to work for HP and during a server demo of a new 386 box I asked when a 386 desktop would be available. The reply was desktop users would never need this much power. Those quotes seem kind of silly don't they. How about yours?
-
-
Let me see. Where have I heard something like that before? Oh yea, Bill Gates once questioned why anyone would need more than 640k of memory. I used to work for HP and during a server demo of a new 386 box I asked when a 386 desktop would be available. The reply was desktop users would never need this much power. Those quotes seem kind of silly don't they. How about yours?
I suppose I should have added "yet" to the end of my statement. Will consumer computers reach 128 bits? Most certainly. Do we need 128 bits now? Nope.
-
I call this one a Niche play.
Why?
Itanium's instruction set has zero commonality with x86/x64. So to get existing (x) code to run, there must be come kind of container, wrapper, or virtualized environment to do it for you. Now, before anyone comes back with WOW64 - understand that operates on the OS level and that the 32 bit binaries are still run on the processor natively. This can not be done on an Itanium box.
So to make existing x** applications work in an Itanium box, they'll have to operate in some sort of a container. AKA Java.
On Itanium processors WOW64 runs an emulation of x86, converts x86 instructions to IA-64 instructions. Where as compared to WOW64 on x86-64 processors WOW64 switches the CPU to x86 mode and forwards API calls. So running x86 applications on Itanium is very possible. 
http://en.wikipedia.org/wiki/WOW64
-
![]()
Mea Culpa :) But understand I didn't say it wasn't possible to run at all. Just that it requires some kind of container to handle the emulation, and (I hinted at) the attendant performance overhead when I compared it to (the notoriously hungry) Java. What I didn't know is there was a version of WOW64 for Itanium that already does this. In retrospect, I suppose I should have.
The difference, though, is the current version of WoW64 (as available in consumer Win 7) runs 32 bit (x86) binaries natively at the processor level. "Natively at the processor level" can not be done on an Itanium because of the completely different the instruction sets. This is what was in my head when I made my above statement.
****
(edit) What Microsoft have to say:
http://msdn.microsoft.com/en-us/libr...19(VS.85).aspx
- Processor hardware. Instruction emulation is performed on the chip. On the x64 processor, instructions are executed natively by the micro-architecture. Therefore, execution speed under WOW64 on x64 is similar to its speed under 32-bit Windows. On the Intel Itanium processor, more software is involved in the emulation, and performance suffers as a result.
- API thunk overhead. This overhead is small compared to the NT kernel call itself. NT kernel functions are intended to be called infrequently.
- Virtual memory size. On the Intel Itanium processor, WOW64 adds significant overhead if two or more instances of the same 32-bit application are running concurrently. This is due to the native 8 KB pages on the Intel Itanium, which complicates the emulation of the native 4 KB pages on the x86 architecture (more pages are marked as writable; all writable pages are private to the process). This can adversely affect the scalability of Terminal Services on certain processors. This is not the case for the x64 processor.
- Working set. WOW64 increases the size of the application's working set.
WOW64 enables 32-bit applications to take advantage of the 64-bit kernel. Therefore, 32-bit applications can use a larger number of kernel handles and window handles. However, 32-bit applications may not be able to create as many threads under WOW64 as they can when running natively on x86-based systems because WOW64 allocates an additional 64-bit stack (usually 512 KB) for each thread. In addition, some amount of address space is reserved for WOW64 itself and the data structures it uses. The amount reserved depends on the processor; more is reserved on the Intel Itanium than on the x64 processor.
If the application has the IMAGE_FILE_LARGE_ADDRESS_AWARE flag set in the image header, each 32-bit application receives 4 GB of virtual address space in the WOW64 environment. If the IMAGE_FILE_LARGE_ADDRESS_AWARE flag is not set, each 32-bit application receives 2 GB of virtual address space in the WOW64 environment.
Last edited by Scotteq; 08 Oct 2009 at 11:25.
Reason: To Add MSDN reference
-
-
![]()
I call this one a Niche play.
Why?
Itanium's instruction set has zero commonality with x86/x64. So to get existing (x) code to run, there must be come kind of container, wrapper, or virtualized environment to do it for you. Now, before anyone comes back with WOW64 - understand that operates on the OS level and that the 32 bit binaries are still run on the processor natively. This can not be done on an Itanium box.
So to make existing x** applications work in an Itanium box, they'll have to operate in some sort of a container. AKA Java.
On Itanium processors WOW64 runs an emulation of x86, converts x86 instructions to IA-64 instructions. Where as compared to WOW64 on x86-64 processors WOW64 switches the CPU to x86 mode and forwards API calls. So running x86 applications on Itanium is very possible.
WoW64 - Wikipedia, the free encyclopedia
I believe you're both saying the exact same thing: x64 can run 32-bit code directly on the processor, while IA-64 requires software emulation (wow64cpu.dll) because the processor doesn't itself speak 32-bit.
-
To all those who would argue that we do not need this kind of power on the desktop today - Speak for yourself.
I would have an immediate use for the ability to solve for a 20 layer deep time-of-day sensitive LCR solution for 1,000+ international terminations in real-time.
Today, I settle for three layers. And it takes a half-hour.
-
To all those who would argue that we do not need this kind of power on the desktop today - Speak for yourself.
I would have an immediate use for the ability to solve for a 20 layer deep time-of-day sensitive LCR solution for 1,000+ international terminations in real-time.
Today, I settle for three layers. And it takes a half-hour.
That hurt my head. 
I do agree that those who say we do not need that kind of power should only speak for themselves.
If everyone thought like that we'd still think 32mb (or lower) of RAM is POWERFUL!
-
-
To all those who would argue that we do not need this kind of power on the desktop today - Speak for yourself.
I would have an immediate use for the ability to solve for a 20 layer deep time-of-day sensitive LCR solution for 1,000+ international terminations in real-time.
Today, I settle for three layers. And it takes a half-hour.
Hi there
and I thought that deriving and solving the equations of motion of a Supermarket trolley was difficult. 
Cheers
jimbo
-
GAWD.
Who will EVER use the full potential of a x128 machine?!? x128 may be ready for Win8 and/or Win9 but a normal user using the full potential of a x128 platform isn't for either Win8 or Win9. It will be MUCH MUCH later.
You must be a casual user.
I would love to do some data modeling in the 128-bit realm.
I have 2GB of RAM and a 32-bit system... I didn't even really use all of my 2GB of RAM... Why would I need 1M+TB of RAM on a x128 machine?!?
-
... Why would I need 1M+TB of RAM on a x128 machine?!?
...if you want to upgrade to windows 10 or winX
Quote