Intel is reasoning..CTO FUD(sigh)

Pirox · Sep 20, 2003

See theinquirer...prescott has 64bits supports.

---
If you go to work and your name is on the door, you're rich. If your name is on your desk, you're middle class. If your name is on your shirt, you're poor!

Mephistopheles · Sep 20, 2003

What is there to sigh about? That is good news for us... and bad news for AMD; but the consumers will benefit from this. And it would be kind of dumb if Intel didn't have plans ready... They have been thinking about 64-bit desktops for far too long already! And it wouldn't be the first time that some new tech comes along as disabled and "used whenever needed" - like Hyperthreading...

I hope they activate the damned thing soon.

:evil:

Mephistopheles

spud · Sep 20, 2003

I said this in my propaganda post dont know guys read???

-Jeremy

:evil:

<A HREF="http://service.futuremark.com/compare?2k1=6940439" target="_new">Busting Sh@t Up!!!</A> :evil:

<A HREF="http://service.futuremark.com/compare?2k3=1228088" target="_new">Busting More Sh@t Up!!!</A> :evil:

traviss187 · Sep 20, 2003

well some of us are kinda lazy and those posts are soo long, maby a recap at the end highlighting main points for those of us who have a tendency to fall asleep....
jk. I love the prop. posts.
yeah I heard from a different source not to be worried about amd's 64bit because intel has had it covered for a while.
but it will be interesting to see weither or not it's initially enabled

spud · Sep 20, 2003

*spud nods* Yup Yup I hear ya.

-Jeremy

:evil:

<A HREF="http://service.futuremark.com/compare?2k1=6940439" target="_new">Busting Sh@t Up!!!</A> :evil:

<A HREF="http://service.futuremark.com/compare?2k3=1228088" target="_new">Busting More Sh@t Up!!!</A> :evil:

pitsi · Sep 20, 2003

Actually I am not so sure that consumers will benefit from this. If AMD's 64bit extensions are incompatible with Intel's 64bit extensions, then companies will have to release their product either for Athlon64 or Prescott. I am just not very optimistic about this.

eden · Sep 20, 2003

That's a shock lol.

But since it's a rumor, we don't know. It'd be great for competition, but again, it won't do jack for any of us using our PCs for home use. If anything it will just encourage coding for extra registers, if that is how they will go by implementing it.

I can't wait to see what Kinney will say on that.

--
<A HREF="http://www.lochel.com/THGC/album.html" target="_new">Are you ugly and looking into showing your mug? Then the THGC Album is the right place for you!</A>

eden · Sep 20, 2003

That's a valid point there. The way I see it, is that if coding can be done just to tailor to register width extension, you can create a standard coding path which works on any 64-bit x86 CPU, and then go for individual core-specific instructions to optimize even further.

In other words, if coding for register length only can be done, all CPUs should benefit, and then you can move onto individual core optimizations. I may be wrong, I have no programming knowledge.

--
<A HREF="http://www.lochel.com/THGC/album.html" target="_new">Are you ugly and looking into showing your mug? Then the THGC Album is the right place for you!</A>

TknD · Sep 21, 2003

That's a valid point there. The way I see it, is that if coding can be done just to tailor to register width extension, you can create a standard coding path which works on any 64-bit x86 CPU, and then go for individual core-specific instructions to optimize even further.

In other words, if coding for register length only can be done, all CPUs should benefit, and then you can move onto individual core optimizations. I may be wrong, I have no programming knowledge.

That doesn't make any sense.

jurians · Sep 21, 2003

no that wouldnt work because theres actual instructions that are used.... and if they arenot the same then ummm we are [-peep-] of luck...... instruction sets are like the following mov, add, mul, mult, store, etc. this is the main reason why i dont care about the 32-64bit war atm.. because theres going to be a huge compatibility issue if both amd and intel release thier own instruction sets which makes 2x the world for programmers.

spud · Sep 21, 2003

Ill just wait for IA64 to trickle down... This hybrid [-peep-] makes me mad [-peep-] half breeds running around!!!

-Jeremy

:evil:

<A HREF="http://service.futuremark.com/compare?2k1=6940439" target="_new">Busting Sh@t Up!!!</A> :evil:

<A HREF="http://service.futuremark.com/compare?2k3=1228088" target="_new">Busting More Sh@t Up!!!</A> :evil:

eden · Sep 21, 2003

