Does Conroe emulate 64-bit or not?

I think you guys are missreprenting what I said. MS did not have programmers waiting for Intel to get around to jumping on the x86-64 bandwagon. What I did say, or what I was trying to convey, is that MS had no real motivation to get XP 64-bit to market until there was more of a market than JUST AMD. I have reps at all three companies...back around that time, AMD was all about trying to get MS to release XP 64-bit before Intel had a product that would work with it. Microsoft was in NO RUSH to release a piece of software to such a niche audience (its not like everyone with an A64 bought XP 64-bit when it became availabe, hell there are alot of ppl that still don't own it or have tried it). That is until both AMD and Intel had compatible processors...there were no programmers sitting around...XP 64-bit was done before Intel released EM64T, but it wasn't forsale until after they hit the market.

I had the "beta" XP 64-bit running way before it went gold through MSDN. And that beta looks and feels a whole lot like the final version.
 
Donnie27 said:
Sure, but anything can be coded for! Appple proved that.
Click to expand...

Misinformation and !!!!!!ism....

If your talkin about PPC, then you should stop now. PPC was, and is one of the best general purpose architectures available today.
 
duby229 said:
Misinformation and !!!!!!ism....

If your talkin about PPC, then you should stop now. PPC was, and is one of the best general purpose architectures available today.
Click to expand...

You're just hard headed. Turn off SIMD's and see what in the hell happens? Oh, that's right, you don't know do ya'. You're example of what's wrong with Fans! Besides that, do you have something personal against me?
 
Donnie27 said:
You're just hard headed. Turn off SIMD's and see what in the hell happens? Oh, that's right, you don't know do ya'. You're example of what's wrong with Fans! Besides that, do you have something personal against me?
Click to expand...

Not at all. I dont hold anything against anyone.

It's just that you tend to argue with me about everything I post, and yet it is you who dont have a clue what your talkin about. Before you decide to bash PPC specifically Altivec, then maybe you should go read a book about it...

Think abou it like this.... Lets turn off SSE in the P4, or the Conroe, and see what happens. Same thing. Any argument that you make can easily be flipped the other way.

I wonder why every single one of the next gen game consoles will be using some derivitive of a PPC architecture? hmmmm

Getting back to the topic on hand does Conroe support 64bit? Yes it is a true 64bit chip. And becouse of the architectural advancements made, it should also be able to take advantage of the extra GPR's pretty well too...
 
ToastMaster said:
Um, it's well known that K8 is a heavily-modified, 64-bit K7 (as you yourself just related to).

Now, while P4 may not be identical to the P3 or K7/K8, it is still an x86 architecture. Did it take Intel time to implement it? Yes. However, read any breakdown of the EMT64, and read Intel's own publishings on it, and you will see that they made use of the work AMD had already done. EMT64 is essentially AMD64 modified for the P4, with some instructions designed solely for K8 removed, and replaced with instructions that Intel desired.

I think you yourself need to read up a little on the history of AMD 64 and EMT64.

Oh, and the concept of adapting to 64-bit doesn't seem difficult: the actual taking of a 32-bit x86 architecture, and modifying it for 64-bit is a time-consuming, somewhat difficult feat, especially for a company with at the time a single engineering design team (AMD).

If it weren't difficult, it wouldn't have taken them 4+ years to implement. :)
Click to expand...

The fact that P4 and K8 are both x86 architectures means absolutely nothing. From front to back, through microcode and datapth, everything is totally different. The only thing intel took from AMD64 is the new instructions, and beyond that, it is all new work in-house. Much like AMD taking SSE* instructions and doing the backend implementation on the K8.

What intel papers state that intel used AMD work to come up with a EM64T implementation? Because AMD wouldn't even release such information in the first place, and even if they did, it'd be totally useless for the P4 design team.

As for the difficulty of 64-bits, is that the only difference between K7 and K8? There's plenty more work to be done to take 4 years. Is 64-bit support easy? Of course not. Is it so difficult as to take 4+ years? Hell no. EM64T took the prescott team less than six months to code and validate, as I recall, and no, they didn't use any tidbits from AMD.

And save your arrogance for someone else, thanks.
 
eno-on said:
If I drop a V8 into my car, which was previously an I4, are you saying that my car isnt REALLLLY a V8 because, well, it started life with an I4?
That's what you are implying. Which makes very, very little sense.
Alphas were 64 bit years ago, btw.
Click to expand...


