View Full Version : 8-bit, 16-bit - What do these mean?
EternalIdiot
10-24-2006, 04:36 PM
I've seen video game systems referred to as 8-bit, 16-bit, 64-bit, etc. What does this mean?
Also, what does 32-bit computing mean?
Alex_Dubinsky
10-24-2006, 05:04 PM
bit count can refer to A LOT of things regarding computing (this is obvious, since bits underpin everything).
In reference to video game consoles, they refer to the width of the data bus to memory. IE, how many physical wires there are running from a processor to memory. If you have an 8-bit bus going at 100MHz, you have a max theoretical bandwidth of 100MB/s (800Mbits/s) because each wire can transport 1 bit per Hz.
You'll note that memory width is a bit meaningless without specifying frequency, so "bits" is mostly a fluffy marketing number in this case. However, the greater memory widths and bandwidths of successive generations of consoles allowed them to pump more bitmap data to/from the graphics memory. This allowed for higher resolution rendering (output), higher resolution textures (input), and even the use of multiple input textures to create a single pixel of output (the standard nowdays). However, many, many other factors go into the performance of a video game system beside raw memory bandwith.
Interesting note: memory width, which once used to scale rapidly, has hit a ceiling. The problem is that the memory bus isn't on a silicon chip but on a printed circuit board. And there is no Moore's law for PCBs. Technology to increase the number of wires that can go to or from a chip does not advance quickly and is limited by mechanical fabrication techniques (none of this shine lasers onto silicon BS). 256bits, which has been the standard for high-end video cards for the past three-four years, is almost as wide as is practical. You'll notice that 128bit and 64bit datapaths are still often used because their cost has simply not come down by much. CPUs (always lagging behind GPUs in terms of memory) currently typically use 128bits ("dual-channel") but will move to 256bits within a year (AMD's quad-core architecture has quad-channels). 512bits may yet appear in consumer video cards, this year it made an appearance in "GPU Stream processors" and workstations, but 1024 is almost definately out. 2048... no way. Just too expensive. Of course, frequencies continue to go up (especially for signals...processor frequencies have kind of stood still lately) and overall memory bandwidth will continue to increase for some time. In the long term, however... yeah, there might be problems and more and more memory will eventually migrate onto CPUs/GPUs. However, it'll be using transistors (6 for every bit, to be precise) which could have been spent on logic.
As for "32-bit computing"... that means something else entirely. It refers to the size of the integer data type in a processor. A 32bit (unsigned) integer has a maximum binary value of 11111111111111111111111111111111, which comes out to about 4 billion. The important thing is that memory addresses are represented as integers. If your integers can only go up to 4 billion, so can your memory addresses. Thus, the limit on addressable memory for 32-bit systems (without using tricks) is 4GB. 64bit systems use 64 bit integers and can thus address far more memory. 64bit integers, however, do not have much value for doing computations (if you really really need to use more than 32bit, 64bit probably won't be enough either. you'll have to do some sort of emulation using a bunch of 32bit values). Therefore, the shift to 64bit integers has come about only because of the need to address memory. Using 128bit integers is perfectly possible, but there just isn't any point and there won't be for a very, very long time.
Note that floating-point numbers have been 64bits (double precision) for several decades, because there the need for precision is great. 128bit floating-point numbers have been used in some systems, but that is mostly overkill.
Themenin
10-24-2006, 05:04 PM
Bits refers to the number of digits in a binary byte. A byte is the base unit for computer data.
An 8 bit byte (octet) might look like this 00000111 or 11110000 etc
Each of these bytes represents a single unit of data, so the more bits per byte, the greater the number of distinct data units that can be represented by a single byte.
An analogy would be the number of letters in the alphabet. An alphabet with few letters would require very long words, an alphabet with many letters could have an increasingly large number of distinct short words - the extreme case would be a writing system where each word was represented by a single distinct character.
A 16 bit system allows more distinct bytes than an 8 bit system - complex information can be recorded in a smaller number of bytes.
I don't know how well longer bytes converts into a real world performance improvement in PCs or Nintendos.
snailboy
10-24-2006, 05:05 PM
Officially, it refers to the size of the registers in the processors. Processors have registers which temporarily hold data for calculations to be processed. Before it does any alterations to anything in memory, it has to be moved to a register first. So an 8-bit processor has eight transistors which can be set to 1 or 0 (binary). With eight of them, you can hold an unsigned integer from 0 to 255 or a signed integer from -128 to 127 (a total of 256 values in both cases). A 16-bit processor can hold unsigned integers from 0 to 65,536 or signed integers from -32,768 to 32,767. Of course it just goes up from there. For some operations, a single unit of data can be held in two registers effectively giving you double the bits, but this typically takes more time.
Sometimes the video game companies lie though. The Turbografx 16 was supposedly 16-bit, but in actuality it just had 2 8-bit processors similar to the processor found in the NES. I've heard the SNES wasn't truely 16-bit either, but they called it that because it had 16-bit graphics. In the case of graphics, 8-bit means 256 possible colors for each pixel, 16-bit means 65,536 possible colors, etc. While the size of the registers does make somewhat of a difference, it's not nearly as important as other things.
gazpacho
10-24-2006, 05:05 PM
It generally means the number of bits in a common data path within the micro processor of the video game or the computer. In general computer process data in small chunks. 8, 16, 32 and 64 bits generally refer to the size of these chunks.
Sometimes it means the size of the words used to keep tracks of addresses in memory. A 32 bit system can use up to 2^32 or 4 megabytes of memory a 64 bit system can address much more.
A lot of times it refers to both things.
32 and 64 bit computing usually are talking about the size of the possible address space, the second usage.
iamthewalrus(:3=
10-24-2006, 05:45 PM
A 32 bit system can use up to 2^32 or 4 megabytes of memory a 64 bit system can address much more.Obviously just a typo, but a 32 bit system can address 4 Gigabytes of memory.
Alex_Dubinsky
10-24-2006, 06:52 PM
Themenin.. did you imply that 16-bit systems have 16-bit bytes?
Punoqllads
10-24-2006, 07:20 PM
Put simply, when you see a video game system declaring itself a "8-bit", "16-bit", "32-bit", etc. system, you are seeing marketing-speak for, "We found something somewhere that takes this many bits." Maybe it's the bus width (even if it's the memory-to-video bus) , maybe it's the processor's addressable memory limits (even if the actual memory is much smaller), or maybe it's an actual useful number like the naitive floating-point size of the graphics processor. It's just some number that someone in marketing found that projects the image that they want to sell.
32-bit computing, as gazpacho notes, usually refers to the maximum addressable memory that an application can access. Depending upon the operating system, however, a 32-bit application might be limited to either 4GB or 2GB, or slightly under those limits.
AHunter3
10-24-2006, 08:25 PM
Not to contradict anything that anyone else said, but if I didn't already know what you guys were talking about, I sure wouldn't know what you guys are talking about.
OK, imagine this dot, right here: •
Let's say I'm allowed only one bit of information to describe it.
Bits are either on or off. "On" can mean "yes" while "Off" means no, but you only get two possibilities regardless of how they are interpreted. For our dot, "on" could mean "black" and "off" could mean "white" and then on a black and white screen I can either make that dot black or white. Can't make it grey or purple or chartreuse, though, I only get two states to choose between.
If I had a whole bunch of those dots (let's call them pixels, shall we?) and I have one bit for each one of them, I can turn any of them off or on. Black or white. I can make a white background and then represent the letters of the alphabet with black pixels in the shapes of the letters.
Sir, may I have two bits to play with? I can? Yippee!!!
Look what I can do with two bits!
Bit A on Bit B on = white
Bit A on Bit B off = light grey
Bit A off Bit B on = dark grey
Bit A off Bit B off = black
Now I could make a white rectangular area against a dark grey background, give it a black border 20 pixels wide, and then put a label (a bunch of pixels in the shape of letters making up words) in light grey.
Give me four bits and I can have up to 16 colors. That's a poor kid's Crayola box's worth of colors! I can draw pictures! I can do (ugly looking but recognizable) representations of color photos, even!
The number of possibilities is the square of the number of bits you get to play with. And just as it lets me do cool things with a screen, extra bits let programmers do cool things in general — the more bits, the more options; the more possible combinations, where each combination can mean something specific.
Hope this helps. (I suppose I'm arrogant for thinking this description will be more accessible, but so be it...)
DanBlather
10-24-2006, 08:32 PM
Not to contradict anything that anyone else said, but if I didn't already know what you guys were talking about, I sure wouldn't know what you guys are talking about.
OK, imagine this dot, right here: •
Let's say I'm allowed only one bit of information to describe it.
Bits are either on or off. "On" can mean "yes" while "Off" means no, but you only get two possibilities regardless of how they are interpreted. For our dot, "on" could mean "black" and "off" could mean "white" and then on a black and white screen I can either make that dot black or white. Can't make it grey or purple or chartreuse, though, I only get two states to choose between.
If I had a whole bunch of those dots (let's call them pixels, shall we?) and I have one bit for each one of them, I can turn any of them off or on. Black or white. I can make a white background and then represent the letters of the alphabet with black pixels in the shapes of the letters.
Sir, may I have two bits to play with? I can? Yippee!!!
Look what I can do with two bits!
Bit A on Bit B on = white
Bit A on Bit B off = light grey
Bit A off Bit B on = dark grey
Bit A off Bit B off = black
Now I could make a white rectangular area against a dark grey background, give it a black border 20 pixels wide, and then put a label (a bunch of pixels in the shape of letters making up words) in light grey.
Give me four bits and I can have up to 16 colors. That's a poor kid's Crayola box's worth of colors! I can draw pictures! I can do (ugly looking but recognizable) representations of color photos, even!
The number of possibilities is the square of the number of bits you get to play with. And just as it lets me do cool things with a screen, extra bits let programmers do cool things in general — the more bits, the more options; the more possible combinations, where each combination can mean something specific.
Hope this helps. (I suppose I'm arrogant for thinking this description will be more accessible, but so be it...)That is overly simplified and misleading. The colors analaogy makes sense when you are describing the color quality (i.e., the number of bits associated with a pixel) but it is not really applicable to how game console makers use the term x-bit. As other posters has said, that can refer to how much data can be processed in one instruction, how much data can be transferred in a unit of time, or the range of memory that can be directly addresseed.
snailboy
10-24-2006, 09:19 PM
The number of possibilities is the square of the number of bits you get to play with.
Good explanation on how computer graphics work, except that the quoted sentence is incorrect. If the number of bits is x, then the number of possibilities is 2^x. With 8-bit, you have 256 possibilities, not 64. It's basically the same as any number system. If you have a random 3 digit decimal number, then there are 10^3, or 1,000, possibilities, assuming leading zeros are allowed.
Also, as an assembly programmer, I'd just like to point out that the graphics bitwidth refers to the number of colors that can be displayed on the screen at the same time, not necessarily all of the colors possible. For instance, with 8-bit color, you have a palette with 256 colors, and you can choose one color from that palette for each pixel. However, you can usually set the colors that go in that palette, and on computer video cards (at least back in the old days), you set 3 8-bit values for the amount of red, blue, and green. Consequently, you can show 256 colors on the screen at the same time, but a total of 16,777,216 colors by altering the palette. This probably doesn't go to answering the original question, but I figured it should be mentioned with all this talk about computer graphics.
AHunter3
10-24-2006, 11:33 PM
Good explanation on how computer graphics work, except that the quoted sentence is incorrect. If the number of bits is x, then the number of possibilities is 2^x.
:smack:
That is of course what I meant.
ididntbeatmymistress
10-24-2006, 11:43 PM
So an 8-bit processor has eight transistors which can be set to 1 or 0 (binary).
I don't think this is completely correct. A register is made up of a chain of flip-flops, which is made up of a series of logic gates (AND/OR/NOT, etc), and those are made up of transistors. So yes, an 8-bit register is made up of transistors - just not 8.
Flip -Flop made up of logic gates:
http://www.cs.umass.edu/~weems/CmpSci535/Discussion8.html
Talks a little about a register being an array of flip flops:
http://www.rz.uni-hohenheim.de/hardware/basics/csc102/ch12.html
Wiki logic gates:
http://en.wikipedia.org/wiki/Logic_gate
groman
10-25-2006, 03:37 AM
I don't think this is completely correct. A register is made up of a chain of flip-flops, which is made up of a series of logic gates (AND/OR/NOT, etc), and those are made up of transistors. So yes, an 8-bit register is made up of transistors - just not 8.
It is possible to have a flip-flop with only one clocked transistor. I don't remember how, but it's possible. So theoretically you could have an 8 transistor 8-bit register. You usually don't, but you could.
robardin
10-25-2006, 10:09 AM
To clarify a bit about what "32-bit computing" means: not necessarily the same as what a "32-bit" or "64-bit" game console means.
As others have already mentioned, from a hardward perspective the bits being counted refer to the width of the memory bus, which among other things in turn dictates the largest addressable memory space for a process.
However just because the memory bus is a certain width doesn't always mean the operating system is taking full advantage. I remember programming for Windows 3.1 back in the early 1990s on 80386-based computers. The 80386 was a 32-bit processor but for the sake of backwards compatibility with 80286 and 8088 based device drivers, Windows was still a 16-bit operating system... With various hack-like API extensions for 32-bit computing to allow addressing beyond 2^16 bytes via a kind of virtual "chaining", different types for "far" and "near" pointers, etc.
As a result, one of the developers I worked with at the time preferred worked in assembly rather than C for his graphical work specifically to have a clean, flat 32-bit memory model availble to him.
Similarly, I am currently working with Sun workstations running 32-bit versions of Solaris (the Sun operating system that is a variant of UNIX) on 64-bit machines (in an mixed environment where we still have mostly 32-bit machines available). While the systems themselves support physical memory configurations of more than 4GB, the operating system can still only run processes that max out at 4GB in size.
gazpacho
10-25-2006, 10:11 AM
It is possible to have a flip-flop with only one clocked transistor. I don't remember how, but it's possible. So theoretically you could have an 8 transistor 8-bit register. You usually don't, but you could.I have never heard of a one transistor flip flop and would need to see the circuit to believe the claim. Dynamic ram cells will have one transistor per bit storing charge on the gate of the transistor to indicate one or zero. An Sram cell is not a flipflop. People might make register files in a processor out of srams but I would think that is pretty uncommon.
A simple flip flop has two inputs and one output. inputs D and Clk output Q. The value on Q gets passed to Q on a rising edge of the Clk pin. (Sometimes it is the falling edge) You can add to this with other pins that set and clear the flop enables and muxes on the inputs are common. A very important characteristic of a flipflop is that the Q output is available all the time. The one transistor storage elements I have seen involve a read phase of time that make them quite different in how they are used from flip flops.
gazpacho
10-25-2006, 10:13 AM
Now that I think about it sram cells don't store charge on the gate. They store it in a capacitor on the source or drain of the transistor and the gate is used to control read or write. Flash stores charge on the gate.
groman
10-25-2006, 11:13 AM
I have never heard of a one transistor flip flop and would need to see the circuit to believe the claim. Dynamic ram cells will have one transistor per bit storing charge on the gate of the transistor to indicate one or zero. An Sram cell is not a flipflop. People might make register files in a processor out of srams but I would think that is pretty uncommon.
I've been racking my brain about this in the shower and now it occurs to me that I was probably wrong. Unless there is some sort of a D flip-flop that can be created out of a transistor-capacitor DRAM cell I can't think of any way of accomplishing this.
control-z
10-25-2006, 01:47 PM
SIMPLE ANSWER: The number of bits determines what size numbers a computer can handle.
The bits would be a simplified measure of what a computer can do, sort of like saying a car has a 6 cylinder engine. A 6-cylinder engine could produce 150 horsepower, or it could produce over 300 horsepower, depends on how it's set up.
Kevbo
10-25-2006, 02:55 PM
SIMPLE ANSWER: The number of bits determines what size numbers a computer can handle.
That should say: What size numbers the computer can handle in one operation By breaking a problem into many steps, almost any computer can handle arbitrarly large or precise numbers. However, with more bits available for each operation, larger numbers can be handled in fewer operations, which takes less time...much less time in many cases.
Alex_Dubinsky
10-25-2006, 03:17 PM
SIMPLE ANSWER: The number of bits determines what size numbers a computer can handle.Either you are talking about the size of integers or float-point numbers. In which case that is only a part of the whole answer. Or you are talking about numbers in the most abstract way, which will yield your answer non-constructive.
To repeat. Regarding video consoles, it's about the number of bits that can be read from memory in a single clock cycle. Regarding color, it's the number of bits used to represent a single pixel. Regarding "64-bit computing," it's the number of bits that are used in a single integer variable, and hence the number of bits that are used to construct a memory address. Regarding Intel Core 2's new 128bit-wide floating point data paths, it's the number of bits that can be moved between registers and into the arithmetic units in a single cycle.
Actually, regarding consoles the marketing number may sometimes be a mix of those real measurements.
What limits bitness in an architecture is either: the difficulty of placing and routing wires (on the PCB when talking about memory, but also on the chip when moving data from one place to another) and the difficulty of constructing a multiplier/divider/etc that will deal with large numbers (when talking about number data types).
Placing and routing wires is usually the dominant concern for all kinds of hardware-related bit measurements, especially in the modern age. But the wires may relate to a lot of different things, serve many various functions, and have all sorts of implications.
Almost always, bitness is irrelevant. It is the signficance for the wider architecture that matters (ie, how much bandwidth you have, how much memory you can address, what the cost-benefits are for implementing some particular thing). That is always the case with engineering, but here especially.
snailboy
10-25-2006, 06:18 PM
I don't think this is completely correct. A register is made up of a chain of flip-flops, which is made up of a series of logic gates (AND/OR/NOT, etc), and those are made up of transistors. So yes, an 8-bit register is made up of transistors - just not 8.
You are correct. I meant to say an 8-bit register has 8 flip-flops.
I'm not the only one who is incorrect, though. Those saying that 64-bit computing refers to the memory bus are incorrect as well. I remembered reading in my Sledgehammer programmer's manual that it is less than that. I don't have the manuals here, but I did manage to find an article (http://www.hardwaresecrets.com/article/324/4) on the Internet.
When it was released with Athlon 64, AMD64 architecture brought a new 64-bit mode for x86 instructions. This mode is called x86-64 by AMD and what it does is to expand the existing 32-bit registers into 64-bit ones. All AMD64 CPUs have sixteen 64-bit general purpose registers when running under x86-64 mode. Under this mode the CPU address bus is also expanded from 32 to 40 bits, enabling the CPU to directly access up to 1 TB of RAM (2^40). Also under this mode the CPU can access up to 256 TB of virtual memory (2^48). Virtual memory is a technique that allows the CPU to simulate more RAM memory that the computer has by creating a file on the hard disk drive called swap file.
Even including virtual memory, you don't have 64 bits of memory addressing.
DanBlather
10-25-2006, 10:09 PM
You are correct. I meant to say an 8-bit register has 8 flip-flops.
I'm not the only one who is incorrect, though. Those saying that 64-bit computing refers to the memory bus are incorrect as well. I remembered reading in my Sledgehammer programmer's manual that it is less than that. I don't have the manuals here, but I did manage to find an article (http://www.hardwaresecrets.com/article/324/4) on the Internet.
Even including virtual memory, you don't have 64 bits of memory addressing.We are getting deep in the shed here. There is a difference between the size of an address and how much memory a processor can access. In the case you cited the Atholon used (or was abe to use) 64 bit addresses; i.e., it could load or store to an address range from 0x0000000000000000 to 0xFFFFFFFFFFFFFFFF. The actual physical memory that the processor could accomodate was only 2^40 bits. From an application programmers standpoint however, it would appear that they have the full 64-bit address range avalilable to them.
The description of virtual memory in the article you quoted is not particularly precise. VM may or may not be associated with a swap file on disk. In real-time systems it often doesn't. The implicatioon of virtual memory is that the addresses used by in CPU instructions are "virtual" (i.e., pretend) and are translated to phyical addresses though page tables which map virtual addresses to physical addresses. An example might make this clear. Imagine a program written so that it thinks it starts at address 0x0. Without virtual memory you could only have one instance of that application running. With virtual memory you can have multiple applications running at the same time that all think they are accessing 0x0. The virtual memory subsystem will give each of them a unique range of physical memory to run in.
control-z
10-26-2006, 09:06 AM
Either you are talking about the size of integers or float-point numbers. In which case that is only a part of the whole answer. Or you are talking about numbers in the most abstract way, which will yield your answer non-constructive.
I knew my "simple answer" would not satisfy you geeks out there. If anyone has noticed, the OP hasn't been back, probably overwhelmed by the answers. :D
RaftPeople
10-26-2006, 01:56 PM
I knew my "simple answer" would not satisfy you geeks out there. If anyone has noticed, the OP hasn't been back, probably overwhelmed by the answers. :D
I thought your simple answer was actually pretty good for the audience asking the question.
I know of too many processors with different data bus/address bus/register size/etc. etc. etc. that I think it would be hard to have 1 simple answer. Here is a question for you techies: was the 8088 8bit or 16bit? How about the 6809?
snailboy
10-26-2006, 06:40 PM
We are getting deep in the shed here. There is a difference between the size of an address and how much memory a processor can access. In the case you cited the Atholon used (or was abe to use) 64 bit addresses; i.e., it could load or store to an address range from 0x0000000000000000 to 0xFFFFFFFFFFFFFFFF. The actual physical memory that the processor could accomodate was only 2^40 bits. From an application programmers standpoint however, it would appear that they have the full 64-bit address range avalilable to them.
The register for memory addressing may be 64-bits, but what good does that do if the bus can only support 48-bits in paging mode? Why would you use a value greater than 2^48? What would happen if you did? I actually know little about 64-bit assembly programming. I really wish I had my architecture guide here.
DanBlather
10-26-2006, 06:48 PM
The register for memory addressing may be 64-bits, but what good does that do if the bus can only support 48-bits in paging mode? Why would you use a value greater than 2^48? What would happen if you did? I actually know little about 64-bit assembly programming. I really wish I had my architecture guide here.The memory bus is seeing physical addresses; i.e., after they have been translated by the memory managment subsystem.
Punoqllads
10-27-2006, 03:37 PM
The register for memory addressing may be 64-bits, but what good does that do if the bus can only support 48-bits in paging mode? Why would you use a value greater than 2^48? What would happen if you did? I actually know little about 64-bit assembly programming. I really wish I had my architecture guide here.There is a piece of hardware called the TLB that translates between the 64-bit address that the program works with and the actual physical address. Part of the operating system's job is managing that lookup table. When a section of memory haven't been used in a while, the operating system will find a space on the disk drive to put that memory and save where it put that memory in another space on the disk drive. If a program tries to access a piece of memory that has been saved to disk, the TLB generates a signal called a page fault that suspends the application and wakes up the operating system. The operating system finds out where it had put that piece of memory, finds a space in physical memory for it, puts the translation from the virtual address to the physical address in the TLB, and returns control to the program.
Actually, it's a little bit more complicated than that, because the TLB isn't big enough to hold all of the possible translations, so a page fault can occur on memory that is actually in physical memory. The operating system has a locked down piece of physical memory that it uses to quickly assess whether a page fault has occurred on a virtual address that has its data in physical memory or whether the data has been paged out to disk.
Voyager
10-27-2006, 05:49 PM
In reference to video game consoles, they refer to the width of the data bus to memory. IE, how many physical wires there are running from a processor to memory. If you have an 8-bit bus going at 100MHz, you have a max theoretical bandwidth of 100MB/s (800Mbits/s) because each wire can transport 1 bit per Hz.
It is purely marketing, but could it refer to the size of the processor in the system - which in turn determines the memory bus width.
[/quote]
Interesting note: memory width, which once used to scale rapidly, has hit a ceiling. The problem is that the memory bus isn't on a silicon chip but on a printed circuit board. And there is no Moore's law for PCBs. Technology to increase the number of wires that can go to or from a chip does not advance quickly and is limited by mechanical fabrication techniques (none of this shine lasers onto silicon BS). 256bits, which has been the standard for high-end video cards for the past three-four years, is almost as wide as is practical. You'll notice that 128bit and 64bit datapaths are still often used because their cost has simply not come down by much. CPUs (always lagging behind GPUs in terms of memory) currently typically use 128bits ("dual-channel") but will move to 256bits within a year (AMD's quad-core architecture has quad-channels). 512bits may yet appear in consumer video cards, this year it made an appearance in "GPU Stream processors" and workstations, but 1024 is almost definately out. 2048... no way. Just too expensive. Of course, frequencies continue to go up (especially for signals...processor frequencies have kind of stood still lately) and overall memory bandwidth will continue to increase for some time. In the long term, however... yeah, there might be problems and more and more memory will eventually migrate onto CPUs/GPUs. However, it'll be using transistors (6 for every bit, to be precise) which could have been spent on logic.
[/QUOTE]
Well, I'm not sure if PCB density strictly follows Moore's Law, but the smaller and smaller size of discretes and every more routing layers on board has helped. Actually, though, we're going away from increasing signal bandwidth by increasing the number of signals. (OP, avert your eyes :) ) Synchronizing high speed signals is nearly impossible, and there are tons of signal integrity issues. What is now increasingly common is the use of SERDES busses, which serialize a mult-bit signal into one bit, send it at very high speed, and deserialize it on the other side. The clock can be recovered from the signals. This can go so much faster than parallel busses it makes sense. Some processors now pretty much only have serdes busses, which causes all sorts of problems I won't get into. So it is not always true that an m bit bus has less bandwidth than an n bit bus for n > m.
Voyager
10-27-2006, 06:00 PM
I don't think this is completely correct. A register is made up of a chain of flip-flops, which is made up of a series of logic gates (AND/OR/NOT, etc), and those are made up of transistors. So yes, an 8-bit register is made up of transistors - just not 8.
Flip -Flop made up of logic gates:
http://www.cs.umass.edu/~weems/CmpSci535/Discussion8.html
This is a bit inaccurate. In fact, very inaccurate. While it may be convenient to describe a flop as made out of gate, in reality they are heavily optimzied transistor level designs, possibly with some tristate gates in some cases. They are used so often that there are specialized groups who develop cell libraries, optimized for area or power.
The first diagram shows an RS flop. I don't think I've seen anyone actually use one of these in 20 years. They are conceptually simple, so show up in classes, but have a problem with illegal input states, as mentioned in the text.
The second diagram is misleading also. Most flops change on the rising (or falling) edge of the clock, which eliminates the problem mentioned. Latches, which typically capture on a static clock, do have this problem. Sometimes logic gets put between the pos and neg latches, since values can propagate through the logic when the clock is 1, which lets the design do useful work on both clock values.
BTW, register files, while represented as a chain of flops, might also be optimized.
Voyager
10-27-2006, 06:09 PM
Bits refers to the number of digits in a binary byte. A byte is the base unit for computer data.
An 8 bit byte (octet) might look like this 00000111 or 11110000 etc
Each of these bytes represents a single unit of data, so the more bits per byte, the greater the number of distinct data units that can be represented by a single byte.
Alex implied this was wrong. It is wrong. A byte, by definition, is 8 bits. Bits do not refer to the the number of digits - a bit is the basic unit of information, 1 or 0. The size of a word depend on the architecture of the computer, and is not standardized the way a byte is.
DanBlather
10-27-2006, 06:12 PM
Alex implied this was wrong. It is wrong. A byte, by definition, is 8 bits. Bits do not refer to the the number of digits - a bit is the basic unit of information, 1 or 0. The size of a word depend on the architecture of the computer, and is not standardized the way a byte is.That is not true. Most (if not all) computers today use 8-bit bytes but historically there have been many machines with byte sizes other than 8 bit. An octet is 8 bits by definition. I think the best definition of a byte is the smallest addressable unit of memory on a computer.
gazpacho
10-27-2006, 07:22 PM
That is not true. Most (if not all) computers today use 8-bit bytes but historically there have been many machines with byte sizes other than 8 bit. An octet is 8 bits by definition. I think the best definition of a byte is the smallest addressable unit of memory on a computer.But nobody uses that definition of a byte anymore. Currently in the industry a byte is 8 bits even if the processor accesses things 16 or 32 bits at a time.
Cervaise
10-27-2006, 08:35 PM
What does this mean?So, is everything clear yet?
DanBlather
10-27-2006, 10:23 PM
But nobody uses that definition of a byte anymore. Currently in the industry a byte is 8 bits even if the processor accesses things 16 or 32 bits at a time.I may be overly picky on thi because I'm a long time computer geek going back to the days of the punch card. I did a quick Google search and about 3 out of 4 sites define byte as 8 bits and the rest say something like "typically 8 bits". Saying a byte is defined as 8 bits is probably safe. I think there are two important things to keep in mind about a byte: 1) a byte is the unit of storage used to hold a character (usually) and 2) a byte is the smallest addressable unit of computer memory.
Derleth
10-27-2006, 11:29 PM
Here is a question for you techies: was the 8088 8bit or 16bit?16-bit, because it had 16-bit registers and you didn't need to know or care that the path to RAM was 8-bit. The 8088 could run 8086 software completely unmodified, except it was slower due to having to break every 16-bit value moved to or from RAM into two 8-bit pieces.How about the 6809?According to Wikipedia (http://en.wikipedia.org/wiki/Motorola_6809), it had 16-bit registers and a 16-bit ALU. I'm going to say it's 16-bit, because even though the accumulator could be split into two 8-bit halves you could do 16-bit math in a single opcode. You could also split most of the 8086's 16-bit registers into 8-bit halves, but nobody could reasonably call the 8086 an 8-bit chip.
RaftPeople
10-28-2006, 02:25 AM
16-bit, because it had 16-bit registers and you didn't need to know or care that the path to RAM was 8-bit. The 8088 could run 8086 software completely unmodified, except it was slower due to having to break every 16-bit value moved to or from RAM into two 8-bit pieces.According to Wikipedia (http://en.wikipedia.org/wiki/Motorola_6809), it had 16-bit registers and a 16-bit ALU. I'm going to say it's 16-bit, because even though the accumulator could be split into two 8-bit halves you could do 16-bit math in a single opcode. You could also split most of the 8086's 16-bit registers into 8-bit halves, but nobody could reasonably call the 8086 an 8-bit chip.
I tend to agree with your logic. It's far more important for me to know the logical limits of the architecture/registers/opcodes vs the physical attributes of the bus.
Derleth
10-28-2006, 03:38 AM
I tend to agree with your logic. It's far more important for me to know the logical limits of the architecture/registers/opcodes vs the physical attributes of the bus.I heartily agree, especially when the same ISA is implemented by multiple slightly-different physical machines to hit different points of the price-performance curve. (IBM is/was famous for doing this: They invented the concept of an ISA not defined by a single kind of machine so they could make and sell multiple different kinds of the wildly successful System/360 minicomputer: Code compiled for one kind of 360 was binary-portable to all models of the series, albeit with different speed characteristics on each.)
And registers are only part of the equation: It's more interesting to look at how large of an address you can form without using segmentation or (especially) bank-switching. That goes a long way to determining what the machine can practically be used for, by determining how much RAM people are likely to be able to actually use. Since the 8088 and the 6809 could both form 16-bit addresses without segmentation, they're rightfully considered 16-bit chips.
vBulletin® v3.7.3, Copyright ©2000-2013, Jelsoft Enterprises Ltd.