It also doesn't make any sense for you to say I don't make sense, if you can't argument back and explain what is up. I even stated I may be wrong, and that opens the door for you or anyone to correct me.

--
<A HREF="http://www.lochel.com/THGC/album.html" target="_new">Are you ugly and looking into showing your mug? Then the THGC Album is the right place for you!</A>

eden · Sep 21, 2003

The most basic way to make a CPU 64-bit, is just to extend the GPRs, IIRC. Intel can do that as AMD can, in fact it's as easy as that, that AMD could call it x86-64. Of course you need to create ways to access it, and then you get your own instructions. Intel can't make people not see Windows AMD64, however it can try to make the instructions similar and label the 64-bit tech anything they want. IMO, the reason why AMD renamed the extension, was because x86-64 isn't registrable as a copyright, since it is a logical nomenclature like x86-32. So they use AMD64. If that is the case, then Intel can use Yamhill as the extension name, and have x86-64's properties behind it. Do you see what I am trying to say?

And besides, these simple instructions you pointed out, are basically there to any CPU, that's pretty obvious and logical. It's probably the triggers and other things that make use of 64-bitness that are different. Again I would like someone to correct me or explain calmly what goes on.

--
<A HREF="http://www.lochel.com/THGC/album.html" target="_new">Are you ugly and looking into showing your mug? Then the THGC Album is the right place for you!</A>

TknD · Sep 21, 2003

To begin with, I have worked with x86 asm code. I have read on architectures. I have the very basic knowledge as to how digital logic and other cpu circuitry (ALU, Micro code, etc) work.

That's a valid point there. The way I see it, is that if coding can be done just to tailor to register width extension, you can create a standard coding path which works on any 64-bit x86 CPU, and then go for individual core-specific instructions to optimize even further.

There is no similar "coding path" (whatever that means), between an AMD64 cpu that supports both x86 32bit instructions and another 64bit cpu at the moment. Itanium can run emulated x86, but does not natively support x86. There is no "hybrid" x86 chip from intel at the moment that is both "64bit" and has x86 ISA support.

Secondly, the difference between 64bit and 32bit in reference to cpu architecture isn't as simple as 64bit registers vs 32bit registers. ALL computational components of the CPU (ALU, FPU, etc) must be modified to support computations on 64bits rather than just 32bits. If that is not done, then you are wasting 32bits by just performing the old 32bit instructions.

Thirdly, the only way to have compatible "coding paths" (again, this term in reference to what i believe you are talking about is being used in completely incorrect context) is to have compatible ISA (Instruction Set Architecture). x86 is the ISA your Pentium 4, Athlon XP, and even 386 is compatible with. MMX, 3dnow!, SSE, and SSE2 are all extensions on x86 meaning they are optional and can optionally be supported in x86 code. AMD64 ISA (formerly x86-64) can be treated as a new ISA, NOT an extension.

Therefore, the only way to take advantage of the 64bit-ness of AMD64 processors is to recompile or produce code in AMD64 ISA, not x86. Although the instructions are similar between x86 and AMD64, you can't simply take an x86 program and start using AMD64 instructions and expect that mix of x86 and AMD64 code to work on old processors as well as new ones. It's either x86 code or AMD64 code, not both--more specifically x86 compiled code when recompiled as AMD64 code (no instruction changes) will work, AMD64 + x86 "like" code compiled as AMD64 code will work, however, x86 + AMD64 code compiled as x86 will not work--it won't even compile.

I could continue on, but I think that is sufficient to illustrate the point.

I may be wrong, I have no programming knowledge.

There's a difference between speculation and saying something utterly wrong. If one speculates, then there is little or no evidence at the time of writing that immediately proves the statements false or true. x86 and basic cpu architecture has been around for more than a decade.

So to conclude, what you have said makes no sense.

jurians · Sep 21, 2003

heh yeah thats the long reason -_- and much better said than me.... much better... and thus is the reason why im not jumping on the athlon 64 boat. if intel comes out with a similiar chip with a new instruction set... then u see the possible problem

eden · Sep 22, 2003

Then can you explain how Windows X86-64 works? I'll need to get this info before I can possibly think I could refute, otherwise drop it as I have no other explanations.

--
<A HREF="http://www.lochel.com/THGC/album.html" target="_new">Are you ugly and looking into showing your mug? Then the THGC Album is the right place for you!</A>

eden · Sep 22, 2003

I do have to ask though, are we all thinking Yamhill is using something other than an x86 with 64-bit extensions, such as IA64 or what?
Seems to me some are thinking this is a completely different 64-bit architecture added.

--
<A HREF="http://www.lochel.com/THGC/album.html" target="_new">Are you ugly and looking into showing your mug? Then the THGC Album is the right place for you!</A>

TknD · Sep 22, 2003

Yamhill as far as speculation goes, is intel's "64bit" with x86 mesh similar to AMD's K8 cpus. Whether it is x86-64/AMD64 ISA or IA64 ISA hasn't been determined.

In my opinion, it has to be AMD64 rather than IA64. Itanium architecture and ISA are VERY different from x86--basically consider all of that branch prediction stuff split between the compiler and features on the chip. Branching is no longer complete guess work for the chip, there are special methods of compiling the code so that Itanium knows what to do in the case of a branch. In x86, there is no way for the CPU to have any clue as to which branch to take, it just has to make the best guess and hope it's right most of the time. Itanium is a complete redesign in architecture and ISA. I'm not saying that it isn't impossible to have an Itanium/x86 chip, I'm just saying it isn't as easy as having an x86/AMD64 chip.

Whatever Yamhill is, or whatever 64bit-ness Intel has planned for prescott, I don't think that their implementation of AMD64 will be as good as AMD's, it'll more just be an experimentation/marketing exploit. The only advantage with AMD64 is that it is very similar to x86 meaning if Intel decides to jump on the wagon, it won't be very painful in implementation.

eden · Sep 22, 2003

I know what the Itanium 64 architecture does and how it works, at the base.

I was indeed thinking of x86-64 as Yamhill. In fact it's most dangerous for Intel to go anywhere else, if MS is supporting Win AMD64. Users won't go on Windows Update to get the latest extension support ya know.

Now whether 64-bit drivers must be written for both cores is another question. I mean, when the P4 came out, did programmers have to rewrite their code for the P4's architecture necessarily? If not, then would 64-bit register extension at the very base, require reprogramming for each core? Suppose the GPRs Intel adds or extends are the very same names of AMD's.

Anyways, I strongly believe Intel's 64-bit extensions are pretty much similar to AMD's and that programming to each should not be a hassle at all. It's more the support that I am questioning and whether you DO need to reprogram to each, and get an OS for each. If MS caters to less than 20% of the population now, it's no question they will for Intel, but that will be a bad thing, to start dividing your own OS to different people when a PC x86 OS is made for every kind of x86 PC.

--
<A HREF="http://www.lochel.com/THGC/album.html" target="_new">Are you ugly and looking into showing your mug? Then the THGC Album is the right place for you!</A>

Mephistopheles · Sep 22, 2003

I'm not saying that it isn't impossible to have an Itanium/x86 chip, I'm just saying it isn't as easy as having an x86/AMD64 chip.

This still doesn't rule out a third possibility, another extension, not necessarily less efficient than x86-64... But it's hard to tell, because if it is a secret, then software support will take more time to appear... It feels a little strange... Using AMD's x86-64 extension would endorse their technology, so I don't really think Intel would try to copy AMD's tech...

:evil:

Mephistopheles

eden · Sep 22, 2003

Two things:

1) As I theorized, AMD may have changed the 64-bit extension's name to AMD64 because their model is not registrable. It is very possible just like x86-32 is a universal name and does not apply to anyone's property.
2)You're forgetting the cross-license agreement, stating AMD and Intel must license free of charge any extensions they develop. AMD used SSE and SSE2 pretty much like Intel, although less efficiently for the latter, so Intel has as much right to go use x86-64.

--
<A HREF="http://www.lochel.com/THGC/album.html" target="_new">This just in, 56+ no-lifers have their pics up on THGC's Photo Album! :lol: </A>

TknD · Sep 23, 2003

Now whether 64-bit drivers must be written for both cores is another question. I mean, when the P4 came out, did programmers have to rewrite their code for the P4's architecture necessarily? If not, then would 64-bit register extension at the very base, require reprogramming for each core? Suppose the GPRs Intel adds or extends are the very same names of AMD's.

Anyways, I strongly believe Intel's 64-bit extensions are pretty much similar to AMD's and that programming to each should not be a hassle at all. It's more the support that I am questioning and whether you DO need to reprogram to each, and get an OS for each. If MS caters to less than 20% of the population now, it's no question they will for Intel, but that will be a bad thing, to start dividing your own OS to different people when a PC x86 OS is made for every kind of x86 PC.

