Windows 8 128bit?

[Gamingphreek]

The writer of that post clearly as 0 knowledge of computer architecture.

First off, this isn't for Itanium. Itanium is based on the EPIC (Explicitly Parallel Instruction Computing) architecture and uses the IA64 IS (Instruction Set). While there are version of Windows for this architecture, even the Itanium's, to my knowledge, there is no mention on any of the roadmaps for such a deal.

Second off, we haven't fully moved over the 64 bit computing yet. So much so, that I believe on current chips, we are still limited to 48-bit memory addressing for the simply fact that we are NO WHERE REMOTELY CLOSE to needing 18 EB's of RAM.

Third off, 128, 64, and 32bit in no way correlates to how many cores or physical processor can be placed in a system.

Fourth off, what would be one reason to push something along like this? I would love to see significant examples of values that 64bit registers or the soon to be made 128-bit vector registers cannot handle. What programmers would both to support this? What programs would see any benefit from this.

Fifth off, there is no reason why 32-bit code or 64-bit code would not run on a 128-bit system despite what the author says about abandoning 32-bit altogether.

Finally, once again, your pointer size in applications would double once again. We are running on the extreme lower end of 64-bit as it is. Why would we want to increase our memory usage in programs once again?

I would go so far as to say that we will not even hear 128-bit architectures mention in the next 20 years and quit probably longer.

-Kevin

Edit: Additionally, did I add that it is impossible to program for 128-bit. There is no ISA capable of creating the appropriate assembly for such instructions because no one has created extensions for our existing ISA's!

 

[A5]

MS want a piece of the ever increasing netbook market. i have a sammy NC10 (atom), and is 32bit only but runs win 7 like a dream.

if win7 was 64bit only then i'd have to choose between vista and xp (linux is a no go), meaning it would run xp.

I'm sure Intel will make a 64-bit Atom by the time Windows 8 rolls around. We're going to have netbooks and MIDs with 4+GB of RAM by then.

 

[Nothinman]

Second off, we haven't fully moved over the 64 bit computing yet. So much so, that I believe on current chips, we are still limited to 48-bit memory addressing for the simply fact that we are NO WHERE REMOTELY CLOSE to needing 18 EB's of RAM.

And that 48-bits is virtual, the CPU in my home machine only does 40-bits physical. I think the amount varies a bit between models and vendors but AFAIK none support the full 64-bits virtual or physical yet.

Fourth off, what would be one reason to push something along like this? I would love to see significant examples of values that 64bit registers or the soon to be made 128-bit vector registers cannot handle. What programmers would both to support this? What programs would see any benefit from this.

Yea, they would be better off either adding another group of registers and set of instruction extensions to use them or just more GPRs and a CPUID flag to tell whether they exist or not. Although the latter would probably be a compatibility nightmare from a compiler standpoint.

 

[tommo123]

I'm sure Intel will make a 64-bit Atom by the time Windows 8 rolls around. We're going to have netbooks and MIDs with 4+GB of RAM by then.

but waiting means they miss potential profit, not to mention allowing linux to get a decent share of that market in the meantime (poss meaning that users may start using it on their desktops instead of windows).

 

[Gamingphreek]

And that 48-bits is virtual, the CPU in my home machine only does 40-bits physical. I think the amount varies a bit between models and vendors but AFAIK none support the full 64-bits virtual or physical yet.



Yea, they would be better off either adding another group of registers and set of instruction extensions to use them or just more GPRs and a CPUID flag to tell whether they exist or not. Although the latter would probably be a compatibility nightmare from a compiler standpoint.

Yea I don't know that anything in the x86 world supports all 64bit. I would imagine the in the EPIC or perhaps the SPARC architecture might. Haha - Wow 'only' 40 bit Just over 1TB of addressable memory then....

Yea that would be a compiler nightmare wouldn't it? Having to rewrite all the access functions, all the math functions, create new data types, redo pointers.... ugh.

-Kevin

 

[Nothinman]

Yea I don't know that anything in the x86 world supports all 64bit. I would imagine the in the EPIC or perhaps the SPARC architecture might. Haha - Wow 'only' 40 bit Just over 1TB of addressable memory then....

Yea that would be a compiler nightmare wouldn't it? Having to rewrite all the access functions, all the math functions, create new data types, redo pointers.... ugh.

-Kevin

Well gcc already has a few dozen architecture specific switches for x86 to enable/disable stuff so chances are it would be as simple as adding another one to access the new GPRs, but I doubt it would be worth it.

 

[MStele]

I want to add that it is possible to run 128-bit software using 2 64-bit processors strapped together. A quad core cpu can easily be used in this way to create a dual core 128-bit setup. Even though its possible, there is no apparent use for it because 64-bit provides plenty of overhead for many years to come. Specialized computers that need 128+ bits can always be developed on a per need basis, so end users will likely never see it for a very long time.

 

[Gamingphreek]

I want to add that it is possible to run 128-bit software using 2 64-bit processors strapped together. A quad core cpu can easily be used in this way to create a dual core 128-bit setup. Even though its possible, there is no apparent use for it because 64-bit provides plenty of overhead for many years to come. Specialized computers that need 128+ bits can always be developed on a per need basis, so end users will likely never see it for a very long time.

....No. This isn't even remotely close to right.

 

[JimKiler]

MS want a piece of the ever increasing netbook market. i have a sammy NC10 (atom), and is 32bit only but runs win 7 like a dream.

if win7 was 64bit only then i'd have to choose between vista and xp (linux is a no go), meaning it would run xp.

That is why I went with the MSI u210 with the AMD Neo which does do 64 bit but my free upgrade to Win7 is 32 bit.

 

[MStele]

....No. This isn't even remotely close to right.

This is what I meant. I apologize if I didn't explain what I meant clearly.

http://www.anandtech.com/showdoc.aspx?i=2939&p=3

"In the K8 architecture AMD can execute two SSE operations in parallel; however the SSE execution units are only 64-bits wide. For 128-bit SSE operations, the K8 had to handle them as two 64-bit operations. This also means that when a 128-bit SSE instruction is fetched, it is first decoded into two micro-ops (one for each 64-bit half of the instruction), thus taking up an extra decode port for a single instruction."

If you had two such processors, I would imagine each could run half the process and thus when used in tandem quasi 128-bit. I realize its inefficient to run this way i'm just saying it could be done, not should be.

If i'm misunderstanding how this tech works, please let me know. I'm willing to learn.

 

[Nothinman]

This is what I meant. I apologize if I didn't explain what I meant clearly.

http://www.anandtech.com/showdoc.aspx?i=2939&p=3

"In the K8 architecture AMD can execute two SSE operations in parallel; however the SSE execution units are only 64-bits wide. For 128-bit SSE operations, the K8 had to handle them as two 64-bit operations. This also means that when a 128-bit SSE instruction is fetched, it is first decoded into two micro-ops (one for each 64-bit half of the instruction), thus taking up an extra decode port for a single instruction."

If you had two such processors, I would imagine each could run half the process and thus when used in tandem quasi 128-bit. I realize its inefficient to run this way i'm just saying it could be done, not should be.

If i'm misunderstanding how this tech works, please let me know. I'm willing to learn.

That just means that a process can use SSE to do math on 128-bit numbers. Generally, for a process to be called "128-bit" it needs to have 128-bits worth of VM space which will never happen with a 64-bit CPU.

 

[Cogman]

This is what I meant. I apologize if I didn't explain what I meant clearly.

http://www.anandtech.com/showdoc.aspx?i=2939&p=3

"In the K8 architecture AMD can execute two SSE operations in parallel; however the SSE execution units are only 64-bits wide. For 128-bit SSE operations, the K8 had to handle them as two 64-bit operations. This also means that when a 128-bit SSE instruction is fetched, it is first decoded into two micro-ops (one for each 64-bit half of the instruction), thus taking up an extra decode port for a single instruction."

If you had two such processors, I would imagine each could run half the process and thus when used in tandem quasi 128-bit. I realize its inefficient to run this way i'm just saying it could be done, not should be.

If i'm misunderstanding how this tech works, please let me know. I'm willing to learn.

You're pretty far off base here. The number of cores a processor has, has ABSOLUTELY nothing to do with its ability to process 128bit data segments. Heck with that logic, you could argue that processors are infinite-bit processors, they just have to step through each bit with 32/64bit segments.

Processors have seperate SSE registers that are 128 bits wide. SSE instructions work directly with these registers. A processor is considered x-bit based on how wide the general registers are, not how wide specialty registers are.

As has been stated, there is a close to zero benefit to switching to a 128 bit architecture right now. Sure, we could do really accurate math a little faster, or add big numbers faster. But those are really pretty worthless features in the grand scheme of things. The biggest benefit that 64bit CPU's brought was the ability to quickly access more then 4GB of memory.

 

[Gamingphreek]

You're pretty far off base here. The number of cores a processor has, has ABSOLUTELY nothing to do with its ability to process 128bit data segments. Heck with that logic, you could argue that processors are infinite-bit processors, they just have to step through each bit with 32/64bit segments.

Processors have seperate SSE registers that are 128 bits wide. SSE instructions work directly with these registers. A processor is considered x-bit based on how wide the general registers are, not how wide specialty registers are.

As has been stated, there is a close to zero benefit to switching to a 128 bit architecture right now. Sure, we could do really accurate math a little faster, or add big numbers faster. But those are really pretty worthless features in the grand scheme of things. The biggest benefit that 64bit CPU's brought was the ability to quickly access more then 4GB of memory.

Given that you were the person who introduced me to SSE/Compiler Intrinsics, naturally, I agree with everything you just wrote lol.

Also, I'm pretty sure I read somewhere that the latest Vector registers in the latest SSE revision are going to be increased to 256 - Just as a side note

 

[bamacre]

Sure, but not for many years. You can address 18 exabytes of RAM with 64bit addressing. It's going to be a long, long time before we have 18EB of RAM.

And with current memory prices, it's gonna be a while before most of us even run 24GB.