a218@mindlink.UUCP (Charlie Gibbs) (12/18/89)
In article <14102@grebyn.com> ckp@grebyn.com (Checkpoint Technologies) writes: >In article <6037@sun.acs.udel.edu> barry@sun.acs.udel.edu (Barry Fausnaugh) >writes: > >>Not only that, but haven't a number of the 486 chips been recalled due to a >>serious bug in the architecture or something like that. I vaguely remember >>reading that somewhere...have to see if I can drudge up the article. > > Don't be too hasty; Motorola hasn't released the 68040 yet. They >may accomplish the same thing Intel did, release a chip with a bug or >two. I seem to recall that the 386 was released with bugs too. As for the 286, I hear that IBM went so far as to hardwire fixes that depended on the bug being there, and Intel *couldn't* fix it later. I haven't heard similar stories about the 680x0 line, but of course that doesn't mean that there have been no problems. On the other hand, maybe Motorola takes longer to get a chip out the door because they work harder at getting the bugs out first. Intel seems to subscribe to the policy that it's better to be first than to be best. It doesn't seem to have hurt them much. :-/ Charlie_Gibbs@mindlink.UUCP For every vision there is an equal and opposite revision.
meuchen@grad2.cis.upenn.edu (Paul Eric Menchen) (12/18/89)
In article <14960@boulder.Colorado.EDU> kuo@boulder.Colorado.EDU (KUO ANDY Y) writes: lots of stuff deleted > > It is a fact that NuBus, SCSI, AppleTalk, 68xxx chip is superior than >EISA/MCA, ESDI, nothing standard or build in, 80xxx(not include 80486). > Why not include the 80486. From what I here, the 68040 is plenty faster. I don't remember the specifics - as a matter of fact I don't think the specs are out but word is it's faster. Paul Eric Menchen meuchen@grad1.cis.upenn.edu
barry@sun.acs.udel.edu (Barry Fausnaugh) (12/18/89)
In article <18213@netnews.upenn.edu> meuchen@grad2.cis.upenn.edu (Paul Eric Menchen) writes: > >lots of stuff deleted >> >Why not include the 80486. From what I here, the 68040 is plenty >faster. I don't remember the specifics - as a matter of fact I don't >think the specs are out but word is it's faster. Not only that, but haven't a number of the 486 chips been recalled due to a serious bug in the architecture or something like that. I vaguely remember reading that somewhere...have to see if I can drudge up the article. -- Arpa: barry@vax1.acs.udel.edu Uucp: ...{ihnp4,unidot,uunet}!cfg!udel!udccvax1!barry
brandonl@amadeus.WR.TEK.COM (Brandon G. Lovested) (12/18/89)
The 80486 bug, which a friend of mine at Compaq helped to find, had something to do with multiplication, I believe. The article was in EE Times, about a month to six weeks ago. ================================================================================ | Brandon G. Lovested | "I will not be pushed, filed, stamped, | indexed, briefed, debriefed, or numbered! brandonl@amadeus.WR.TEK.COM | My life is my own." | ================================================================================
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (12/18/89)
In article <18213@netnews.upenn.edu> meuchen@grad2.cis.upenn.edu (Paul Eric Menchen) writes: | Why not include the 80486. From what I here, the 68040 is plenty | faster. I don't remember the specifics - as a matter of fact I don't | think the specs are out but word is it's faster. I think it's early to say what the performance, cost, or reliability of the 040 are. For that matter I don't think we really know what the 486 will be, other than a lot faster next year (supposedly the 50MHz version will ship in 1990). Certainly the 486 seems a lot more developed in terms of available machines which use it. Does the 040 have the FPU built in? I'm told the memory manager is there, but I have heard nothing reliable on the 040. And the leaked performance figures have all been at 33 or 40MHz, so they are not only possibly inaccurate, but need to be scaled somehow, too. I doubt that either chip will push the other off the market, and I would bet that the 486 will sell a lot more units because of the demand for fast DOS machines. This will bring down the cost of manufacture, although I wouldn't bet on either Intel or Motorola dropping prices a lot. Note I haven't said one was better than the other... -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
ckp@grebyn.com (Checkpoint Technologies) (12/19/89)
In article <6037@sun.acs.udel.edu> barry@sun.acs.udel.edu (Barry Fausnaugh) writes: > >Not only that, but haven't a number of the 486 chips been recalled due to a >serious bug in the architecture or something like that. I vaguely remember >reading that somewhere...have to see if I can drudge up the article. Don't be too hasty; Motorola hasn't released the 68040 yet. They may accomplish the same thing Intel did, release a chip with a bug or two.
a218@mindlink.UUCP (Charlie Gibbs) (12/19/89)
In article <49900@bbn.COM> denbeste@bbn.com (Steven Den Beste) writes: >The original release of the 68000 had a bug in the "page fault" interrupt, >so that it pushed the STACK POINTER onto the stack frame instead of the RETURN >ADDRESS. Needless to say, this made it pretty hard to use an MMU with a 68000. Ouch. I hadn't heard that one. Thanks for the historical note. The score now stands at: 680x0: 1 wart 80x86: 3 warts Does anyone have any more horror stories? Charlie_Gibbs@mindlink.UUCP "I'm cursed with hair from HELL!" -- Night Court
chari@nueces.cactus.org (Chris Whatley) (12/19/89)
ckp@grebyn.com (Checkpoint Technologies) writes: >In article <6037@sun.acs.udel.edu> barry@sun.acs.udel.edu (Barry Fausnaugh) writes: >> >>Not only that, but haven't a number of the 486 chips been recalled due to a >>serious bug in the architecture or something like that. I vaguely remember >>reading that somewhere...have to see if I can drudge up the article. > Don't be too hasty; Motorola hasn't released the 68040 yet. They >may accomplish the same thing Intel did, release a chip with a bug or >two. It is my impression that he '040 is finished and is being held up by legal issues with Toshiba dataing to their co-development on the '030. I hope that this means that we will see a legally delayed, fully debugged chip when it comes to market. Chris -- Chris Whatley Work: chari@pelican.ma.utexas.edu (NeXT Mail) (512/471-7711 ext 123) Play: chari@nueces.cactus.org (NeXT Mail) (512/499-0475) Also: chari@emx.utexas.edu
denbeste@bbn.com (Steven Den Beste) (12/19/89)
In article <819@mindlink.UUCP> a218@mindlink.UUCP (Charlie Gibbs) writes: > > I seem to recall that the 386 was released with bugs too. As >for the 286, I hear that IBM went so far as to hardwire fixes that >depended on the bug being there, and Intel *couldn't* fix it later. > > I haven't heard similar stories about the 680x0 line, but of >course that doesn't mean that there have been no problems. On the >other hand, maybe Motorola takes longer to get a chip out the door >because they work harder at getting the bugs out first. The original release of the 68000 had a bug in the "page fault" interrupt, so that it pushed the STACK POINTER onto the stack frame instead of the RETURN ADDRESS. Needless to say, this made it pretty hard to use an MMU with a 68000. One of the very first machines with a 68000 and MMU (it may have been from Apollo, my memory is hazy) actually had TWO 68000's, with one runnine one instruction ahead of the other. When the leading 68000 got a page-fault, the trailing one got a different, correctly working interrupt. It would then fix up the stack frame for the leading 68000 and massage the MMU. Is that ugly enough for you? (I might mention that in the Intel vs. Motorola fight, I'm a firm Motorola fan. But let's keep things in perspective here, OK?) Steven C. Den Beste || denbeste@bbn.com (ARPA/CSNET) BBN Communications Corp. || {apple, usc, husc6, csd4.milw.wisc.edu, 150 Cambridge Park Dr. || gatech, oliveb, mit-eddie, Cambridge, MA 02140 || ulowell}!bbn.com!denbeste (USENET)
brandonl@amadeus.WR.TEK.COM (Brandon G. Lovested) (12/20/89)
One of the overriding concerns of the 386 was to bring out a chip that
would correct some major flaws in the 286 - ASAP.
But, in general, every engineer that has to work with Intel 80xxx
knows that they are "bug for bug compatible with previous chips."
This was the decision made by Intel - to incorporate previous bugs
into new chips based upon the same architecture so that all those
fixes for the original bugs would still operate with the new chips.
That isn't a ridiculous decision. The main complaint of Intel
chips is their lack of orthogonality, as compared to Motorola
68xxx chips.
P.S. : What's a 80246? ;-)
*
+ *
*
+ *
- - - - -----------=============<<<<<<<<<<{{{{{{{{[[[[[[ BRANDONIUS
+ +
* *
+ +
daveh@cbmvax.commodore.com (Dave Haynie) (12/20/89)
in article <49900@bbn.COM>, denbeste@bbn.com (Steven Den Beste) says: > In article <819@mindlink.UUCP> a218@mindlink.UUCP (Charlie Gibbs) writes: >> >> I seem to recall that the 386 was released with bugs too. ... >> I haven't heard similar stories about the 680x0 line .... > The original release of the 68000 had a bug in the "page fault" interrupt, > so that it pushed the STACK POINTER onto the stack frame instead of the RETURN > ADDRESS. Needless to say, this made it pretty hard to use an MMU with a 68000. No, actually, that wasn't the problem. You can certainly take a bus error exception on the 68000, and return from it. However, there essentially is no "page fault" exception in the 68000. Not a bug, a design defficieny. If a 68000 takes a bus error in the midst of an instruction, there's no way to transparently patch things up and either restart or continue the instruction. In the 68010, Moto added a larger stack frame for the bus error exception. This allows software to figure out what failed, patch things up by loading a new page or whatever else may be necessary, and then RTE back to continue the instruction no matter where the fault was detected. The 68010 also added another little goody so that it could function as a true virtual machine (a program in user mode on the 68000 can actually find out it's in user mode, while on the 68010 the OS can trap things and fool that program into believeing it's actually in supervisor mode). > One of the very first machines with a 68000 and MMU (it may have been from > Apollo, my memory is hazy) actually had TWO 68000's, with one runnine one > instruction ahead of the other. Yup, that was Apollo; others probably used the technique too. I believe the first Suns were 68010 machines, though. We had a bunch of the old Apollos around here for awhile, the others used a weird bit-slice CPU that emulated the 68010. Now all the Apollos are neat '020 and '030 machines not much larger than an A2000. > Is that ugly enough for you? (I might mention that in the Intel vs. Motorola > fight, I'm a firm Motorola fan. But let's keep things in perspective here, OK?) Again, that wasn't a bug. Bugs are generally fixed in the next rev of the silicon after they're discovered. Basic flaws in design are much harder to take care of. Again, here's a place where Intel has had to work much harder than Motorola -- Moto _almost_ got it right the first time, Intel went through the 8086/88, 80186, and 80286 before finally getting pretty close in the '386. > Steven C. Den Beste || denbeste@bbn.com (ARPA/CSNET) -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (12/20/89)
In <1617@bnr-rsc.UUCP>, schow@bcarh185.bnr.ca (Stanley T.H. Chow) writes: >In article <824@mindlink.UUCP> a218@mindlink.UUCP (Charlie Gibbs) writes: >> >>Does anyone have any more horror stories? >> > >How about the inconsistancy between 68000 & 68010? (Specifically the MOVESR >problem). The 'inconsistency', as you call it, is a bug fix. Is it a big deal for you? Was it worth leaving in the machine so future genrations of the chip would have to have ever more kludges to work around the problem? >For myself, I prefer the Intel approach - that is, make the successors >have exactly the same bugs as well. That way, a pin-compatible '010 will >really be pin-compatible. You are one sick puppy. You remind me of the fellow with the broken watch who won't get it fixed because he is used to the way it loses time, and having one that worked would only confuse him. >How about the '020 MMU being a subset of the '851 MMU? Not a bug, but >certainly an extremely undesirable feature for a later member of any >architecture family. Undesirable feature? How would you suggest implementing the I/O stuff, when the MMU has been moved inboard and made inaccesible to the I/O? Tell me.. how many 8080's are in the latest CPU array from Intel? -- " All I ask of my body is that it carry around my head." - Thomas Alva Edison - +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
schow@bcarh185.bnr.ca (Stanley T.H. Chow) (12/20/89)
In article <824@mindlink.UUCP> a218@mindlink.UUCP (Charlie Gibbs) writes: > >Does anyone have any more horror stories? > How about the inconsistancy between 68000 & 68010? (Specifically the MOVESR problem). For myself, I prefer the Intel approach - that is, make the successors have exactly the same bugs as well. That way, a pin-compatible '010 will really be pin-compatible. How about the '020 MMU being a subset of the '851 MMU? Not a bug, but certainly an extremely undesirable feature for a later member of any architecture family. Stanley Chow BitNet: schow@BNR.CA BNR UUCP: ..!psuvax1!BNR.CA.bitnet!schow (613) 763-2831 ..!utgpu!bnr-vpa!bnr-rsc!schow%bcarh185 Me? Represent other people? Don't make them laugh so hard.
new@udel.edu (Darren New) (12/21/89)
I heard a rumor that a special sequence of otherwise meaningless instructions will cause the 68000 to stuff into one of the registers some sort of CPU serial number, implying that not all 68000's are exactly the same. Can anybody substantiate this rumor? (I chose this thread because if anybody would have this sort of info it would be the people that know what bugs were in the CPUs...) Thanks in advance! -- Darren
jeffw@pro-graphics.cts.com (Jeff Waltzer) (12/21/89)
In-Reply-To: message from barry@sun.acs.udel.edu
As far as I know the 68040 is vaporware so it is not fair to compare it to the
80486 which actually exists in products now.
Jeff Waltzer
Beware of Atnas.
UUCP: crash!pro-graphics!jeffw
DDN: crash!pro-graphics!jeffw@nosc.mil
INET: crash!jeffw@pro-graphics.cts.comkeithh@atreus.uucp (Keith Hanlan) (12/22/89)
In article <1617@bnr-rsc.UUCP> bcarh185!schow@bnr-rsc.UUCP (Stanley T.H. Chow) writes: >In article <824@mindlink.UUCP> a218@mindlink.UUCP (Charlie Gibbs) writes: >> >>Does anyone have any more horror stories? >> > >How about the inconsistancy between 68000 & 68010? (Specifically the MOVESR >problem). > >For myself, I prefer the Intel approach - that is, make the successors >have exactly the same bugs as well. That way, a pin-compatible '010 will >really be pin-compatible. Come now Stanley, you're going to get roasted for this one so let me start :-) Remember that this philosophy is what has given rise to our IBM mainframes with their 30 year old architecture complete with punch cards... Heck - they aren't even bugs so much as anachronisms and deficiencies. Bugs are even worse. No, I think it's smarter the bite the bullet as many times as necessary to keep the bites small and manageable. This is the only way to permit progress. > >How about the '020 MMU being a subset of the '851 MMU? Not a bug, but ^^^ - do you mean the '030? See Dave Haynie's earlier comments on this. If you really need it - which most will contend you don't - add the '851 anyways. Best of the season to everybody... Keith Keith Hanlan Bell-Northern Research, Ottawa, Canada 613-765-4645 uunet!utgpu!bnr-vpa!bnr-fos!bmers58!atreus!keithh or keithh@bnr.ca
daveh@cbmvax.commodore.com (Dave Haynie) (12/22/89)
in article <1617@bnr-rsc.UUCP>, schow@bcarh185.bnr.ca (Stanley T.H. Chow) says: > Summary: > Followup-To: > Keywords: > How about the inconsistancy between 68000 & 68010? (Specifically the MOVESR > problem). Easily enough handled by the OS; in the Amiga OS, you say GetCC() and it works on any system. Like I mentioned in a previous article, the 68000 was never designed to handle virtual memory or act as a virtual machine, and it shows. But it's no big deal. The other thing is that the only problem executing MOVE SR on a non-68000 causes in user mode is an exception that's trivial to fix with a simple trap handler. There are about 3 or more of these trap handlers around for the Amiga OS; I use one called DeciGel, it works great on those 1 or 2 programs that didn't use GetCC(). > For myself, I prefer the Intel approach - that is, make the successors > have exactly the same bugs as well. That way, a pin-compatible '010 will > really be pin-compatible. When each chip needs to have a brand new mode, plus emulations of all the prior modes, you might as well throw the bugs in. The 680x0 chips are still all user-mode compatible, so there's no emulation and no reason to propagate any bug than can be easily fixed with a trap or something (in that the MOVE SR problem is the only real incompatibility I've run into across the family). > How about the '020 MMU being a subset of the '851 MMU? Not a bug, but > certainly an extremely undesirable feature for a later member of any > architecture family. That's the '030 MMU, and while it's a subset, it's a pretty substantial subset. Mostly they cut out a couple of addressing modes here and there, most of the instructions, the way the MMU works, etc. is the same. But who cares, that's a supervisor mode change. Motorola makes them when they make good architectural sense. No big deal, you fix the kernel. It's never been a big deal; in fact, for AMIX they just use the common set of MMU instructions, far as I know. Sun had to modify their kernel, but they were using a hand-rolled MMU in their '020 machines anyway. All the programs still work because user mode stuff doesn't change. > Stanley Chow BitNet: schow@BNR.CA -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough
schow@bcarh185.bnr.ca (Stanley T.H. Chow) (12/22/89)
In article <668@bmers58.UUCP> keithh@atreus.UUCP (Keith Hanlan) writes: >In article <1617@bnr-rsc.UUCP> bcarh185!schow@bnr-rsc.UUCP (Stanley T.H. Chow) writes: >>For myself, I prefer the Intel approach - that is, make the successors >>have exactly the same bugs as well. That way, a pin-compatible '010 will >>really be pin-compatible. > >Come now Stanley, you're going to get roasted for this one so let me >start :-) Remember that this philosophy is what has given rise to our >IBM mainframes with their 30 year old architecture complete with punch >cards... Heck - they aren't even bugs so much as anachronisms and >deficiencies. Bugs are even worse. This depends on your point of view - do you want a pretty architecture or do you want to get some work done. For esthetics, of course I would like to see bugs fixed, loosed ends tidied up, but this is of little concern to the Real World. In order to put bread on the table, work has to get done. This means bugs that have work-arounds should be left alone. Changing the behaviour of a system just to remove anachronisms is simply not a cost-effective thing to do. For example, are you happy that the MOVESR instruction is priviledged on the '010? Or would you rather see it the same as the '000 so that we can drop '010 into the '000 socket and not worry about decigel, etc.? What did this change buy us? The *conceptual* ability to virtualize a '010! Whoppie. How many people do you know run virtual '010? How many simply use the '010 as a faster '000? > >No, I think it's smarter the bite the bullet as many times as necessary >to keep the bites small and manageable. This is the only way to permit >progress. It all depends on how expensive each bite is. In many cases, a small bite is just expensive as a big one - it is the existance of a change that trigers regression testing, etc. The size of the change does not really affect the cost. There is also the problem of why should I bite the small bullet now when I have the option of not biting any bullet ever? This of course depends on whether you are designing or using a system. I, as a user, don't want to see incompatible changes. So what the designer of the system has to sweat bullets to make the new system compatible - this is what they get paid for. >> >>How about the '020 MMU being a subset of the '851 MMU? Not a bug, but > ^^^ - do you mean the '030? See Dave Haynie's earlier Silly typo, of course I meant the '030, >comments on this. If you really need it - which most will contend you >don't - add the '851 anyways. This is what I call a bug in the "Family Architecture": put an MMU into the CPU just so that you can disable it and add an off-chip MMU. Brillant use of the silicon real estate. What I tried to point out is that in some ways, the 68K family is not well thought out in terms of functions provided and the partitioning of the functions that are provided. This is not to say that Motorola is incompetent, everyone makes mistakes. Considering the age of 68K family, I think Motorola has done remarkably well, I just don't think they have been perfect. Stanley Chow BitNet: schow@BNR.CA BNR UUCP: ..!psuvax1!BNR.CA.bitnet!schow (613) 763-2831 ..!utgpu!bnr-vpa!bnr-rsc!schow%bcarh185 Me? Represent other people? Don't make them laugh so hard.
daveh@cbmvax.commodore.com (Dave Haynie) (12/23/89)
in article <1624@bnr-rsc.UUCP>, schow@bcarh185.bnr.ca (Stanley T.H. Chow) says: > Summary: > Followup-To: > Keywords: > For example, are you happy that the MOVESR instruction is priviledged on > the '010? Yes, actually, since it's completely painless in any reasonable operating system. > What did this change buy us? The *conceptual* ability to virtualize a '010! > Whoppie. How many people do you know run virtual '010? If there's one, that's more than used a similar capability in the Intel system at the time. But Intel users saved a few byte of memory 'cause they didn't have a trap to install and didn't have an operating system to get between them and the raw hardware. But enough of that nonsense; MOVE SR doesn't amount to a hill of beans. > How many simply use the '010 as a faster '000? Not many. Some folks will do anything for a 5%-10% increase, as witnessed by the Mac II -> Mac IIx upgrades. But the main reason for the 68010 was real support for virtual memory. Every Sun 2 owner benefitted from this, as well as the owners of AT&T UNIX PCs and Tektronics lab computers. If you didn't need the virtual memory, you could stick with the 68000. Your argument can very easily be switched around. I could make the claim that the 68010 was the perfect upgrade for the 68000. It fixes that silly MOVE SR design flaw, so that your 68000 machine can be made user-mode compatible with all 68020,30, and 40 machines for years to come. And the damn thing's even pin compatible. What more could you ask! > This is what I call a bug in the "Family Architecture": put an MMU into > the CPU just so that you can disable it and add an off-chip MMU. Brillant > use of the silicon real estate. No one ever does that. No one. There's no reason to. If you keep insisting there is, you're confused and probably bound to stay that way. This is an implementation detail known only by the operating system. It will not effect a single piece of user software. If you want to consider a bug in the family architecture, consider what you're losing with Intel architecture in having to have complete hardware emulators of the 8086 and 80286 in every '386 and '486 chip. If that space hadn't been wasted supporting architectural hair from the past, it could have been used for something truely useful. When they designed the '386 native mode, they had to cripple it with too few registers, no cache, and a weak MMU to make room for that stuff. Not to mention missing addressing modes. They really cleaned up the architecture of the '386 mode so that most folks don't complain and so that they didn't have to add yet another incompatible mode for the '486. Your claim that the bugs should be maintained really loses when you apply it elsewhere. For example, software. You bug a new software package for your computer, and use it pretty heavily. It has a bug here and there, occasionally crashes, but it's still quite useful. Then the company announces an update. An Intel-style update would give you a new program with two modes. The compatibility mode would read your hundreds of man-years worth of files for this wonder-program, but it would still crash and do anything else nasty the old one did. And it wouldn't offer any new features. The new mode would have all kinds of bug fixes and other goodies, but it wouldn't read any of your old files. The Motorola-style update would add the new features on top of the old, and fix the bugs. You'd be able to read most of your old applications into the new mode of the program, and they'd be immediately able to take advantage of the new features. There might be a few old-style files it wouldn't read directly, but a thoughtfully provided patch program (called, for some unknown reason, "DeciGel") would fix up the old files so that they worked just fine on the new program. > Stanley Chow BitNet: schow@BNR.CA > BNR UUCP: ..!psuvax1!BNR.CA.bitnet!schow > (613) 763-2831 ..!utgpu!bnr-vpa!bnr-rsc!schow%bcarh185 > Me? Represent other people? Don't make them laugh so hard. -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough
schow@bcarh185.bnr.ca (Stanley T.H. Chow) (12/23/89)
In article <9140@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >in article <1624@bnr-rsc.UUCP>, schow@bcarh185.bnr.ca (Stanley T.H. Chow) says: > >> For example, are you happy that the MOVESR instruction is priviledged on >> the '010? > >Your argument can very easily be switched around. I could make the claim >that the 68010 was the perfect upgrade for the 68000. It fixes that silly >MOVE SR design flaw, so that your 68000 machine can be made user-mode ^^^^^^^^^^^^ >compatible with all 68020,30, and 40 machines for years to come. And the >damn thing's even pin compatible. What more could you ask! Thanks Dave, so nice to have my point confirmed by a real expert. The original discussion was on bug-lists for different micro-processors. Someone asked for bugs on the 68K side and I pointed out the MOVESR as an example. Please note that I have nothing against fixes (or any changes). I just think there are better times and worse times for making them. E.g., if the '010 was/is intended as replacement for the '000 and the change is painless, then Motorola should just drop the '000 all together. The fact the Motorola still sells mostly '000 means either people think the change is hard or that the people think the change is not worth it. Case in point - Amiga after 4 release still does not support it. Yes, I know the '010 is priced much higher, but it had a very short marketing window and was essentially replace by the '020. It would have been much more sensible to fix all the problems in the '020 since the software kernal had to change anyway. > >> This is what I call a bug in the "Family Architecture": put an MMU into >> the CPU just so that you can disable it and add an off-chip MMU. Brillant >> use of the silicon real estate. > >No one ever does that. No one. There's no reason to. If you keep insisting >there is, you're confused and probably bound to stay that way. This is an >implementation detail known only by the operating system. It will not effect >a single piece of user software. Perhaps Dave needs to talk to Keith. :-) In artivle <668@bmers58.UUCP>, Keith Hanlan writes: > See Dave Haynie's earlier >comments on this. If you really need it - which most will contend you >don't - add the '851 anyways. Dave, why do you consider the operating system to be non-software? Surely, of all people, you ought to know the expense in making a change like that to an operating system! The point is not whether the two MMU's are individually good enough. The point is also not whether the O/S can hide the difference. The point is that they are different! > >If you want to consider a bug in the family architecture, consider what you're >losing with Intel architecture in having to have complete hardware emulators ^^^^^^ >of the 8086 and 80286 in every '386 and '486 chip. Why do you think they *had* to make it compatible? It happens to be good business to protect the user's software investment. Do you think the '286 & '386 clones would have been so popular so quickly if everyone had to buy new versions or had to install interrupt interceptors that may-be sometimes work? I have no intention of defending *any* processor family so I won't get into that line of discussion. >Your claim that the bugs should be maintained really loses when you apply >it elsewhere. For example, software. You bug a new software package for >your computer, and use it pretty heavily. It has a bug here and there, >occasionally crashes, but it's still quite useful. Then the company >announces an update. Does this have anything to do with MOVESR? Are you saying MOVESR causes occasional crashes? I would have put it into the annoying design-flaw catagory. :-) You are talking an interesting situation, but unrelated to the topic of discussion. A closer analogy is a software package that works correctly with an update that introduces new features. > >An Intel-style update would give you a new program with two modes. The >compatibility mode would read your hundreds of man-years worth of files >for this wonder-program, but it would still crash and do anything else >nasty the old one did. And it wouldn't offer any new features. The new >mode would have all kinds of bug fixes and other goodies, but it wouldn't >read any of your old files. As I said, the closer analogy is that the new package still works correctly for the old files, but for new files, it has new features. Wait a minute, I seem to remember this being done for some successful packages. > >The Motorola-style update would add the new features on top of the old, >and fix the bugs. You'd be able to read most of your old applications >into the new mode of the program, and they'd be immediately able to take >advantage of the new features. There might be a few old-style files >it wouldn't read directly, but a thoughtfully provided patch program >(called, for some unknown reason, "DeciGel") would fix up the old files >so that they worked just fine on the new program. > My version says the update broke the old way of doing things needlessly for new features that a user does not want. The point is: "If it ain't broke, don't fix it". The real point is: "If it is broke, but nobody cares, don't fix it anyway". Stanley Chow BitNet: schow@BNR.CA BNR UUCP: ..!psuvax1!BNR.CA.bitnet!schow (613) 763-2831 ..!utgpu!bnr-vpa!bnr-rsc!schow%bcarh185 Me? Represent other people? Don't make them laugh so hard.
schow@bcarh185.bnr.ca (Stanley T.H. Chow) (12/23/89)
In article <936@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >In <1617@bnr-rsc.UUCP>, schow@bcarh185.bnr.ca (Stanley T.H. Chow) writes: >>In article <824@mindlink.UUCP> a218@mindlink.UUCP (Charlie Gibbs) writes: >>> >>>Does anyone have any more horror stories? >>> >> >>How about the inconsistancy between 68000 & 68010? (Specifically the MOVESR >>problem). > >The 'inconsistency', as you call it, is a bug fix. Is it a big deal for you? >Was it worth leaving in the machine so future genrations of the chip would have >to have ever more kludges to work around the problem? You know, Charlie Gibbs asked for horror stories, I pointed out the MOVESR *inconsistancy* and here you are calling it a *bug*! Boy, are you gonna to get flamed by the Motorola-lovers. :-) It sure is nice to have my point confirmed by experts like Larry (and Dave). > >>For myself, I prefer the Intel approach - that is, make the successors >>have exactly the same bugs as well. That way, a pin-compatible '010 will >>really be pin-compatible. > >You are one sick puppy. You remind me of the fellow with the broken watch who >won't get it fixed because he is used to the way it loses time, and having one >that worked would only confuse him. You are one closed-minded loud-mouth sicko bleeding-heart conservertive. Now that I called you names right back, feel better? Shell we get on with a discussion with information? Would you like to tell me *why* you object to that approach? >>How about the '020 MMU being a subset of the '851 MMU? Not a bug, but >>certainly an extremely undesirable feature for a later member of any >>architecture family. ^^^^^^^^^^^^^^^^^^^^ > >Undesirable feature? How would you suggest implementing the I/O stuff, when the >MMU has been moved inboard and made inaccesible to the I/O? Are you saying there is no other difference? As I recall, the difference is quite a bit more than that. But then, I haven't checked the details for quite sometime. > >Tell me.. how many 8080's are in the latest CPU array from Intel? I don't know. Why do you ask? Ohh, I get it. This is a clever way of saying that Intel does as badly as Motorola! It is really strange and annoying that critizism of Mac's automatically trigger attacks on PC's, any discussion of Motorola gets Intel draged in as well. Why can't we discuss the 68K on its own merits? Do you consider its case so weak that you have to bloster it with weaknesses of other processors? In any case, your question is truly unrelated to this discussion. I was talking about members of one architecture family. > >-- >" All I ask of my body is that it carry around my head." > - Thomas Alva Edison - >+-----------------------------------------------------------------------+ >| // Larry Phillips | >| \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | >| COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | >+-----------------------------------------------------------------------+ Stanley Chow BitNet: schow@BNR.CA BNR UUCP: ..!psuvax1!BNR.CA.bitnet!schow (613) 763-2831 ..!utgpu!bnr-vpa!bnr-rsc!schow%bcarh185 Me? Represent other people? Don't make them laugh so hard.
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (12/24/89)
In <1627@bnr-rsc.UUCP>, schow@bcarh185.bnr.ca (Stanley T.H. Chow) writes: >In article <936@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >>In <1617@bnr-rsc.UUCP>, schow@bcarh185.bnr.ca (Stanley T.H. Chow) writes: >>>In article <824@mindlink.UUCP> a218@mindlink.UUCP (Charlie Gibbs) writes: >>>> >>>>Does anyone have any more horror stories? >>>> >>> >>>How about the inconsistancy between 68000 & 68010? (Specifically the MOVESR >>>problem). >> >>The 'inconsistency', as you call it, is a bug fix. Is it a big deal for you? >>Was it worth leaving in the machine so future genrations of the chip would have >>to have ever more kludges to work around the problem? > >You know, Charlie Gibbs asked for horror stories, I pointed out the MOVESR >*inconsistancy* and here you are calling it a *bug*! Boy, are you gonna to >get flamed by the Motorola-lovers. :-) Call it what you will... bug, inconsistency, design flaw. The point remains that MOVESR should have been a priviledged instruction. It was not, on the 68000. It is, on the rest of the line, starting with the 68010. The inconsistency/bug/design flaw was removed as of the 68010. In any case, it is far from being a 'horror story'. >It sure is nice to have my point confirmed by experts like Larry (and Dave). I don't claim to be an expert. Do you? >>>For myself, I prefer the Intel approach - that is, make the successors >>>have exactly the same bugs as well. That way, a pin-compatible '010 will >>>really be pin-compatible. >> >>You are one sick puppy. You remind me of the fellow with the broken watch who >>won't get it fixed because he is used to the way it loses time, and having one >>that worked would only confuse him. >You are one closed-minded loud-mouth sicko bleeding-heart conservertive. Thank you. I see you have me pegged quite nicely. >Now that I called you names right back, feel better? Shell we get on with >a discussion with information? Would you like to tell me *why* you object >to that approach? Yes. I object to that approach because every succeeding incarnation that carries the bugs/design flaws/inconsistencies of the previous incarnations needs the same workarounds; the same gyrations, and stifles progress. If a processor is well thought out to start with, there need be no carryover of braindead bits. In my opinion, Intel should have done a complete redesign at the 8086/8088 level, and stopped mucking with full compatibility to their previous stuff. >>>How about the '020 MMU being a subset of the '851 MMU? Not a bug, but >>>certainly an extremely undesirable feature for a later member of any >>>architecture family. > ^^^^^^^^^^^^^^^^^^^^ >> >>Undesirable feature? How would you suggest implementing the I/O stuff, when the >>MMU has been moved inboard and made inaccesible to the I/O? > >Are you saying there is no other difference? As I recall, the difference is >quite a bit more than that. But then, I haven't checked the details for >quite sometime. I haven't either. I happened to use that one example to point out that the internal MMU need not be a full implementation of the external MMU. >>Tell me.. how many 8080's are in the latest CPU array from Intel? > >I don't know. Why do you ask? > >Ohh, I get it. This is a clever way of saying that Intel does as badly as >Motorola! No, this is a way of saying that all the anachronisms of the 8080 are present in the entire family. Motorola learned a lot from the 6800 and 6809, and decided that carrying the baggage into their next line was no appropriate. That there was a problem in the 68000 is beside the point. It was changed to be a non-problem in the 68010, requiring workarounds only in the single processor that had the problem, rather than in all succeeding processors. >It is really strange and annoying that critizism of Mac's automatically >trigger attacks on PC's, any discussion of Motorola gets Intel draged in >as well. Why can't we discuss the 68K on its own merits? Do you consider >its case so weak that you have to bloster it with weaknesses of other >processors? It is really strange and annoying that you say this, when you yourself have brought up points about Intel, as in your statement above: "For myself, I prefer the Intel approach -". I am addressing those statements, among others. I am not addressing Mac issues. >In any case, your question is truly unrelated to this discussion. I was >talking about members of one architecture family. You may be talking about members of one architecture family, but I assure you that the perception from this end is that you are talking about two different philosophies of architectural design, and are including Intel and Motorola's examples of the two philosophies. >Stanley Chow BitNet: schow@BNR.CA >BNR UUCP: ..!psuvax1!BNR.CA.bitnet!schow >(613) 763-2831 ..!utgpu!bnr-vpa!bnr-rsc!schow%bcarh185 >Me? Represent other people? Don't make them laugh so hard. Merry Christmas, Stanley. -- " All I ask of my body is that it carry around my head." - Thomas Alva Edison - +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (12/24/89)
In article <1626@bnr-rsc.UUCP> bcarh185!schow@bnr-rsc.UUCP (Stanley T.H. Chow) writes: >In article <9140@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>[...] the 68010 was the perfect upgrade for the 68000. It fixes that silly >>MOVE SR design flaw, so that your 68000 machine can be made user-mode > ^^^^^^^^^^^^ >>compatible with all 68020,30, and 40 machines for years to come. And the >>damn thing's even pin compatible. What more could you ask! > >Thanks Dave, so nice to have my point confirmed by a real expert. > >The original discussion was on bug-lists for different micro-processors. >Someone asked for bugs on the 68K side and I pointed out the MOVESR as an >example. "Bug" and "design flaw" are not the same thing. MOVE SR on the 68000 behaves the way it was designed to--therefore, it is *not* a bug. It does mean that the 68000 can't be virtualized, which could be considered to be a "design flaw", depending on your application and interests. >Please note that I have nothing against fixes (or any changes). I just think >there are better times and worse times for making them. E.g., if the '010 >was/is intended as replacement for the '000 and the change is painless, >then Motorola should just drop the '000 all together. The fact the Motorola >still sells mostly '000 means either people think the change is hard or >that the people think the change is not worth it. Case in point - Amiga >after 4 release still does not support it. The '10 was not intended as a replacement for the 68000. It was intended to be a 68XXX family processor which could support virtual memory and page fault interrupts, and could be virtualized. Those are important features for workstation manufacturers, so presumably Motorola wanted a 68XXX family processor with those feature available before it finished the 68020, and it wanted to have a low-end 68XXX family processor with those features available after the 68020 was released. Motorola still sells mostly 68000 because most micros don't need virtual memory, page fault interrupts and virtualization (yet), and workstation vendors have mostly switched to the '20 and '30. You're missing the point by locking yourself into the view that the '10 had to be an upgrade to the 68000 for every application, when this just isn't so--it provided some important features, but not everyone needs those features. If they don't need those features, they use the cheaper 68000. I don't understand your comment that the Amiga doesn't "support" the 68010. The Amiga works fine with a 68010. Some software which violates Commodore's explicit guidelines for Amiga software does not work with a 68010. Some software which violates Commore's guidelines does not work with later releases of the operating system, or different memory or hardware configurations. This doesn't mean that the Amiga doesn't support the 68010, any more than it means the Amiga doesn't support later releases of its own operating system. It does mean that some developers wrote broken software. If you mean that the Amiga doesn't use the extra features of the 68010 (yet), sure, that's true. That doesn't mean the 68010 isn't supported. >>> This is what I call a bug in the "Family Architecture": put an MMU into >>> the CPU just so that you can disable it and add an off-chip MMU. Brillant >>> use of the silicon real estate. >> >>No one ever does that. No one. There's no reason to. If you keep insisting >>there is, you're confused and probably bound to stay that way. This is an >>implementation detail known only by the operating system. It will not effect >>a single piece of user software. > >Perhaps Dave needs to talk to Keith. :-) > >In artivle <668@bmers58.UUCP>, Keith Hanlan writes: >> See Dave Haynie's earlier >>comments on this. If you really need it - which most will contend you >>don't - add the '851 anyways. No, Keith needs to talk to Dave. >The point is: "If it ain't broke, don't fix it". > >The real point is: "If it is broke, but nobody cares, don't fix it anyway". And we're telling you that people care. -Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell University