Jump to content

Talk:128-bit computing

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by SineBot (talk | contribs) at 22:57, 9 November 2012 (Signing comment by Jimw338 - "Clarification to lead paragraph: new section"). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
WikiProject iconComputing Start‑class High‑importance
WikiProject iconThis article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
StartThis article has been rated as Start-class on Wikipedia's content assessment scale.
HighThis article has been rated as High-importance on the project's importance scale.
Taskforce icon
This article is supported by Computer hardware task force.

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)[reply]

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)[reply]

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 (talkcontribs).

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)[reply]

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)[reply]
All of you need to read WP:NOTAFORUM. Anyhow, Emotion Engine isn't 128-bit. Read about it's details-no it's not 128-bit. — Preceding unsigned comment added by Jasper Deng (talkcontribs) 04:49, 29 December 2010 (UTC)[reply]

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)[reply]


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)[reply]
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)[reply]


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. [1]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

AS/400

This article says:

The AS/400 virtual instruction set defines all pointers as 128-bit.

while the AS/400 article says:

The IBM System i's instruction set defines all pointers as 48-bit.

which is true? —Preceding unsigned comment added by 213.61.9.74 (talk) 15:38, 28 February 2011 (UTC)[reply]

On the AS/400, pointers are 128-bit, but physical addresses were 48-bit, and now 64-bit. 70.239.13.84 (talk) 09:51, 28 May 2011 (UTC)[reply]

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)[reply]

Grammar

I've noticed many grammar errors regarding the use of plural nouns, like IPv6 addresses. You don't say:

  • The length of IPv6 address...

Instead, say:

  • The length of a IPv6 address...

or

  • The length of IPv6 addresses...

I fixed some of these errors. Please watch out for them.Jasper Deng (talk) 06:11, 23 February 2011 (UTC)[reply]

Clarification to lead paragraph

I made a clarification to the lead paragraph, changing the following:

   There are currently no mainstream general-purpose processors built to operate on 128-bit integers or addresses,
   though a number of processors do operate on 128-bit data. The IBM System/370 could be considered the first
   rudimentary 128-bit computer as it used 128-bit floating point registers. Most modern CPUs feature SIMD
   instruction sets (..)

to

   While there are currently no mainstream general-purpose processors built to operate on 128-bit integers or addresses,
   a number of processors do have specialized ways to operate on 128-bit chunks of data. The IBM System/370 could be
   considered the first rudimentary 128-bit computer, as it used 128-bit floating point registers. Most modern CPUs feature
   SIMD instruction sets (SSE, AltiVec etc.) where 128-bit vector registers are used to
   store several smaller numbers, such as four 32-bit floating-point numbers. A single instruction can then operate on all
   these values in parallel. However, these processors do not operate on individual numbers that are 128 binary digits in length,
   only their registers have the size of 128-bits.

Is this correct? (Is there a "simple" text-box formatting wiki-markup that follows HTML syntax such as <box wrap=true> whatever text </box> ? — Preceding unsigned comment added by Jimw338 (talkcontribs) 22:55, 9 November 2012 (UTC)[reply]

  1. ^ "Microsoft mulling 128-bit versions of Windows 8, Windows 9". Eightforums Blog. October 7, 2009.