64 Bit busses

If G5 is 64 bit AND dual core, could a 64 bit bus be "split" into two data streams? Would a 400Mhz bus then function as a dual path 200Mhz 32 bit bus? Could this be how we get from a 64 bit chip to 32 bit common Hardware?

Unfortunatly, I doubt if that will happen. In order to do this, you would have to manufactur the CPU chip essentially as 2 chips built together. Plus, this I believe would run much slower than just providing emulation. Remember back a long time ago when we went from 16-bit to 32-bit, and all of our old programs either ran slower, or didn't run at all. Same thing will happen when the hardware moves from 32 to 64-bit. Different manufactures are doing different ways to address this "transitional" period. Intel is providing emulation for 32-bit apps. AMD is essentually doing the oppisite and almost providing an emulated 64-bit. I have no idea what IBM or Motorola is doing.

One of the first major benifits of a 64-bit system will be expanded RAM addressing. Currently 32-bit allows for 4 GBs of RAM. Most WinTel systems already provide MotherBoard support for this muchs RAM. Also along with this will be larger Hard Drive addressing, and this should provide the bandwidth necessary for efficient voice interface machines. Think no more keyboards!

Originally posted by sturm375 Also along with this will be larger Hard Drive addressing, and this should provide the bandwidth necessary for efficient voice interface machines. Think no more keyboards!

Click to expand...

But that'll make it more difficult to surf my "adult" sites when others are around.

In order to move to true 64-bit, all hardware would be required to be 64-bit. You could not just "double" 32-bit and get to 64-bit (more information below), and thus it is difficult for even AMD and Intel to devise a way to move over to new processors.

This allows for significantly more work to be done with fewer processes. Thus, an 800MHz Itanium is king of virtually all processors, with the exception of 1GHz Itaniums. So, if you think about, if you "doubled" a 32-bit connection, it would take many more processes to work up to the speed of a 64-bit processor and bus. Furthermore, I believe it would actually take two processors running on seperate data pipelines to accomplish this.

Don't take this for granted, I have no way of proving this other than my basic understanding of how a processor works.

CPUs have different types of busses: data, address, internal and external.

The internal data bus determines how much data can be processed during the execution of a single command - eg adding 2 numbers. If you can add 2 64 bit numbers, you get twice the performance as adding 2 32 bit numbers.

However, not all data is 64 bits. For example, keystrokes are represented as 16 bit data, so even 32 bit capacity is overkill for that. So, unless you actually have 64 bit data that you are manipulating, increasing the data bus does not help you.

According to the Book E spec which defines the G5, integer processing units are increasing from 32 to 64 bits - making the G5 64 bit data since integer units are normally used to determine the data size of the processor. The floating point processing units remain at 64 bit - same as the G4.

Also, you cannot combine data streams. So, when the G5 comes out, any programs that are designed and compiled for 32 bit will use half of the data bandwidth available according to Book E, and you won't be able to run 2 32 bit data streams at a time to take advantage of the unused capacity.

