# Why are there no 256-bit or 512-bit microprocessors?

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?

• Even marketing can't just keep increasing a number forever. – Olin Lathrop Oct 4 '12 at 13:11
• Why is there no 256 blade razor yet? – Rocketmagnet Oct 4 '12 at 15:30
• @OlinLathrop Checkout the Gillete Fusion Power, with 5 blades and a battery! – Brendan Long Oct 4 '12 at 16:05
• 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 4 '12 at 16:05
• @Russell: Because there'd then be a global shortage of cylinders. – Olin Lathrop Oct 4 '12 at 16:13

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.

• 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 4 '12 at 15:54
• @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 4 '12 at 16:03
• @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 4 '12 at 16:18
• @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 4 '12 at 21:10
• 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 4 '12 at 22:35

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$.

VLIW Architecture

• most financial calculations :( running into this problem now – im so confused Oct 4 '12 at 14:47
• I thought the x86 was a VLIW CPU. ;-) – Macke Oct 5 '12 at 5:51
• @MarcusLindblom Only if by VLIW you mean Variable Length Instruction Words. ;-) – a CVn Oct 5 '12 at 7:58
• @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 8 '12 at 16:41
• 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 8 '12 at 16:48

"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.

• That is an impressive architecture. – Trygve Laugstøl Oct 4 '12 at 16:31
• +1 for "sneaky marketer wanting to bend regularly used terms." – Dan Neely Oct 4 '12 at 18: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.

• 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 4 '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. – whitequark Oct 4 '12 at 21:16
• 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 Neely Oct 5 '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 1 '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 <R1, G1, B1> is to be modulated by another color <R2, G2, B2>, the GPU can produce the resulting color <R1*R2, G1*G2, B1*B2> in one operation. – Kaz May 1 '13 at 23:36

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.
• “640K ought to be enough for anybody.” -Bill Gates (1981) – jippie Oct 4 '12 at 19:35
• @jippie - Gates never actually said that. – Rocketmagnet Oct 4 '12 at 22:07
• 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 5 '12 at 6:03
• @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 5 '12 at 7:03
• @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 5 '12 at 8:54

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.

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.

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.

• "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? – a CVn Oct 5 '12 at 8:04
• At first glance that looked like a Kraft Single with an Intel logo on it – Chris Laplante Oct 5 '12 at 14:29
• 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 6 '12 at 4:27

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?).

"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-2011 Socket datasheet, section 6.1, indicates that these CPUs have 256 data pins and 76 address pins (bank address + memory address).

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.

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 !!

• Capitalising nouns makes this hard to read. – pjc50 Oct 5 '12 at 9:33
• hmm, yes i need to start doing that. – Sri Krishna Oct 5 '12 at 13:04
• @pjc50 Maybe he's from Germany? Oh wait, "Asking" and "Buy" are also capitalised, maybe not... – Alex Aug 3 '17 at 20:34

## protected by Dave Tweed♦Nov 1 '14 at 19:53

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).