You were making sense right up till you wrote:

If not, then would 64-bit register extension at the very base, require reprogramming for each core? Suppose the GPRs Intel adds or extends are the very same names of AMD's.

The names of the registers are very small in detail compared to the ISA supported by the CPU. All programming depends on the specification of the ISA, not just the actual architecture of the chip. If Itanium could natively support x86 ISA, then intel would have their combo chip. Register names are also part of the ISA.

Anyway, to answer your question: if intel develops an incompatible 64bit ISA for their next chip, of course new drivers and software will have to be written. If intel develops a chip supporting AMD64, no drivers or software have to be rewritten if they already exist as AMD64 compiled. If intel develops an "new" MMX/SSE/SSE2(/3dnow!) extension to AMD64 but their chip still supports AMD64, software and drivers won't have to be recompiled to work. It all depends on the ISA Intel uses/develops. A change in something as simple as register names implies a new ISA specification.

slvr_phoenix · Sep 23, 2003

I still have this sneaking suspicion that Intel will somehow find a way to add IA64 as an extension to the P4 when they finally do release their hybrid.

I mean think about it. A true pure x86 CPU at heart just plain sucks for duplicating EPIC. However how much of the P4 really at heart follows x86 purely anymore? It's nothing like the Athlon in that respect. And with every new major P4 core revision it supports out of order execution even better. How much more would the P4's core have to be extended for out of order execution before the P4 could actually run EPIC even half-heartedly? How much more would Intel really have to add to the P4 to make it turn IA64 code into microcode that the P4 already knows how to run? How much of what little would be needed is already in Scotty without anyone even knowing? And if nothing along those lines is in Scotty, then how long would it actually take Intel to convert Scotty into a P4 hybrid that can execute IA64 code along side IA32 code?

Sure, a P4 that can run IA64 code wouldn't be as powerful as an actual Itanium, but then that would actually work in Intel's favor because Itanium would still be a justifiable purchase. It would only have to run IA64 code well enough to compete with AMD64. And Microsoft already supports IA64...

I don't know. There's not a shred of proof, but yet to me it looks so obvious that it's hard to ignore. It'd strengthen Intel's push of IA64 code (making actual Itaniums that much easier to accept) while not harming their 32-bit processor market at all. And it'd allow Intel to scoff at AMD64 until the cows come home. For Intel it'd be win-win. For AMD it'd be lose-lose. It's becoming harder and harder for me to imagine Intel doing anything else.

<pre><A HREF="http://ars.userfriendly.org/cartoons/?id=20030905" target="_new">People don't understand how hard being a dark god can be. - Hastur</A></pre>

eden · Sep 23, 2003

I have never given this such thought, but yet I am compelled to really agree and see things differently. I love the fact IA64 is such a powerful ISA using what SHOULD be the future. But, it simply cannot be used for the x86 world, and yet, when you put it that way, it actually does sound obvious and even easy. MS supports it, all Intel needs is to implement it. My concern would then be how truthful are you in your statement that the P4 has worthy IA64 execution prowess. It would indeed harm AMD if P4 users could then use Windows IA64 easily, negating any advantage AMD had in creating a new community. But then the question asks, will people want to go Intel, or AMD's route? As in, will they want to continue x86 or go IA64? I would love to see IA64 being the norm, given how much the programmer input here reveals it being absolutely not flexible for ILP. It would be a different world in fact, to see how a P4 would work with almost full IPC as the Itanium can do with compiler based decoding. Oh and um, I think I might have said some crap here, so please tell me if I did heh!

It's quite a conundrum what you just layed out, IMO.

--
<A HREF="http://www.lochel.com/THGC/album.html" target="_new">This just in, over 56 no-lifers have their pics up on THGC's Photo Album! </A> :lol: Edited by Eden on 09/23/03 10:16 AM.

Intel is reasoning..CTO FUD(*sigh*)

Distinguished

Distinguished

Distinguished

Distinguished

Distinguished

Distinguished

Champion

Champion

Distinguished

Distinguished

Distinguished

Champion

Champion

Distinguished

Distinguished

Champion

Champion

Distinguished

Champion

Distinguished

Champion

Distinguished

Splendid

Champion

Share this page

Intel is reasoning..CTO FUD(sigh)