• Competitor rules

    Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.

128 bit cpus?

even of 128bit comes out in the next two years, not much hard and software support 64bit, so that'll take a lot of catching to get to 128bit....
+windows 8 won't be released in 2012, thats far to close.
windows 7 only just got released, and its life span should be a minimum of 4 years, maybe longer since whats his face left microsoft.
 
The key point of 64bit versus 128bit isn't RAM, it's the fact that the CPU can operate on 128bits of data in one cycle, rather than multiple cycles if it had to do it in 64bit chunks.

I understand that however x86-64 processors have shown the ability to time and time again outperform nearly every other design 64, 128 and 256bit alike, to the point where high end use is now almost exclusively amd/intel barring legacy systems (see top 500 for examples). Keeping all the extra overheads in mind you could actually lose performance making the switch.

x86-64 ended up giving a boost (~10%) however this was largely because of the massive penalties accessing ram above 2gb on x86 (This is including virtual memory, video memory, system memory etc). Ridiculous and I mean ridiculous overhead; orders of magnitude slower access times. There are no such limitations that x86-64 suffers from. Another thing to Keep in mind: Without hugely increasing CPU cache it would effectively become useless going from 64 > 128. Increasing cost and heat massively. I could be wrong, but I really don't see the huge benefit (other than to sell more chips). Call me a cynic if you want.


They're full 64bit.
Kind-of. They can only access 40bits of ram. They are otherwise fully 64bit, but then that wouldn't be fully, would it?
 
Last edited:
Kind-of. They can only access 40bits of ram. They are otherwise fully 64bit, but then that wouldn't be fully, would it?
They are fully 64bit, they have full 64bit data paths, can process 64bit data with a single instruction, they can even access multiples of 64bits of RAM. LGA1366 chips can access 192bits of RAM at the same time for example.
 
They are fully 64bit, they have full 64bit data paths, can process 64bit data with a single instruction, they can even access multiples of 64bits of RAM. LGA1366 chips can access 192bits of RAM at the same time for example.

I think we're refering to two different things. I'm referring to the virtual address space, which they do not have a true 64 bit implementation of. I was merely pointing out they are not "true 64 bit" in all regards (as you seemed to be suggesting).
Source:
http://en.wikipedia.org/wiki/X86-64#Virtual_address_space_details

