Talk:128-bit
From Wikipedia, the free encyclopedia
Contents |
[edit] Format based heading
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.
[edit] 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.
[edit] 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. ==
[edit] 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. --P3d0 21:37, 29 September 2006 (UTC)
