95

In an 8-bit microprocessor its data bus consists of 8 data lines. In a 16-bit microprocessor its data bus consists of 16 data lines and so on.

Why is there neither a 256-bit microprocessor nor a 512-bit microprocessor? Why don't they simply increase the number of the data lines and create a 256-bit microprocessor or a 512-bit microprocessor?

What is the obstacle that prevents creating a 256-bit microprocessor or a 512-bit microprocessor?

Community
  • 1
Michael harris
  • 1,155
  • 2
  • 9
  • 8
  • 20
    Even marketing can't just keep increasing a number forever. – Olin Lathrop Oct 04 '12 at 13:11
  • 1
    "... its data bus consists of ..." Not so true these days... – Ignacio Vazquez-Abrams Oct 04 '12 at 13:30
  • 86
    Why is there no 256 blade razor yet? – Rocketmagnet Oct 04 '12 at 15:30
  • @Rocket: Wait a few more years. I remember back in the 1970s when Gillette came out with the "Track 2". It was supposed to be some great new advance. Saturday Night Live did a spoof commercial of a "Track 3" with the slogan *because you'll believe anything*. Now we actually have a Track 3 (or whatever they actually called it). Apparently you really will believe anything. – Olin Lathrop Oct 04 '12 at 15:46
  • 11
    @OlinLathrop Checkout the [Gillete Fusion Power](https://en.wikipedia.org/wiki/Gillette_%28brand%29#Newer_products), with 5 blades and a battery! – Brendan Long Oct 04 '12 at 16:05
  • 8
    The answer is about the same as the one to this question: We have got 1 & 2 & 3 & 4 & 5 & 6 & 8 & 12 & 16 cylinder cars. Why do we not have 32 & 64 & 128 cylinder cars? – Russell McMahon Oct 04 '12 at 16:05
  • 3
    Why have we got cars? – Rocketmagnet Oct 04 '12 at 16:10
  • 14
    @Russell: Because there'd then be a global shortage of cylinders. – Olin Lathrop Oct 04 '12 at 16:13
  • 3
    @RussellMcMahon: who says we don't? Here is a Mini Cooper Diesel with 78 liters of displacement, eighteen cylinders, about 12 turbochargers, a mind-numbing 3,500 horsepower, and over 10,000 lb-ft of torque: http://www.topspeed.com/cars/car-news/mini-gets-stupefyingly-enormous-diesel-engine-to-make-appearance-at-goodwood-ar92857.html – jippie Oct 04 '12 at 19:13
  • 2
    @jippie - I like it. BUT it only has 18 cylinders :-). Not even up to the lowest on my list at 32 cylinders :-). – Russell McMahon Oct 05 '12 at 00:52
  • 1
    Interesting little tidbit on 128-bit microprocessors here: http://en.wikipedia.org/wiki/128-bit (since at least two have been designed but none exist in practice). – mikebabcock Oct 05 '12 at 06:32
  • 3
    "x-bit processor has x data lines." Nope. Intel's 8088, circa 1979 was a 16 bit proc with 8 data lines. Intel's 80386-SX, circa 1988, was a 32 bit proc with 16 data lines. Motorola (Freescale) 68000, circa 1979, 32 bit proc with 16 data lines. Motorola 68008, circa 1982 32 bit proc with 8 line data bus. I am sure there are others. http://en.wikipedia.org/wiki/8088, http://en.wikipedia.org/wiki/80386SX#The_i386SX_variant, http://en.wikipedia.org/wiki/Motorola_68000, http://en.wikipedia.org/wiki/Motorola_68008 – Shannon Severance Oct 05 '12 at 23:43
  • Transmeta brought out a 256 bit processor a while ago. It emulated x86 so it could run standard apps. Can't speak for the performance of the 256 bit one, but the 128 bit one was a bit slow! http://en.wikipedia.org/wiki/Transmeta_Crusoe – Matthew Steeples Oct 07 '12 at 07:14
  • Because the market is not ready for them yet. Market acceptance is a very big deal for the finest product. – Chetan Bhargava Dec 22 '12 at 09:24
  • @OlinLathrop - Don't you mean a global shortage of _holes_? Those big shiny holes are expensive you know. – John U Mar 04 '14 at 11:39

10 Answers10

112

Think about it. What exactly do you envision a "256 bit" processor being? What makes the bit-ness of a processor in the first place?

