Talk:IA-64

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

EFI isn't an instruction set[edit]

The reference to "EFI" in instruction set is technically incorrect. EFI is a specification that governs a replacement for system BIOS it applies to any architecture, not IPF in particular. The code that supplements an IPF processor is call the PAL/SAL for Processor Abstraction Layer/System Abstraction Layer. I will change this shortly if nobody objects. --Metadynamics 23:17, 7 October 2005 (UTC)[reply]

Mention AMD64?[edit]

Would it be appropriate to mention AMD's version of the 64-bit architecture? Specifically how AMD will not follow the lead of Intel, and will instead extend the x86 based design into 64 bits. --seav 21:50, Oct 21, 2003 (UTC)

Possibly as a competitor. It's hard to write much about it while the battle is running hot. - David Gerard 11:16, Jan 25, 2004 (UTC)

Merge this with Itanium?[edit]

This article is largely redundant with Itanium - is there actually a difference anyone outside Intel marketing cares about? Should one be folded into the other? - David Gerard 11:16, Jan 25, 2004 (UTC)

Unless anyone strenuously objects (and is willing to work to differentiate the two articles effectively), I'll be merging this with Itanium in a few days - David Gerard 18:16, Mar 29, 2004 (UTC)

Merger with Itanium article[edit]

Did this IA-64 article ever get merged into the Itanium article? — Preceding unsigned comment added by 156.80.108.112 (talk) 12:19, 29 December 2004 (UTC)[reply]

Per the discussion in the talk page for Itanium, this should not be merged as it applies to the IA64 architecture, not the Itanium product as sold by Intel. If anything the Itanium and Itanium2 pages should be merged, even though they are generationally distict they are logically continuous.--Metadynamics 23:17, 7 October 2005 (UTC)[reply]

IA-64 and Apple[edit]

Is this also the same instruction set that Apple Computer will port into? If yes, it should be in the article. — Preceding unsigned comment added by 202.81.191.1 (talk) 03:44, 4 June 2005 (UTC)[reply]

Answer: No, it is not. — Preceding unsigned comment added by 24.211.151.6 (talk) 01:32, 25 February 2006 (UTC)[reply]

IA-32 Execution Layer[edit]

Perhaps the developments around the IA-32 Execution Layer could be added to the part regarding IA-32 Support? — Preceding unsigned comment added by 81.204.121.33 (talk) 15:54, 12 June 2005 (UTC)[reply]

Testing 123 — Preceding unsigned comment added by 143.232.190.169 (talk) 16:52, 29 November 2005 (UTC)[reply]

Isn't IA-64 dead?[edit]

I thought Intel had given up on IA-64 and switched to making x86-64 go faster. If that's true, it should be reflected in this article. (sorry, I don't have a reference at hand) --Alvestrand 22:26, 8 December 2006 (UTC)[reply]

