Updated...Any change of opinions?
Patrick Proctor Cooe • 5 hours ago
Your PC can do it through a software layer. Itanium runs x86 binaries on the hardware out of the box. And yes, it's native. It's just using different circuits from the Itanium code.
Cooe Patrick Proctor • 5 hours ago
I know exactly what you are talking about and you are still wrong. Having a few common x86 registers on die to facilitate EMULATION doesn't mean the code is executing natively. (there's just dedicated hardware to assist with said emulating, the vast majority of the x86 ISC isn't natively supported 1-1 in Itanium, there just wasn't enough room (and that would have made the chip something else entirely). As x86 and Itanium almost have nothing in common aside from common quirks after Intel got IA-64 from original dev. HP, (IA-64 has more in common with VLIW arch's like AMD's TeraScale GPU's than x86), most x86 instructions still have to been converted into IA-64 code in order to be able to execute, leading to an often significant performance penalty when running native x86 code/software (and cause re-writing all your software for a niche instruction set as both Intel & HP had intended (the emulation shenanigans were just a shoddy stop gap solution) is crazy expensive, is a big part of the reason Itanium failed.
Patrick Proctor Cooe • 5 hours ago
No, you didn't have to convert any part of the binaries at all. I am dead right. Go ahead and break the contradiction. Your standard says there is no x86 64-bit CPU at all. Nothing natively runs x86 anymore. So either it's neither, or it's both.
Cooe Patrick Proctor • 4 hours ago
Lol on further research it turns out we're both right in ways actually, you're correct on that it actually was technically the first 64 bit x86 chip (though only on paper, no-one was using them to run x86 code, as other x86 chips of the era could run it faster). The very first Itanium chip did include enough of the x86 ISA in hardware to be able to run native x86 binary's (though again, nobody did). But I was right in that Itanium ALSO used binary level ISA emulation to execute x86 code. Turns out after that first chip, they scrapped the dedicated x86 hardware entirely and switched to an x86 to IA-64 binary translator/re-compiler called the IA-32 Execution Layer that did precisely the kind of ISA binary emulation I was talking about and was precisely what I was thinking of. Easy to see how we got confused when we both had correct information, just not at the same time hahaha. I just had absolutely no idea it wasn't like that throughout the entire Itanium line, so I'll be darned haha. And you are totally correct in that most x86 instructions aren't explicitly located in hardware on modern x86 chips, but rather in microcode for all sorts of obvious reasons (like die space o' course haha).
Patrick Proctor Cooe • 4 hours ago
As I said, two very different approaches to the problem, and both were equally x86 at the outset.
I get a bad rap because I can actually argue. I'm not out to troll (usually, though when I do it's damn obvious) or attack people. I know what I know, and I prove what I can prove.
Now, back to dealing with the anti-HMC crowd...
atomicWAR Patrick Proctor • 2 days ago
Maybe. Seems more like your clinging on to an argument that is lost. Hardware emulation is not native x86. No matter how you slice it. I was clear from post one I was talking native x86. Now I can see where in your head that is splitting hairs, sorta. IA-64 did have hardware emulation, not software. Ok MAYBE. But beast was specific he said AMD made the first x86 64bit CPU. No mention of emulation, it was a native x86 CPU instruction set he spoke of. If anything you are the one who split hairs right then and hoped no one would notice, but I did and I called you out on it. You might want to call facts semantics because they don't suit your argument but that doesn't make them any less facts. One of those links I included was from Intel, the horses mouth. Intel does not consider their own IA-64 a x86 CPU. They consider it an IA-64 CPU with hardware emulation for x86 that by their own admission doesn't run full speed (the definition of emulation, running software designed for different hardware while not running full speed). So by your argument Qualcomm's ARM chips that run x86 through emulation being co-developed by Mircosoft as also x86, even though they are not. They are ARM. And before you say "oh they are using software emulation"...It is still emulation which the IA-64 uses, different implementation granted. And who would be splitting hairs then? Just own it. You are wrong. Be an adult not a troll!
Cooe atomicWAR • 5 hours ago
Haha I replied almost the exact same thing above before I'd read your last two posts of the sub-thread and discovered you'd beat me to it. Touche
.
atomicWAR Cooe • 2 hours ago
Thanks for the back up. I never said all his point were wrong but he wasn't, until very recently, using any logic besides "I am right, everyone else is wrong". No facts just insistence. His arguement as improved but for me it still doesn't make the leap he is trying to say it does. IA-64 is not x86. yes IA-64 had some commonalities. But one big thing is it didn't run full speed x86. It always had to be run at a slower mode. For me this is the crux of the argument. If IA-64 could run x86 full speed in hardware and using microcode, then I wouldn't have as much of a leg to stand on. The fact is as far as i can tell/know. It can't. And that is where his argument hits the wall. It also should not have taken this much back and forth for him to actually state some substance over opinion. I gave him substance from very early on and kept getting "but I am right and you are wrong" with no supporting facts. For a debate to be just that, you need facts. At least he got there eventually. Again still not enough in my book but a much better argument on his side.
Cooe atomicWAR • 2 hours ago
Turns out we were mostly wrong on that point (as you can see from above posts) I found out from further research. The very first Itanium chip DID include complete x86 hardware support that could run x86 code/binary's natively just as it could IA-64. It wasn't till the 2nd gen that they realized no one was using all that hardware, because other x86 chips of the time were faster for x86 code (it being 64bit had no beneifical impact on running 32bit x86 code), and stripped it out and replaced it with the emulation stuff (which stayed for the rest of it's life), which is all I knew about, so I agreed with you. But in actuality the very 1st Itanium chip was a native x86 chip that was 64bit in design (it was essentially a dual ISA chip believe it or not, native in x86 & IA-64).
atomicWAR Cooe • 2 hours ago
Sources? Just want to see for myself. Always willing to own a fault if it is mine to own but also need to see proof first hand.
Cooe atomicWAR • 2 hours ago
https://www.cnet.com/news/i...
Just one of many when I actually went looking. Actually found a fascinating Intel quote from when they were just getting into it with HP that having it be able to run both IA-64 and x86 code natively was required for Intel to jump in (would have to go track it down again though haha). This one makes the point of why the native x86 hardware was removed. It wasn't any faster than competing, only x86 chips. Intel even believed, or at least said they did (at the time) that IA-64 was fast enough to be able to emulate the x86 code faster than the native hardware processed it, hence the switch with the 2nd gen onwards (I imagine this didn't really pan out in reality though lol, IA-64 was kind of crap, and so was Itanium's performance running it (though better than it running native x86, but better enough to be able to emulate x86 and come out on top? Nevermind.. just looked it up. This is true also. The native x86 binary readable (aka it could execute the native binary x86 code/instructions) hardware was SLOWER than the binary x86 to IA-64 translation emulator they made. Wowza. Talk about first, but last hahaha.
atomicWAR Cooe • an hour ago
Yeah that article is a bit vague and if I understand it correctly only restates what I have said. And as far as I can tell it is refering to the hardware emulation I spoke of. Check this quote out from another piece...
"Compatibility with existing x86 applications was a concern in the
IA64 ISA, but not a priority. The ISA specified a mechanism for running x86 programs in hardware, but the chip was optimized for the native ISA, and x86 execution was not to be at-speed[21]. Jeff Havens explained in a personal interview that the goal was to run x86 software as well as the previous generation of contemporary x86 processors. In fact, this goal was never met, and the x86 hardware emulation was eventually removed. Instead, it was replaced by a binary translation mechanism to convert x86 programs to native IA64 code. Havens recalled that the Intel team reported comparable performance using binary translation, and that this was the point at which hardware emulation was cut."
This is what the cnet article you used as evidence refers to. And as I pointed out very early on, this is not native x86. Yes some of the circuitry was there but not in total nor did it run at full speed as I stated. This does not qualify as native x86 IMHO. here is the article is it's totality.
http://courses.cs.washingto...
Cooe atomicWAR • an hour ago
This is all true, though they are using a different form of the word "native" in this context to mean it's primary ISA, but It's still a native x86 chip just as much as it's a native IA-64 chip, as far as instruction support and native code execution, and that's all that matters. It can process both instruction sets/ their binary code (aka no conversions taking place on the data in any way shape, or form), 110% natively. That's an immovable fact. Whether the native x86 side of the chip sucked crap through a straw compared to the more important, primary portion of the chip handling native IA-64 code doesn't make it any less of a true, native x86 processor no matter how badly that sits with you. Native instruction execution (NO MATTER HOW SLOW) is all that matters for that qualifier, and that's just the freaking definition of the term. A chip belongs to a certain ISA if it can natively execute those instructions in hardware. This most definitely can. x86 chip? heck yes, good x86 chip? heck no.
atomicWAR Cooe • an hour ago
Yeah I have to disagree. This is not about how it sits with me but how code is executed. Hardware emulation, is still emulation and therefor not native. The definition of emulation is to run code that IS NOT NATIVE to the instruction set. There is no way around that bit. I have always said IA-64 was capable of running x86 code, just through emulation. This argument only strengthens my stance, not weaken it. And again this is also running the code at a slower speed, again not native. If it ran full speed then another one of my legs would be gone because his argument about CISC running on RISC through microcode would hold more merit. But the short of it is the Itanium never ran x86 code at full speed. While I appreciate you trying to bridge the gap and see both sides, things I admire in any debate, it doesn't change how the code was executed. At the end of the day IA-64 had to use emulation not native code execution.
Cooe atomicWAR • an hour ago
You don't understand the word "emulation" at all. It MEANS converting binary code from one CPU's ISA to another, LITERALLY, as in from my freaking CS textbooks. That's not happening here, the x86 code isn't changed at all lol. And at no point is such a process (or anything analogous) occurring at any point in the x86 execution hardware, the instructions are executed as x86 instructions, on x86 hardware, which from then go to any shared hardware they might need to use (with the IA-64 execution hw, which is completely inactive this entire time because absolutely 0 IA-64 instructions have been processed). It was closer to a dual-arch/ISA frakenchip, heavily weighted in one direction, than anything else.
atomicWAR Cooe • an hour ago
I do understand emulation (different words used but we were saying the same thing), I'll give you if the code is not changed at all it is not emulated but I am still waiting on the broken link to read up on before making further comment.
https://techterms.com/defin...
Everything I was saying is there though I should have left speed out in the strictest terms of the definition though usually slower speed is part of how emulation plays out. However in theory if you system is powerful enough you could emulate software at the same speed as the native system though it is near impossible to do this (with the same generation hardware/ hardware made in the same years time) without some type of slow downs which was why I used a looser definition of the term.
Cooe atomicWAR • an hour ago
It does both natively. From wiki's binary translation article (https://en.wikipedia.org/wi...
- "Intel Corporation developed and implemented an IA-32 Execution
Layer - a dynamic binary translator designed to support IA-32
applications on Itanium-based systems, which was included in Microsoft
Windows Server for Itanium architecture, as well as in several flavors
of Linux, including Red Hat and Suse. It allowed IA-32 applications to
run faster than they would using the native IA-32 mode on Itanium
processors." And there's far more out there to back up it's native x86 execution abilities (no matter how freaking terrible they were).
atomicWAR Cooe • an hour ago
This one has a broken link so i need a bit more to comment on it directly
As far as I can tell this changes nothing but please chime in if i am wrong.
Facebook
Twitter
Instagram