I think if no further qualifications are made, the bit-ness of a processor refers to its ALU width. This is the width of the binary number that it can handle natively in a single operation. A "32 bit" processor can therefore operate directly on values up to 32 bits wide in single instructions. Your 256 bit processor would therefore contain a very large ALU capable of adding, subtracting, ORing, ANDing, etc, 256 bit numbers in single operations. Why do you want that? What problem makes the large and expensive ALU worth having and paying for, even for those cases where the processor is only counting 100 iterations of a loop and the like?

The point is, you have to pay for the wide ALU whether you then use it a lot or only a small fraction of its capabilities. To justify a 256 bit ALU, you'd have to find an important enough problem that can really benefit from manipulating 256 bit words in single instructions. While you can probably contrive a few examples, there aren't enough of such problems that make the manufacturers feel they will ever get a return on the significant investment required to produce such a chip. If it there are niche but important (well-funded) problems that can really benefit from a wide ALU, then we would see very expensive highly targeted processors for that application. Their price, however, would prevent wide usage outside the narrow application that it was designed for. For example, if 256 bits made certain cryptography applications possible for the military, specialized 256 bit processors costing 100s to 1000s of dollars each would probably emerge. You wouldn't put one of these in a toaster, a power supply, or even a car though.

I should also be clear that the wide ALU doesn't just make the ALU more expensive, but other parts of the chip too. A 256 bit wide ALU also means there have to be 256 bit wide data paths. That alone would take a lot of silicon area. That data has to come from somewhere and go somewhere, so there would need to be registers, cache, other memory, etc, for the wide ALU to be used effectively.

Another point is that you can do any width arithmetic on any width processor. You can add a 32 bit memory word into another 32 bit memory word on a PIC 18 in 8 instructions, whereas you could do it on the same architecture scaled to 32 bits in only 2 instructions. The point is that a narrow ALU doesn't keep you from performing wide computations, only that the wide computations will take longer. It is therefore a question of speed, not capability. If you look at the spectrum of applications that need to use particular width numbers, you will see very very few require 256 bit words. The expense of accelerating just those few applications with hardware that won't help the others just isn't worth it and doesn't make a good investment for product development.

Smi
  • 103
  • 4
Olin Lathrop
  • 310,974
  • 36
  • 428
  • 915
  • 11
    I hate to say it, but I disagree here. Let me contrive an example: Graphics rendering for video games. It's a little market you may have heard of worth 10s of billions of dollars. – Rocketmagnet Oct 04 '12 at 15:54
  • 42
    @Rocket: First, the OP asked about a *microcprocessor*, not a graphics processor. Second, graphics rendering doesn't require particularly wide words. Lots of smaller operations can be done in parallel, but I wouldn't call 8 CPU cores in parallel each working on 32 bit data a "256 bit" processor. Do you refer to your quad core PC as a "256 bit" processor just because each core can operate on 64 bit data natively? I think that's a misuse of the term, and even Intel marketing doesn't seem to be pitching multiple cores that way. – Olin Lathrop Oct 04 '12 at 16:03
  • 3
    In that case, still wrong. I'd call an Intel Pentium with MMX a *microprocessor*, and that has SIMD. This is *not* to be confused with 8 *cores*. SIMD is actually implemented by a wide ALU. Each core contains its own wide ALU capable of SIMD. – Rocketmagnet Oct 04 '12 at 16:09
  • 33
    @Rocket: SIMD is a different type of parallelism, but I still wouldn't call it a wide ALU, just a bunch of small ALUs run tightly in parallel. You can't do a 256 bit add with all the carries, for example, on such a SIMD processor. Parallelism is not the same as a wider ALU. You seem to be going out of your way to be contrary. Maybe you can argue wording about what is parallel versus wider, but to use unconventional definitions and then claim other interpretations are *staggeringly wrong* is just engaging in a pissing contest. – Olin Lathrop Oct 04 '12 at 16:18
  • 3
    An SIMD add instruction for example is identical to a very wide add instruction, except that the carry is broken at several points. – Rocketmagnet Oct 04 '12 at 16:26
  • 1
    +1 However, I would add to this answer that if you really need such operations, and you run algorithms which use such values, a **digital signal processor** might be a better choice, and they already exist. For such calculations I find a small DSP with SIMD capability (single instruction multiple data, useful for things like like vector multiplication) to be much more useful than a simple processor with a wider ALU. – vsz Oct 04 '12 at 17:15
  • 1
    @Rocketmagnet yes, and an Intel Pentium with MMX isn't a "128-bit CPU", it's 32-bit. :) – hobbs Oct 04 '12 at 19:00
  • @hobbs - No, it's just an early example of SIMD. However Intel's chips with [AVX](http://en.wikipedia.org/wiki/Advanced_Vector_Extensions) *are* capable of processing 256 bits of data in the ALU on each instruction, *for every core*. This makes them essentially 256-bit CPUs. This is a clear example of the fact that 256-bit CPUs make sense, and are being made for a market that wants them. This is why Olin is wrong. – Rocketmagnet Oct 04 '12 at 19:36
  • 16
    @Rocket: Just because the CPU can work on 256 bits at a time by doing a bunch of operations in parallel doesn't make it a "256 bit" CPU. That would imply it can actually work on 256 bit wide numbers directly, which it can't. As you said yourself, there is no carry between the separate parallel ALU units, which makes it not a 256 bit ALU. You seem to have a unusual definition of what the bitness of a CPU means. It's not the number of bits it can process at once, but the width of a word it can process as a whole. – Olin Lathrop Oct 04 '12 at 21:10
  • 2
    @OlinLathrop - You are too rigid in your thinking. There are many ways to define the bit width of a CPU, including address width, bus width, instruction width, register size, ALU width. It's quite reasonable to call a CPU 256 bit if it can collect two 256-bit packets from memory or registers, process them through a 256 bit wide ALU, and write 256 bits back. – Rocketmagnet Oct 04 '12 at 21:50
  • 20
    When I was in school, we were taught that software people measured the bitness in terms of the "logical" instruction set width, and that hardware people measured the bitness in terms of bus width. So, the 8088 was a 16-bit processor to software people, and an 8-bit processor to hardware people. The 8086 was 16-bit to everyone. Of course the marketing people would take the largest number they could find, so let's hope they don't read this comment thread and start marketing 512-bit CPUs! :-) – Mark Harrison Oct 04 '12 at 22:35
  • 4
    @Rocketmagnet Olin in his main answer covered exceptions like crypto (2000+ bit math operation, multiply, add) and graphics. SIMD is widely used for graphics it is a way to perform that type of math in parallel, but does not have a general purpose case. hand coded algorithms, etc. 32-64 bit is plenty for 99% of what we do, surf web pages full of text and images. Send messages to each other and troll forums. Outside these special purpose the cost is far to great for general computing, nobody would buy them. – old_timer Oct 05 '12 at 05:18
  • I'm not sure about if all the 256-bit combination would be that usefull, since using all that would require energy... http://en.wikipedia.org/wiki/Brute-force_attack#Theoretical_limits – woliveirajr Oct 05 '12 at 12:12
  • 1
    @woliveirajr: Many asymmetric-key cryptographic algorithms require the ability the ability to compute `(n1 * n2) mod n3`, where n1, n2, and n3 are all on the order of 1,000-4,000 bits. A processor with a large multiplier could be helpful for that. On the other hand, if one wishes to perform 4096x4096-bit multiplies, it may be faster and cheaper to subdivide them into 256 chunks each 4096x16, than 256 chunks each 256x256 (the former design could be pipelined to yield 16 bits of final result per cycle, with no carry chain longer than 32 stages). – supercat May 01 '13 at 15:05
  • "there have to be 256 bit wide data paths. That alone would take a lot of silicon area" - don't forget parasitic capacitance. Changing a 256-bit register from -1 to 0 would take a lot of juice. Which means a lot of waste heat. Which means louder fans, bulkier fans, fans that wear out sooner. You get it. – John Dvorak Jul 14 '20 at 15:04
34

