daveh@cbmvax.commodore.com (Dave Haynie) (12/31/89)
in article <1626@bnr-rsc.UUCP>, schow@bcarh185.bnr.ca (Stanley T.H. Chow) says: >>> This [MOVE SR] 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. > 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 changes to the operating system are trivial. The patches too. Sure, I consider the OS a piece of software. But it's a rather small investment as compared with all your other software, and it always gets upgraded, for new system configurations as well as new CPUs. The entire point of having an operating system is to provide an interface layer between applications software and hardware. My claim is that if Motorola can improve their CPUs in any way that is transparent to User Mode programs, they should do this, and we'd be fools to object. No matter what they do, it's not going to be a major problem for the OS to handle; you're probably talking about a week or less of time for a single programmer to adjust for. I think they had AMIX running on the '030 board the first day I gave them one. > 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! No, the point is that the differences are meaningless. They don't cause any problem, there are major advantages, and minor annoyances, if any. I mean, if someone offered to trade me a Porsche 928S for my Fiero, I don't start complaining about the fact that I have to go to the trouble of getting the Fiero keys off the keychain. That's about the extent of these software "problems". >>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? Of course they made it as compatible as they could, they had no other choice. Because of what I'd term design flaws, the 8088/8086 architecture wasn't extendable. There is no user mode, and there is no real OS to hide any differences. That's a bad thing, and the Intel lines will be stuck with it for a long time; even the '486 had to make compromises to let MS-DOS stuff work, and all those folks running UNIX on the '486 will pay the price. > It happens to be good business to protect the user's software investment. Absolutely, which is why I claim the Motorola architecture is superior. It lets the user take along the software investment AND take advantage of performance increases other than simply a faster clock. > ... or had to install interrupt interceptors that may-be sometimes work? The MOVE SR trap handler _always_ works. By design; it's using a standard trap mechanism that's been in place since the first 68000, specifically for this type of thing. Do you really understand the realities of the Motorola architecture and upgrade methodology? It sure sounds like you've just scratched the surfaced and found what sounds to the layman like material for Motorla bashing, without really understanding what you're writing about. > 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