Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!cbmvax!daveh From: daveh@cbmvax.cbm.UUCP (Dave Haynie) Newsgroups: net.micro.68k,net.micro.amiga,net.micro.atari16,net.micro.mac Subject: Re: Re: The Motorola 68030 Message-ID: <833@cbmvax.cbmvax.cbm.UUCP> Date: Fri, 3-Oct-86 17:23:11 EDT Article-I.D.: cbmvax.833 Posted: Fri Oct 3 17:23:11 1986 Date-Received: Sat, 4-Oct-86 12:16:59 EDT References: <205@mipos3.UUCP> Organization: Commodore Technology, West Chester, PA Lines: 123 Xref: watmath net.micro.68k:1934 net.micro.amiga:5129 net.micro.atari16:2330 net.micro.mac:8118 > Keywords: here we go again... > Of course, there is no comparison between the two classes of machines, > because you in here introduce more than two classes of machines. I would not > put Sun workstations and Turbo Amigas in the same class of machine simply > because the Amiga does not support any kind of memory management. If you > want to have a grown-up machine, one that supports multi-user/multi-tasking > you really need to have this. Its nice to have, but required only if your OS demands it. > Not until you have the 68030, or you make an entire subsystem > plug in with a 68020 and an mmu, can you claim to have upgraded your Amiga > the way plugging a 286 upgrades a pc. I don't claim that the 68020 upgrade for a 68000 machine is like a '286 upgrade for an 8088 machine. I claim its a generation removed. The 8088 is an 8/16 bit processor, the '286 a 16/16. The 68000 is a 16/32, the '020 a 32/32. A processor with a good MMU can run UNIX, quickly, and have all the advantages of a protected OS. A non-protected OS can suffer from misbehaved programs and slow context swaps (if its multitasking, which the MS-DOS operating system emphatically isn't. Oranges vs. oranges, remember). A Turbo upgrade for an Amiga can deliver much the same level of performance as a Sun and still use standard off-the-shelf Amiga software and operating system, and it can take advantage of the extra capabilities of the 68020. MS-DOS runs fine on a '286 PC, but it can't use the extended memory addressing capabilities -- unless you kludge it, MS-DOS has a ceiling of 640K. AmigaDOS has a ceiling of 4 Gigabytes. I wouldn't try to run UNIX on a basic Turbo Amiga; UNIX isn't designed to run well without an MMU; the context swapping between processes is going to make it a dog. But the Amiga Exec was designed to provide a fast multitasking environment on a machine without an MMU. It supports 68000, 68010, and 68020 processors in a processor-independent way; the Amiga Exec knows which processor is in place and provides functions to handle the differences, like the different exception stacks. All the AmigaDOS software will work as is with the 68020, or it can be upgraded to take advantage of special 68020 enhancements. These upgrades, however, can be incremental, as each of the many software subsystems in the Amiga Kernal and DOS can be replace independently of each other. How much of the '286 instruction set, etc. will even work under MS-DOS, assuming I were to, say, rewrite the floating point libraries for the '286 and '287 coprocessor? Of course an unprotected multitasking environment is dangerous for poorly behaved programs, but so is a single tasking environment on a machine without adequate hardware support (like a PC). I wouldn't expect to see a good UNIX running on the Amiga without an MMU; then again, an 80286 UNIX has to deal with its own set of inefficiencies, namely the 64K paging limitations that still exist even in protected mode. For a state of the art UNIX environment I need to an an MMU to my Amiga, you need to add a '386 to your PC. An integral/standard MMU is a good idea; Intel finally go one right :-). > In the first place, msdos, while not taking advantage of the functionality > of the 286 or the 386, is certainly not a kludge when run on them. True. Lots of folks think the 8086 modes are kludges; I believe they're not. And the problems with the '286 native mode and MS-DOS are due to both the design of the '286 and the design of MS-DOS. > In addition, when you go from one type of 68* based box to another, you > also need to rewrite the operating system, because the memory management > systems are incompatible. Not helped much by the two different late-coming 680xx MMUs. I know, any standard MMU is better than none at all. > People have also generated 286-based cards that plug into plain old IBM pcs > and have gained a significant performance upgrade, while running their old > software. I'm sure the same thing can and will happen with the 386. That's really only the advantage of going to a 16 bit (or 32 bit) bus versus the old 8 bot of the 8088, plus the faster speed of the thing. But like I said, I can get a much more significant increase in power with the 68020 card in the Turbo Amiga -- double the clock speed, double the data fetch, and extend that memory limit to the full 32 bit address bus. Now I know that this can't be done with every 68000 based micro; many of them do thing that require a 68000 only. That's an OS design issue. And why I'm glad I have an Amiga. > And Unix implementations for 8086-based chips have been floating around for > at least 5 years. MS-DOS already is a 16-bit os, and always has been. > When going from a 68020 to a 68030, you will have to rewrite the os to take > advantage of the memory management that the 68030 provides...otherwise you > just have a little faster 68020, much like you can use a 286 as a faster > 8086. How about if we compare apples to apples? Can you say "incoherency?" I'll leave the "incoherency" to you. You're flaming for running a 68000 with no MMU, then you suggest Unix for 8086-based chips? If I want segmentation as a form of memory mamagement, there's nothing stopping me from requiring my 68000 environment to support only register relative addressing. But anything that _requires_ 64K segments shouldn't be bothering with UNIX. And as I said, my move to an '020 or '030 already gives me much more than just a faster 68000. To use an MMU would require a few sections of the OS to be rewritten, but its no big deal. The hard part is going the other way, which is why memory management is required for UNIX speed, protection issues aside. >>P.S. BTW, have you guys heard about the 78000 (!?) See Nanobytes in >>the latest BYTE (the //GS issue). This is a RISC uprocessor with a >>rated speed of 20 (VAX-equivalent?) MIPS . . . this kind of speed >>totally blows away the RT PC (note: the RT PC performed just a hair >>better than an PC AT in benchmarks . . . see PC World or PC magazine >>of a month ago. . . not very impressive . . .) > > Oh, this is great. Yet another paper product. This one, they haven't > even had a press release on! I guess it must be more than a year > away (:-)). > -- > The above views are personal. > > I've seen the future, I can't afford it... > Ken Shoemaker, Microprocessor Design, Intel Corp., Santa Clara, California > uucp: ...{ hplabs|amdcad|qantel|pur-ee|scgvaxd|oliveb }!intelca!mipos3!kds > csnet/arpanet: kds@mipos3.intel.com -- ============================================================================ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh These opinions are my own, though if you try them out, and decide that you really like them, a small donation would be appreciated.