An undisclosed amount of time ago we received 2 new PowerMacs for testing. These were in generic G4 cases but were painted another color (black). I doubt this is indicative of future case but an attempt to obfuscate what the real case will look like.
These 2 systems are similar to the last one we received. Both are G5 based running at speeds of 1.33GHz and 1.66GHz. As you can tell from these speeds, the RapidIO bus has been upgraded from 500MHz to 667MHz, most likely, in my opinion, to be more syncronous with a DDR-333 RAM option, although this is not as necessary as those to busses are not shared as they were with MPX. I beleive this processor also is limited to processing 32bit integers but memory addressing has been increased to the 40-48bit area. In the documentation it shows the motherboards having support for 64GB but that processor can access more in future motherboard implementations. Possibly as high as 4TB (42bit addressing). The heatsinks are minimal with no active cooling so higher speed processors are likely down the pipeline. These units have full support for PC2700 DDR-SDRAM and contain 3 slots on the card. AGP remains 4X (GeForce4 MX) and the standard 4 PCI slots are all operational. Testing will begin sometime today. I hope to have more details soon.
<strong>An undisclosed amount of time ago we received 2 new PowerMacs for testing. These were in generic G4 cases but were painted another color (black). I doubt this is indicative of future case but an attempt to obfuscate what the real case will look like.
These 2 systems are similar to the last one we received. Both are G5 based running at speeds of 1.33GHz and 1.66GHz. As you can tell from these speeds, the RapidIO bus has been upgraded from 500MHz to 667MHz, most likely, in my opinion, to be more syncronous with a DDR-333 RAM option, although this is not as necessary as those to busses are not shared as they were with MPX. I beleive this processor also is limited to processing 32bit integers but memory addressing has been increased to the 40-48bit area. In the documentation it shows the motherboards having support for 64GB but that processor can access more in future motherboard implementations. Possibly as high as 4TB (42bit addressing). The heatsinks are minimal with no active cooling so higher speed processors are likely down the pipeline. These units have full support for PC2700 DDR-SDRAM and contain 3 slots on the card. AGP remains 4X (GeForce4 MX) and the standard 4 PCI slots are all operational. Testing will begin sometime today. I hope to have more details soon.</strong><hr></blockquote>
perhaps we will see this machines in junuary, MWSF seems to close for the release of this machines wich seems to be still in beta developpement.
<strong>These 2 systems are similar to the last one we received. Both are G5 based running at speeds of 1.33GHz and 1.66GHz. As you can tell from these speeds, the RapidIO bus has been upgraded from 500MHz to 667MHz, most likely, in my opinion, to be more syncronous with a DDR-333 RAM option, although this is not as necessary as those to busses are not shared as they were with MPX. I beleive this processor also is limited to processing 32bit integers but memory addressing has been increased to the 40-48bit area.</strong><hr></blockquote>
It seems a bit odd to me that a "G5" based system would be limited to 32bit integers. For starters, how would you know? Do you have updated, 64bit compilers? As a programmer, my only way of testing would be to do a sizeof(int) in C. What method are you using?
Also, I don't mean to sound like a skeptic, but how about a few performance benchmarks in addition to the specs. It would seem to me that you are already breaking a NDA already just by discussing the specs, assuming one exists. So, let's see some performance benchmarks, please!
Won't the altivec still be able to issue higher than 32 bit instructions?
I'm dreaming of this spec come July.
I pray to Big G that Dorsal is right. Sounds like a scorcher...
I'm not bothered about spec marks. But could you give a 'perceptual' indication of performance on things like Photoshop or MORE importantly 3D app eg Lightwave, Maya, Cinema 4D framerates in Quack III? Does it seem twice as fast? How does it compare to PC boxes you've seen eg Pentium/Athlon?
Does it hang in FPU performance? An area the Athlon is strong on but the G4 is weaker on...
Come to think of it.
What is the G5 influence/factor on altivec? Does it drive altivec 'mini superchip on a chip' faster?
Who's making it. Motorola? Or IBM?
I just hope apple delivers.
If they don't, I wait until 2003. I've waited four year for my next Mac. I can wait a bit longer for 'the best'.
By your previous experience of receiving 'seed' machines...will this one be about ready for Seybold this year?
If not, what's holding up? Apple politics, Moto' yield problems? Motherboard issues? Or merely routine software /'x' on G5 testing issues...for incompatibility issues?
Another question...dual boxes? Do they roar like lions? Or squawk like Mcaws?
It seems a bit odd to me that a "G5" based system would be limited to 32bit integers. For starters, how would you know? Do you have updated, 64bit compilers? As a programmer, my only way of testing would be to do a sizeof(int) in C. What method are you using?
</strong><hr></blockquote>
sizeof(void*) would be a better test. On some 64-bit machines the type "int" (and even "long int") remains at 32-bits, with "long long int" used to get a 64-bit value.
This is probably the most disappointing DorsalM message I've seen -- it just doesn't sound very technically savvy. How does he know its a G5? Is this the Apple machine designation or the Motorola chip designation? Or just his supposition? The information about the physical addressing capabilities is a little odd...
If this is true, then the future of the Macintosh platform seems much, much brighter than predicted by some in some of the other active threads.
Can anyone who has tested PowerMacs, especially the first G4's, in the past under NDA describe the the state of the machines at certain intervals before the machine's release. This may give us a clue as to how long we have to wait for the DorsalMac G5. I would think that disclosure of this information would be perfectly legal as the NDA's would have long since expired.
Yes, However Dorsal ahs consistently been waaayyy early w/ his info. He gave the specs for the 1ghz/133 bus PMG4s long before they were released. He then had sweeter prototypes (or claimed to) before those G4s came out. Look back to the previous generation of prototypes (pre-G5) to get a better idea of what we might see come MWNY.
Dorsal's info has been surprisingly accurate, but we always expect to see the macs he talks about a good four-six months early.
I'd put these G5s at about Sept-November 2002, earliest.
I'd guess we'll get 1.4ghz G4/266mhz bus, rapid io, and raycer implementations this summer.
Dorsal's info has been surprisingly accurate, but we always expect to see the macs he talks about a good four-six months early.
</strong><hr></blockquote>
As Dorsal's first post in this topic was almost exactly 4 months before MWNY 2002, shouldn't you be concluding that them being announced at MWNY is at least quite probable?
sizeof(void*) would be a better test. On some 64-bit machines the type "int" (and even "long int") remains at 32-bits, with "long long int" used to get a 64-bit value.
This is probably the most disappointing DorsalM message I've seen -- it just doesn't sound very technically savvy. How does he know its a G5? Is this the Apple machine designation or the Motorola chip designation? Or just his supposition? The information about the physical addressing capabilities is a little odd...</strong><hr></blockquote>
Regarding the "sizeof()" this is why I specifically asked if he was using a new compiler. The chip being able to handle 64bit INTs is one thing, the compiler recogizing it is another. Yes, I would certainly check shorts, ints and longs. Still, this would only tell me if the compiler is able to recognize the 64bit hardware. I chose INTs for my example because the commonly accepted definition of a "64bit" chip is one which can has (at least) a 64bit address space and one which can natively handle 64bit INTs.
As for these Dorsal posts, I'm more than skeptical. My point is this, why go into details about the hardware, yet not even discuss the performance, other than in some vague sense. Even if he's full of BS, he could at least give us some BS benchmarks! <img src="graemlins/smokin.gif" border="0" alt="[Chilling]" /> Afterall, the point of all these rumors is entertainment, right? Along that line, I'd like to hear what his method of determining the INT size was.
As for these Dorsal posts, I'm more than skeptical. My point is this, why go into details about the hardware, yet not even discuss the performance, other than in some vague sense. Even if he's full of BS, he could at least give us some BS benchmarks!
Steve</strong><hr></blockquote>
I was wondering that too but then I thought if you were testing these machines speed isn't what you're looking for necessarily. It's stability, compatibility etc etc.I doubt these people can stick Q3Arena on it and frag its guts out
On a 32 bit proccessor, the assembly registers are EAX, EBX, EDX, etc. Those are the 32 bit registers. Now what are the 64 bit registers called?
I am taking an assembly class this semester (386 yuk), so it is all 16 bit stuff we are learning, but I was just wondering what the new registers would be accessed as.
On a 32 bit proccessor, the assembly registers are EAX, EBX, EDX, etc. Those are the 32 bit registers. Now what are the 64 bit registers called?
I am taking an assembly class this semester (386 yuk), so it is all 16 bit stuff we are learning, but I was just wondering what the new registers would be accessed as.</strong><hr></blockquote>
Your question only applies to AMD's x86-64 architecture as both Intel and Motorla are not using anything resembling x86 as their 64bit solutions, and you are only learning assembly for x86. x86-64 would rename EAX, EBX, EDX, etc. to RAX, RBX, RDX, etc. See diagram below.
The PowerPC registers are called R0-R31 for the integer registers, FR0-FR31 for the floating point unit, and VR0-VR31 for the vector unit. Or something like that. In a 64-bit implementation the R0-R31 registers just get bigger.
Its about time somebody adds more registers to the Intel instruction set... its just rather funny that its AMD!!
x86 processors really have a lot more registers than that, they are just not programmer accessible. Those shadow registers are used transparently (there can be some hinting from the compiler) and actually turn out to work quite well.
More bothersome is the format of the x86 operation format (a op b -> a) vs the PPC (a op b op c - > d). That really screws up the register situation.
<strong>x86 processors really have a lot more registers than that, they are just not programmer accessible. Those shadow registers are used transparently (there can be some hinting from the compiler) and actually turn out to work quite well.
More bothersome is the format of the x86 operation format (a op b -> a) vs the PPC (a op b op c - > d). That really screws up the register situation.</strong><hr></blockquote>
Yeah, the shadow registers help a lot, but it would be a lot more straightforward if they didn't have to. The x86 gets a lot more use out of its L1 cache as a result.
The other thing that would help the x86 would be making the setting of the CCR optional on a per-instruction basis. I've seen some very smart things done by compilers, allowing branch folding to happen.
The other thing that would help the x86 would be making the setting of the CCR optional on a per-instruction basis. I've seen some very smart things done by compilers, allowing branch folding to happen.</strong><hr></blockquote>
Yeah, I've always longed for some Creedence Clearwater Revival on a per-instruction basis.
You can also use r0-r7, right?</strong><hr></blockquote>
The assembler is pretty much free to name the register whatever it would want to. Im sure you could make a macro renaming all r0 references to RAX etc etc, or the assembler would support both naming schemes directly.
After all, the iportant thing is the binary code, not what the asm name of the instruction is ( or the register, for that matter).
Comments
These 2 systems are similar to the last one we received. Both are G5 based running at speeds of 1.33GHz and 1.66GHz. As you can tell from these speeds, the RapidIO bus has been upgraded from 500MHz to 667MHz, most likely, in my opinion, to be more syncronous with a DDR-333 RAM option, although this is not as necessary as those to busses are not shared as they were with MPX. I beleive this processor also is limited to processing 32bit integers but memory addressing has been increased to the 40-48bit area. In the documentation it shows the motherboards having support for 64GB but that processor can access more in future motherboard implementations. Possibly as high as 4TB (42bit addressing). The heatsinks are minimal with no active cooling so higher speed processors are likely down the pipeline. These units have full support for PC2700 DDR-SDRAM and contain 3 slots on the card. AGP remains 4X (GeForce4 MX) and the standard 4 PCI slots are all operational. Testing will begin sometime today. I hope to have more details soon.
<strong>An undisclosed amount of time ago we received 2 new PowerMacs for testing. These were in generic G4 cases but were painted another color (black). I doubt this is indicative of future case but an attempt to obfuscate what the real case will look like.
These 2 systems are similar to the last one we received. Both are G5 based running at speeds of 1.33GHz and 1.66GHz. As you can tell from these speeds, the RapidIO bus has been upgraded from 500MHz to 667MHz, most likely, in my opinion, to be more syncronous with a DDR-333 RAM option, although this is not as necessary as those to busses are not shared as they were with MPX. I beleive this processor also is limited to processing 32bit integers but memory addressing has been increased to the 40-48bit area. In the documentation it shows the motherboards having support for 64GB but that processor can access more in future motherboard implementations. Possibly as high as 4TB (42bit addressing). The heatsinks are minimal with no active cooling so higher speed processors are likely down the pipeline. These units have full support for PC2700 DDR-SDRAM and contain 3 slots on the card. AGP remains 4X (GeForce4 MX) and the standard 4 PCI slots are all operational. Testing will begin sometime today. I hope to have more details soon.</strong><hr></blockquote>
perhaps we will see this machines in junuary, MWSF seems to close for the release of this machines wich seems to be still in beta developpement.
<strong>These 2 systems are similar to the last one we received. Both are G5 based running at speeds of 1.33GHz and 1.66GHz. As you can tell from these speeds, the RapidIO bus has been upgraded from 500MHz to 667MHz, most likely, in my opinion, to be more syncronous with a DDR-333 RAM option, although this is not as necessary as those to busses are not shared as they were with MPX. I beleive this processor also is limited to processing 32bit integers but memory addressing has been increased to the 40-48bit area.</strong><hr></blockquote>
It seems a bit odd to me that a "G5" based system would be limited to 32bit integers. For starters, how would you know? Do you have updated, 64bit compilers? As a programmer, my only way of testing would be to do a sizeof(int) in C. What method are you using?
Also, I don't mean to sound like a skeptic, but how about a few performance benchmarks in addition to the specs. It would seem to me that you are already breaking a NDA already just by discussing the specs, assuming one exists. So, let's see some performance benchmarks, please!
Thanks!
Steve
But isn't the first iteration of the G5 32 bit?
Won't the altivec still be able to issue higher than 32 bit instructions?
I'm dreaming of this spec come July.
I pray to Big G that Dorsal is right. Sounds like a scorcher...
I'm not bothered about spec marks. But could you give a 'perceptual' indication of performance on things like Photoshop or MORE importantly 3D app eg Lightwave, Maya, Cinema 4D framerates in Quack III? Does it seem twice as fast? How does it compare to PC boxes you've seen eg Pentium/Athlon?
Does it hang in FPU performance? An area the Athlon is strong on but the G4 is weaker on...
Come to think of it.
What is the G5 influence/factor on altivec? Does it drive altivec 'mini superchip on a chip' faster?
Who's making it. Motorola? Or IBM?
I just hope apple delivers.
If they don't, I wait until 2003. I've waited four year for my next Mac. I can wait a bit longer for 'the best'.
By your previous experience of receiving 'seed' machines...will this one be about ready for Seybold this year?
If not, what's holding up? Apple politics, Moto' yield problems? Motherboard issues? Or merely routine software /'x' on G5 testing issues...for incompatibility issues?
Another question...dual boxes? Do they roar like lions? Or squawk like Mcaws?
Lemon Bon Bon
<strong>
It seems a bit odd to me that a "G5" based system would be limited to 32bit integers. For starters, how would you know? Do you have updated, 64bit compilers? As a programmer, my only way of testing would be to do a sizeof(int) in C. What method are you using?
</strong><hr></blockquote>
sizeof(void*) would be a better test. On some 64-bit machines the type "int" (and even "long int") remains at 32-bits, with "long long int" used to get a 64-bit value.
This is probably the most disappointing DorsalM message I've seen -- it just doesn't sound very technically savvy. How does he know its a G5? Is this the Apple machine designation or the Motorola chip designation? Or just his supposition? The information about the physical addressing capabilities is a little odd...
Can anyone who has tested PowerMacs, especially the first G4's, in the past under NDA describe the the state of the machines at certain intervals before the machine's release. This may give us a clue as to how long we have to wait for the DorsalMac G5. I would think that disclosure of this information would be perfectly legal as the NDA's would have long since expired.
Dorsal's info has been surprisingly accurate, but we always expect to see the macs he talks about a good four-six months early.
I'd put these G5s at about Sept-November 2002, earliest.
I'd guess we'll get 1.4ghz G4/266mhz bus, rapid io, and raycer implementations this summer.
<strong>
Dorsal's info has been surprisingly accurate, but we always expect to see the macs he talks about a good four-six months early.
</strong><hr></blockquote>
As Dorsal's first post in this topic was almost exactly 4 months before MWNY 2002, shouldn't you be concluding that them being announced at MWNY is at least quite probable?
<strong>
sizeof(void*) would be a better test. On some 64-bit machines the type "int" (and even "long int") remains at 32-bits, with "long long int" used to get a 64-bit value.
This is probably the most disappointing DorsalM message I've seen -- it just doesn't sound very technically savvy. How does he know its a G5? Is this the Apple machine designation or the Motorola chip designation? Or just his supposition? The information about the physical addressing capabilities is a little odd...</strong><hr></blockquote>
Regarding the "sizeof()" this is why I specifically asked if he was using a new compiler. The chip being able to handle 64bit INTs is one thing, the compiler recogizing it is another. Yes, I would certainly check shorts, ints and longs. Still, this would only tell me if the compiler is able to recognize the 64bit hardware. I chose INTs for my example because the commonly accepted definition of a "64bit" chip is one which can has (at least) a 64bit address space and one which can natively handle 64bit INTs.
As for these Dorsal posts, I'm more than skeptical. My point is this, why go into details about the hardware, yet not even discuss the performance, other than in some vague sense. Even if he's full of BS, he could at least give us some BS benchmarks! <img src="graemlins/smokin.gif" border="0" alt="[Chilling]" /> Afterall, the point of all these rumors is entertainment, right? Along that line, I'd like to hear what his method of determining the INT size was.
Steve
<strong>
As for these Dorsal posts, I'm more than skeptical. My point is this, why go into details about the hardware, yet not even discuss the performance, other than in some vague sense. Even if he's full of BS, he could at least give us some BS benchmarks!
Steve</strong><hr></blockquote>
I was wondering that too but then I thought if you were testing these machines speed isn't what you're looking for necessarily. It's stability, compatibility etc etc.I doubt these people can stick Q3Arena on it and frag its guts out
Lemon Bon Bon
On a 32 bit proccessor, the assembly registers are EAX, EBX, EDX, etc. Those are the 32 bit registers. Now what are the 64 bit registers called?
I am taking an assembly class this semester (386 yuk), so it is all 16 bit stuff we are learning, but I was just wondering what the new registers would be accessed as.
<strong>Question:
On a 32 bit proccessor, the assembly registers are EAX, EBX, EDX, etc. Those are the 32 bit registers. Now what are the 64 bit registers called?
I am taking an assembly class this semester (386 yuk), so it is all 16 bit stuff we are learning, but I was just wondering what the new registers would be accessed as.</strong><hr></blockquote>
Your question only applies to AMD's x86-64 architecture as both Intel and Motorla are not using anything resembling x86 as their 64bit solutions, and you are only learning assembly for x86. x86-64 would rename EAX, EBX, EDX, etc. to RAX, RBX, RDX, etc. See diagram below.
Its about time somebody adds more registers to the Intel instruction set... its just rather funny that its AMD!!
More bothersome is the format of the x86 operation format (a op b -> a) vs the PPC (a op b op c - > d). That really screws up the register situation.
<strong>x86 processors really have a lot more registers than that, they are just not programmer accessible. Those shadow registers are used transparently (there can be some hinting from the compiler) and actually turn out to work quite well.
More bothersome is the format of the x86 operation format (a op b -> a) vs the PPC (a op b op c - > d). That really screws up the register situation.</strong><hr></blockquote>
Yeah, the shadow registers help a lot, but it would be a lot more straightforward if they didn't have to. The x86 gets a lot more use out of its L1 cache as a result.
The other thing that would help the x86 would be making the setting of the CCR optional on a per-instruction basis. I've seen some very smart things done by compilers, allowing branch folding to happen.
<strong>
The other thing that would help the x86 would be making the setting of the CCR optional on a per-instruction basis. I've seen some very smart things done by compilers, allowing branch folding to happen.</strong><hr></blockquote>
Yeah, I've always longed for some Creedence Clearwater Revival on a per-instruction basis.
You can also use r0-r7, right?
<strong>
You can also use r0-r7, right?</strong><hr></blockquote>
The assembler is pretty much free to name the register whatever it would want to. Im sure you could make a macro renaming all r0 references to RAX etc etc, or the assembler would support both naming schemes directly.
After all, the iportant thing is the binary code, not what the asm name of the instruction is ( or the register, for that matter).
<strong>
Yeah, I've always longed for some Creedence Clearwater Revival on a per-instruction basis.
Heh. I always thought the band's name stood for "Condition Code Register".
:eek: