Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/13/84; site intelca.UUCP Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!sun!idi!intelca!kds From: kds@intelca.UUCP (Ken Shoemaker) Newsgroups: net.arch Subject: Re: Re: Re: Bad devices (timing loops) Message-ID: <232@intelca.UUCP> Date: Mon, 10-Mar-86 16:51:05 EST Article-I.D.: intelca.232 Posted: Mon Mar 10 16:51:05 1986 Date-Received: Wed, 12-Mar-86 22:43:22 EST References: <374@mips.UUCP> <38@gilbbs.UUCP> Distribution: net Organization: Intel, Santa Clara, Ca. Lines: 91 > I do feel, however, that my comments were cogent. Mr. Shoemaker was, in > essence, using his position as a microprocessor designer at INTEL as a point > of authority to support his thesis. While I'll grant that it is certainly a > matter of opinion, it is my opinion that working for Intel doesn't qualify > anyone as an authority on anything (judgement based on shipped products and > ethical standards in advertising and specification listings(or lack thereof). > Therefore, it was cogent to point out that his position of authority was > questionable. > > I also suggested that perhaps Mr. Shoemaker's concepts of engineering and > quality were warped. This suggestion *WAS* preceded by a conditional, > which I still adhere to: "*IF* hardware designers are suggesting that system > designers should accept badly designed chips *SIMPLY* because it is possible > to work around the flaws in software, *THEN* I would suggest that their concepts > of engineering and quality are warped.". Mr. Shoemaker (and several others) > chose to take this as a personal affront. Perhaps due to the manner in which > I expressed myself. I therefore also apologize for any personal distress my > ineptitude caused. I stand by the essence of my statements, however. > > I do not believe that it is always possible to discuss even technical > issues without occasionally making personal observations and/or comments. If, > however, it is clearly the wish of the majority of readers of net.arch that > this be the rule, I will abide by it. > > Thank you. By saying that I am a microprocessor designer at Intel in the tail of my articles, I am by no means attempting to give greater weight to the statements that I put in those articles. In fact, I specifically say that the article contains *my own opinions* and should not be taken to be those of Intel, or any other of its employees. It seems that, at least for many people on the net, merely admitting that I work for Intel is all I need do to have my opinions denegrated! By stating that I work for Intel, I am merely giving people a base from which to interpret my opinions. If I happen to be overly familiar with Intel products, and not quite so with other manufacturers' products, well, it just goes with the territory. Also, they pay the bills for this machine. I would think that trying to hide or misrepresent that I work for Intel would not be such a good idea, since if this were generally applied, it could undermine the validity of many discussions on the net. By my line of work, one could assume that I have spent a bit of time working on microprocessors and microprocessor based products and am therefore familiar with the tradeoffs that go into not only microprocessor based systems, but into microprocessors themselves. I do not, by any strech of the imagination, claim to have a monopoly on these tradeoffs or skills. As for the SCC, I happen to like the device a lot. I have used it in systems and have no problem with it. If it needs a bit of a recovery time, well, it isn't the first peripheral chip that I have worked with that has required the same kind of thing. I like the fact that it integrates 2 synchronous/ asynchronous channels into a 40-pin DIP, with their own baud rate generators. I like that it has a 4-byte receive character FIFO. Etc. I personally would rather have a second serial channel than to have 0ns command recovery time. Or than having a ready output pin. I don't even mind its having a data bus float time longer than most any microprocessor in the world can tolerate. These are things I can take care of outside the chip. I am very suprised that Mr. Keller seems so adamantly opposed to external logic, and yet is still a big 68020 fan. At least with the 386, you get the MMU and page support hardware on the same chip as the CPU! Just think how many devices you save there! The interface parameters of a chip are well documented. If you have a problem with them, you don't have to use the chip. It sounds almost as if Mr. Keller has overlooked this parameter in his own code, and is looking for someone else to blame for his shortcoming. People should also be aware that semiconductor companies don't exist in a vacuum. They are always looking for people and organizations that are working with their devices to suggest improvements. But they can't do miracles, and they can't be everything to everyone. You should realize that the decisions on what to do in a chip usually aren't made arbitrarily, or, at least, that is my opinion from having watched the process. As one of the radio newsmen in the Bay Area is fond of saying, "if you don't like the news, go out and make some of your own." You can also change an organization from within. I mean, with the bozos that we must routinely hire, anyone could get a job with Intel, right, Mr. Keller? Or start your own company. If you are so full of good ideas, then bring one of them to fruition, sell them, and become the greatest commercial success since time immemorial. Oh well, I think I've said enough for now. Perhaps we should get on with what I would think would be more appropriate discussions on net.arch. I won't suggest that people mail me flames, because everyone has to get their last words in. -- If you don't like the answer, then ask another question! Everything is the answer to something... Ken Shoemaker, Microprocessor Design, Intel Corp., Santa Clara, Ca. {pur-ee,hplabs,amdcad,scgvaxd,oliveb,qantel}!intelca!kds ---the above views are personal.