No they have not, as of Feb 2007. Please see Itanium 2. The fact that apparently everybody in the industry thinks that they should just give it up does not mean that they have given it up. See Intel iAPX 432 for the last time this happened. - Arch dude 23:01, 6 February 2007 (UTC)[reply]
I think the relationship between IA-64 and x86-64 is just like yesterday's Windows NT and Windows 9x(95, 98 and Me). For years, Windows NT 4.0 stay in the silent, but Windows 9x was popular and many following editions released. But one day Windows XP arrived, everything changed. I think Itanium Architecture is just like yesterday's Windows NT, and eventually would take over the all the x86 market to arrive on everyone's desktop. Janagewen (talk) 03:24, 23 August 2014 (UTC)[reply]
Far from "just like". Microsoft was always planning to bring the 9x users into the NT family; you can see that in roadmaps they published as early as 94. Whereas, there has never been a roadmap or anything else from Intel that suggests they are even thinking about introducing Itanium to the typical desktop (not, at least, since the wild success of AMD64, followed by Intel's grudgingly following suit). Heck, with the performance increases seen by x64, Itanium is not even much of a contender in the workstation market. It is inherently a much higher cost architecture to make chips for than x86/x64, so it's never going to be able to compete at the low end. Jeh (talk) 23:17, 31 August 2014 (UTC)[reply]
Janagewen... you don't have to strike something out just because someone has disagreed with you! Jeh (talk) 22:45, 2 September 2014 (UTC)[reply]
Nowadays more and more software and hardware manufacturers stall support for it, but through its outstanding design, there is no equivalent replacement to it. So at this point, the future Itanium might need a hybrid change, leaving the x86 support on the level of decoder on microarchitecture, rather than on the firmware or OS level. Hybriding the x86 and Itanium codes together when running on IA-32 OS might be the potential future view of it. In other words, not let OS aware of the Itanium codes, but Itanium itself could manipulate themselves, when working under IA-32 or x64 OSes. When working under pure Itanium mode OS, x86 support could be removed at all. From Pentium through Core i7, Intel is definitively the proficient microarchitecture designer. So I think IA-64 is not dead at all, but like roses grow themselves up in the long cold winters. I do apologize for my fantasy guess. Janagewen (talk) 22:20, 15 September 2014 (UTC)[reply]
I should do my apologize to this guy, Jeh, that there might be something wrong with internet connection when I post my last reply. So that might be the reason cause something not right here. And this time I fix it. I've no purpose to make any damage or interference of what other's writes. But Jeh, how you make warning to me, that is the business of your own. But for more than that, I think one should respect to him/herself on Wikipedia.org first of all... Janagewen (talk) 05:25, 16 September 2014 (UTC)[reply]

Needs more sources[edit]

I think this article needs more sources. Whole sections do not cite a single source. New guy 01:12, 31 December 2006 (UTC)[reply]

Request for comment: consolidated article[edit]

I have attempted to write a consolidated article, capturing all the important stuff from Itanium, Itanium 2, and IA-64, with the intent of replacing the three with one article named Itanium.

The proposed article is in my workspace. Please review and comment. (Comments on the proposed article's talk page, please.)

In addition to simplification and consolidation, I have attempted to add citations wherever I could, and I have removed some material that I could not find citations for. The article is basically a complete rewrite, but almost everything in it is from the original articles, with two major exceptions:

  • The material on the architecture is considerably more detailed and focused on architecture.
  • I added a timeline, moved many statements to the timeline, and added material to it.

The form of the citations still needs work, and we need still more citations. We are still missing a lot of history from the timeline,(mostly 1994-1997) and we are missing a paragraph in the "History" section abou tthe period from 2002 to present.However, this is material that is not present in the current articles either.

Thanks.-Arch dude 23:05, 19 March 2007 (UTC)[reply]

UPDATE: Colleagues, the WP:MERGE guideline is that a proposed merge can be completed after a two-week discussion period if consensus is reached, or after a four-week period if no comments are received. So far, there are no comments. I intend to perform the merger on or about 16 april if there are still no comments by then , but I would really prefer to have someone review the proposed new article. -Arch dude 18:28, 30 March 2007 (UTC)[reply]

It would be nice for the current status of IA-64 to be made clear[edit]

The introduction ends with, "As of 2008, Itanium was the fourth-most deployed microprocessor architecture for enterprise-class systems, behind x86-64, Power Architecture, and SPARC."

The History section's last subsection is, "Itanium 9500 (Poulson): 2012".

I resorted to using my browser's page search functionality to search for successive years: "2013", "2014", "2015".

It would be nice if the article made the current status of IA-64 more clear and/or more obvious.

Thanks for reading! 173.13.156.125 (talk) 07:45, 23 April 2015 (UTC)[reply]

External links modified[edit]

Hello fellow Wikipedians,

I have just added archive links to 2 external links on IA-64. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

checkY An editor has reviewed this edit and fixed any errors that were found.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—cyberbot IITalk to my owner:Online 20:52, 27 February 2016 (UTC)[reply]

As was the case on Itanium, the first of those references, and I fixed the reference to point to its new location. The second one's Wayback Machine location works. Guy Harris (talk) 21:01, 27 February 2016 (UTC)[reply]

Do we need to duplicate Itanium in the History section?[edit]

Processor details are already covered in Itanium, and that coverage is more up-to-date. Perhaps we should just quickly summarize the various IA-64/Itanium implementations here, leaving the details to Itanium. Guy Harris (talk) 20:51, 30 April 2017 (UTC)[reply]

Both Itanium and IA-64 are the architecture name, why not merge them together? — Preceding unsigned comment added by 119.53.118.176 (talk) 22:21, 30 April 2017 (UTC)[reply]

External links modified[edit]

Hello fellow Wikipedians,

I have just modified 9 external links on IA-64. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 08:14, 24 May 2017 (UTC)[reply]

External links modified[edit]

Hello fellow Wikipedians,

I have just modified 2 external links on IA-64. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

checkY An editor has reviewed this edit and fixed any errors that were found.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 08:10, 27 July 2017 (UTC)[reply]

Is IA-64 superscalar?[edit]

In this edit, "The Itanium architecture is based on explicit instruction-level parallelism, in which the compiler decides which instructions to execute in parallel. This contrasts with other superscalar architectures..." was changed to "The Itanium architecture is based on explicit instruction-level parallelism, in which the compiler decides which instructions to execute in parallel. This contrasts with superscalar architectures...", with the edit comment "itanium is not superscalar, it's vliw".

That was reverted in this edit, with the edit comment "rv, it literally supports instruction level parallelism (which is what the superscalar article defines itself as) so... ???".

What superscalar says is:

The superscalar technique is traditionally associated with several identifying characteristics (within a given CPU):
  • Instructions are issued from a sequential instruction stream
  • The CPU dynamically checks for data dependencies between instructions at run time (versus software checking at compile time)
  • The CPU can execute multiple instructions per clock cycle

and it further says, in superscalar#Alternatives:

Collectively, these limits drive investigation into alternative architectural changes such as very long instruction word (VLIW), explicitly parallel instruction computing (EPIC), simultaneous multithreading (SMT), and multi-core computing.
With VLIW, the burdensome task of dependency checking by hardware logic at run time is removed and delegated to the compiler. Explicitly parallel instruction computing (EPIC) is like VLIW with extra cache prefetching instructions.

This seems to suggest that VLIW is not the same thing as superscalar, because superscalar processors determine dynamically, in hardware, what operations to do in parallel, while in VLIW ISAs the instructions are statically set up for parallel execution by the code generator. IA-64 appears to fall into the VLIW category, not the superscalar category; there's more to superscalarity, at least as I read superscalar, than just instruction-level parallelism. Guy Harris (talk) 19:35, 9 February 2020 (UTC)[reply]

I really wasn't looking forward to a long debate on this. So this should be exciting. First, the language "contrasts with other superscalar architectures" has been around since at least 2013, if not earlier. So we're debating changing the wording and the meaning significantly after at least seven years of stability because of an anon IP edit that provided no source to justify the change. Second, the IA-64 instruction set, while offloading much of the parallel instruction decision making to the compiler, is still performing multiple operations simultaneously and is scalable because of the way the actual bytecode is generated. The important word is "contrasts", it's still a superscalar architecture, it simply leaves much of the parallel processing up to the compiler. —Locke Cole • t • c 23:18, 9 February 2020 (UTC)[reply]
It is superscalar if it executes more than one instruction per clock cycle. VLIW normally does this by supplying more than one instruction in the instruction word. In theory that isn't enough, as there is no requirement that VLIW execute all the instructions in one cycle. Given that, I an not so sure that it should apply to an architecture separate from its implementation. I don't know any reason to distinguish dynamic from static scheduling, though. Gah4 (talk) 01:38, 10 February 2020 (UTC)[reply]
For what it's worth, section 3.7 "Exploiting ILP Using Multiple Issue and Static Scheduling" of the Sixth Edition of Hennessy and Patterson's Computer Architecture: A Quantitative Approach says:
The goal of the multiple-issue processors, discussed in the next few sections, is to allow multiple instructions to issue in a clock cycle. Multiple-issue processors come in three major flavors:
1. Statically scheduled superscalar processors
2. VLIW (very long instruction word) processors
3. Dynamically scheduled superscalar processors
The two types of superscalar processors issue varying numbers of instructions per clock and use in-order execution if they are statically scheduled or out-of-order execution if they are dynamically scheduled.
VLIW processors, in contrast, issue a fixed number of instructions formatted either as one large instruction or as a fixed instruction packet with the parallelism among instructions explicitly indicated by the instruction. VLIW processors are inherently statically scheduled by the compiler. When Intel and HP created the IA-64 architecture, described in Appendix H, they also introduced the name EPIC (explicitly parallel instruction computer) for this architectural style.
So they draw a distinction between VLIW and superscalar. I'll see what other references I can find. Guy Harris (talk) 04:47, 10 February 2020 (UTC)[reply]
One way would be to ask them. Patterson was here last year for a talk, and I even had him sign my book. (3rd edition). I suspect, though, it gets back to the meaning of instruction. Looking at this article, they call the word a bundle containing multiple instructions. Consider that machines for years have performed more than one operation in an instruction, such as address computation (addition for indexing), or more, so you could make some really complex instructions that would count as one. IA64 could have defined the whole word as one instruction with multiple independent operations, but instead use the term bundle. As above, though, even with an architecture that defines multiple instructions in a bundle, there is no necessary requirement on the clock cycles needed to execute them. Counting cycles on modern (or even not so modern) processors isn't always easy, with various clock multipliers and such, different parts might have a different clock. But if you really want to know what H&P meant, I think you have to ask. Gah4 (talk) 13:31, 10 February 2020 (UTC)[reply]
OK, I e-mailed Patterson, will see if he replies. Gah4 (talk) 13:39, 10 February 2020 (UTC)[reply]
Answer is:
I think superscalar originated in reaction to VLIW but using a standard ISA with ILP unspecified . VLIW has explicit ISA visible ILP fixed. Itanium is hybrid.
Does that help? Gah4 (talk) 19:46, 10 February 2020 (UTC)[reply]
"Itanium is hybrid" sounds like "EPIC is a hybrid of VLIW and superscalar", which I read as saying that it's sufficiently distinct from both as to merit removing the "other" from "This contrasts with other superscalar architectures...".
The EPIC article says:
EPIC architectures add several features to get around the deficiencies of VLIW:
  • Each group of multiple software instructions is called a bundle. Each of the bundles has a stop bit indicating if this set of operations is depended upon by the subsequent bundle. With this capability, future implementations can be built to issue multiple bundles in parallel. The dependency information is calculated by the compiler, so the hardware does not have to perform operand dependency checking.
  • A software prefetch instruction is used as a type of data prefetch. This prefetch increases the chances for a cache hit for loads, and can indicate the degree of temporal locality needed in various levels of the cache.
  • A speculative load instruction is used to speculatively load data before it is known whether it will be used (bypassing control dependencies), or whether it will be modified before it is used (bypassing data dependencies).
  • A check load instruction aids speculative loads by checking whether a speculative load was dependent on a later store, and thus must be reloaded.
The first of those sounds as if it's the main difference between VLIW and EPIC - that description sounds like superscalarity between bundles. I have the impression that parallel execution within a bundle is explicit, given that the up-to-three instructions within a bundle use different execution unit types, rather than implicit as it is in conventional "have an implementation of an ISA that executes multiple instructions in parallel, even though the ISA doesn't have any explicit architectural notion of parallel execution". Parallel execution of separate bundles is also explicit, to the extent that the compiler (or assembler-code writer) explicitly indicates which bundles depend on other bundles and thus can't be executed in parallel. Guy Harris (talk) 21:18, 10 February 2020 (UTC)[reply]

architecture or processor?[edit]

To continue the above, but in a different direction. IA-64 is an architecture which can be implemented in processors. Those processors may implement it in different ways, as long as the result follows what the architecture says. Most often, architectures try to leave out implementation details, only describing the results of operations. One of those details is almost always speed. That allows for fast (expensive) and slow (not so expensive) implementations. One of the goals of IBM S/360, usually considered the origination of the idea of architecture, was a wide range of speed (and price) implementations, all compatible at the user level. Following that, IA-64 as an architecture should not include things like superscalar. A perfectly fine implementation could execute each bundle in 60 clock cycles. However, the reason for bundling is to make it easier to overlap instruction execution, which has been hard for many other architectures. Gah4 (talk) 19:58, 10 February 2020 (UTC)[reply]

Predicate registers[edit]

From the article. "64 one-bit predicate registers. These also have 32 static registers and 96 windowed or rotating registers. pr0 always reads 1 (true)." That doesn't add up. 2A02:168:2000:5B:B286:589F:2352:96B8 (talk) 16:34, 9 July 2020 (UTC)[reply]

Alleged claims of 'industry analysts predicting, that IA-64 would dominate in servers' and elsewhere, are completely unfounded[edit]

In the section marketing, the article claims, that "Industry analysts predicted that IA-64 would dominate in servers, workstations, and high-end desktops, and eventually supplant both RISC and CISC architectures for all general-purpose applications." while referencing sources on AnanTach and VentureBeat. First of all, not only is that a pretty bold statement to make and highly subjective, it seems even to be entirely made up as it just looks like utter Intel-propaganda.

Secondly, the AnandTech article came out in November 9, 2005. The article on VentureBeat came out in May 2009!

That was actually already several years after AMD's AMD64 came to market (2003) and when the battle between AMD's AMD64 and Intel's IA-64 over any future 64-bit extension (or in case of Intel, outright replacement) was already settled years ago in favour of AMD's AMD64 (which Intel was forced to adapt to stay relevant). So how on earth do article being written an published years after the first Itanium-iteration came to market (2001), are possibly able to retroactively 'predict' Intel's Itanium being the dominating future platform?

Worst of all, neither the article on AnandTech nor VentureBeat even mentioning said bits Itanium becoming the mainstream dominant platform. I'd thus suggest to strike out the parts, since they're largely nonsense at best. --Smartcom5 (Talk ?) 01:18, 15 August 2022 (UTC)[reply]

@@ Suggestion - > Perhaps people would benefit from more clarity in the article on what Intel were trying to achieve introducing this architecture and why it ultimately failed to compete. — Preceding unsigned comment added by 84.67.78.105 (talk) 15:58, 12 May 2023 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:IA-64&oldid=1202888810"