i liked this post but i think you went about it wrong. what you would compare it to would be if a car maker went from making a car with an I4 and then a year or 2 later made the car with V8, or gave the option of v8 from factory. this would seem more comparable to the situation.
 
CEREAL_KILLER said:
i liked this post but i think you went about it wrong. what you would compare it to would be if a car maker went from making a car with an I4 and then a year or 2 later made the car with V8, or gave the option of v8 from factory. this would seem more comparable to the situation.
Click to expand...

It still needs to be tweaked some more. A car engine is like the CPU of a computer. So if you swapped engines it's just like upgrading to a new CPU. A more apt example would be to go from a carburator (god I've worked on cars to 20 years and still can't spelled that right) to a more efficient port injection system while keeping the same motor.
 
dmens said:
The fact that P4 and K8 are both x86 architectures means absolutely nothing. From front to back, through microcode and datapth, everything is totally different. The only thing intel took from AMD64 is the new instructions, and beyond that, it is all new work in-house. Much like AMD taking SSE* instructions and doing the backend implementation on the K8.

What intel papers state that intel used AMD work to come up with a EM64T implementation? Because AMD wouldn't even release such information in the first place, and even if they did, it'd be totally useless for the P4 design team.

As for the difficulty of 64-bits, is that the only difference between K7 and K8? There's plenty more work to be done to take 4 years. Is 64-bit support easy? Of course not. Is it so difficult as to take 4+ years? Hell no. EM64T took the prescott team less than six months to code and validate, as I recall, and no, they didn't use any tidbits from AMD.

And save your arrogance for someone else, thanks.
Click to expand...


Intel reverse engineered AMD64

Crawl back under your rock. Thanks.

Anyone with any working knowledge of how instruction sets are implemented and how the design team implemented EMT64, could tell you that Intel made use of the cross-licensing deal with AMD for x86, and utilized the work that AMD did. Is the P4 an identical architecture to the K8? Ofcourse not. However, they're both based upon x86 and as such, the 32-bit elements of x86 that the P4 does make use of, can be modified in a much similar way to how AMD modified the K8, thus allowing EMT64 to be implemented.

The Netburst architecture is different from K8, but it still is an x86 architecture at its core. Thus, if you already have a working plan (AMD's) of how to begin modifying x86, Intel had a jump on how to make the modifications. You seem to think that AMD simply tacked on 64-bit registers compared to the previous 32-bit, developed the instruction set, and *poof* 64-bit Athlon 64. Sorry to break it to you, that's not how it works.
 
ryan_975 said:
They may have RE'd AMD64, but all that told them is what the top leverl instructions were supposed to do. They still have to break those instruction into microcode that was compatible with P4's execution units
Click to expand...

Yes, and that is an area that I never said Intel had copied AMD.

Remember though, an architecture is much more than simply how it breaks down microcode for execution.
 
ToastMaster said:
Yes, and that is an area that I never said Intel had copied AMD.

Remember though, an architecture is much more than simply how it breaks down microcode for execution.
Click to expand...

All in all Netburst, P6, K7, and k8 are not x86 at their cores. they have to break the x86 instructions into their native micro ops whatever they may be.
 
ToastMaster said:
Anyone with any working knowledge of how instruction sets are implemented and how the design team implemented EMT64, could tell you that Intel made use of the cross-licensing deal with AMD for x86, and utilized the work that AMD did. Is the P4 an identical architecture to the K8? Ofcourse not. However, they're both based upon x86 and as such, the 32-bit elements of x86 that the P4 does make use of, can be modified in a much similar way to how AMD modified the K8, thus allowing EMT64 to be implemented.

The Netburst architecture is different from K8, but it still is an x86 architecture at its core. Thus, if you already have a working plan (AMD's) of how to begin modifying x86, Intel had a jump on how to make the modifications. You seem to think that AMD simply tacked on 64-bit registers compared to the previous 32-bit, developed the instruction set, and *poof* 64-bit Athlon 64. Sorry to break it to you, that's not how it works.
Click to expand...

OK, since I'm actually a member of that design team, I can tell you right away that the P4 backend has absolutely no "elements" in common with the K8 backend, whatever the hell "elements" is supposed to be. Whatever AMD did in the K8 backend does not apply on a P4 backend. Get it?

Hey, I know exactly how the 64-bit GPR's work, and yeah, it's more than just tacking on the extended GPR's for uarch state. But since you seem to think that there are "elements" which are common on both P4 and K8, care to extrapolate which ones matter for 64-bit operation?
 
ToastMaster said:
Yes, and that is an area that I never said Intel had copied AMD.

Remember though, an architecture is much more than simply how it breaks down microcode for execution.
Click to expand...

On the contrary, the functional backend is just that... processing microcode generated uops. That's it.
 
dmens said:
OMG you're stupid as hell. I've already stated that Intel took AMD64 instructions to create the EM64T specification. AMD was first to spec, so Intel had to follow. But the implementation protocols in P4 are entirely new, because K8 is not P4. DUH!

There's a *HUGE* difference between copying a specification, and reverse-engineering an implementation.

That analyst is an idiot, the guy who wrote the article is an idiot, and you are an idiot.
Click to expand...

LOL. So here's the funny thing about all of this: an instruction set is useless without the supporting architecture to operate it.

Thus, if Intel had *only* reverse-engineered AMD's instruction set, what use would it have been? The AMD64 instruction set *requires* that the architectural changes be in place, i.e. x86-64.

Now, are there changes between the P4 and the K8? Obviously. No fool would say otherwise. Issues such as the number of FPUs, ALUs, the width, length and number of pipelines, etc. are all major differences between the two architectures. But these don't define the x86 architecture itself.

Think of it this way: AMD first modified the x86 architecture at its very core, such as changing registers over to 64-bit, expanding the number of registers from 8 to 16, etc., all to update x86 to being a 64-bit implementation. The Athlon 64 line is one implementation of x86-64 that makes use of th AMD64 accompanying instruction set. Nocona, Prescott, and later models of the P4 are all versions of x86-64 that implement EMT64 (derived from AMD64), and have larger architectural differences in terms of how it executes the code that it handles. However, remember that even though there are differences in the pipeline design, etc. of all of these, a pipeline is nothing more than a means at which to cut-down on the time to execute instructions, themselves derived due to x86.

The simplest way I can put it is, it takes a lot of time to expand the x86 architecture. You should maybe do some research and look how long it took Intel to expand it from a 16-bit to a 32-bit architecture. Intel in the late 90's, decided against expanding x86, feeling that once 32-bit systems had run their course, a different architecture would be in place. AMD went with expanding it, and thus developed x86-64. Intel ultimately decided to take this route, reverse-engineered AMD's x86 designs (remember, they have a cross-licensing deal and thus Intel has every right to do so), and implemented it into Prescott at the same time they were modifying Netburst. Do you think it's a coincedence that it went into Prescott, the first major overhaul of Netburst that required essentially beginning with x86 from the beginning and enhancing it? I don't think so.

Thus, I don't see what the big deal is. Had Intel not reverse-engineered AMD's work, it would have taken longer for them to release a 64-bit P4. As Donnie has pointed out, they've now improved upon EMT64 quite a bit, and they should be applauded. However, the fact remains, that knowing that MS was going in a 64-bit Windows XP direction that supported AMD's x86-64 architecture, how can you possibly say that Intel didn't actually modify it and use it as well? I think part of the confusion here is that people tend to view AMD64 as only an instruction set, when in reality, it's the name for what AMD originally called x86-64. Intel named x86-64 EMT64, and AMD renamed theirs AMD64.

Oh, and for clarification:
"In February of 2004, Intel introduced another, more radical revision of the architecture called Prescott. The Prescott was produced on a 90 nm process, and included several major design changes, including the addition of an even larger cache (from 512KB in the Northwood to 1MB, and later 2MB), a much larger instruction pipeline (31 stages as compared to 20 in the Northwood), a heavily improved branch predictor, the introduction of the SSE3 SIMD instructions, and later, the implementation of EM64T, Intel's branding for their compatible implementation of the AMD64 64-bit version of the x86 architecture (as with hyper-threading, all Prescott chips have hardware to support this feature, but it was initially only enabled on high-end Xeon processors before being officially introduced in processors with the Pentium brand)."

Wiki article in Netburst

And I'm sorry for my hostility. I've been having a bad day, and I'm unfairly taking it out on others.
 
ToastMaster said:
LOL. So here's the funny thing about all of this: an instruction set is useless without the supporting architecture to operate it.

Thus, if Intel had *only* reverse-engineered AMD's instruction set, what use would it have been? The AMD64 instruction set *requires* that the architectural changes be in place, i.e. x86-64..
Click to expand...


The use would have been to see how the instruction act so they could omplement the hardware requirements that came up with the same results when an AMD64 instruction was called.
 
dmens said:
OMG you're stupid as hell. I've already stated that Intel took AMD64 instructions to create the EM64T specification. AMD was first to spec, so Intel had to follow. But the implementation protocols in P4 are entirely new, because K8 is not P4. DUH!
Click to expand...
I'm glad you decided to register here, but you'll probably start getting warnings from mods or banned if you make personal insults. :p

Since you're here, how about answering a couple of questions about Yamhill/EM64T? As early as March 2003, Hans De Vries found clues to Yamhill in Prescott die photos. That was about a month before the K8 was previewed around the Internet. My questions: When was Yamhill finally given a go ahead? Is it correct that the decision to add Yamhill was made before the first K8 shipped?
----

I don't know why people think "AMD64" is some kind of revolutionary change. It's mostly a logical extension to iA32 that thankfully (finally) increased the GPR count. But it's less of a change than what Intel did between the 286 and 386.
 
ToastMaster said:
LOL. So here's the funny thing about all of this: an instruction set is useless without the supporting architecture to operate it.

Thus, if Intel had *only* reverse-engineered AMD's instruction set, what use would it have been? The AMD64 instruction set *requires* that the architectural changes be in place, i.e. x86-64.

Now, are there changes between the P4 and the K8? Obviously. No fool would say otherwise. Issues such as the number of FPUs, ALUs, the width, length and number of pipelines, etc. are all major differences between the two architectures. But these don't define the x86 architecture itself.

Think of it this way: AMD first modified the x86 architecture at its very core, such as changing registers over to 64-bit, expanding the number of registers from 8 to 16, etc., all to update x86 to being a 64-bit implementation. The Athlon 64 line is one implementation of x86-64 that makes use of th AMD64 accompanying instruction set. Nocona, Prescott, and later models of the P4 are all versions of x86-64 that implement EMT64 (derived from AMD64), and have larger architectural differences in terms of how it executes the code that it handles. However, remember that even though there are differences in the pipeline design, etc. of all of these, a pipeline is nothing more than a means at which to cut-down on the time to execute instructions, themselves derived due to x86.

The simplest way I can put it is, it takes a lot of time to expand the x86 architecture. You should maybe do some research and look how long it took Intel to expand it from a 16-bit to a 32-bit architecture. Intel in the late 90's, decided against expanding x86, feeling that once 32-bit systems had run their course, a different architecture would be in place. AMD went with expanding it, and thus developed x86-64. Intel ultimately decided to take this route, reverse-engineered AMD's x86 designs (remember, they have a cross-licensing deal and thus Intel has every right to do so), and implemented it into Prescott at the same time they were modifying Netburst. Do you think it's a coincedence that it went into Prescott, the first major overhaul of Netburst that required essentially beginning with x86 from the beginning and enhancing it? I don't think so.

Thus, I don't see what the big deal is. Had Intel not reverse-engineered AMD's work, it would have taken longer for them to release a 64-bit P4. As Donnie has pointed out, they've now improved upon EMT64 quite a bit, and they should be applauded. However, the fact remains, that knowing that MS was going in a 64-bit Windows XP direction that supported AMD's x86-64 architecture, how can you possibly say that Intel didn't actually modify it and use it as well? I think part of the confusion here is that people tend to view AMD64 as only an instruction set, when in reality, it's the name for what AMD originally called x86-64. Intel named x86-64 EMT64, and AMD renamed theirs AMD64.
Click to expand...

You got the design process wrong. First you come up with the specification. In this casee, intel got the list of new instructions and their functionality. Then the designers go figure out how to make the P4 execute the new functionality. The instruction set is nothing more than a meta-definition, not even a direct definition. How do you reverse engineer the instruction set? It is right there on AMD's website.

"A pipeline is nothing more than a means at which to cut-down on the time to execute instructions, themselves derived due to x86". I cannot disagree with that more. The pipeline organization defines all high-level implementation protocols on a processor. Add on the fact that P4 and K8 have nothing in common to begin with, dataflow or control, what good would the K8 implementation be to a P4 designer? Nada.

The 16-bit to 32-bit transition was but one factor in the old days, where processor performance basically doubled every generation. There were many different factors back then, none of which can be applied to the 32 to 64 transition.

You keep insisting intel "reverse-engineered" (read:copied) AMD's design. That is just completely absurd. Like I've been saying, even if intel knew the exact details of how to make the new instructions work on a K8, it would not have helped the P4 design team, and prescott would've taped out at the exact same time. The prescott overhaul of netburst had nothing to with the x86 uarch, which only matters to the frontend anyways. The vast majority of changes were in the backend, which does not even deal with the x86 definition. In the whole scope of things, EM64T was one of the easier tasks on prescott.

Oh, just to disprove the "reverse-engineering" argument once and for all, even if intel had some strange desire to figure out the implementation details of AMD64 on a K8, it'd take far longer than figuring it out independently. Reverse-engineering these days is a monstrously complex task. Just look at how long it took the chinese to come out with their crappy MIPS clone.
 
pxc said:
Since you're here, how about answering a couple of questions about Yamhill/EM64T? As early as March 2003, Hans De Vries found clues to Yamhill in Prescott die photos. That was about a month before the K8 was previewed around the Internet. My questions: When was Yamhill finally given a go ahead? Is it correct that the decision to add Yamhill was made before the first K8 shipped?
----

I don't know why people think "AMD64" is some kind of revolutionary change. It's mostly a logical extension to iA32 that thankfully (finally) increased the GPR count. But it's less of a change than what Intel did between the 286 and 386.
Click to expand...

Good point, prescott taped out with EM64T on-die before K8 was unveiled, and EM64T itself was approved and designed long before that, during the initial definition. So K8 shipping had nothing to do with the decision to add 64-bit support, but then again, everyone knew AMD was going to be first out the door...
 
So basically Intel adapted AMD's 64 bit extension to their uarch. Is that more acurate than saying they RE'd it
 
dmens said:
Good point, prescott taped out with EM64T on-die before K8 was unveiled, and EM64T itself was approved and designed long before that, during the initial definition. So K8 shipping had nothing to do with the decision to add 64-bit support, but then again, everyone knew AMD was going to be first out the door...
Click to expand...

Prescott first taped out in May 2003, while K8 was unveiled in early 2002. Now if you mean it taped out before K8 was officially released, then yes that is correct.
 
ToastMaster said:
Prescott first taped out in May 2003, while K8 was unveiled in early 2002. Now if you mean it taped out before K8 was officially released, then yes that is correct.
Click to expand...

Right. And prescott definition started before 2002.
 
dmens said:
Oh, just to disprove the "reverse-engineering" argument once and for all, even if intel had some strange desire to figure out the implementation details of AMD64 on a K8, it'd take far longer than figuring it out independently. Reverse-engineering these days is a monstrously complex task. Just look at how long it took the chinese to come out with their crappy MIPS clone.
Click to expand...

Ok, so as I just stated, Prescott taped out in May of 2003. Now as you yourself said earlier, it supposedly took Intel 6 months to implement EMT64. Now, K8 was unveiled to the public in early 2002, or over a year before, and AMD has been working on the design since 1999.

Now, remember also that due to the cross-licensing deal between AMD and Intel, Intel is free to see and use any changes that AMD did to x86, and make use of them (just as AMD is allowed to make use of any changes Intel does: i.e., SSE, etc.)

I think another interesting piece of evidence is that two instruction sets not present in EMT64 initially (not added until G1) were the LAHF and SAHF instructions. These are notable as having been originally included in AMD's designs for implementation, and then before released, they removed them. Intel, *possibly* following AMD's architectural differences, didn't implement them into EMT64 either. Ultimately, AMD did put it back in, and thus has been supported. Intel only added them in later. This is my own opinion, so please take note of that, but it seems more likely to me that Intel's official public line was that they didnt see a need for consumer 64-bit processors, but they implemented it while working on Prescott, making use of work AMD had already done. Thus, you are correct dmens in that they didn't reverse-engineer it. From my perspective, they likely simply saw the changes AMD had already made as well as were still working it ,and followed suit with their own. AMD was still the one who began the process of adapting x86 to 64-bit however, as I've never seen anyone in the industry say that Intel adopted the x86 architecture to 64-bit also separately from the work AMD did. If you have an article supporting that, I'd stand corrected. :)
 
dmens said:
Right. And prescott definition started before 2002.
Click to expand...

And AMD64/K8 work began before 2000.

Edit - And AMD actually unveiled the K8 in late 2001, as they were showing off Clawhammer in working form already in Feb. 2002.
 
There were always rumors that Intel was working on a x86-64 implementation. I would lean towards the fact that Intel had some sort of x86-64 implemenation in their labs, but to let that get out when they were trying to push Itanium so hard would have been a big WTF.

I don't know if it was fact or not as they were always reported as rumors, but a good deal of the speculation was being tossed around by trade mags back when Intel was basically handed Alpha on a silver platter by HP, and was pushing hard to promote its own Itanium architecture. Damn Intel...the Alpha chip could scale like a mofo...too bad all that's left of it is bits and pieces of tech integrated into other chips
 
hardwarephreak said:
There were always rumors that Intel was working on a x86-64 implementation. I would lean towards the fact that Intel had some sort of x86-64 implemenation in their labs, but to let that get out when they were trying to push Itanium so hard would have been a big WTF.

I don't know if it was fact or not as they were always reported as rumors, but a good deal of the speculation was being tossed around by trade mags back when Intel was basically handed Alpha on a silver platter by HP, and was pushing hard to promote its own Itanium architecture. Damn Intel...the Alpha chip could scale like a mofo...too bad all that's left of it is bits and pieces of tech integrated into other chips
Click to expand...

The DEC Alpha was an awesome chip. The Power architecture isn't bad either.

And I don't recall any actual rumors concerning developing x86-64 I remember that they were considering extending x86, but ultimately decided to go with an entirerly new architecture (IA-64), that they had hoped would ultimately at some point find its way to the consumer market as well. However, that obviously never did and likely never will come to pass. :p

It could be however that they had started work. All I am sure of is that AMD has recieved credit for being the company that actually did extend/adapt x86 to 64 bit.
 
hardwarephreak said:
There were always rumors that Intel was working on a x86-64 implementation.
Click to expand...
"Yamhill" had been popping up in rumors since late 2001. And that it had taped out in early 2003 shows it was in design for longer than that.

ToastMaster said:
And I don't recall any actual rumors concerning developing x86-64 I remember that they were considering extending x86, but ultimately decided to go with an entirerly new architecture (IA-64),
Click to expand...
Intel did consider extending x86 to 64 bits way back when. Itanium is for a completely different segment than desktops and small servers.

I'll post where Intel had considered extending x86 to 64-bits when I find the link.

(edit) I knew i'd find it. :D Intel rejected extending x86 to 64-bit when designing the P6 (Pentium Pro): http://groups.google.com/group/comp...lr=&ie=UTF-8&group=comp.arch#94a1fd3e9797b655

From: Andy Glew - view profile
Date: Tues, Mar 9 2004 8:46 am
Email: "Andy Glew" <[email protected]>
Groups: comp.arch

> > If Gelsinger says we're soon going to have chips made up of lots of
> > little cores and almost all code now being written is single-threaded,

> [Who is this Gelsinger, and where did he say this? Not that I think he's
> wrong, mind.]

Pat Gelsinger, some VP, probably CEO in training, of Intel.
Exactly what he's a VP of I don't know.
"Pseudo-CTO?"

One of the co-fathers of the i386.

My biggest memory of Pat is trying to persuade him to
let us add a 64 bit extension to the P6: explaining
that it was unreasonable to expect any 64 bit extension,
RISC or otherwise, to cain more than 15% performance.
This was just prior to the original P7 RISCy 64 bit extension
being cancelleed, and the VLIW 64 bit extension starting up.
Click to expand...
 
duby229 said:
Not at all. I dont hold anything against anyone.

It's just that you tend to argue with me about everything I post, and yet it is you who dont have a clue what your talkin about. Before you decide to bash PPC specifically Altivec, then maybe you should go read a book about it...

Think abou it like this.... Lets turn off SSE in the P4, or the Conroe, and see what happens. Same thing. Any argument that you make can easily be flipped the other way.

I wonder why every single one of the next gen game consoles will be using some derivitive of a PPC architecture? hmmmm

Getting back to the topic on hand does Conroe support 64bit? Yes it is a true 64bit chip. And becouse of the architectural advancements made, it should also be able to take advantage of the extra GPR's pretty well too...
Click to expand...

Turn off Altivec and see what happens that's all I said. It's not Rocket Science, just someone who's done it before. Since you haven't, you don't know=P Please stop while you're ahead LOL!

If you didn't suffer from short term memory lost, you'd remember me telling you all modern CPUs depend on SIMD to a certain extent. Not that they can't run without them but that they (SIMDs) speed things up. So please flip it around, you help me make my point. Meaning, anything can be coded for.

I already gave links to Conroe and Woodcrest running 64bit software, from Tech-Report, you forgot!

http://techreport.com/etc/2006q2/woodcrest/index.x?pg=1

Tech Report said:
SiSoft Sandra 2007 1098 64-bit
CPU-Z 1.33
Cinebench 9.5
POV-Ray for Windows 3.6.1 64-bit
SMPOV 4.6
3ds max 8
Windows Media Encoder 9 x64 Edition
Xmpeg 5.0.3 with DivX 6.2
LAME MT 3.97a 64-bit
Sphinx 3.3
picCOLOR 4.0 build 561 64-bit
Click to expand...

Sad part is, I already linked you to that. So you don't forget again, save this one before you try to preach to me about how Netburst sucks?

http://www.hkepc.com/bbs/news.php?tid=621654&starttime=0&endtime=0

On July 23 Intel will be releasing its next-generation x86 architecture, the one that will put it back in a full leadership position in the x86 space. The Core 2 architecture contains many features that make the Core 2 family performs better than AMD's chips. Yet most of the testings are based on 32-bit environment, one would wonder if the Core 2 still led in the 64-bit environment. The answer is sure, but with less performance gain than Pentium 4.

According to the internal document from the manufacturers (Intel Core 2 Extreme X6800 VS AMD Athlon 64 FX 62 & Intel Pentium XE 965), Pentium XE 965 could perform 5-10% (2-3% for Athlon 64 FX 62) better in 64-bit, Core 2 however was found no obvious boost.

The introduction of a macro-op fusion, where two instructions are executed simultaneously, will provide enhancements of floating point operations. The design of such implementation in Core 2 is based on 32-bit. But 64-bit environment contains less operation, Fusion is less useful. The case is similar to K8. Netburst however is an outstanding in the performance gain in 64-bit environment. The Trace Cache design in Pentium 4 benefits a longer instruction, in which will offer another 10-15% boost in 64-bit environment. In conclusion, Intel Core 2 family would provide a very good performance in 64-bit as in 32-bit, yet it’s no more gain between twos.
Click to expand...

So here you have Donnie27 reporting a Chink in Conroe's Armor while you still seem very partial to AMD, please give up Duby or I'll just simply stop posting to you. Here we have this site saying Core doesn't gain from 64bit. Optimization is the main reason why=P Do you think this will stay the same or get better on Core 2 Duo? It also explains why that Woodcrest above didn't seem to do as well on some apps.
 
If anything, the missing instructions further reinforce the fact that intel simply took the x86-64 specification and called the implementation "EM64T". At least now you understand there was no reverse-engineering going on. I only pursued this so far because it is irritating to be accused of copying a competing product, because the only reason that'd be necessary is if you can't figure it out yourself, which is crazy for something as relatively simple...

Here we have this site saying Core doesn't gain from 64bit. Optimization is the main reason why=P Do you think this will stay the same or get better on Core 2 Duo? It also explains why that Woodcrest above didn't seem to do as well on some apps.
Click to expand...

Nah, the glassjaw has nothing to do with fusion or optimizations. core2 does have weaknesses (already demonstrated by several previews), but it's complicated and confidential. oh well.
 
dmens said:
If anything, the missing instructions further reinforce the fact that intel simply took the x86-64 specification and called the implementation "EM64T". At least now you understand there was no reverse-engineering going on. I only pursued this so far because it is irritating to be accused of copying a competing product, because the only reason that'd be necessary is if you can't figure it out yourself, which is crazy for something as relatively simple...



Nah, the glassjaw has nothing to do with fusion or optimizations. core2 does have weaknesses (already demonstrated by several previews), but it's complicated and confidential. oh well.
Click to expand...

Well, I wouldn't say that copying what someone else does is necessarily because you can't figure it out.

I'm sure MS could have figured out a GUI, but essentially "copying" what Apple had done (the work itself having originally begun with Xerox, with Apple making use of it) saved MS a lot of time and money.

Same now goes for Vista, and many of the features it implements that are almost direct copies of OS X.
 
pxc said:
"Yamhill" had been popping up in rumors since late 2001. And that it had taped out in early 2003 shows it was in design for longer than that.

Intel did consider extending x86 to 64 bits way back when. Itanium is for a completely different segment than desktops and small servers.

I'll post where Intel had considered extending x86 to 64-bits when I find the link.
Click to expand...

Well, I knew they had considered it within. I didn't know they had actually begun work on extending it.
 
dmens said:
Big difference between hardware and software...
Click to expand...

True. But that's true for everything in life. I was simply trying to relate.

Oh, and the GUI took Xerox several years to develop and work out. It took Apple a couple of more years to work it out. And it took MS a while also. Thus, in some ways, you can say that software can be more difficult than hardware to work out. :)
 
Donnie27 said:
Turn off Altivec and see what happens that's all I said. It's not Rocket Science, just someone who's done it before. Since you haven't, you don't know=P Please stop while you're ahead LOL!
Click to expand...

As someone who has quite a bit of work with Altivec G4s, I can tell you this:

Altivec can be very, very useful. Compare Altivec-enhanced Photoshop for OS X to Photoshop for XP.

And turning off Altivec would be like turning off SSE/2/3 on an Intel or AMD system. Why would you do it, given how much is optimized for each?
 
dmens said:
If anything, the missing instructions further reinforce the fact that intel simply took the x86-64 specification and called the implementation "EM64T". At least now you understand there was no reverse-engineering going on. I only pursued this so far because it is irritating to be accused of copying a competing product, because the only reason that'd be necessary is if you can't figure it out yourself, which is crazy for something as relatively simple...

Nah, the glassjaw has nothing to do with fusion or optimizations. core2 does have weaknesses (already demonstrated by several previews), but it's complicated and confidential. oh well.
Click to expand...

Doesn't bother me any, I still can't wait to get my hands on Conroe and I don't use 64bit anyway, even on my A64 3500+ ;) Thank you for clearing that up.
 
ToastMaster said:
As someone who has quite a bit of work with Altivec G4s, I can tell you this:

Altivec can be very, very useful. Compare Altivec-enhanced Photoshop for OS X to Photoshop for XP.

And turning off Altivec would be like turning off SSE/2/3 on an Intel or AMD system. Why would you do it, given how much is optimized for each?
Click to expand...

EXACTLY!
 
dmens said:
Big difference between hardware and software...
Click to expand...
It's funny ToastMaster used that type of example again. He does not see any difference between the high level (instruction set or GUI) and implementation.

Windows 1.0 was not a copy of Mac OS, and the various Windows APIs have virtually nothing in common with Mac OS. So i've always thought it was n00bish when people call Windows a copy of Mac OS. Apple didn't invent the GUI, or even ship the first commercial graphical computer (the first and second were the Perq, 3 years before the Lisa, and Perq T2, right before the original Macintosh).
 
pxc said:
It's funny ToastMaster used that type of example again. He does not see any difference between the high level (instruction set or GUI) and implementation.

Windows 1.0 was not a copy of Mac OS, and the various Windows APIs have virtually nothing in common with Mac OS. So i've always thought it was n00bish when people call Windows a copy of Mac OS. Apple didn't invent the GUI, or even ship the first commercial graphical computer (the first and second were the Perq, 3 years before the Lisa, and Perq T2, right before the original Macintosh).
Click to expand...

Once again, I simple used it as an analogy. If you can actually show where I said that there wasn't a difference between an instruction set, GUI and implementation, please point it out.

And saying that Windows 1.0 was a direct copy of the Mac OS would be false, you're right. However, MS was years away from developing a GUI of its own, even with how much of an impression VisiOn had on Bill Gates.

However, Microsoft was a 3rd party as well as being a Mac developer, and was able to obtain pre-production Macs, equipped with the Mac OS GUI. Yes, the code was different (obviously, given Windows 1.0 was for IBM PCs). Can you honestly say though that being able to observe how the Mac OS GUI functioned, how interaction occured, and the conceptual work behind it didn't in any way influence Microsoft's work on Windows 1.0. I don't think so...

And once again, you put words further in my mouth. I didn't say Apple invented the GUI. I did say Xerox Parc helped it along, although even this was set up largely due to the demonstrations by Douglas Englebart.

And I don't even know why you decided to bring in who built the first calculator.

So please, no words in my mouth. If you have something against me, take it to PM. Thanks. :)
 
Edit to above post, since it isn't allowing me to use the edit response:

Edit - Oh, and I find it amusing that the thread that you quoted, pxc, and proceeded to attempt to deride me on, was concerning dmens' response to my analogy for companies who've supposedly/apparently copied designs in the past. No where was it a relation between high level and implementation. So please, read the entire post chain, instead of picking out one and replying. Thanks. :)
 
ToastMaster said:
who've supposedly/apparently copied designs in the past.
Click to expand...
I unfortunately have read all your posts in this thread. Your analogies are based on false information, so it is reasonable to point that out. OK?
 
You must log in or register to reply here.
Back
Top