jxw@fas.ri.cmu.edu (John Willis) (11/23/85)
But wait... IBM tried workstations around both the 8088 and 68000. While the Entry System division was designing the PC, IBM Instruments was developing the 9000 family around the 68000. Both were initially given the kind of strong marketing support IBM is famous for. Customers cast an economic vote for the 8088, not the 68000. I believe that there were good technical reasons... * Ignoring the abortive 68451, Motorola did not even produced an external VLSI MMU until 1985 (does it work even now ?). When it came time to put XENIX on the 9000, a separate board full of LSI was required, substantially driving up the cost. The 8088 came with MMU on board. * Virtual memory support (through the MMU) required an awkward probing of each page with the 68000 in order to avoid having to use two processors for each system. It took the 68010 to make demand paging a real possibility. * The Motorola addressing scheme lead to use of Motorola's Versabus in an effort to support an outside standard. Versabus was far more complex and expensive to support than the "proprietary" PC bus. Carrying a sixteen bit data path through out the machine led to a planar board nearly 17" square. * Motorola did not have a real VLSI floating point processor, leading IBM to OEM the SKY Versabus FPU board. For ~7K$, the consumer got perhaps five times the performance of a 150$ 8087. Without the accelerator, the 68000 was substantially slower on floating point than the 8088 / 8087. (Newer SKY boards now provided higher bang / buck.) The 68000 had it's chance, with some of the best effort IBM could put behind it, and failed to make the impact the PC has for numerous, solid technical reasons. -John
dave@heurikon.UUCP (Dave Scidmore) (11/26/85)
> * Ignoring the abortive 68451, Motorola did not even > produced an external VLSI MMU until 1985 (does it work > even now ?). When it came time to put XENIX on the > 9000, a separate board full of LSI was required, > substantially driving up the cost. The 8088 came with > MMU on board. Three points: 1) Our company has been very successfully using the "abortive" 68451 in our UNIX based products for two and one half years. It does, and always has, worked exactly the way the documentation says it should. 2) The 8088 has *no* MMU at all. It has a segmentation scheme that amounts to little more than a simple memory map. The 8088s segment register scheme has nothing approaching the features an MMU needs to support a multitasking, multiuser operating systems like UNIX. 3) If you don't know what you are talking about, don't get involved in technical discussions. Dave Scidmore
hammond@petrus.UUCP (Rich A. Hammond) (11/26/85)
> IBM tried workstations around both the 8088 and 68000. While > ... Customers cast an economic vote for the 8088, not the 68000. > > I believe that there were good technical reasons... > Re: MMU - the 68451 is at least as good as 8088's on board MMU besides, it is quite possible to write position ind. code with a 68000. (i.e. no MMU required) Re: Virtual Memory - the 8088 can handle page faults? No way! Faulting on segment sized (64k) objects in a 256k memory is pretty silly. Re: Addressing scheme - Motorola's addressing scheme does not force one to do anything in particular. The use of the Versabus was probably to pick up some exisiting boards (A/D, ... maybe?). A sixteen bit data path isn't all that expensive, remember, both systems have a 20 bit plus address bus. 20 + 8 vs 20 +16 Re: 8087 support vs Motorola. I don't believe early PC's came with an 8087, by the time the 8087 could have been a factor PC's were already well established. Most software ported from CP/M systems didn't use 8087's. > > The 68000 had it's chance, with some of the best effort IBM > could put behind it, and failed to make the impact the PC has for > numerous, solid technical reasons. > > -John One other point, which you don't mention, but many do. The 68000 supports 8 bit peripherals (6800 family chips) with CPU generated E, VMA', VPA' and with instructions (Move Peripheral Data). The 6800 family chips include a nice video display controller, UART, ... As far as I can see, the claim that an 8088 supports 8 bit stuff better is pure baloney. You fail to convince me that the reasons are technical, or solid. I don't believe that the 68000 had the best effort behind it, marketing wise, and it was certainly aimed at a different environment than a PC. Rich Hammond {ucbvax|allegra|decvax|ihnp4} !bellcore!hammond
jer@peora.UUCP (J. Eric Roskos) (11/26/85)
> Both were initially given the same kind of strong marketing support IBM > is famous for. Customers cast an economic vote for the 8088. IBM gave both strong marketing support, but in vastly different areas. The CS9000 was intended for use in a laboratory. If you look at it, it *looks* like a lab instrument... not at all the sort of thing you'd have sitting in your office. The overall design and "feel" of the machine is distinctly not that of a personal computer. And it was provided with a real-time OS, and peripherals for interfacing to lab instruments, rather than taking the "build it like the Apple II" approach that seems to have been used for the IBM PC (i.e., a simple ROM BIOS, very general, simple bus that was really just the 8088's bus brought out to some edge connector sockets, and a simple OS with a "home-grown" feel to it (which it was, at the time of PC-DOS version 1)). I think IBM eventually came out with a version of the CS9000 that had a lot of the lab interfaces omitted, for use in general computing, but that was apparently the result of market pressure rather than original design (just as the IBM PC and the Macintosh each changed under market pressure after they were announced). If you look at how it was presented in the popular press, you see the same thing. Before the IBM PC even became available, Byte magazine had written a long article praising the machine. In comparison, the CS9000 had been around for many months before an article appeared in Byte with a "forgotten PC" motif (i.e., the article started out with the premise that here was a machine designed for lab use by IBM Instruments which the author felt, despite IBM's marketing emphasis, might make a good personal computer). So I don't think it is really very accurate to try to claim that the relative merit of the 8088 over the 68000 at the time of introduction of the two machines was shown by which of the two sold better in the PC market; the CS9000 was never targeted for the same market. [Incidentally, the other "solid technical reasons" given in the referenced article, other than the additional area required to support the 16-bit bus, were not areas of concern at the time of the introduction of the original 5150 PC. There was no MMU; IBM refused to acknowledge that the empty socket on the CPU board was for an 8087 (despite the fact that everyone was fairly sure that it was, and a notation "N. P." on the CPU board diagrams suggested "Numeric Processor"); and the choices of buses where more a matter of the intent of supporting existing VME boards on the CS9000 than any sort of "Motorola-driven" requirement for a VME bus, which IBM could certainly have disregarded.] -- UUCP: Ofc: jer@peora.UUCP Home: jer@jerpc.CCC.UUCP CCC DNS: peora, pesnta US Mail: MS 795; CONCURRENT Computer Corp. SDC; (A Perkin-Elmer Company) 2486 Sand Lake Road, Orlando, FL 32809-7642
broehl@watdcsu.UUCP (Bernie Roehl) (11/27/85)
> 1) Our company has been very successfully using the "abortive" 68451 > in our UNIX based products for two and one half years. It does, and > always has, worked exactly the way the documentation says it should. I know nothing of the "68451", except that (so far as I know) almost no one is using it. The fact that it works "exactly the way the documentation says it should" ought not to be remarkable; why is it? > 2) The 8088 has *no* MMU at all. It has a segmentation scheme that > amounts to little more than a simple memory map. This is untrue. The segmentation scheme (which is, granted, a pain in the butt for a programmer working in assembler (which almost no one does)) provides *some* of the functionality of an MMU; a bare 68000 does not. I think the original poster (to whom you were replying) may have been exaggerating a bit by calling it an MMU, but you've certainly exaggerated in the other direction. > 3) If you don't know what you are talking about, don't get involved in > technical discussions. With all due respect, the same can be said of you. In any case, this kind of "observation" is petty and childish. > Dave Scidmore
henry@utzoo.UUCP (Henry Spencer) (11/28/85)
> besides, it is quite possible to write position ind. code > with a 68000. (i.e. no MMU required) Try writing the code for position-independent pointers some time; it's lots of fun, especially if you are never allowed to have a position-dependent value around even for an instant (except in pre-agreed places like the A registers). It's easy to write position-independent code if that code and its data will *never* need to be moved once it starts running. Writing code that can be moved at randomly-chosen times and continue to run is not so simple. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
jxw@fas.ri.cmu.edu (John Willis) (11/29/85)
* The 68451 may work now. After trying three separate samples during the first year Motorola tried to push them, we did not find one that ran within reasonable temperature specs, let along the published spec. Our software people got disgusted well before Motorola final sold us a running sample. Even within the spec, the chip's translation time can easily be improved on by LSI, take the SUN MMU for instance. * Everyone's definition of an MMU is slightly different, but the large number of XENIX systems happily running on the 8088 suggest that their scheme provides the basics for a UNIX system. Try opening your mind to something beyond Motorola hype. * I wouldn't stoop to the level of character assasination to support a point. -John
mdm@ecn-pc.UUCP (Mike D McEvoy) (12/02/85)
In article <1916@watdcsu.UUCP> broehl@watdcsu.UUCP (Bernie Roehl) writes: >I know nothing of the "68451", except that (so far as I know) almost no one >is using it. Since you claim to know nothing about the critter, how do you know anything about it's user base??? Heurikon, and other manufacturers make some very nice machines based on the chip. True, the 68851 is an order of magnitude better > >The segmentation scheme (which is, granted, a pain in the >butt for a programmer working in assembler (which almost no one does)) provides >*some* of the functionality of an MMU; a bare 68000 does not. I called a friend at the big "I" who said that the segmented scheme was an architectural extension to the 8080, and not memory management, period. What do you define as memory management????
glen@intelca.UUCP (Glen Shires) (12/07/85)
> > besides, it is quite possible to write position ind. code > > with a 68000. (i.e. no MMU required) > > Try writing the code for position-independent pointers some time; it's lots > of fun, especially if you are never allowed to have a position-dependent > value around even for an instant (except in pre-agreed places like the A > registers). It's easy to write position-independent code if that code and > its data will *never* need to be moved once it starts running. Writing code > that can be moved at randomly-chosen times and continue to run is not > so simple. > -- > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,linus,decvax}!utzoo!henry Precisely why Mac accesses all pointers (called "handles") through a table requiring a double indirect access on all pointers. Also, for position independance during runtime, they limit some code pieces to 32K to allow branches with 16-bit signed pointers. And people ask why Mac is so slow! Segments, especially big 4Gigabyte ones, allow simple runtime relocatability without having to resort to such programming techniques. -- ^ ^ Glen Shires, Intel, Santa Clara, Ca. O O Usenet: {ucbvax!amd,pur-ee,hplabs}!intelca!glen > ARPA: "amd!intelca!glen"@BERKELEY \-/ --- stay mellow
tim@ism780c.UUCP (Tim Smith) (12/11/85)
Henry Spencer == "<" "<" == Henry Spencer @ U of Toronto Zoology ">" == Glen Shires, Intel, Santa Clara, Ca. "!" == someone else ! besides, it is quite possible to write position ind. code ! with a 68000. (i.e. no MMU required) < will *never* need to be moved once it starts running. Writing < code that can be moved at randomly-chosen times and continue to < run is not so simple. One system that does this sort of thing is the Macintosh ( anyone know if the Amiga and the 520ST do this also? ). They are able to get away with it because memory only gets shuffled on calls to the memory manager. Relocatable blocks are accessed through a "handle", which is a pointer to a fixed pointer to the block. > Precisely why Mac accesses all pointers (called "handles") through a table > requiring a double indirect access on all pointers. Also, for position > independance during runtime, they limit some code pieces to 32K to allow > branches with 16-bit signed pointers. And people ask why Mac is so slow! The Mac is slow because the resource manager is slow. Also, the Finder does not deal with directories in an efficient manner. When a program actually gets running, the Mac comes out OK. I doubt that 32k code segments have anything to do with it. Also, unlike certain other systems that enforce segmentation, you can have data bigger than 64k. -- Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim ^ ^-- Not ISM780C, ignore the header!
jer@peora.UUCP (J. Eric Roskos) (12/30/85)
> > Also, for position > > independance during runtime, they limit some code pieces to 32K to allow > > branches with 16-bit signed pointers. And people ask why Mac is so slow! > > The Mac is slow because the resource manager is slow. The use of handles probably has very little to do with the slowness of the Mac; the user doesn't have to (usually) access things by handles very often, and the OS routines that do can cache up the handle in an address register. The Mac is perceived to be slow (by users) because someone (no longer with Apple) vehemently insisted on doing disk I/O via old-fashioned timing loops, like in the Apple II, rather than using a separate disk controller. This has other side-effects, too; e.g., losing mouse interrupts while disk I/O is going on. The Mac is so slow because the built-in floppy disk is so slow. If you use a RAM disk, or one of the better-designed hard disks, it's very fast. (I believe, if I'm not mistaken, that the disk I/O routine has to poll the serial ports while disk I/O is going on, also, in order to avoid losing serial interrupts.) [Count this as a comment that should have been in net.os.] "Some times software has to stand on its head to eliminate a chip in the hardware." -- A Mac software designer (I think Andy Hertzfield) -- UUCP: Ofc: jer@peora.UUCP Home: jer@jerpc.CCC.UUCP CCC DNS: peora, pesnta US Mail: MS 795; CONCURRENT Computer Corp. SDC; (A Perkin-Elmer Company) 2486 Sand Lake Road, Orlando, FL 32809-7642
stubbs@ncr-sd.UUCP (Jan Stubbs) (01/03/86)
In article <1880@peora.UUCP> jer@peora.UUCP (J. Eric Roskos) writes: >The Mac is perceived to be slow (by users) because someone (no longer with >Apple) vehemently insisted on doing disk I/O via old-fashioned timing >loops, like in the Apple II, rather than using a separate disk controller. According to several articles I read on the Mac, Steve Wozniak takes credit for this, it saved the price of a disk controller, and allowed different rotation speeds controlled by software depending on whether the track being accessed was inside or outside. This was to equalize the density of information.They called this technique the "Wos Machine". Steve, defend yourself if this isn't true! Jan Stubbs ..sdcsvax!ncr-sd!stubbs Opinions expressed are those of the author. Z