Well, I don't know about 256 or 512 bit, but I've heard about a 1024 bit processor (I can't find it right now). The word is VLIW, for Very Long Instruction Word. So that's the instruction bus, not the data bus width. The advantages are that you can implement Instruction Level Parallelism (ILP) on a large scale.

My first encounter with ILP must have been 20 years ago with Motorola DSPs, which had instructions for performing a MAC (Multiply and ACcumulate) while moving data to and from memory, so that you could perform a new MAC on the next instruction, without wasting time between two MACs for moving data.
Today there are also general-purpose controllers offering this option. VLIW applies this at a much higher scale.

Since your data bus width won't be as wide you can have several instructions plus constants in an instruction. The reason why the data bus doesn't follow the trend is that it's pretty useless; a 64-bit data register can represent a 20 decimal digit number. When was the last time you needed 20 digits of accuracy? For most applications 10\$^{20}\$ = \$\infty\$.

Further reading
VLIW Architecture

hippietrail
  • 133
  • 5
stevenvh
  • 145,145
  • 21
  • 455
  • 667
  • most financial calculations :( running into this problem now – im so confused Oct 04 '12 at 14:47
  • I thought the x86 was a VLIW CPU. ;-) – Macke Oct 05 '12 at 05:51
  • 2
    @MarcusLindblom Only if by VLIW you mean Variable Length Instruction Words. ;-) – user Oct 05 '12 at 07:58
  • @MarcusLindblom: That's probably because it has Variable Length Instructions. One of the reasons it's still doing well; common instructions are shorter which benefits the code cache. – MSalters Oct 05 '12 at 08:01
  • @AK4749, You're running financial transactions that require 20 decimal digits? I'll gladly swap bank accounts with you, even if yours is denominated in Rupiah. – The Photon Oct 05 '12 at 15:59
  • @ThePhoton hahaha yeah, no one saw this coming a few years ago, so now we're stuck with using tricks such as dynamic rounding and whatnot to keep minuscule FP errors from accumulating over just a few years when amortizing – im so confused Oct 08 '12 at 14:17
  • @AK4749, accounting standards have a history that goes back way before computers were available at every bank branch. I think in the US, calculations are only done to 0.00001 cent (1/100 mil) or so. If you are doing finance, you should be using fixed point and use the rounding standards common in your country, not using floating point and trying to maximize precision beyond those standards. – The Photon Oct 08 '12 at 16:14
  • @ThePhoton Ah, but see that's where we have a misunderstanding. We deal with financial clients and their *predictions*. A 12 digit number before the decimal can throw off the after decimal value by as much as a hundredth on rare occasions involving replaying old transactions with different results. A single cent difference can project an extra 1+ trillion dollars over just a decade. Up-to-date accounting is a simple, exact science. Ours is not. – im so confused Oct 08 '12 at 16:29
  • 3
    @AK4749 In that case, your predictions are just as likely to be thrown off by the banks that handle your transactions using "real" accounting rules. Meaning if you go to execute a plan based on those rules, it's going to not give the expected results because the real banks will use the real accounting rules, not nano-cent precision. And of course because markets are uncertain. So if 1 cent error at the start gives $1 trillion error at the output, that $1 trillion is simulation effect only, not something your clients should be using to make plans with. – The Photon Oct 08 '12 at 16:41
  • 1
    Of course, they would never use decade-long predictions as a basis for current decisions, even I as a programmer would not be so foolish. However, (and to be clear, we've solved the divergent error problem so it doesn't exist) the largest clients do in fact require these types of capabilities for whatever nefarious purposes they choose not to divulge to their vendors. In addition, having worked in the financial space for a couple years, I can tell you that financial companies actually DO use higher precision calculations (1/2) – im so confused Oct 08 '12 at 16:48
  • (2/2) and if necessary, convert back to a lower precision when handing data over to a sector/subsidiary if they, for some reason, cannot cope with higher precision numbers. *Banking* is a separate space from *finance* and has a hugely different set of requirements as a result of having different goals. – im so confused Oct 08 '12 at 16:49
28

"Bitness" of a microprocessor is usually defined in terms of size of the general purpose registers. The size determines how large numbers a processor can handle natively and how much memory it can access. 64bit numbers are enough for almost any algorithm and the amount of addressable memory (16 million terabytes) is enough for quite some time to come. There simply isn't any advantage to increasing the size of the general purpose registers. On the flip side, the area of arithmetic logic units (ALU) used to perform operations on the registers scales with the square of the amount of bits. A 256bit ALU would be 16x larger and significantly slower.

On the other hand, there is point in widening the processor to make it possible to do many smaller operations at once. In fact Intel's Sandy Bridge and Ivy Bridge processors do just that, they have 256bit SIMD registers and can do two arithmetic operations and one memory operation per cycle on them. So one could justify calling them 256bit, or even 768bit processors, if one was a sneaky marketer wanting to bend regularly used terms.

Ants Aasma
  • 381
  • 2
  • 3
16

Firstly, the bit size of a processor is usually determined by the abstract architecture that is visible to the machine language programmer, not by implementation details like the size of the data bus.

For example, the Motorola 68000 is a 32 bit processor. It has 32-bit data registers and 32-bit address registers. Now, the first version of that architectural family only expose 24 bits of address lines. Furthermore, variants exist which have only an 8 bit data bus (so 32 bit memory operations are performed by the processor as multiple access cycles).

Now about the question, why not go to 256 and 512. Processors "natively" manipulate several kinds of data types, so it is helpful to look at what 256 or 512 bits means for each of these data types individually. We have integers, pointers and floating-point types.

  1. Integers: Programs get a lot of mileage out of 32 and 64 bit integers. If 64 bits is a limitation, the fix for that is to have software-implemented bignum integers. High level languages can implement integer types such that the operations smoothly shift between "fixnums" and "bignums". Of course you take a performance hit with bignums, but you have to consider that in the big picture: how many of the operations in a program are bignum operations. 256 or 512 bit numbers do not eliminate the need for bignums, they only increase the headroom before we have to switch to bignums. If you want to manipulate 2048 bit public keys, 512 bit integers will not do (but a bignum with 512 bit digits could be fast).

  2. Pointers: Wider pointers allow two things: wider address spaces, and additional meta-data stored in a pointer. Address spaces are virtual these days and so they can grow even if memories do not grow. It has been proposed that if you have 128 bit pointers, the address space is so vast that you can put all the user-space processes of an operating system, and the kernel, at random places in a single unprotected space, and they are unlikely to collide. Rather than simply creating a larger address space, fatter pointers can be used to carry bits which are not address bits, such as information about the referent object (type, size and other info) or security-related information. There is probably some "optimal fatness" for this kind of thing, and if I were to guess, I would still cap it at 128 bits. It doesn't seem to make sense to go to 256 bit pointers, never mind 512. Fatter pointers have a disadvantage: they bloat all data structures which contain pointers. And, generally, you want pointers to be the same size, otherwise you need complications in the instruction set architecture (like memory segments) whereby you then have full pointers (segment descriptor and offset) or just local pointers (offset within some understood segment).

  3. Floating-point types: More bits in floating point numbers means more precision. I would say that the floating-point types benefit the most from a wider representation. A 256 or 512 bit floating type will improve the stability of numeric code and the quality of scientific calculations that require many iterations, and accumulate errors along the way. Precision in floating-point is not the same as precision in integers: we cannot separate the floating point type into ranges like fixnums versus bignums. More precision in floating point affects the quality of all inexact numbers, whether they are close to zero or have a large magnitude. More bits in floating point exponents can also vastly extend the range of floating point numbers, and much faster than adding bits to a bignum integer.

For these reasons, I suspect that the predominant future trend will be increases in the width of hardware floating-point numbers, not necessarily followed by increases in the widths of pointers and integers.

Remember that floating-point numbers have already been ahead of the other types in the past. For instance, for a while we had a predominance of 32 bit processors supporting 64 bit IEEE double floats. This is because while you can do a lot with 32 bit pointers and integers, 32 bit floats are very limited for any serious numeric work.

One very, very useful feature that would be nice to see emerge in floating-point representations would be a few spare bits for a type tag. Implementing floating-point types in dynamic, high-level languages (in which objects have type, but storage locations hold values of any type) is a struggle because whereas spare bits can be found in pointers and integer-like objects to put parts of an identifying type tag, this is difficult to do with floating-point numbers. So what often ends up happening is that floating-point numbers get heap-allocated. Some schemes steal bits from the mantissa, so then floating-point types in that language lose precision compared to floats in other languages on the same machine.

