Article-I.D.: fas.212
Posted: Sat Nov 23 00:58:09 1985
Date-Received: Mon, 25-Nov-85 08:02:16 EST
Organization: Carnegie-Mellon University, CS/RI
Lines: 44
Xref: watmath net.micro:12837 net.arch:2170


	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

Article-I.D.: ima.97800009
Posted: Tue Nov 26 12:56:00 1985
Date-Received: Fri, 29-Nov-85 08:50:44 EST
References: <212@fas.UUCP>
Lines: 20
Nf-ID: #R:fas:-21200:ima:97800009:000:1061
Nf-From: ima!johnl    Nov 26 12:56:00 1985


The IBM Instruments CS9000 was a failure, but that has little to do with the
merits of the 68000 chip.  I know people who tried to do software work on the
box, and they all tell me that it's a lousy, amateruish design.  The
peripherals don't work very well, particularly the hard disk.  The standard
operating system they give you is incompatible with anything else.  And it's
expensive.

As I understand it, IBM Instruments was a little lab instrument company in
Danbury CT which IBM bought to dabble in the instrumentation biz.  The CS9000
was originally designed to control gas chromatographs, which it presumably
does OK.  That's why the keyboard was optional but the panel of buttons was
standard.  Then somebody thought it was a general purpose computer, but it's
not -- it's a hack put together by people who build instruments.

My friends express constant amazement that the CS9000 was ever released as a
product, but I guess IBM believes in letting 100 flowers bloom, even though
some of them turn out to be Stinking Lousewort.

John Levine, ima!johnl

Article-I.D.: intelca.147
Posted: Fri Dec  6 19:15:19 1985
Date-Received: Sun, 8-Dec-85 03:23:29 EST
References: <212@fas.ri.cmu.edu>, <702@petrus.UUCP> <6178@utzoo.UUCP>
Organization: Intel, Santa Clara, Ca.
Lines: 27
Xref: watmath net.micro:12988 net.arch:2230

> > 	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

Article-I.D.: ism780c.133
Posted: Tue Dec 10 21:30:48 1985
Date-Received: Sun, 15-Dec-85 06:41:03 EST
References: <212@fas.ri.cmu.edu> <702@petrus.UUCP> <6178@utzoo.UUCP> <147@intelca.UUCP>
Reply-To: tim@ism780c.UUCP (Tim Smith)
Organization: Interactive Systems Corp., Santa Monica, CA
Lines: 34
Xref: watmath net.micro:13076 net.arch:2294

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!

Article-I.D.: peora.1880
Posted: Mon Dec 30 08:31:00 1985
Date-Received: Tue, 31-Dec-85 03:41:18 EST
References: <212@fas.ri.cmu.edu> <702@petrus.UUCP> <6178@utzoo.UUCP> <147@intelca.UUCP> <133@ism780c.UUCP>
Organization: CONCURRENT Computer SDC, Orlando, Fl.
Lines: 28
Xref: watmath net.micro:13317 net.arch:2364

> > 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

Article-I.D.: ncr-sd.382
Posted: Thu Jan  2 16:30:42 1986
Date-Received: Fri, 3-Jan-86 02:03:56 EST
Reply-To: stubbs@ncr-sd.UUCP (0000-Jan Stubbs)
Distribution: net
Organization: NCR Corporation, San Diego
Lines: 17
Xref: watmath net.micro:13348 net.arch:2372

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