"Virtual address space details
Although virtual addresses are 64 bits wide in 64-bit mode, current implementations (and any chips known to be in the planning stages) do not allow the entire virtual address space of 16 EiB (18,446,744,073,709,551,616 bytes) to be used. Most operating systems and applications will not need such a large address space for the foreseeable future (for example, Windows implementations for AMD64 are only populating 16 TiB (17,592,186,044,416 bytes), or 44 bits' worth), so implementing such wide virtual addresses would simply increase the complexity and cost of address translation with no real benefit. AMD therefore decided that, in the first implementations of the architecture, only the least significant 48 bits of a virtual address would actually be used in address translation (page table lookup). However, bits 48 through 63 of any virtual address must be copies of bit 47 (in a manner akin to sign extension), or the processor will raise an exception. Addresses complying with this rule are referred to as "canonical form." Canonical form addresses run from 0 through 00007FFF`FFFFFFFF, and from FFFF8000`00000000 through FFFFFFFF`FFFFFFFF, for a total of 256 TiB (281,474,976,710,656 bytes) of usable virtual address space.

This "quirk" allows an important feature for later scalability to true 64-bit addressing: many operating systems (including, but not limited to, the Windows NT family) take the higher-addressed half of the address space (named kernel space) for themselves and leave the lower-addressed half (user space) for application code, user mode stacks, heaps, and other data regions. The "canonical address" design ensures that every AMD64 compliant implementation has, in effect, two memory halves: the lower half starts at 00000000`00000000 and "grows upwards" as more virtual address bits become available, while the higher half is "docked" to the top of the address space and grows downwards. Also, fixing the contents of the unused address bits prevents their use by operating system as flags, privilege markers, etc., as such use could become problematic when the architecture is extended to 52, 56, 60 and 64 bits."

The current virtual address space implementation is 48bit.
 
Ah ok I see what you mean, I thought you were making claims like Atari did over the Jaguar on the basis some registers were 64bit.

The data width is what determines whether it's a CPU is 64bit, not the depth of RAM addressing or other aspects of CPU design where they aren't 64bit (as many busses are going serial now). Indeed, 64bit addressing is somewhat overkill considering the amount of RAM required to make use of it is of roughly the same order of magnitude of the total amount of RAM, in all the desktop PCs in the world.
 
The key point of 64bit versus 128bit isn't RAM, it's the fact that the CPU can operate on 128bits of data in one cycle, rather than multiple cycles if it had to do it in 64bit chunks.

Yes, but the size of a 64bit integer is pretty huge, its not a major limitation for even the scientific world. Apparently the 80bit floats from the x87 copro dont even work in 64bit mode, so scientific apps in 64bit mode should be using SSE, which is already capable of 128bit math. (Note: Pentium 4 used to have to break 128bit SSE instructions into 2x64bit chunks, but Core 2/i3/i5/i7 do not)

So in reality our processors are already 128bit, and infact able to execute many 128bit SSE instructions in a single clock cycle.

I dont see a 128bit "general purpose" cpu any time soon, and certainly not for the next version of windows.
 
Yes, but the size of a 64bit integer is pretty huge, its not a major limitation for even the scientific world. Apparently the 80bit floats from the x87 copro dont even work in 64bit mode, so scientific apps in 64bit mode should be using SSE, which is already capable of 128bit math. (Note: Pentium 4 used to have to break 128bit SSE instructions into 2x64bit chunks, but Core 2/i3/i5/i7 do not)

So in reality our processors are already 128bit, and infact able to execute many 128bit SSE instructions in a single clock cycle.

I dont see a 128bit "general purpose" cpu any time soon, and certainly not for the next version of windows.
Only Atari would claim that they were 128bit :p
 
On the topic of Microsoft: Was there a 13th Microsoft Office? I was told that there wasn't and that they skipped to Office 14 because they had Triskaidekaphobia (fear of the number 13)
 
The data width is what determines whether it's a CPU is 64bit, not the depth of RAM addressing or other aspects of CPU design where they aren't 64bit (as many busses are going serial now). Indeed, 64bit addressing is somewhat overkill considering the amount of RAM required to make use of it is of roughly the same order of magnitude of the total amount of RAM, in all the desktop PCs in the world.

Actually the cpu makers generally consider the width of the general purpose integer registers, coupled with a 64bit instruction set in the ALU to be the deciding factor on how a cpu is marketted.

Intel 8088 16bit GP registers, 8bit data bus to motherboard, 20bit memory bus (able to access 1024k ram). Considered a 16bit processor

Intel 8086 16bit GP registers, 16bit data bus, 20 bit memory address bus. 16bit processor

Intel 80286 16 bit GP registers, 16bit data bus, 24bit memory address bus, able to access 16MB ram, still considered 16bit processor.

Intel 80386 32bit GP registers, 32bit data and address buses, able to access 4GB ram, considered 32bit processor.

Motorola 68000 is a bit of an oddball, as it has 16bit databus, 25bit address bus, 32bit registers, but most of the CPU's instructions were only 16bit, so most of the time the 32bit registers were not fully utilized. Its considered a 16/32bit hybrid.

Anyway, kinda off topic now. In the intel / amd world a 64bit processor is an CPU which has 64bit wide general purpose registers, and a full compement of 64bit instructions in the ALU. AMD64, and EM64T are absolutely 64bit designs.

As I mentioned earlier, the x87 co processors (which are integrated into modern cpus) are actually build on 80bit registers, and can technically be used to processess 64bit integers, and the SSE coprocessors are 128bit... But the standard that is followed is based on a CPUs ALU.
 
Motorola 68000 is a bit of an oddball, as it has 16bit databus, 25bit address bus, 32bit registers, but most of the CPU's instructions were only 16bit, so most of the time the 32bit registers were not fully utilized. Its considered a 16/32bit hybrid.

The registers were fully utilised. MOVE commands took 2 reads to fill the register from RAM. ADD/SUB etc... worked on the full 32 bits.
I admit, I used to stick to 16 bit numbers as much as possible to speed up the code.... You could often work on 2 16 bit numbers at the same time if you were careful, early SIMD :)

Then there's the 68008, same basic design as the 68K but with an 8 bit data bus.... Was used in the sinclair QL. 2 reads to get the instruction, 4 to fill a register, boy was it slow!

The 56000 is also worth mentioning, 24 bit bus and 2 56-bit accumulators :)
 
Back
Top Bottom