Kaz
  • 19,838
  • 1
  • 39
  • 82
  • Nice description. By the way, the common x86 processors have had 80 bit floating point for a long time, since the first hardware floating point unit for them if I remember right. The 80 bits is internal to the FPU, then generally 32 or 64 bits are exported. – Olin Lathrop Oct 04 '12 at 18:43
  • Technically, already done. Google "nan boxing" or "nun boxing". What's more promising is hardware type tags in 64-bit ARMs, but that won't be soon unfortunately. – Catherine Oct 04 '12 at 21:16
  • 3
    It was possible to access the 80 version directly. Back in the 90s when I was learning to program in TurboPascal there was an 80bit float type. – Dan Is Fiddling By Firelight Oct 05 '12 at 13:28
  • @DanNeely: I've sometimes thought that processors would benefit from 3d-coordinate floating-point types, combining either three 80-bit numbers into a 256-bit chunk, or three 42-bit numbers into a 128-bit chunk, or three 21-bit numbers into a 64-bit chunk. I wonder how hard such a thing would be to implement, and how useful it might end up being? – supercat May 01 '13 at 22:44
  • @supercat GPGU Wikipedia: *Most operations on the [NVidia] GPU operate in a vectorized fashion: one operation can be performed on up to four values at once. For instance, if one color is to be modulated by another color , the GPU can produce the resulting color in one operation.* – Kaz May 01 '13 at 23:36
  • @Kaz: My question was predicated on the observation that while 256 bits would be enough to store only two 80-bit values that were padded out to 128 bits each, padding triplets out to 256 bits would yield better storage/bus/cache efficiency, and numbers often are used in triplets. I miss the 80-bit hardware floating-point types that my Borland compilers used to support, and would like to see them used more. Further. 40ish bit types would be better than 32, and 20ish better than 16, in cases needing small formats for XYZ values. – supercat May 02 '13 at 14:42
10

It doesn't actually help you do anything useful. 64 bit numbers give you enough precision for almost all purposes (Intel systems have 80-bit floating point, though), but the extra lines increase cost and power consumption while having a small negative impact on clock speed.

Historically CPUs use the minimum number of bits that makes practical sense for their intended purpose. With the advances in technology wider buses and ALUs became possible, hence the increase in bus size to serve wider applicability:

  • 4 bits: enough for a digit, hence practical for (BCD-style) calculators, cash registers, etc. (which is a rather limited area)
  • 8 bits : enough for an (ASCII) character, practical for text-processing systems (which is a VERY wide area), also for low-quality sound
  • 16 bits : when 16-bitters were popular 2^16 memory addresses was a reasonable amount (at least much more reasonable than 2^8 or 2^32). 16 bits yields a quite acceptable audio quality, and most A/D converters yield less than 16 bits of result, hence calculating with such values in 16 bits makes sense
  • 32 bits : 32 bits fits the accuracy of most (but not all) human-measured quantities, and unless you are dealing with large databases 2^32 addresses were adequate for most practical purposes.
  • 64 bits : having > 2^32 bytes of memory now practical.
  • 128 bits : at this moment little advantage over 32, except in cryptography. When do we expect more than 2^64 bytes on a hard disk? probably not soon.
hippietrail
  • 133
  • 5
pjc50
  • 46,540
  • 4
  • 64
  • 126
  • You probably need to read stevenvh's links and do more research before you say that. – Rob Oct 04 '12 at 13:36
  • 2
    “640K ought to be enough for anybody.” -Bill Gates (1981) – jippie Oct 04 '12 at 19:35
  • 6
    @jippie - Gates never actually said that. – Rocketmagnet Oct 04 '12 at 22:07
  • @Rocketmagnet I thought that was true as well, but I guess you're right http://www.wired.com/politics/law/news/1997/01/1484 – kenny Oct 05 '12 at 00:50
  • 1
    Actually most 8-bit CPUs were able to address 2^16 bytes of memory, and 16 bitters 2^32, the 80386 (32 bits) could in theory also address 2^64 bytes (4GB) of memory which would have been pretty useless in those days anyway... – Axel Oct 05 '12 at 06:03
  • @Rocket - It belongs in the list of Famous Quotes Which Are Not True, like "Play it again, Sam", which Bogart never said either. – stevenvh Oct 05 '12 at 06:59
  • 1
    @Axel - the 16-bit 8086 could only address 2\$^{20}\$ bytes of memory, and when they found out that wasn't enough they had to come up with horrible things like extended and expanded memory managers. – stevenvh Oct 05 '12 at 07:03
  • @stevenvh The 8086 came out in **1978** (design efforts began a few years earlier), at which time 1 MiB of RAM must have seemed about as extreme as 4 GiB of RAM looked when the 80386 debuted in 1985-1986. Compare the TRS-80 which initially shipped with **4 KiB** of RAM in 1977. Today, having more than 4 GiB of RAM is commonplace even in low-to-medium-end home PCs (my PC at home has 32 GiB of RAM, which was almost inconceivable even as secondary storage for anything resembling a PC around the time the 80386 was introduced and a perhaps 100 MB hard drive was considered large). – user Oct 05 '12 at 08:17
  • Yes, I remember the days... not everything was better back then ;-) – Axel Oct 05 '12 at 08:18
  • @MichaelKjörling: Not sure if 100MB hds even existed back then. FAT could only reasonably handle partitions up to a certain size, and the number of partitions per disc wasn't unlimited either. First computer with a harddisk I saw had incredible 10MB (IBM XT). No one knew what to do with that much storage at the time... – Axel Oct 05 '12 at 08:27
  • @Axel - my first PC had a gigantic 80 MB hard disk, which I had to partition into two 32 MB and a 16 MB partition, since 32 MB was the maximum DOS could handle. – stevenvh Oct 05 '12 at 08:29
  • @Axel That's kind of my point. A 386-based PC we had at home somewhere around that time had a 40 MB hard disk, as I recall. I know there were larger disks targetted towards the high-end and network server market, but I don't know if 100 MB drives were in existence back then. However, that's beside the point, which was that such a drive would have been considered large then, in contrast to the fact that these days, many home PCs have several GB of **RAM**. – user Oct 05 '12 at 08:30
  • Actually, Wikipedia mentions for Nov 1985 "many 40- and 80-megabyte disks were in use" [source](http://en.wikipedia.org/wiki/Timeline_of_DOS_operating_systems) (about half way down on the page) – user Oct 05 '12 at 08:35
  • 3
    @Michael - it's of all times, and I've seen it throughout all my career: there are very few really visionary product managers out there. Anecdote: early 1970s, at a lecture by Robert Noyce about the future of microprocessors he predicts the current miniaturization, and someone in the audience says: "Damn, I wouldn't want to lose a whole computer in a cranny in the floor." Upon which Noyce replied contemptuously: "You don't understand it at all. You don't care about that one you lost; you'll have thousands of others". That was early 1970s. Robert Noyce was a visionary. – stevenvh Oct 05 '12 at 08:54
  • @Michael - The 8-bit 6809 processor had a companion MMU chip, the 6829, which could address 2 MB. For an 8-bitter, before 1980. – stevenvh Oct 05 '12 at 08:56
  • @stevenvh This is starting to look like extended discussion, but of course you can come up with an architecture to allow addressing more memory even with a low-bitcount CPU. I was saying that with the memory sizes of the time and how the 8086 was likely envisioned to be used, it might not have been an important design criteria to be able to use such vast amounts as more than 1 MiB of RAM directly. This was resolved when the 80286 came out in 1982 and was able to directly address 16 MiB of RAM, but very few DOS applications took advantage of that ability, and few PCs had that much RAM. – user Oct 05 '12 at 11:40
  • If my calculations are correct, 64 bits is enough to specify the size of the universe to the nearest Planck length! – Rocketmagnet Oct 08 '12 at 13:34
  • @Rocket - Diameter observable universe: 46 billion light years. 1 light year = 9.5 x 10^15 m. -> universe is 4.4 x 10^26 m, = 2^88 m, which is already larger than 2^64. In Planck lengths: 2.7 x 10^61 = 2^204. Looks like we'll need that 256 bit processor after all! :-) – stevenvh Oct 11 '12 at 09:24
  • @stevenvh - Damn Windows calculator! Apparently it's got a maximum binary number length of 64 digits. I thought it sounded too amazing to be true. – Rocketmagnet Oct 11 '12 at 11:00
9

Actually, such processors exist and are common, depending on how you define the bitness. You're almost certainly using one now. As Olin explained, there's not a great deal of use for 256-bit numbers, but what about 4 x 32-bit numbers? What if the ALU could add 4 pairs of 32-bit numbers at the same time. Such ALUs (that I know of) were first implemented in vector supercomputers in the 1970s. The first time I ever owned such a computer was when I had one of the Intel Pentiums with MMX.

Intel MMX guy

Remember those guys?

The MMX chips had a Single Instruction - Multiple Data instruction set (SIMD), allowing you to add 1×64-bit pair, 2×32-bit pairs, 4×16-bit pairs or 8×8-bit pairs.

But that's nothing. A modern graphics card has a GPU (which used to stand for Graphics Processing Unit, but now stands for General Processing Unit). These are often wide SIMD implementations, capable of branches, loads, and stores on 128 or 256 bits at a time. Intel's Larrabee prototype microarchitecture includes more than two 512-bit SIMD registers on each of its cores.

GPU SIMD

Please note that SIMD is not to be confused with multi-core. Each core of a CPU will have its own wide ALU capable of adding together a set of integers.

Rocketmagnet
  • 26,933
  • 17
  • 92
  • 177
  • 1
    "1×16-bit pair, 2×32-bit pairs, 4×16-bit pairs or 8×8-bit pairs" Are you sure you got that part right? – user Oct 05 '12 at 08:04
  • 4
    At first glance that looked like a Kraft Single with an Intel logo on it – Chris Laplante Oct 05 '12 at 14:29
  • 4
    4x32 bit variables is **still** only 32 bits. The bit-ness is the maximum *individual* integer the ALU can operate on. Doing it many times in parallel does not increase the bit-width. -1 – Connor Wolf Oct 06 '12 at 04:27
  • 1
    @ConnorWolf -- I don't think you are using the same definition for bit-ness as RocketMagnet. You seem to be looking at the bits-per-word, whereas I believe he is looking at total-bits-processed-in-one-clock-cycle. (Processed or Transferred.) IMHO, This is about throughput, either of MIPS or of the raw transfer rate between processor and RAM etc. So please rethink your -1. Thanks. – MicroservicesOnDDD Dec 30 '20 at 05:22
  • To test if the word can do that, substitute "bit-size" and see if it works. He is talking about the bit-size of the bus, and the SIMD processing power, but you think he should only be talking about the bit-size of the individual instruction, or the bit-size of the individual calculation. I think bit-ness (bit-size) works in both settings. Don't you? – MicroservicesOnDDD Dec 30 '20 at 05:34
3

Because we don't need it yet.

Normally, the bitness (which I'd define as the number of bits in a register) translates more or less directly into the amount of addressable memory. This is of course simplified, since depending on the processor, there might be registers have 2 times the length of the bitness, or there exist techniques to circumvent those memory limitations (anybody out there remembering doing programming on 16-bit windows?).

Axel
  • 131
  • 2
3

"Why don't they simply increase the number of the data lines and create a 256-bit"

All Intel processors that fit the LGA-2011 Socket do, in fact, have 256 data pins, connecting to 256 data lines on the motherboard that lead to the DRAM. I'd be a little surprised if the most recent laptop or desktop machine you used didn't have at least 256 data lines. May I ask where you got this mistaken idea that they "don't ... simply increase the number of data lines"?

The LGA-211 Socket datasheet (was: LGA-2011 Socket datasheet), section 6.1, indicates that these CPUs have 256 data pins and 76 address pins (bank address + memory address).

davidcary
  • 17,426
  • 11
  • 66
  • 115
-1

because there's no application that needs or have the possibilities to represent data using more than 128 bits at once.

and you know, multimedia processors and graphic cards will get there way before mainboards cpu's, just because with photo/video it makes sense to use such large data lengths to be processed at once.

Paulo
  • 1
-5

A computer System is in its meaning a Computing machine, which requires some inputs and give some outputs. We have to satisfy the computer in these lines, hence the developers came to have a benchmark by having 3 Buses, namely Address Bus, Data Bus and Control Bus. 1) The Address Bus fetch/Select a particular Address in the Memory, for Read/Write Operations. 2) The Data Bus then Fetches the Data Present this Data to/from processor and Memory for Processing / Storage Purposes. 3) The Control Bus Create a Interface Controlling Protocol and asks the System to Respect it.

These are required to do some useful Computation for a User/Server/Client. In general the Performance(Speed of Task Completion, Less Glitches, etc) Depends on Clearing the Bottle Necks in the System. i.e. If the CPU is able to process at a Much Higher Rate than the Transfer Speed from a Hard Disk Drive, then the bottle neck occurs at the HDD. Similarly we need to have a right Processing Speed for a particular Data Speeds and Code Width.

From the Start, Because of various reasons like H/W Complexity, Cost, Requirement, Effective Algorithms and the main reason Market Scope are the main hindrances for the production of High Data Bus Width, as mentioned by the Question Host, say 256 bit or 512 bit. These are possible ! But the requirement is not yet present, the market scope is not yet visible with the needs today and the absence of complimenting Software Support.

256 bit processor signifies the width of the Data Bus, that particular processor can handle, or the ALU can process in a single Execution. We Started form 4 bits, then 8,16,32 and presently 64 and even 128 bits which are the present Market Scope Products.

So before Asking these Questions, you must always see the Market Side Demand and its Scope, In history it is the only Straight Forward way to understand the ways of Life. If you can't afford it how can you buy it? and if you can't Buy it, how can the producer produce? and if he can't produce, then there is no existence for that product !!

Sri Krishna
  • 101