Bytes != 8 bits is news to me too, please give some specific examples. I always thought the BYTE declaration was a programming best practice to eliminate magic numbers, not allow weird redefinitions of an industry standard (although you could declare your BYTE to be whatever you wanted, 8 bits would still be a byte).</strong><hr></blockquote>
There's nothing magic about a byte being 8b.
Byte grew up being whatever it took to represent a character--so on some of the earliest systems is was 4 [hex only] or 6 [alphanumeric w/ctrl] bits in length [which could segue into the creation of ESC for getting additional characters].
Whatever the length of byte, the decision is fairly arbitrary--obviously, it's convenient to be able to store any character in one memory cell so you really want at least 7b bytes [for lower ASCII].
8b is really a tradition, but also nicely maps into the double-nibble hex representation we all know and love.
You'll find 16bit bytes in scientific-specific machines [if only for addressable memory constraints], and quite a bit in DA/AD/DAC units which will always be working with data larger than 8b anyway [a lot of the wireless stuff has embedded hardware w/16b byte-length].
Lots of the IBM machines used 9b bytes. ASCII is centred around a 7b byte.
On a <a href="http://gcc.gnu.org/ml/gcc/2000-09/msg00073.html"; target="_blank">PDP-10</a> a "byte" is defined as any contiguous bit field in a 36-bit word. So for ISO-C, the size of the byte must be 36bits.
Here's some information about the bus-discussion above, from a P4 motherboard designer I asked [so, it's not about the 970--but has useful information]:
As far as busses go, the P4 actually does have a 64 bit system bus... A 64 bit data bus, that is. It has a 32 bit address bus. The size of the data bus makes it faster, the size of the address bus allows it to address more memory.. I can't remember the memory limit on a 32 bit address bus is, but it is a lot.. especially when it is addressing 64 bits of data at each address.
That is the front side bus (the connection between the CPU and the memory controller hub (MCH))
The DDR memory has a 64 bit data bus, and each channel of DDR, at least as far as DIMMs are defined, have a 13 bit address bus. With dual channel DDR, you get twice that - 128 bit wide data. That is some sweet shite.
The connection between the memory controller hub and the i/o controller hub (ICH) is a 12 bit multiplexed address/data bus, which connects hard drives, PCI, floppy, serial, parallel, etc. All that shite is pretty slow compared to stuff going on the FSB and DDR.
So, the thing that is crazy is that busses are starting to shrink in size.. for example, PCI used to connect the MCH and ICH and it is 32 multiplexed address and data lines. But the replacement hub interface that is 12 bits wide is many times faster than PCI, even though it has less wires. And when PCI Express comes out (this will be replacing PCI in the next few years), it'll be way faster than PCI and will only need 4 wires..
This is all looking at the signalling stuff on the motherboard, though.
64 bit processing is different, though. You can do a hell of a lot more stuff at the same time, if your software is optimised for it.. That could really speed things up. A 32 bit processor, even if it has access to 64 bits of data at a time, can still only process 32 bits at a time.. so, that would be the real advantage - that you could process 64 bits in the same amount of time it would take a 32 bit processor to do 32. It's useless though unless software is optimised to take advantage of it..
I guess my point is that busses will probably not change a whole lot because of 64 bit processors. They are more likely to change just because no matter what, processors keep getting faster and busses are always the bottleneck.. So improvements always need to be made.
UPDATE:-----------
I asked a friend who works on supercomuting OSs and received the following response:
most supercomputers have NON-8-bit archs, for example:
Cray1: 60-bit word, NO byte at all
CDC 6000 series: ditto: 60bit words, NO concept of byte.
And Cyber series (successor of CDC 6000).
END UPDATE:-----------
Some RFCs referencing the length-of-byte [these, of course, are in re networking.]
Comments
<strong>Where can we find real information about the PPC 970? Is there a roadmap anywhere on IBM's site?</strong><hr></blockquote>
Find it <a href="http://www-3.ibm.com/chips/products/powerpc/"; target="_blank">here</a>.
PS
In South Australia I was born
Heave away, haul away
South Australia 'round Cape Horn
Bound for South Australia[/QB]<hr></blockquote>
...mmmmm, the pogues.
<strong>
Bytes != 8 bits is news to me too, please give some specific examples. I always thought the BYTE declaration was a programming best practice to eliminate magic numbers, not allow weird redefinitions of an industry standard (although you could declare your BYTE to be whatever you wanted, 8 bits would still be a byte).</strong><hr></blockquote>
There's nothing magic about a byte being 8b.
Byte grew up being whatever it took to represent a character--so on some of the earliest systems is was 4 [hex only] or 6 [alphanumeric w/ctrl] bits in length [which could segue into the creation of ESC for getting additional characters].
Whatever the length of byte, the decision is fairly arbitrary--obviously, it's convenient to be able to store any character in one memory cell so you really want at least 7b bytes [for lower ASCII].
8b is really a tradition, but also nicely maps into the double-nibble hex representation we all know and love.
You'll find 16bit bytes in scientific-specific machines [if only for addressable memory constraints], and quite a bit in DA/AD/DAC units which will always be working with data larger than 8b anyway [a lot of the wireless stuff has embedded hardware w/16b byte-length].
<a href="http://www.bobbemer.com/BYTE.HTM"; target="_blank">Some information on the origin of the byte:</a>
Lots of the IBM machines used 9b bytes. ASCII is centred around a 7b byte.
On a <a href="http://gcc.gnu.org/ml/gcc/2000-09/msg00073.html"; target="_blank">PDP-10</a> a "byte" is defined as any contiguous bit field in a 36-bit word. So for ISO-C, the size of the byte must be 36bits.
Here's some information about the bus-discussion above, from a P4 motherboard designer I asked [so, it's not about the 970--but has useful information]:
As far as busses go, the P4 actually does have a 64 bit system bus... A 64 bit data bus, that is. It has a 32 bit address bus. The size of the data bus makes it faster, the size of the address bus allows it to address more memory.. I can't remember the memory limit on a 32 bit address bus is, but it is a lot.. especially when it is addressing 64 bits of data at each address.
That is the front side bus (the connection between the CPU and the memory controller hub (MCH))
The DDR memory has a 64 bit data bus, and each channel of DDR, at least as far as DIMMs are defined, have a 13 bit address bus. With dual channel DDR, you get twice that - 128 bit wide data. That is some sweet shite.
The connection between the memory controller hub and the i/o controller hub (ICH) is a 12 bit multiplexed address/data bus, which connects hard drives, PCI, floppy, serial, parallel, etc. All that shite is pretty slow compared to stuff going on the FSB and DDR.
So, the thing that is crazy is that busses are starting to shrink in size.. for example, PCI used to connect the MCH and ICH and it is 32 multiplexed address and data lines. But the replacement hub interface that is 12 bits wide is many times faster than PCI, even though it has less wires. And when PCI Express comes out (this will be replacing PCI in the next few years), it'll be way faster than PCI and will only need 4 wires..
This is all looking at the signalling stuff on the motherboard, though.
64 bit processing is different, though. You can do a hell of a lot more stuff at the same time, if your software is optimised for it.. That could really speed things up. A 32 bit processor, even if it has access to 64 bits of data at a time, can still only process 32 bits at a time.. so, that would be the real advantage - that you could process 64 bits in the same amount of time it would take a 32 bit processor to do 32. It's useless though unless software is optimised to take advantage of it..
I guess my point is that busses will probably not change a whole lot because of 64 bit processors. They are more likely to change just because no matter what, processors keep getting faster and busses are always the bottleneck.. So improvements always need to be made.
UPDATE:-----------
I asked a friend who works on supercomuting OSs and received the following response:
most supercomputers have NON-8-bit archs, for example:
Cray1: 60-bit word, NO byte at all
CDC 6000 series: ditto: 60bit words, NO concept of byte.
And Cyber series (successor of CDC 6000).
END UPDATE:-----------
Some RFCs referencing the length-of-byte [these, of course, are in re networking.]
RFC 102: for HOST/HOST output: specifies requirement to include size of bytes w/response <a href="http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc0102.html"; target="_blank">http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc0102.html</a>;
RFC: 1037 - NFile <a href="http://rfc-1037.rfc-index.net/rfc-1037-39.htm"; target="_blank">http://rfc-1037.rfc-index.net/rfc-1037-39.htm</a>;
[ 01-23-2003: Message edited by: dumpster ]
[ 01-23-2003: Message edited by: dumpster ]</p>