sundar@mipos2.intel.com (Sundar Iyengar~) (06/02/89)
>In article <20275@obiwan.mips.COM> mark@mips.COM (Mark G. Johnson) writes: >>We certainly see this phenomenon as well. The number of "I was the >>designer of the 80386" resume's that cross our desks is astonishing... > >Gee, if I was hiring someone, I'd be sorely tempted to throw those resumes >in the garbage as soon as I saw that line. Not something to be proud of >in my books! :-) :-) > >(Okay, I know the designers mostly weren't to blame for the architecture...) >-- >Van Allen, adj: pertaining to | Henry Spencer at U of Toronto Zoology >deadly hazards to spaceflight. | uunet!attcan!utzoo!henry henry@zoo.toronto. Henry Spencer is a prolific contributor to the Space and Computer Architecture groups on the USENET. He is well informed about the current affairs and usually his comments are intelligent and well received. However, what troubles me most is his blatant dislike for the people who design, implement and support the x86 architectures. In his views on Intel, I see a lack of ability to separate people from the issues. The people who work on our projects are intelligent, diligent and possess great problem solving abilities. Whatever they came up with in terms of x86 architectures and designs, represent the best given the constraints and the needs of our users as they existed when we started addressing them. Without knowing what those constraints and needs were, ridiculing the people for the end result they produced is not professional. Sundar Iyengar Microprocessor Design UUCP: intelca!mipos3!mipos2!sundar Intel, SC4-59 ARPA: sundar@mipos2.intel.com 2625, Walsh Avenue CSNET: sundar@mipos2.intel.com Santa Clara, CA 95051 AT&T: O: (408) 765-5206 Disclaimer: I am not a spokesman for Intel. The views presented here are mine and mine alone.
henry@utzoo.uucp (Henry Spencer) (06/02/89)
In article <182@mipos3.intel.com> sundar@mipos2.intel.com (Sundar Iyengar~) writes: >... However, what troubles me most is his blatant dislike for >the people who design, implement and support the x86 architectures. >In his views on Intel, I see a lack of ability to separate people >from the issues. The people who work on our projects are >intelligent, diligent and possess great problem solving abilities... Just as well, given some of the problems they have to face... :-) More seriously, I think you're confusing my views on the issues with my views on the people. One humorously-intended remark does not a "blatant dislike" make. I loathe the architectures. There is nothing particularly wrong with the people except for an apparent inability to distinguish good projects (worthy of their time and talents) from vile, disgusting ones. This is a serious lapse of taste and judgement but does not imply that they are stupid, lazy, or incompetent. Indeed, their intelligence, diligence, and competence in service to the x86 are all too depressingly obvious. (All the above said with tongue slightly, but only slightly, in cheek.) -- You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
peter@ficc.uu.net (Peter da Silva) (06/03/89)
But... isn't the truth an absolute defense against a charge of slander? Or is that libel? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
mash@mips.COM (John Mashey) (06/04/89)
In article <4392@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >But... isn't the truth an absolute defense against a charge of slander? >Or is that libel? - >Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. OK, it's really time for this one to stop cold; in my opinion, this is a new low for comp.arch. Although I often agree with Henry, the negative comments on the Intel designers were: a) uncalled-for (OPINION), and b) untrue (DATA to support this follows) Data: 1) I know a fair number of people, who have proven track records in this business, whose opinions I respect highly, who know and have worked with Intel designers that they believe are very good. 2) At least one processor that Henry likes [MIPS R2000] was designed by a team that included a fair number of [in my opinion, very good] people who also worked on the X86s..... 3) Neither Henry nor Peter is obviously in a position to personally evaluate the abilities of Intel or ex-Intel designers; certainly, it is fact that neither of them is located anywhere near the several places where such designers are usually found. Opinion: 1) This doesn't mean I love the X86 architecture. I don't. Even if I thought it was the worst architecture in the world, [I don't] it would be foolish to believe that people who worked on it were automatically bad. In my experience, although the best projects seldom have many turkeys, even the worst giant turkeys of projects usually have some good people. In any case, X86s are not remotely near being giant turkeys. 2) Even if I sometimes disagree with their marketing claims, I'm impressed that they make that architecture go as fast as it does. It clearly takes hard work by smart people to do this. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
henry@utzoo.uucp (Henry Spencer) (06/04/89)
In article <20993@winchester.mips.COM> mash@mips.COM (John Mashey) writes: >... Although I often agree with Henry, the negative >comments on the Intel designers were: a) uncalled-for (OPINION), and >b) untrue (DATA to support this follows) Data: My negative comments were all (that I recall) either a) accompanied by ":-)" or b) addressed specifically to their judgement about what project to work for at the time rather than their competence. Opinion: It seems clear to me that although Intel made several major mistakes in the original x86 architecture, and has made occasional lesser ones in the various implementations, most of the people involved in the implementations were (unfortunately) very good. The x86 wouldn't be half the pain it is if the implementation end hadn't been carried through so well. (Of note, in particular, is the reputed decision of the IBM PC's original [non-IBM] designers to use the Intel CPU simply because Intel was delivering good silicon at a time when nobody else was.) -- You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
pokey@well.UUCP (Jef Poskanzer) (06/05/89)
In the referenced message, sundar@mipos2.intel.com (Sundar Iyengar~) wrote: }Whatever they came up with in terms of x86 architectures and designs, }represent the best given the constraints and the needs of our users }as they existed when we started addressing them. Translation: "Trust us. We know what's good for you." Right... --- Jef Jef Poskanzer {ucbvax, lll-crg, sun!pacbell, apple, hplabs}!well!pokey "Life is too short to spend debugging Intel parts." -- Van Jacobson
peter@ficc.uu.net (Peter da Silva) (06/05/89)
In article <20993@winchester.mips.COM>, mash@mips.COM (John Mashey) writes: > In article <4392@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >But... isn't the truth an absolute defense against a charge of slander? > >Or is that libel? > OK, it's really time for this one to stop cold; in my opinion, this is > a new low for comp.arch. I assume you picked my message to reply to because it happened to be the one you were reading when you reached flashpoint. This is, I think, the only message I have written in this chain, and is not intended as a slam on intel's engineers, either individually or as a group. They have, given what they have to do, done a decent job with the 386. The people I'm unhappy with are the people who made the market decisions that lead to the current IBM/intel/64-k-segment morass in the PC world. So, basically what I'm saying is that you're attributing to me a series of messages that do not represent my opinions. And that, unfortunately, I haven't been following closely. Anyway, that's not very nice. With one exception, we seem to be in close agreement. > In any case, X86s are not remotely near being giant turkeys. Have you spent any significant amount of time trying to make large programs run well on the 8086 and/or the 80286? I have, and I think the phrase 'giant turkey' is far too kind a term. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
gillies@p.cs.uiuc.edu (06/06/89)
>In article <20275@obiwan.mips.COM> mark@mips.COM (Mark G. Johnson) writes: >Gee, if I was hiring someone, I'd be sorely tempted to throw those resumes >in the garbage as soon as I saw that line. Not something to be proud of >in my books! :-) :-) >-- >Van Allen, adj: pertaining to | Henry Spencer at U of Toronto Zoology >deadly hazards to spaceflight. | uunet!attcan!utzoo!henry henry@zoo.toronto. Well, if you're going to point fingers, why don't you blame MIT and project MAC? They were the one of the ones that took segmentation to outrageous extremes to begin with. Intel was only copying them. And if you wish MIT project MAC had never happened, then why not throw away all your Berkeley UNIX manuals, since there wouldn't have been UNIX if it weren't for two guys who had a knee-jerk reaction to Multics. History's greatest mistakes give rise to history's greatest successes. When there is failure (Multics, VAX architecture, i8086) it causes fanatics to go 180 degrees in the other direction, often with good results (Unix, RISC, Awesome 8x86 optimizing compiler technology). Don Gillies, Dept. of Computer Science, University of Illinois 1304 W. Springfield, Urbana, Ill 61801 ARPA: gillies@cs.uiuc.edu UUCP: {uunet,harvard}!uiucdcs!gillies
boyne@hplvli.HP.COM (Art Boyne) (06/06/89)
henry@utzoo.uucp (Henry Spencer) writes: > ... (Of note, >in particular, is the reputed decision of the IBM PC's original [non-IBM] >designers to use the Intel CPU simply because Intel was delivering good >silicon at a time when nobody else was.) Hmmm..., I seem to remember (I'm sure I'll be corrected if I'm wrong) that IBM bought a 60% (?) stake in Intel in the late 1970's, to guarantee a RAM supply after the RAM shortage in about the 1975-6 timeframe. I wonder if practically owning the company had any influence on IBM's decision to use Intel. :-) Art Boyne, boyne@hplvla.hp.com
hankd@pur-ee.UUCP (Hank Dietz) (06/06/89)
In article <20993@winchester.mips.COM> mash@mips.COM (John Mashey) writes: >OK, it's really time for this one to stop cold; in my opinion, this is >a new low for comp.arch. Although I often agree with Henry, the negative >comments on the Intel designers were: a) uncalled-for (OPINION), and >b) untrue (DATA to support this follows) ... Absolutely correct. I *HATE* the '86 family machines -- as do the majority of my fellow compiler writers/researchers -- but I certainly appreciate that they do what they do very well indeed. Intel is darn good at designing and fabricating chips... although we could argue about what they chose to design. Certainly, there are other processors out there that are commonly used and are far worse than the '86 line, but people are not so offended by them. Why? I think that "Intel bashing" is a direct consequence of the aggressive, and perhaps overly creative ;-), marketing approach that Intel has taken -- especially in the early days of the '86 family. This recognition may be the only profitable thing to come from this discussion. -hankd@ee.ecn.purdue.edu
jac@paul.rutgers.edu (J. A. Chandross) (06/07/89)
gillies@p.cs.uiuc.edu > And if you wish MIT project MAC had never happened, then why not throw > away all your Berkeley UNIX manuals, since there wouldn't have been > UNIX if it weren't for two guys who had a knee-jerk reaction to Multics. Actually, there were more than 2 guys. And they didn't have a "knee-jerk" reaction to Multix. Au contraire. They *liked* Multics. But when Bell Labs pulled out of the Multics project they were going to lose their comfortable niche. So they consed up a replacement environment. Jonathan A. Chandross Internet: jac@paul.rutgers.edu UUCP: rutgers!paul.rutgers.edu!jac
graham@fuel.dec.com (kris graham) (06/07/89)
> > History's greatest mistakes give rise to history's greatest successes. > When there is failure (Multics, VAX architecture, i8086) it causes > fanatics to go 180 degrees in the other direction, often with good > results (Unix, RISC, Awesome 8x86 optimizing compiler technology). > > Don Gillies, Dept. of Computer Science, University of Illinois > 1304 W. Springfield, Urbana, Ill 61801 > ARPA: gillies@cs.uiuc.edu UUCP: {uunet,harvard}!uiucdcs!gillies Could you elaborate on why you think the "VAX architecture" is one of "History's greatest mistakes or failure....."? and what "history's greatest successes." can be attributed to the "VAX architecture mistakes and failures" ? Christopher Graham Digital Equipment Corp Ultrix Resource Center Internet: graham@fuel.dec.com 2 Penn Plaza UUCP: ...!decwrl!fuel.dec.com!graham New York City
chris@softway.oz (Chris Maltby) (06/07/89)
In article <1989Jun2.163144.5197@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > (All the above said with tongue slightly, but only slightly, in cheek.) Calm down Mr Spencer. Like the 360 architecture in its day and the poor, I think the x86's will be with us forever. We'll just have to deal with the reality - pleasant or otherwise. It's architectures like that which ensure that programmers will never become redundant... -- Chris Maltby - Softway Pty Ltd (chris@softway.sw.oz) PHONE: +61-2-698-2322 UUCP: uunet!softway.sw.oz.au!chris FAX: +61-2-699-9174 INTERNET: chris@softway.sw.oz.au
jkrueger@daitc.daitc.mil (Jonathan Krueger) (06/09/89)
In article <1641@softway.oz>, chris@softway (Chris Maltby) writes: >It's architectures like [the x86] which >ensure that programmers will never become redundant... No, just their programs. How many incompatible ways can YOU work around an architectural limit? Answer: too many. -- Jon --