jsp@glia.u.washington.edu (Jeff Prothero) (10/26/90)
I'm upset. Twice in six months I've spent a week or so tracking down
a bug, only to find that it's in my '386 instead of in my code.
That's not why I'm upset -- I know this is the computer industry,
where defective merchandise doesn't entitle you to a repair, a
replacement, or even an apology :-). I'm upset because (after a month
or so of playing ring-around-the-rosie, accumulating manuals I don't
need) I'm told that Intel considers known bugs in their chips to be
proprietary and confidential information.
This policy strikes me as reprehensible and downright stupid. There
are a *lot* of '386s out there, some of them in embedded systems
performing life-critical tasks. It doesn't take much imagination to
construct a scenario leading from a deliberately suppressed bug report
to bodybag(s) to a massive lawsuit.
My questions:
Does anyone want to explain why Intel adopted this policy?
Does anyone want to *defend* this policy?
Is this SOP in the industry? Do Motorola, AMD, NS ... follow the
same policy?
Can I go to Motorola for a list of known Intel bugs, and vice versa?
Is there a net archive of known bugs? Any interest in forming one?
Any other affordable source? Any reports to contribute?
For the the record, the latest bug is that a POPAD followed by a MOV
ECX, [EDX+EDI] will clobber EAX. It appears that Intel got a little
too aggressive on the pipelining here, and that the final POPAD cycle
(which restores EAX) is being trashed by the address unit computations
for [EDX+EDI]. Here's some code to reproduce the problem, provided
courtesy of John Lauro (jal@acc.flint.umich.edu). The bug has been
detected on an old 16MHz '386 and a new 25MHz DX, and not on an SX.
We haven't checked any other machines.
jsp@milton.u.washington.edu
---- Cut here ----
.386
DATA SEGMENT USE16 PUBLIC
MOK DB 'POPAD ok',13,10,'$'
MNOTOK DB '*** POPAD fails test ***',13,10,'$'
DATA ENDS
;
;
STKSEG SEGMENT USE16 STACK
DW 100 DUP(?)
STKSEG ENDS
;
;
CODE SEGMENT USE16 PUBLIC
ASSUME CS:CODE,SS:STKSEG,DS:DATA
CODES PROC FAR
START: MOV AX,DATA
MOV DS,AX
mov eax,12345678
mov edx, 0
mov edi, 0
pushad
popad
; The instruction immediately following popad is the critical
; instruction. Simple fix, insert a NOP after popad.
mov ecx, [edx+edi]
cmp eax, 12345678
je ok
mov dx, offset mnotok
outmsg: mov ah, 09h ; ConStringOutput
int 21h
mov ah, 4ch ; Exit
mov al, 0
int 21h
ok: mov dx, offset mok
jmp outmsg
CODES ENDP
CODE ENDS
END START
----------------------------------
--
- Jeff (S)jcallen@Encore.COM (Jerry Callen) (10/26/90)
In article <JSP.90Oct25155458@glia.u.washington.edu> jsp@glia.u.washington.edu (Jeff Prothero) writes: > > [A very reasonable complaint about a bug in an 80386 costing a week of > work, and, to rub salt in the wounds, Intel considers the bug list > proprietary information.] >This policy strikes me as reprehensible and downright stupid. No argument there; I'm a big believer in making bug lists public (even though companies I work for may not necessarily agree...). Moto does; I have bug lists for each rev of the 88100/88200 chips. Getting them was not hard; I called up Moto and they faxed them to me. >There >are a *lot* of '386s out there, some of them in embedded systems >performing life-critical tasks. It doesn't take much imagination to >construct a scenario leading from a deliberately suppressed bug report >to bodybag(s) to a massive lawsuit. Hmmmm... "Motorola, Inc. General policy does not recommend the use of its components in life support applications wherein a failure or malfunction of the component may directly threaten life or injury. Per Motorola Terms and Conditions of Sale, the user of Motorola components in life support applications assumes all risk of such use and indemnifies Motorola against all damages." and... "NATIONAL PRODUCTS ARE NOT AUTHORIZED FOR USE AS CRITICAL COMPONENTS IN LIFE SUPPOERT DEVICES OR SYSTEMS WITHOUT THE EXPRESS WRITTEN APPROVAL OF THE PRESIDENT OF NATIONAL SEMICONDUCTOR CORPORATION. As used herein: 1) Life support devices or systems are devices or systems which, (a) are intended for surgical implant into the body, or (b) support or sustain life, and whose failure to perform, when properly used in accordance with instructions for use provided in the labeling, can reasonably be expected to result in significant injury to the user. 2) A critical component is any component of a life support device or system whose failure to perform can be reasonably expected to cause the failure of the life support device or system, or to affect its safety or effectiveness." These statements were found in obvious places in Motorola and National data sheets. Interestingly I searched and could find no such disclaimer on Intel data sheets. Of course, I have no idea whether such disclaimers are worth the paper they are printed on. >My questions: > >Does anyone want to explain why Intel adopted this policy? A combination of shortsightedness, arrogance and stupidity? >Does anyone want to *defend* this policy? Not me! >Is this SOP in the industry? Do Motorola, AMD, NS ... follow the >same policy? I do know that Motorola and National make this information available if you ask for it. Can't say about others. >Can I go to Motorola for a list of known Intel bugs, and vice versa? Wouldn't be very sporting, would it? :-) >Is there a net archive of known bugs? Any interest in forming one? >Any other affordable source? Any reports to contribute? Sounds like a GREAT idea. I'm not real keen on typing in the 88100/88200 bug sheets I have, but maybe someone from Moto has them in machine-readable form? -- Jerry Callen jcallen@encore.com
linden@fwi.uva.nl (Onno van der Linden) (10/27/90)
jsp@glia.u.washington.edu (Jeff Prothero) writes: [Stuff deleted] >For the the record, the latest bug is that a POPAD followed by a MOV >ECX, [EDX+EDI] will clobber EAX. It appears that Intel got a little >too aggressive on the pipelining here, and that the final POPAD cycle >(which restores EAX) is being trashed by the address unit computations >for [EDX+EDI]. Here's some code to reproduce the problem, provided >courtesy of John Lauro (jal@acc.flint.umich.edu). The bug has been >detected on an old 16MHz '386 and a new 25MHz DX, and not on an SX. >We haven't checked any other machines. Well, I checked the 386SX at home and it _does_ have the bug described above.Are there any 'fixed' 386SX's on the market ? [Program to detect bug deleted] Onno van der Linden linden@fwi.uva.nl
jal@acc (John Lauro) (10/27/90)
In article <1398@carol.fwi.uva.nl> linden@fwi.uva.nl (Onno van der Linden) writes: > Well, I checked the 386SX at home and it _does_ have the bug described >above.Are there any 'fixed' 386SX's on the market ? Yes, all the 386SX machines I tested here do not have the bug. The machines are from Zenith, and are over 10 months old. - John_Lauro@ub.cc.umich.edu - jal@acc.flint.umich.edu
kaleb@thyme.jpl.nasa.gov (Kaleb Keithley ) (10/27/90)
In article <13056@encore.Encore.COM> jcallen@encore.Com (Jerry Callen) writes: >In article <JSP.90Oct25155458@glia.u.washington.edu> jsp@glia.u.washington.edu (Jeff Prothero) writes: >> >> [A very reasonable complaint about a bug in an 80386 costing a week of >> work, and, to rub salt in the wounds, Intel considers the bug list >> proprietary information.] > >>This policy strikes me as reprehensible and downright stupid. > While we're on the topic, what about 486 bugs. I have a B5 486; any known bugs in it. Does any manufacturer have a "recall" policy where they replace your cpu at a price substantially lower than retail. -- Kaleb Keithley Jet Propulsion Labs kaleb@thyme.jpl.nasa.gov causing trouble again.
chris@mimsy.umd.edu (Chris Torek) (10/27/90)
In article <JSP.90Oct25155458@glia.u.washington.edu> jsp@glia.u.washington.edu (Jeff Prothero) writes: >For the the record, the latest bug is that a POPAD followed by a MOV >ECX, [EDX+EDI] will clobber EAX. ... Another shining example of the inherent superiority of CISC to RISC :-) (sorry, could not stop myself) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
feustel@netcom.UUCP (David Feustel) (10/27/90)
Let's start a 386/486 bugs newsgroup. -- David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631
mslater@cup.portal.com (Michael Z Slater) (10/27/90)
>In article <JSP.90Oct25155458@glia.u.washington.edu> jsp@glia.u.washington.edu >(Jeff Prothero) writes: >>I'm upset. Twice in six months I've spent a week or so tracking down >>a bug, only to find that it's in my '386 instead of in my code. >>That's not why I'm upset -- I know this is the computer industry, >>where defective merchandise doesn't entitle you to a repair, a >>replacement, or even an apology :-). I'm upset because (after a month >>or so of playing ring-around-the-rosie, accumulating manuals I don't >>need) I'm told that Intel considers known bugs in their chips to be >>proprietary and confidential information. >This policy strikes me as reprehensible and downright stupid. >> > >No argument there; I'm a big believer in making bug lists public (even >though companies I work for may not necessarily agree...). Moto does; >I have bug lists for each rev of the 88100/88200 chips. Getting them >was not hard; I called up Moto and they faxed them to me. Intel and Motorola BOTH treat bug lists as confidential. As a customer, you should be able to get bug lists from either, though you may have to sign an NDA. I would ALWAYS insist on getting bug lists from a vendor if I was starting a design with their chip, and I'd ask every month or two for the updated version. I have waged a long and unsuccessful campaign to get these companies and others to provide their bug lists to Microprocessor Report. Motorola has been just as unwilling to cooperate as Intel. The semiconductor companies are afraid that their competitors will use their bug lists against them, and they argue that any legitimate chip user can get the bug list by asking. As the first article in this thread makes clear, many users end up writing software without access to the bug list. My position: bug lists should be public information. Microprocessor Report has published bug lists in the past, and if people will send them to me, I'll continue to publish them (for chips of general interest). Michael Slater, Editor and Publisher, Microprocessor Report mslater@cup.portal.com 707/823-4004 fax: 707/823-0504 874 Gravenstein Hwy. So., Suite 14, Sebastopol, CA 95472
rfg@NCD.COM (Ron Guilmette) (10/28/90)
In article <13056@encore.Encore.COM> jcallen@encore.Com (Jerry Callen) writes:
<>Is this SOP in the industry? Do Motorola, AMD, NS ... follow the
<>same policy?
<
<I do know that Motorola and National make this information available
<if you ask for it. Can't say about others.
One champion of us `users' in this regard has been Michael Slater and his
Microprocessor Report. He has been campaining for full disclosure of
chips bugs for some time now. He has even managed to extract commitments
from some chip vendors that they will release such information freely,
fully, and in a timely manner (or something like that).
I forget who all the vendors are that he has gotten such commitments from,
but based solely upon the content of the discussion I have been reading
here, I would have to guess that Intel is not among them.
<>Is there a net archive of known bugs? Any interest in forming one?
I have created and distributed (electronically) lists of bugs in various
C++ language processors, but I am rather straying from the subject now
aren't I? I just mentioned it so that y'all would know that such things
can be done easily enough, so long as there is one person who is motivated
enough (or paid enough) to maintain and distribute such a bug list.
--
// Ron Guilmette - C++ Entomologist
// Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg
// Motto: If it sticks, force it. If it breaks, it needed replacing anyway.lindsay@gandalf.cs.cmu.edu (Donald Lindsay) (10/28/90)
In article <35322@cup.portal.com> mslater@cup.portal.com (Michael Z Slater) writes: >Intel and Motorola BOTH treat bug lists as confidential. As a customer, you >should be able to get bug lists from either, though you may have to sign an >NDA. I would ALWAYS insist on getting bug lists from a vendor if I was >starting a design with their chip, and I'd ask every month or two for the >updated version. In the above, you are clearly talking about the early-stepping bugs that plague a chip in its sample-quantity days. The original poster claimed to have just found a bug in the 386, which has been a volume item for qute some time now. Surely the situations are very different? -- Don D.C.Lindsay
ccplumb@spurge.uwaterloo.ca (Colin Plumb) (10/30/90)
In article <13056@encore.Encore.COM> jcallen@encore.Com (Jerry Callen) writes: >No argument there; I'm a big believer in making bug lists public (even >though companies I work for may not necessarily agree...). Moto does; >I have bug lists for each rev of the 88100/88200 chips. Getting them >was not hard; I called up Moto and they faxed them to me. Well, Michael Slater weakened this argument, but someone leaning over my shoulder suggested it was an economic necessaity for Intel. Motorola's bug lists are probably a few pages. Intel would need to send out a small book. Yes, tongue-in-cheek, but Intel's bug lists are famous for their size. -- -Colin
ingoldsb@ctycal.UUCP (Terry Ingoldsby) (10/31/90)
In article <13056@encore.Encore.COM>, jcallen@Encore.COM (Jerry Callen) writes: > In article <JSP.90Oct25155458@glia.u.washington.edu> jsp@glia.u.washington.edu (Jeff Prothero) writes: ... > >There > >are a *lot* of '386s out there, some of them in embedded systems > >performing life-critical tasks. It doesn't take much imagination to > >construct a scenario leading from a deliberately suppressed bug report > >to bodybag(s) to a massive lawsuit. ... > "Motorola, Inc. General policy does not recommend the use of its components > in life support applications wherein a failure or malfunction of the component > may directly threaten life or injury. Per Motorola Terms and Conditions of > Sale, the user of Motorola components in life support applications assumes all > risk of such use and indemnifies Motorola against all damages." > > and... > > "NATIONAL PRODUCTS ARE NOT AUTHORIZED FOR USE AS CRITICAL COMPONENTS IN LIFE > SUPPOERT DEVICES OR SYSTEMS WITHOUT THE EXPRESS WRITTEN APPROVAL OF THE > PRESIDENT OF NATIONAL SEMICONDUCTOR CORPORATION. As used herein: > I sympathize completely with Jerry (who complains that Intel won't publish a bug list). I use software from a vendor who has much the same attitude. It is *infuriating* to twiddle with something for days, only to conclude that the fault lies in someone else's product, log the complaint, and hear that it is a known bug. No excuse for it. Why do we tolerate it? There is a difference between the refusal to publish a bug list and the disclaimer for using a product in a life support application. In fairness to the vendor, they build a product that will satisfy *most* users. This means that incomplete testing procedures are used, both in design and production. This is not sloppy workmanship, it is economics. If you can catch most of the flaws with a 30 second test, is it reasonable to spend a day to certify that a chip is 100% OK? The cost of the component would soar. Not only that, but you'd have to establish an insurance fund in case some flaw did slip through (it may not be feasible to guarantee 100% performance). Most users would rather take the chance that their workstation might be down 1 day a year, than pay 5 times the price for the station. In life critical applications, either the supplier, or the VAR can perform the necessary tests and charge only those people that need the high reliability. That is probably why medical equipment costs *so* much. -- Terry Ingoldsby ctycal!ingoldsb%cpsc.ucalgary.ca Land Information Services or The City of Calgary ...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsb
brian@positron.amd.com (Brian McMinn) (10/31/90)
(Jeff Prothero) writes: | Is this SOP in the industry? Do Motorola, AMD, NS ... follow the | same policy? These are my observations from the inside of AMD, not official company policy. I was the "keeper of the bug list" for the Am29000 a couple of years ago. The list contained both a detailed internal description (digestible only by those with intimate knowledge of the part and a full set of logic schematics) and a functional description (all known ways to observe the bug) as well as any known workarounds. The detailed description was strictly internal, but the remainder of the of the list was sent to our marketing group (for distribution to customers) on a regular basis. To my knowledge, our bug list was and still is freely available. There was (and probably still is) some deliberate delay in releasing new bug reports. These delays were for engineering reasons, not marketing reasons. We did not tell the world of a new bug until we had replicated the bug ourselves, understood its cause, looked for as-yet-unreported ways it might manifest itself, and looked diligently for a workaround. Intel's position is different (and somewhat understandable, even if it is deplorable :-) in light of the fact that their chips are second sourced. If Intel made their bug list public, then AMD would have free access to it. One of the not-so-obvious advantages that Intel gains by not making their bug list public is that they can implement fixes to the undisclosed bugs and then reveal both the bug list and the "new and improved" chip at the same time. This prevents AMD from beating them to the draw with a fix. Again, these are my opinions. Brian McMinn brian.mcminn@amd.com Advanced Micro Devices N5PSS Austin, Texas 1-(512)-462-5389 "You can't leap a chasm in two jumps."
mslater@cup.portal.com (Michael Z Slater) (10/31/90)
>(Jeff Prothero) writes: > >| Is this SOP in the industry? Do Motorola, AMD, NS ... follow the >| same policy? > > Brian McMinn writes: > >These are my observations from the inside of AMD, not official >company policy. >I was the "keeper of the bug list" for the Am29000 a couple of years >ago. The list contained both a detailed internal description >(digestible only by those with intimate knowledge of the part and a >full set of logic schematics) and a functional description (all known >ways to observe the bug) as well as any known workarounds. The >detailed description was strictly internal, but the remainder of the >of the list was sent to our marketing group (for distribution to >customers) on a regular basis. > >To my knowledge, our bug list was and still is freely available. >There was (and probably still is) some deliberate delay in releasing >new bug reports. These delays were for engineering reasons, not >marketing reasons. We did not tell the world of a new bug until we >had replicated the bug ourselves, understood its cause, looked for >as-yet-unreported ways it might manifest itself, and looked diligently >for a workaround. AMD would not provide me with a copy of the 29K bug list until AFTER the branch target cache was fixed. In fact, they got rather upset when I printed a description of the bugs from another source. When the chip was nearly fully functional, they decided to give me the list. This is typical of how most companies have behaved -- if the chip is nearly bug-free, then they'll give me the list. Intel has NEVER given me a list -- perhaps because their chips aren't ever nearly bug-free! :-) So, AMD, how about posting (or sending to me) the bug list for the 29050? The position of most companies is that their customers get the lists, so there is no need to give them to the press. The problem with this attitude is that many people program the chips, or build hardware but don't have good contacts with the chip supplier, and thus don't get the lists. If you aren't ashamed of your silicon, you shouldn't be afraid to let the bug list be published. My offer to any chip companies: send me your bug lists, and I'll put you on our official "good guys" list (and publish a summary of your bug list). Submissions from chip users are welcome as well, and may be anonymous. Because of the difficult of verifying bug reports, however, our interest is primarily in copies of vendor-supplied bug lists. And of course, I can't encourage anyone to violate an NDA. Michael Slater, Microprocessor Report mslater@cup.portal.com 874 Gravenstein Hwy. So., Suite 14, Sebastopol, CA 95472 707/823-4004 fax: 707/823-0504
jkenton@pinocchio.encore.com (Jeff Kenton) (10/31/90)
From article <35431@cup.portal.com>, by mslater@cup.portal.com (Michael Z Slater): > > AMD would not provide me with a copy of the 29K bug list until AFTER the > branch target cache was fixed. > > . . . > > My offer to any chip companies: send me your bug lists, and I'll put you on > our official "good guys" list (and publish a summary of your bug list). > For the 88000, Motorola provided errata sheets which were reasonably complete and were updated regularly. The current one is mercifully short. My experience with them has been good in this regard from the beginning. You might ask them (not me) if they will send you a copy. ----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ----- ----- jeff kenton: consulting at jkenton@pinocchio.encore.com ----- ----- until 11/30/90 -- always at (617) 894-4508 ----- ----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -----
henry@zoo.toronto.edu (Henry Spencer) (11/01/90)
In article <35431@cup.portal.com> mslater@cup.portal.com (Michael Z Slater) writes: >... If you aren't ashamed of >your silicon, you shouldn't be afraid to let the bug list be published. And then, of course, there are people who *ought* to be ashamed of their silicon... I remember being somewhat surprised about how free National was with the 32032 bug list, bearing in mind some of the things on it... -- "I don't *want* to be normal!" | Henry Spencer at U of Toronto Zoology "Not to worry." | henry@zoo.toronto.edu utzoo!henry
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (11/01/90)
In article <35431@cup.portal.com> mslater@cup.portal.com (Michael Z Slater) writes: | My offer to any chip companies: send me your bug lists, and I'll put you on | our official "good guys" list (and publish a summary of your bug list). I can't offer to publish in a nation magazine, but I can install verified bug lists on the mail archive server on sixhub, which will allow people to reach them. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) The Twin Peaks Haloween costume: stark naked in a body bag
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (11/02/90)
In article <35431@cup.portal.com>, mslater@cup.portal.com (Michael Z Slater) writes: > ... >The position of most companies is that their customers get the lists, ... Hah! --expletives deleted-- My personal experience with AMD in the last 18 months has been that if I find 1 bug and my AMD FAE and I are persistent about it, then AMD will eventually deign to confirm the problem exists and to reward me with one or two more bugs in an old bug list. For one 29K characteristic (it won't be changed so it is not a bug), it took enormous effort for months from a lot of people to get AMD to admit that concern was warrented and to get the easy work-around. I have had similar recent and ancient experiences with INTEL. I don't recall any difference between the two companies in this regard. I think the problem is not a matter corporate nastiness, but of the familiar human reluctance to admit errors. People who find problems with my code might say nasty things about my enthusiasm for agreeing with them. Vernon Schryver, vjs@sgi.com
kls30@duts.ccc.amdahl.com (Kent L Shephard) (11/02/90)
In article <35420@cup.portal.com> brad@cup.portal.com (Paul B Anders) writes: >Brian McMinn of AMD writes : > >>Intel's position is different (and somewhat understandable, even if it >>is deplorable :-) in light of the fact that their chips are second >>sourced. If Intel made their bug list public, then AMD would have >>free access to it. One of the not-so-obvious advantages that Intel >>gains by not making their bug list public is that they can implement >>fixes to the undisclosed bugs and then reveal both the bug list and >>the "new and improved" chip at the same time. This prevents AMD from >>beating them to the draw with a fix. >> >>Again, these are my opinions. > >Perhaps if AMD would develop some original products of its own that could >generate the revenue that the "second-sourced" and cloned Intel parts do, >then poor AMD wouldn't have to worry about the "deplorable" actions of >Intel. > >These are my opinions, not Intel's. > >Brad Anders > >brad@cup.portal.com >anders@gemini.intel.com I don't work for either company but, I think that what Intel did sucks big time!!!!! If someone signed an agreement with me and then when stuff got real profitable they said "I'm keeping everything; and for you tough shit." I would be pissed as hell and rightly so!!! Amd does develop profitable products on their own. If Intel signed an then they should stick by it. When Intel needed AMD everything was fine but when Intel started getting more profits and the majority of computers were using Intel products, they decided "We got em' locked in now forget second sourcing." When AMD started making faster 286's from masks they developed themselves, because Intel wouldn't give them functional stuff, Intel started taking notice. AMD are you listening?????? Can we say cheap 387 like the 287, or can we say package 287 for 387dx/sx????? Hurray for AMD and the 386 cpu clone!!!!!!!!!!! Kent. -- /* -The opinions expressed are my own, not my employers. */ /* For I can only express my own opinions. */ /* */ /* Kent L. Shephard : email - kls30@DUTS.ccc.amdahl.com */
esmith@goofy.apple.com (Eric Smith) (11/03/90)
In article <35420@cup.portal.com> brad@cup.portal.com (Paul B Anders) writes:
Perhaps if AMD would develop some original products of its own that could
generate the revenue that the "second-sourced" and cloned Intel parts do,
then poor AMD wouldn't have to worry about the "deplorable" actions of
Intel.
Perhaps if Intel didn't violate second-source agreements it signed with
AMD, AMD wouldn't complain about the deplorable actions of Intel.
--
Eric L. Smith Opinions expressed herein do not necessarily reflect those
esmith@apple.com of my employer, friends, family, computer, or even me! :-)scott@electron.amd.com (Scott McMahon) (11/05/90)
In article <35420@cup.portal.com> brad@cup.portal.com (Paul B Anders) writes: | Brian McMinn of AMD writes : | > [Brian points out a side benefit of Intel not releasing any bug | > lists: it helps defer the competition from updating] Brad Anders of Intel replies: | Perhaps if AMD would develop some original products of its own that could | generate the revenue that the "second-sourced" and cloned Intel parts do, | then poor AMD wouldn't have to worry about the "deplorable" actions of | Intel. | | Brad Anders | | brad@cup.portal.com | anders@gemini.intel.com Rather interesting reply.. Brian was/is involved with an AMD original product.. the Am29000 and Am29050. Granted, they don't pull in the revenues that the i386 does, but they are giving Intel headaches in the embedded arena. I guess your reply wouldn't have been so amusing had it been someone else other than Brian. :-) To address the issue that you raise.. you might want to ask yourself the question of how valuable the 80286 and later generations would be had AMD not second sourced them at their earlier stages? Would they be as widely accepted as they are today? -Scott ---- Scott McMahon - 29k Advanced Processor Development - Advanced Micro Devices scott@amd.com (800) 531-5202 x54985
phil@brahms.amd.com (Phil Ngai) (11/06/90)
In article <380S02pf039A01@JUTS.ccc.amdahl.com> kls30@DUTS.ccc.amdahl.com (PUT YOUR NAME HERE) writes: |>Perhaps if AMD would develop some original products of its own that could |>generate the revenue that the "second-sourced" and cloned Intel parts do, |>then poor AMD wouldn't have to worry about the "deplorable" actions of |>Intel. |> |>These are my opinions, not Intel's. |> |>Brad Anders | |I don't work for either company but, I think that what Intel did sucks big |time!!!!! If someone signed an agreement with me and then when stuff |got real profitable they said "I'm keeping everything; and for you tough |shit." I would be pissed as hell and rightly so!!! I have the entire text of the arbitrator's decision and it's pretty clear he feels the same way. That's probably why Intel went to court to try to get him removed after they saw what he wrote. |When Intel needed AMD everything was fine but when Intel started getting |more profits and the majority of computers were using Intel products, they |decided "We got em' locked in now forget second sourcing." According to the arbitrator, Intel actually decided a long time ago to deny new designs to AMD but to keep holding out the promise of continued second sourcing so that AMD would not do chips for other processors like the 68K family. You could say they wanted to have their cake and eat it too. (I speak for no one but myself.) -- I voted. Did you?
david@neutron.amd.com (David Witt) (11/06/90)
In article <73898@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >Hah! --expletives deleted-- > >My personal experience with AMD in the last 18 months has been that if I >find 1 bug and my AMD FAE and I are persistent about it, then AMD will >eventually deign to confirm the problem exists and to reward me with one or >two more bugs in an old bug list. For one 29K characteristic (it won't be >changed so it is not a bug), it took enormous effort for months from a lot >of people to get AMD to admit that concern was warrented and to get the >easy work-around. I have had similar recent and ancient experiences with >INTEL. I don't recall any difference between the two companies in this >regard. Whatever it is worth, I was involved in this particular episode referred to by the gentleman at SGI, so for all you microprocessor users out there here is another perspective. The 29K characteristic I believe he was referring to was a non-deterministic failure, ie on large programs a board that SGI was buying by a 3rd party was crashing their system during a particular communication protocol. When I got involved in it, (which is typically when everyone else has looked at it and given up), we eventually ran this down to the 3rd party was reading a byte control field from an FDDI note controller into the 29K, and floating the rest of that data bus, ie a word transfer with only 8 bits defined. This was having some downstream nasty effects when the undriven values on the data bus would decay and be read an manipulated inside the 29K, resulting in non-deterministic failures. When the outside source was told to execute a byte load instead of a word load, the problem was eliminated, although as you can imagine this took a fairly long time to isolate. The final result back to the end customer apparently was that AMD was slow in identifying this errata, and that it was not a problem in the chip (ie reading unstable data on word transfers), ie that we were trying to pass the problem off on someone else. Often problems are quite difficult to isolate such as this, and also quite often the problem turns out to be the customers use of the chip, which takes just as long to isolate as all the real errata that must be documented, work around identified, and fixed in the next revision. Just a little sympathy sometimes guys, we all are in this together. > >I think the problem is not a matter corporate nastiness, but of the >familiar human reluctance to admit errors. People who find problems with >my code might say nasty things about my enthusiasm for agreeing with them. > > >Vernon Schryver, vjs@sgi.com David Witt 1-(512)-462-5846 Advanced Processor Development Advanced Micro Devices domainLand: david@neutron.AMD.COM Austin, Texas
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (11/06/90)
In <35431@cup.portal.com> mslater@cup.portal.com (Michael Z Slater) writes: >My offer to any chip companies: send me your bug lists, and I'll put you on >our official "good guys" list (and publish a summary of your bug list). While this would be better than nothing, it would be worse than many other things. At $295 a year for Microprocessor Report (or whatever the subscription is currently) the bug list still wouldn't be easily enough available to the small developer. -- Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi A pointer is not an address. It is a way of finding an address. -- me
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (11/08/90)
In article <1990Nov5.172110.15994@mozart.amd.com>, david@neutron.amd.com (David Witt) writes: > ...[an account of a problem]... I don't want to get into a flame war about this, but this is what I remember of the events described: -being a software hack but having heard the evils of undriven/unclocked inputs to 29Ks and having heard if not understood the "MetaStable" incancation, I asked the board vendor and AMD if there might be a problem if status values presented as memory values (ie. "memory mapped") did not fill an entire word. That is, I asked if there might be a problem if parts of a "status word" were undriven. -I convinced the board vendor to be concerned, so we each asked via our separate channels. -both the board vendor and I were told "no problem" by AMD. -this was not consistent with the 29K manual, so the board vendor asked again, more forcefully. -someone (not AMD or the board vendor) suggested reading a know location to "pre-charge the bus" to a known state. -AMD told the board vendor again "no problem" -I continued to hear via various sources that indeterminate inputs to the 29K data bus are a problem, so I adopted "pre-charging the bus" as a preventive in my 29K code. (Hey--I'm only a software jock) -the silliness of this precharing so enraged the board vendor, that they finally got thru to David Witt. He gave the assurance that all that was needed was masking off the bogus bits. Hearing "there can be a problem" after months of "no problem" was not popular. All of this took many weeks, and almost none of the delay was the fault of the board vendor. The reason the initial "no problem" from AMD did not quiet me was that it was too simple to be consistent with my naive (mis)understands and the book. At no time was any observed failure attributed to the problem. It was always in the realm of "gee, indeterminates in --- can cause --- or at best generate indeterminate results." (sorry for my bad translation from the original hardware-ese.) If AMD had initially said the two things they said at the end, "all modern chips have this issue" and "simply mask the bogus bits with AND or use DW=1 and byte loads," everyone on this side of the fence would have said "Wow!, those great AMD guys are not like the rest of the chip pushers." Instead I heard unprintable words concerning the likelihood of the board vendor's future use of AMD parts. Those words were surely overstatements, but they reflected real and justifiable irritation at an initial refusual to acknowledge a known concern. AMD is no worse than the rest of them, or us. As I said last time: > >I think the problem is not a matter corporate nastiness, but of the > >familiar human reluctance to admit errors. Vernon Schryver, vjs@sgi.com