The virtual address space for G5 is moving from 32 to 64 bits. This means that any one program running on the G5 will be able to address up to 2^64 bytes of memory (I don't know what to compare that to because it is soooo huge). The OS will determine how much of the address space user apps can use. There are very few apps even today that really need and can take advantage of that, which is why the Alpha did not do as well as DEC hoped it would.

The external data bus determines how much info is transferred across the memory bus when loaded or stored. The G4 is 64 bit (Maxbus), so it loads 2x as much data as is requested during one load command - same as Intel does it on some of it's processors. The theory is that the next info requested will be right beside what you are requesting now, so it will be preloaded in cache when actaully required. If you have good compilers, this works great. I haven't seen any info as to what bus will be used on the G5.

The external address bus determines how much memory you can physically talk to on the memory bus. The G4 is 36 bit, so although any one program can only address 4GB (32 bit), you could actually have 64GB on the system. I haven't seem any info about what is happening with the G5 in this area.

Finally, the dual core issue. You are right in that 2 cores means 2 complete CPUs on 1 die. This is blazingly fast if you have a large cache running at or near the clock speed of the CPU because the communications between the processors takes place at CPU speed. The biggest issue in this area is keeping the CPUs fed with data because of the delay in accessing main memory to feed the cache.

Hope this helps. If I confused anyone, let me know and I'll try to fix it.

Originally posted by gbojim OK I can help with this one. Sorry in advance for the long post.

CPUs have different types of busses: data, address, internal and external.

The internal data bus determines how much data can be processed during the execution of a single command - eg adding 2 numbers. If you can add 2 64 bit numbers, you get twice the performance as adding 2 32 bit numbers.

However, not all data is 64 bits. For example, keystrokes are represented as 16 bit data, so even 32 bit capacity is overkill for that. So, unless you actually have 64 bit data that you are manipulating, increasing the data bus does not help you.

According to the Book E spec which defines the G5, integer processing units are increasing from 32 to 64 bits - making the G5 64 bit data since integer units are normally used to determine the data size of the processor. The floating point processing units remain at 64 bit - same as the G4.

Also, you cannot combine data streams. So, when the G5 comes out, any programs that are designed and compiled for 32 bit will use half of the data bandwidth available according to Book E, and you won't be able to run 2 32 bit data streams at a time to take advantage of the unused capacity.

The virtual address space for G5 is moving from 32 to 64 bits. This means that any one program running on the G5 will be able to address up to 2^64 bytes of memory (I don't know what to compare that to because it is soooo huge). The OS will determine how much of the address space user apps can use. There are very few apps even today that really need and can take advantage of that, which is why the Alpha did not do as well as DEC hoped it would.

The external data bus determines how much info is transferred across the memory bus when loaded or stored. The G4 is 64 bit (Maxbus), so it loads 2x as much data as is requested during one load command - same as Intel does it on some of it's processors. The theory is that the next info requested will be right beside what you are requesting now, so it will be preloaded in cache when actaully required. If you have good compilers, this works great. I haven't seen any info as to what bus will be used on the G5.

The external address bus determines how much memory you can physically talk to on the memory bus. The G4 is 36 bit, so although any one program can only address 4GB (32 bit), you could actually have 64GB on the system. I haven't seem any info about what is happening with the G5 in this area.

Finally, the dual core issue. You are right in that 2 cores means 2 complete CPUs on 1 die. This is blazingly fast if you have a large cache running at or near the clock speed of the CPU because the communications between the processors takes place at CPU speed. The biggest issue in this area is keeping the CPUs fed with data because of the delay in accessing main memory to feed the cache.

Hope this helps. If I confused anyone, let me know and I'll try to fix it.

Okay, you couldn't actually split out the streams.......how about "DDR'ing" it: one process pings on the upswing, one on the downswing? I guess what I was asking is: Does this allow room for true multitasking across cores through some kind of on the fly configurable data path?

We're off into theory now and that's really what I'm getting at. I'm wondering if there's any reason not to effectively build a mobo that's every bit as much 2, 4 or 8 cored as the chip itself: IE why not Altivec the whole damn machine?
At some point technology will go there: running 2, 4 or 8 side by side tasks through the same wires. I know that much of this works like music; breaking out by factors of 2 with harmonic sweet spots and what amount to "octaves". So what's to say you couldn't oscillate the mobo at a given frequency@ so-many-bits-wide and assign data paths to key sub-harmonics of that master frequency?

I have always wondered about the idea of scaling data sent into the processor much the way the AltiVec engine does. The AltiVec engine can work on 3 simultanious 32-bit pieces of data, or it can scale 2 16-bit into the space of each of the three 32-bit processes, or even 4 8-bit ones. The thing is that these have to all have the same instruction being done to them.
Example:
you would have 32, 8-bit pieces of data having say 3 added to them each (a very useful trick when data corresponds to one another like animating a bouncing ball, you need all the points of the ball to correspond to one another, therefore add the same movement to each vector.

This is my interpretation based on all the info I have read about processors and I cannot be held accountable for any inaccuracies.

yeah but... its since its a 64bit bus, and how altivec works, breaking it down, like altivec right now allows for 4 32bit operations (128bit altivec engine) or 8 16bit, or 16 8bit operations at once. but now since its 64bit(256bit altivec) you can do 4 64bit, 8 32bit, 16 16bit, or 32 8bit. think about it.... plus these new G5's will feature an AMD Hypertransport bus allowing for around 12.8GB/sec of bandwith between the processor, the pci slots, agp slots, memory, and all the other **** like gigabit ethernet and firewire.. also on another not, if gigawire is going to run a 1.6GB/sec, and DDR266 provides 2.1GB/sec of bandwith, wouldnt that allow for huge allocations of ram via gigawire, and gigawire is supposed to top out at 3.2GB/sec, thats more than DDR333 memory!

MacRumors attracts a broad audience
of both consumers and professionals interested in
the latest technologies and products. We also boast an active community focused on
purchasing decisions and technical aspects of the iPhone, iPod, iPad, and Mac platforms.