Talk:Intel i860
This is the talk page for discussing improvements to the Intel i860 article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
![]() | This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
The i860 was never superscalar -- it was quasi-VLIW. I will leave this comment here for a while to elicit feedback, and then correct the commentary. gnetwerker - 12/29/04
- Just saw this now -- some easier way to track comments would be nice. Anyway I'm not sure the two are as separate as you note, the term "superscalar" generally means "runs more than one instruction at once". I think the i860 certainly fits this definition. Of the two, VLIW is more restrictive, such that all VLIW processors are superscalar (or what's the point?!) while only a very few superscalar designs are VLIW. Maury 13:24, 31 Jan 2005 (UTC)
Well, no, not really -- "superscalar" does not mean "more than 1 insn at once" -- it means "more than one instruction at once from a normal, linear instruction stream". Otherwise microcode machines and others were doing it for years. Read Patterson and Hennessey or Mike Johnson's (from AMD) book on the subject. VLIW is VLIW, Superscalar is superscalar. The two are different. The literature backs me up on this one. I know because I wrote some of it. -- Gnetwerker 22:49, 7 Feb 2005 (UTC)
OK, I did a certain amount of work on this. First, as noted above, the i860 was NOT Superscalar. Second, calling VLIW an "extension" of RISC is completely wrong, as well as historically out of place, as the i860 was developed in they heyday of RISC, and was a competitor to more normal RISC concepts. Third, the i960 actually taped out long before the i860, though I have left some wiggle room in there because I don't know the precise tape-out date for the 860 (the 960 first tape-out was October 85, same month as the i386). Fourth, the central paragraph was a blatantly POV trumpeting of its superior performance which was (IMHO) insufficiently corrected by the (problems) para. Ideally these would be merged into a single NPOV para but I'm not there yet. - Gnetwerker 08:15, 30 Mar 2005 (UTC)
No, I'm not just trolling
editYou note:
First, as noted above, the i860 was NOT Superscalar.
Well let's see what foldoc says:
A superscalar architecture is a uniprocessor that can execute two or more scalar operations in parallel.
Pretty clear so far. By this definition the i860 is definitely superscalar.
Some definitions include superpipelined and VLIW architectures; others do not.
So certainly the definition used in this article can apply.
Superscalar architectures (apart from superpipelined architectures) require multiple functional units, which may or may not be identical to each other.
The i860 certainly fits this description.
In some superscalar processors the order of instruction execution is determined statically (purely at compile-time), in others it is determined dynamically (partly at run time).
Once again, the i860 is defined by, at least, the loose definition.
I would claim that the common definition, and even some of the more pendantic ones, support the statement "the i860 was a superscalar processor". I can find no instances of a general definition that explicitly disagrees, all I can find are comments in the context of VLIW that say it's different. I don't think these definitions are either widely used, nor particularily useful.
If one does wish to claim VLIW is not superscalar, I'd really like to know what purpose that claim would serve. Since the general understanding of superscalar is more the one instruction at a time, VLIW implementations would always appear to be a subset (is there a counterexample? can their be?). Saying that VLIW machines are not superscalar would be like saying a Jeep isn't a car, because it only comes in wheel drive: you have to redefine "car" in order to make the definition work. And for what reason?
Moving on, I don't remember the article calling VLIW an extension of RISC. But even if it did, it's equally incorrect to claim that VLIW is, by definition, different (or competing). RISC is based on a small number of basic concepts:
- make memory access explicit; it's expensive, make the programmer known they're doing it and thereby try to avoid it
- use lots of registers instead, and make most instructions register-register only instead of providing lots of versions in microcode -- use that silicon for something else instead
It is for these reasons that the literature often tries to use the term load-store instead of RISC, as the later is misleading.
I suppose it's entirely possible that someone could build a VLIW-based CISC design; that is, a CPU with lots of microcode, lots of addressing modes, and a VLIW instruction format.
The i860 certainly fit into this definition of RISC as far as I can tell. It is certainly fair to call the Merced a VLIW-RISC system, and it would seem the same is true for the i860. The only way to know for sure is to look at the addressing modes.
Maury 01:20, 25 Apr 2005 (UTC)
If You're Not Trolling, You're Just Plain Wrong
editVLIW is not superscalar because if it were, every bitslice microcode processor out there would be "superscalar" -- it would have no meaning. As I said already, and you have ignored, the reputable, published literature on the subject defines superscalar as I have. The definitive work is "Superscalar Microprocessor Design", by Mike Johnson, Pentice-Hall, 1991. On page 6, he says: "A superscalar processor ... allow[s] concurrent execution of instructions in the same pipeline stage ..." (emphasis in original). If you choose the one-line definition from an on-line dictionary of no greater repute than Wikipedia, you demean both.
So let me repeat: I was on the i960 design team. I was intimately acquainted with the i860 design and team. Intel did not market or describe the i860 as superscalar. The dominant experts in the field do not consider the i860 superscalar. The distinction between superscalar and VLIW is a clear and important one (having to do with the trade-off between instruction decode complexity and fetch bandwidth/code expansion). You are, quite simply, wrong. If you, an apparent amateur with no specific qualification in the field, want to force this issue, then you reinforce the central complaint about Wikipedia -- it can never be trusted. -- Gnetwerker 08:24, 25 Apr 2005 (UTC)
- I think (as less than amateur) that you guys are pretty much splitting terminological hairs here. Nobody will take this entry as some kind of definitive reference. I don't think that this shows that Wikipedia cannot be trusted - just that one is well advised to check Talk page and source documents, if doing more than just idly browsing. Where are Talk pages in Britannica? :) --bonzi 21:28, 15 January 2006 (UTC)
BTW, there is no argument that the i860 might be called "RISC" (someone tried to call almost every processor built after 1986 thusly). What it is not meaningful to say is that it is an "extension" of RISC. It is not. It was a different direction that failed and is now largely dead. -- Gnetwerker 08:24, 25 Apr 2005 (UTC)
Who are these "experts in the field"?
editOK, I would recommend you actually look at the i860 ISA before calling it a VLIW machine. It is by any definition a superscalar processor.
I believe a lot of the confusion comes from the fact that the 860 was, however, an "implicit superscalar" design. since each instruction/opcode is isolated and targets a single functional unit, unlike VLIW instructions. Unlike explicit superscalars (or dynamic if you may) the 860 made the pipeline visible, meaning that there were very strict restrictions on the instruction ordering. That still does not make it a VLIW machine, in the sense that a machine with delay slots is not considereded automatically a VLIW design just because. Some people argue that this "visibility" of the pipeline makes the i860 not a SuperScalar design, but the truth of the matter is that superscalar just refers to processors with the ability of executing/issuing 2+ instructions per cycle.
So let's all coold down our engines, please.
The Experts: People Who Were There
editTo the question: Who Were the Experts? -- They were those of us actively working in the field in the late 1980s. Most likely in attendance at the Hot Chips Conference, or several others. Some (already noted) published books on the subject (Mike Johnson, John Hennessey/Bill Patterson), some designed these chips (Glen Myers, Randy Steck), others marketed them (Claude Leglise). Claude, the overall manager for the i860, never referred to, considered, or marketed the 860 as Superscalar. No one at any contemporaneous conference referred to it as such.
What part of "A superscalar processor ... allow[s] concurrent execution of instructions in the same pipeline stage ..." do you fail to understand? The i860 achieved multiple instruction execution from wide instructions, not from superscalar technology. You are confusing the fact that the i860 had a "single intruction mode" as well as the (default) dual instruction mode with the notion that it could issue multiple simultaneous instructions from single instruction mode -- it could not, therefore was not superscalar. In dual instruction mode, it was VLIW.
From http://www.nxp.com/acrobat/other/vliw-wp.pdf:
In the early 1990s, Intel introduced the i860 RISC microprocessor. This simple chip had two modes of operation: a scalar mode and a VLIW mode. In the VLIW mode, the processor always fetched two instructions and assumed that one was an integer instruction and the other floating-point. A single program could switch (somewhat painfully) between the scalar and VLIW modes, thus implementing a crude form of code compression.
-- Gnetwerker 9 July 2005 06:43 (UTC)
"A superscalar processor ... allow[s] concurrent execution of instructions in the same pipeline stage ..."
I am afraid you are the one here who fails to understand this sentence, the i860 allowed up to 2/3 concurrent instructions: 1 integer, 1 FP, and possibly 1 FP in the MACC unit for GFX and yes they were all concurrent since the pipelines were decoupled. Thus making it a superscalar, whether you like it or not. It is not a true VLIW in the sense that the instructions themselves were RISC not VLIW.... The people from multiflow, cyndrome, et al would take a serious offence at the i860 being considered a VLIW.
Link down
editLink entitled "Intel i860 64-Bit Microprocessor Data Sheet" is down 87.234.92.102 16:02, 30 December 2006 (UTC)
XScale
editJust a note: XScale has been sold to Marvell 193.131.176.54 10:32, 8 March 2007 (UTC)
Surely XScale has no relation whatsoever to i860, other than that they were both RISC designs. The last sentence in the article seems misleading. —Preceding unsigned comment added by 130.88.195.88 (talk) 13:41, 20 May 2008 (UTC)
Chipset
editWhere is (or should be) the wiki page for the i860 chipset? 195.38.110.188 (talk) 00:02, 3 December 2008 (UTC)
- Added as Template:Distinguish2; Alecv (talk) 06:48, 5 December 2008 (UTC)
Lead
editLong blockquotes in the lead generally don't work. I would like to see it moved farther down, into the body. Perhaps the quote can be summarized in fewer words in the lead, if necessary. Viriditas (talk) 10:19, 19 April 2009 (UTC)
Clock speeds of the i860 etc
editI recall that the i860 was internally clock doubled. If that can be verified, perhaps it should be added. Also, if it was released at the same time as the i486, was it the first internally clock-doubled Intel CPU? I ask because later i486's were internally clock doubled/trebled (DX2 and DX4s).
I also recall that some manufacturer (the name escapes me now) had built a "supercomputer" using four i860 CPUs. Part of the advertising was that it cost less than some threshold dollar figure (and I seem to recall $10,000, but don't count that as factual). It was targeted more for the university/research market. If some information on that design could be found, including theoretical and actual performance, that would make a nice addition as an example of a real design.
Thanks!
97.93.196.70 (talk) 19:10, 24 December 2010 (UTC) Will in Texas, December 24, 2010
hauppauge i4860
editHauppauge sold a workstation (called the i4860, if I remember correctly) back in the early 1990s that had both an i486 and an i860 on the motherboard. We used them to help write code for our iPSC/860 Hypercubes. 173.164.82.58 (talk) 15:38, 17 July 2011 (UTC) John Kuras
I admin'd one back in the day, '95 or so I'd guess, it ran an SVR4 variant, had an EISA bus and some kind of SVR4 UNIX. — Preceding unsigned comment added by 205.210.53.214 (talk) 21:51, 29 November 2011 (UTC)
External links modified
editHello fellow Wikipedians,
I have just modified one external link on Intel i860. 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:
- Added archive https://web.archive.org/web/20080525110753/http://www.geek.com/intels-486-cpu-turns-15/ to http://www.geek.com/intels-486-cpu-turns-15/
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: 5 June 2024).
- 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) 15:31, 14 November 2017 (UTC)