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
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
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
R_Tim_Coslet@cup.portal.com (10/28/90)
In article: <15632@netcom.UUCP> feustel@netcom.UUCP (David Feustel) writes... >Let's start a 386/486 bugs newsgroup. >-- >David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631 Why limit it to x86 chips... the group should cover any processor that people have RELIABLE bug info on. R. Tim Coslet Usenet: R_Tim_Coslet@cup.portal.com BIX: r.tim_coslet
gillies@m.cs.uiuc.edu (10/28/90)
> 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. What we need is a Ralph Nader or Mike Wallace/60 Minutes Team to STOP THIS PRACTICE. It is downright stupid. Today more than ever people are working on languages that depend on dynamic code generation for speed and correctness. Without a list of these instruction sequence bugs, these language implementations are in great peril. Don W. Gillies, Dept. of Computer Science, University of Illinois 1304 W. Springfield, Urbana, Ill 61801 ARPA: gillies@cs.uiuc.edu UUCP: {uunet,harvard}!uiucdcs!gillies
feustel@netcom.UUCP (David Feustel) (10/30/90)
Seconded.
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/30/90)
Information on Intel bugs is posted from time to time in the 386users
mailing list. If I got a buglist from a reliable source I would post it.
--
bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
VMS is a text-only adventure game. If you win you can use unix.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."
brian@positron.amd.com (Brian McMinn) (10/31/90)
(David Feustel) writes... | Let's start a 386/486 bugs newsgroup. R_Tim_Coslet@cup.portal.com writes: | the group should cover any processor that | people have RELIABLE bug info on. The catch word here is RELIABLE. An unmoderated newsgroup would lead to mass rantings and ravings about >suspected< bugs, but very little useful information about real bugs. If the newsgroup was moderated to eliminate this, then (by the very logic under which the group was proposed) the most qualified potential moderators could not be trusted! 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
seanf@sco.COM (Sean Fagan) (11/01/90)
In article <1990Oct30.210852.15087@mozart.amd.com> brian@positron.AMD.COM (Brian McMinn) writes: >If the newsgroup was moderated to >eliminate this, then (by the very logic under which the group was >proposed) the most qualified potential moderators could not be >trusted! I don't know about that. A "qualified potential moderator" would be someone who had access to a '386 machine to test on, best would be someone who had access to many '386 machines. Just by being the moderator, I suspect intel would like to be on friendly terms with said person, so that would help. So... who has lots of '386 and '486 machines they can use for testing, and isn't affiliated with Intel? 8-) -- -----------------+ Sean Eric Fagan | "Quoth the raven," seanf@sco.COM | "Eat my shorts!" uunet!sco!seanf | -- Lisa and Bart Simpson (408) 458-1422 | Any opinions expressed are my own, not my employers'.
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
mpd@anomaly.sbs.com (Michael P. Deignan) (11/07/90)
seanf@sco.COM (Sean Fagan) writes: >I don't know about that. A "qualified potential moderator" would be someone >who had access to a '386 machine to test on, best would be someone who had >access to many '386 machines. Just by being the moderator, I suspect intel >would like to be on friendly terms with said person, so that would help. I would like to see this group a "mailing list", not a "newsgroup". I don't think a newsgroup could generate sufficient volume. Even if you expand it to include all processor types.... In which case you'd need someone with ALOT of CPU's laying around. >So... who has lots of '386 and '486 machines they can use for testing, and >isn't affiliated with Intel? 8-) We've got 16/20mhz SX's, 20/25/33mhz 386 DX's, and a 25mhz 486. And, a 4381 System 370 machine too. But, no 68xxx or other RISC types. <Sigh> I'd be happy to provide anyone with confirmed results on these machines. MD -- -- Michael P. Deignan, President -- Small Business Systems, Inc. -- -- Domain: mpd@anomaly.sbs.com -- Box 17220, Esmond, RI 02917 -- -- UUCP: ...uunet!rayssd!anomaly!mpd -- Telebit: +1 401 455 0347 -- -- XENIX Archives: login: xxcp, password: xenix Index: ~/SOFTLIST --
brett@cayman.amd.com (Brett Stewart) (11/08/90)
After listening to the last little bit of this news thread, about
the relationship between Intel and AMD, and who did what to whom, and
so on, I am prompted to point out a fact. Intel DOES derive monopoly
pricing from the 386. They sell it at many many many times the cost
to make it. An independent judge says that they contrived to do so
in an unscrupulous fashion. And AMD was damaged. However, AMD was
damaged by being denied the right to sell competitively a chip it
had expected to get under its agreement. If it had got it, as the
agreement would have allowed if not thwarted, AMD would NOT have
made a *monopoly* profit, it would have made a *normal* profit.
AMD's presence in the market would have caused 386 pricing to fall
to normal profit levels, not the ridculous levels permitted by
Intel's position as a monopoly supplier.
Not only was AMD damaged by Intel's thwarting of the agreement, but
each and every purchaser of something with a 386 inside was damaged.
AMD can be angry, because Intel cheated on a deal. But YOU can be
angry, because they did so to exploit YOU. Some commentary here suggests
that its authors LIKE being exploited. I dont. And, I own and use
PC's. Probably, many of you on the net paid about $800 more for your
386-unix PC than you would have if Intel had honored its deal.
Again, these are my own opinions, based on my reading of the judge's
entire decision and my education in economics. I am prepared to
change them if anyone can demonstrate:
1.) The judge did not find Intel liable for breach of its
agreement with AMD (impossible, because he did find them liable)
2.) Someone can argue that 386 pricing is near the level where
it would be had not Intel breached, per 1. above. I think
this will be tough. The 386 is about 70K square mils. The
29000 is about 175K square mils. Silicon, folks, is
silicon, and the 29000 perversely costs a lot less than a
386. The costs to make them go as die size, and that's just
how it is.
3.) (A tough one) Someone can argue that they are somehow
better off for having hundreds of dollars less than they
would have, or if someone can argue that it is better that
Intel and AMD between them did not make more 386's at a
lower price. Basically, this is what an economist might call
'consumer surplus,' the value everyone gets when prices get
pushed down to sustain a 'normal' profit rather than a
'monopoly' profit; it is the very same consumer surplus
that gets eliminated by taxation that effectively raises a
price to a level above the pure competion point where
marginal revenue = marginal cost. Intel caused there to be
fewer 386's out there (at a higher and more profitable price)
so they eliminated value to consumers both by exploitively
high pricing and by denying the market the benefit of
greater volume. A monopolist cannot charge any price;
eventually some consumers balk. What a monopolist does is
pick the price point it wants and then sell what it can at
that price.
I do not work in the part of AMD that has something to do with iAPX
architectures.
Best Regards; Brett Stewart
Advanced Micro Devices, Inc. 1-512-462-5321 FAX
5900 E. Ben White Blvd MS561 1-512-462-4336 Telephone
Austin, Texas 78741 USA brett@cayman.amd.comts@cup.portal.com (Tim W Smith) (11/08/90)
I wonder if reluctance to reveal bug lists is partly to encourage bug reports? I used to work for a company that sold a Unix machine. We bought our Unix port from a company that specialized in porting Unix for people. Their policy on bugs was that if you reported it, they would confirm it and fix it in the next release (~6 months). They would not tell other companies about the bug unless those companies found it themselves. For a company that had no in-house Unix experise, this sucked. However, for a company like ours, which had a lot of such experise, it wasn't that bad. We would find a lot of bugs and fix them ourselves. The result was that our release would work better than many of our competitors release, because we had fixed these bugs. The competitors would not get these fixes until the next release from the port vendor, so we had a better Unix release. If the port vendor had been free with the bug list, there would have been a definite temptation on our part to *NOT* report bugs, but to simply fix them ourselves. It would have been a hassle to keep integrating our fixes into each new release until the port vendor found and fixed the bugs, but it might have been worth the hassle to keep our kernel better than our competitors. On the other hand, such a policy encouraged in-house Unix expertise from the clients of this port vendor. When it became time to move to a demand paged VM form of System V (this was a long time ago), we did it ourselves rather than wait for the port vendor. This was probably not something that pleased them! This is not meant as a defense of secret bug lists. It is just meant as an example of where such secrecy might have a semi-rational basis. It probably does not apply to hardware, since once you build something with a chip, you usually don't update it, unlike software. Tim Smith
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
lindsay@gandalf.cs.cmu.edu (Donald Lindsay) (11/08/90)
In article <1990Nov7.184237.22840@mozart.amd.com> brett@cayman.amd.com (Brett Stewart) writes: <discussion of monopoly elided> > Intel caused there to be > fewer 386's out there I can practically hear Henry Spencer cheering. What would the business look like today if we'd shot Gene Amdahl in 1971? Multics and TOPS-10 would have looked better against much more expensive 370's. Nightmare for the day: in 2001, there will be a gallium arsenide chip with an 8086 mode. -- Don D.C.Lindsay
chedley@eecs.cs.pdx.edu (Chedley A. Aouriri) (11/08/90)
In article <1990Nov7.184237.22840@mozart.amd.com> brett@cayman.amd.com (Brett Stewart) writes: ... > 2.) Someone can argue that 386 pricing is near the level where > it would be had not Intel breached, per 1. above. I think > this will be tough. The 386 is about 70K square mils. The > 29000 is about 175K square mils. Silicon, folks, is > silicon, and the 29000 perversely costs a lot less than a > 386. The costs to make them go as die size, and that's just > how it is. However, you are NOT including the R&D costs incured by INTEL for the 386. While it is true that silicon is silicon, the logic/microcode which goes into that silicon is an essential added value. And the cost to develop that logic is by no means nil!!! So, regardless of the contractual legalities, INTEL does have a point in refusing to share the spoils of its R&D outlays and risks with another company who did not contribute a dime to the R&D costs of the 386. Following your logic, a Boeing-747 should cost only a few thousands dollars. Metal is metal, is n't it!!!??? Or are you advocating that Boeing should give free licence to any manufacturer who wants to build the 747, even if it did not contribute to the R&D cost of the airplane ??? >.... > greater volume. A monopolist cannot charge any price; > eventually some consumers balk. What a monopolist does is > pick the price point it wants and then sell what it can at > that price. No! a monopolist tries to maximize its profit or revenue, regardless of the price or the demand for its product. A monopolist is NOT a price taker or a price picker. It sells at any price and any quantities which maximize its profit. So, the monopolist sells quatitities at the price solution to the equation: marginal revenue = marginal cost. And that's exactly what INTEL is doing. It is maximizing its profit and return on investment in the 386, by selling as many 386's as it can manufacture, at the highest price it can get. ..CHEDLEY..
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (11/09/90)
In article <1990Nov7.184237.22840@mozart.amd.com> brett@cayman.amd.com (Brett Stewart) writes: | Intel DOES derive monopoly | pricing from the 386. They sell it at many many many times the cost | to make it. Motorola has a monopoly on the 68000. What's your point? If the 386 costs too much the DOS people go 286, the workstation people go RISC. Therefore the price stays down. I don't see all the sources for SPARC making them so cheap people use them in bunches. | I dont. And, I own and use | PC's. Probably, many of you on the net paid about $800 more for your | 386-unix PC than you would have if Intel had honored its deal. Since the retail cost of the CPU is less than $800 I would really like to know how you come up with that number. Partucularly since *my* cost is < $800, and no matter what Intel charges the distributor and retail vendor would still mark it up, as a chip or in a system. | 2.) Someone can argue that 386 pricing is near the level where | it would be had not Intel breached, per 1. above. I think | this will be tough. The 386 is about 70K square mils. The | 29000 is about 175K square mils. Silicon, folks, is | silicon, and the 29000 perversely costs a lot less than a | 386. The costs to make them go as die size, and that's just | how it is. That's just not true. The cost is a factor of die size and process. The cost of the same area in 2.5 micron CMOS (static memory) is a lot less than the same area filled with 0.8 micron CMOS (a CPU). If it was really cheaper to use less area everyone would use 6000 angstrom design rules for everything, right? Since it seems AMD didn't deliver their part of the technology swap (this part didn't make as many headlines), AMD can't claim to be without fault in this case. Therefore why don't the people who are complaining about this, most of whom seem to be from AMD, take this to alt flame. It's not a proper issue for this group, if it ever was. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) The Twin Peaks Halloween costume: stark naked in a body bag
croft@csusac.csus.edu (Steve Croft) (11/09/90)
Despite what was previously posted, Motorola does not have a monopoly on the 68000... they are second-sourced by Signetics and maybe others... Steve
sysmgr@KING.ENG.UMD.EDU (Doug Mohney) (11/09/90)
In article <11019@pt.cs.cmu.edu>, lindsay@gandalf.cs.cmu.edu (Donald Lindsay) writes: >Nightmare for the day: in 2001, there will be a gallium arsenide chip >with an 8086 mode. Nightmare hell, sounds like an interesting idea. Maybe Intel will take the '586 or whatever they have at that time and move it to GA.
peter@ficc.ferranti.com (Peter da Silva) (11/09/90)
In article <595@pdxgate.UUCP> chedley@eecs.UUCP (Chedley A. Aouriri) writes: > Or are you advocating that Boeing should give free licence to any manufacturer > who wants to build the 747, even if it did not contribute to the R&D cost of > the airplane ??? If they had an agreement ahead of time with that manufacturer to do so, certainly they should. -- Peter da Silva. `-_-' Professional computer nerd, second class. +1 713 274 5180. 'U` Gallery Furniture really will SAVE YOU MONEY! peter@ferranti.com (Have you hugged your wolf today?)
casey@gauss.llnl.gov (Casey Leedom) (11/09/90)
| From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) | | | I don't. And, I own and use PC's. Probably, many of you on the net paid | | about $800 more for your 386-unix PC than you would have if Intel had | | honored its deal. | | Since the retail cost of the CPU is less than $800 I would really like | to know how you come up with that number. Particularly since *my* cost is | < $800, and no matter what Intel charges the distributor and retail | vendor would still mark it up, as a chip or in a system. It's common to see manufacturing cost increases scale by three to six into retail price increase. Thus if something costs a manufacturer $100 they might pass that on in the retail price as $300 to $600. | Since it seems AMD didn't deliver their part of the technology swap (this | part didn't make as many headlines), AMD can't claim to be without fault | in this case. What part was that? (Sincere curiousity. I'm just watching.) Casey
winkler@cunixf.cc.columbia.edu (Andrew Winkler) (11/10/90)
Are you suggesting that Intel didn't understand the significance of R&D costs when it made the agreement? Poor Intel had to agree to give up its technology without being recompensed, and all it got in return was the IBM account.
brett@cayman.amd.com (Brett Stewart) (11/13/90)
In article <595@pdxgate.UUCP> chedley@eecs.UUCP (Chedley A. Aouriri) writes: >So, regardless of the contractual legalities, INTEL does have a point in ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >refusing to share the spoils of its R&D outlays and risks with another >company who did not contribute a dime to the R&D costs of the 386. Are you saying they didnt make an agreement with AMD? Or that they didnt break it? Neither position is an informed one. Interesting point. I have always thought that rule of law and sanctity of contracts were foundations of our society. I think you might have misunderstood me; I think it is deplorable that they made an agreement then broke it to exploit others. I do not think it is deplorable that they are trying to be monopolists, since every company that sells a differentiated product is trying to do that. Best Regards; Brett Stewart Advanced Micro Devices, Inc. 1-512-462-5321 FAX 5900 E. Ben White Blvd MS561 1-512-462-4336 Telephone Austin, Texas 78741 USA brett@cayman.amd.com
berg@cip-s04.informatik.rwth-aachen.de (AKA Solitair) (11/16/90)
Steve Croft writes: >Despite what was previously posted, Motorola does not have a monopoly on >the 68000... they are second-sourced by Signetics and maybe others... Yes, notably Philips. (Just my $0.02 worth) -- Sincerely, berg%cip-s01.informatik.rwth-aachen.de@unido.bitnet Stephen R. van den Berg. "I code it in 5 min, optimize it in 90 min, because it's so well optimized: it runs in only 5 min. Actually, most of the time I optimize programs."
Bruce.Hoult@actrix.co.nz (Bruce Hoult) (11/19/90)
In article <3699@rwthinf.UUCP> berg%cip-s01.informatik.rwth-aachen.de@unido.bitnet writes: > Steve Croft writes: > >Despite what was previously posted, Motorola does not have a monopoly on > >the 68000... they are second-sourced by Signetics and maybe others... > > Yes, notably Philips. (Just my $0.02 worth) Er, Signetics is part of Philips...