Path: utzoo!attcan!uunet!lll-winken!lll-lcc!lll-tis!ames!pasteur!ucbvax!decwrl!labrea!glacier!jbn From: jbn@glacier.STANFORD.EDU (John B. Nagle) Newsgroups: comp.sys.m68k Subject: Re: 68020 in a *68010* socket? Message-ID: <17482@glacier.STANFORD.EDU> Date: 6 Jun 88 16:58:33 GMT References: <17206@gatech.edu> <10123@mcdchg.UUCP> <17479@glacier.STANFORD.EDU> <6276@cup.portal.com> Reply-To: jbn@glacier.UUCP (John B. Nagle) Organization: Stanford University Lines: 39 In article <6276@cup.portal.com> thad@cup.portal.com writes: >Why do you feel there's such a software incompatibility between the various >680x0 processors? > The problem is, of course, the multiply hardware. The 68000 and 68010 lack hardware for a 32x32 bit multiply, while the 68020 and 68030 have such hardware and a new opcode. Compilers for the 68000 and 68010 typically call a subroutine for every multiply. Some of the smarter compilers handle multiplies by constants in special ways (typically using addition and shifting) to avoid the overhead of the multiply subroutine whenever possible. This speeds up subscript calculations considerably. On Sun machines, software is generated for the 68020 or 68010 based on a compiler switch. Much new software built for the 68020 will not run on the older Sun II machines, which have 68010 processors. The Sun II is considered obsolete in the Sun world, having been superseded by the Sun III more than two (three?) years ago. This history will repeat itself at the low end, on the Mac and Amiga lines. As the mainstream products become 68020-based, more software will be built that assumes a 68020 platform. This software will not run on the smaller machines of the product line. There are already Mac II only products, including CAD systems. There will be more. But there will be 16-bit Macs for a long time to come; there are manufacturing economies, and not all users need the power of a 32-bit machine. What will be needed is a part that the manufacturers can use in later versions of their low-end machines that handles the instruction set of the 68020 but is electrically compabible with the 68010. A microcode subroutine for multiply would probably be sufficient to provide compatibility across the product line. This part should not be significantly more expensive than the 68010 in volume, or it will not achieve its purpose. Motorola need not be the vendor here. Other vendors make 68010-like parts, including Siemens and Signetics. The latter has its own design, the 68070, now going into volume production. But if Motorola does it, the part may achieve greater acceptance, and should, in time, supersede the 68000/68010. John Nagle