Talk:128-bit computing

Format based heading

--64.142.36.76 (talk) 20:57, 29 May 2008 (UTC) I'm not sure you need a crystal ball to see 128-bit processors... what about Cell (microprocessor) for example? -- Coneslayer 18:35, 2005 Apr 26 (UTC)

What about it? Vector processors have had 128-bit wide registers and data paths for several years (or stranger combinations like those present in the MIPS R5900-based Playstation 2 CPU, which lets you combine the high and low portions of registers for varying tasks). What is still a ways off is a 128 bit wide superscalar processor; for superscalar design having a bus and register width that large is wasteful for most tasks. The issue here is similar to the reason that a memory word in most scalar microcomputer architectures is 8 bits wide. -- uberpenguin 16:06, 2005 May 3 (UTC)

I've got here a copy of the VAX Architecture Handbook (title slogan: Architecture For The 80's), which defines an octaword as a 128-bit integer type, and there are even a couple of instructions which act on such quantities. --bjh21 22:05, 26 Apr 2005 (UTC)

Yeah, again, the concept isn't novel. The TIMI implemented in the System/38 on through the AS/400 is a true virtual implementation of a 128-bit machine, designed originally for use on 32-bit processors but in such a way that it would easily scale to newer designs for years to come (and that MI is still used in the brand-new iSeries you can buy today). -- uberpenguin 16:06, 2005 May 3 (UTC)

Uberpenguin, the point is that when this article was created, someone put a "speedy delete" tag on it, saying that "Wikipedia is not a crystal ball." My comment and bjh21's served to point out that the concepts on this page are relevant in the present. -- Coneslayer 16:21, 2005 May 3 (UTC)

Going double width will not double computing power. It will increase addressable memory space and allow higher precision arithemtics, but will not, in general, increase computing power. The last section is therefore unfactual and misleading. I suggest it is removed.

Todays move to 64 bit architecures is mostly about memory addressing. They increase in performance comes mostly from other changes such as adding more registers.

Not quite. Address width is not dependent upon data width. But you're right about it being a negligible performance advantage. (It's actually a penalty in some cases—i.e. moving small payloads in large containers.)
—überRegenbogen (talk) 06:50, 25 June 2010 (UTC)

Expert

here is a 128bit cpu:Emotion_Engine linux even run on it(because linux runs on the playstation2) —The preceding unsigned comment was added by 213.189.165.28 (talk • contribs).

We will never exceed the 64-bit address space. Even with superfast RAM and huge memory bandwidth, it would take thousands of years to just clear (write a 0) to every location of an 64-bit address space. A transition to 128-bit might happen for other reasons though. Large address spaces can be used to "hide" pages, instead of using an MMU to enforce memory safety. It would take an attacker decades (or a lot of luck) to find the pages of another process.

Reply: What about when 64 bit VMs are hosted? One thousand of them on a single machine, each supposedly granting a large amount of address space. --64.142.36.76 (talk) 20:57, 29 May 2008 (UTC)

A 128-bit virtual address space could be useful, even if a 128-bit physical address space isn't. It's the virtual address space that determines the important things in the software world like pointer sizes. --Doradus (talk) 16:57, 5 August 2008 (UTC)

Pleb

"Expert"'s comment above assumes sequential memory access. I can imagine (and probably show) system designs where a process can, will and should exceed 2^64 address bits for regular memory access. This will and does require parallel (non sequentially-dependent) memory access, irrelevant of MMU or potential hacks. IMHO, address-length constraints will "go away" as we require more content-related - non-address-based - data access.

To tie address-space bit-count to ALU word-length is as a result of at least:

• processor construction constraints;
• programmers' desire for (C-type) pointers;
• consumer-level marketing.

It's not even necessary for pointers in high level languages. C handles 24 and 20 bit pointers just fine when compiling for 16-bit CPUs, such as the 65816, 80286, and 8086/8088. Likewise with 16-bit pointers on 8-bit CPUs, like the 6502 and Z80. The resulting machine code is just slightly more complex.
—überRegenbogen (talk) 06:30, 25 June 2010 (UTC)

Boiling the oceans is irrelevant

Just because we can't completely fill a 128-bit address space doesn't mean it can't possibly be useful. A sparse address space could conceivably be very useful. A machine with, say, just 1 GB of physical memory could make use of more than 128 bits of address space. How? I don't know. But I don't have to know; I'm not the one adding speculative remarks to the article. --Doradus 21:37, 29 September 2006 (UTC)

Paragraph about "128-bit consoles" was removed

This really has no place here. The consoles were referred to as "128-bit" because of their graphics memory bus width, not because of their 128-bit processor. The Nintendo 64 has a graphics memory bus width of 64-bits, it doesn't have a 64-bit CPU.

The paragraph was "The sixth generation of game consoles, released in 2000 and 2001 and including the Playstation 2, GameCube and Xbox, is sometimes incorrectly referred to as "the 128-bit era" as the Gamecube and Xbox both used 32-bit CPUs, while the Playstation 2 used a 64-bit CPU. As of January 1, 2008, no video game consoles using 128-bit CPUs have been announced."

But the 7 "co"-processors (SPE's) in the Cell processor is more-or-less pure 128-bit SIMD, as far as I know. However, they are not used for general purpose processing, but more like *graphic cards* or whatever. Read it yourself :b? Crakkpot (talk) 13:07, 23 February 2008 (UTC)

128-bit SIMD doesn't equal one big 128-bit value, since it is two or more smaller values being stored in one bigger register. Rilak (talk) 09:16, 24 February 2008 (UTC)

Uses: IPv6

Meeek :P This is a joke. Read the RFC :) Should it be allowed to continue exist? I vote yes. It is awesome ;) Crakkpot (talk) 13:01, 23 February 2008 (UTC)

128 bit will probably useful for various things, but anything more would probably be created for esoteric/security purposes. BioTube (talk) 23:27, 4 August 2008 (UTC)

Memory impossible because of space?

I would like to know why the statement was added that 2^^128 bytes of memory will never be buildable? Who says it will have to be real RAM? With a 128-bit system for example all hard drives, network volumes and external storage volumes might be memory mapped for example. And mind you, People never thought about Y2K , the 2063 problem or other things... —Preceding unsigned comment added by 128.135.208.32 (talk) 19:27, 31 October 2008 (UTC)

Windows 8 and "AMD128"

Microsoft is working with Intel, AMD, HP and IBM to offer support IA-128 (in development) on Windows 8 and Windows 9.

That's no source, that's a mix of blog vanity and corporate shilling 70.53.136.14 (talk) 23:04, 7 October 2009 (UTC)

To quote the reference: A LinkedIn profile, which has already been taken down, for a Robert Morgan, Senior Research & Development at Microsoft, has shone a sliver of light on the possibility of 128-bit support coming to Windows 8.

This wouldn't constitute a valid source even if WP had less strict demands for reliability. Adrianwn (talk) 19:12, 8 October 2009 (UTC)

It seems that the only "source" for that claim is a deleted entry on a social networking site, all other references go to various blogs containing mostly speculation. Neither Microsoft nor Robert Morgan have confirmed this rumour. So please, before you add this stuff again, get some reliable sources. Adrianwn (talk) 17:14, 24 October 2009 (UTC)

This rumor still seems to exist although it is false, but any statement refuting it would probably be OR, and simply mentioning the rumor without refuting it would lend to much credibility to it. If you disagree, please state your reasons here. Adrianwn (talk) 05:59, 26 April 2010 (UTC)

There are no plans to create 128-bit processor yet and I doubt that at least one will appear in the next century. The market hasn't even completed transition to 64-bit. These sources might be talking about 128-bit SIMD support, but this is already included in all versions of Windows supporting x86-64. Thus I considered that statement in the article plainly nonsense and removed it. 1exec1 (talk) 12:15, 10 August 2010 (UTC)

Address width is not dependent upon data width

In the Uses section, "128-bit processors would allow memory addressing for..." confuses two separate issues

64 bit computing is not about memory capacity. 64 bit address buses could exist in systems with smaller data widths. Whilst it is convenient to be able manipulate pointers as units, data and addresse width are not interdependent.

There have been many CPU architectures with wider address buses than data buses. The computing world before the late 1980s was dominated by them (65816, 80286, 8086, 6502, 6800, Z80, 8080, 8008, 4004, ...). The catch was that pointers had to be handled in pieces or constricted to segments. 64 bit word and address widths happened coincidentally because it was convenient—not necessary.
—überRegenbogen (talk) 05:59, 25 June 2010 (UTC)

lot of bits

128 is a lot of bits!--NASCAR I am (talk) 02:39, 29 December 2010 (UTC)