Xref: utzoo alt.religion.computers:1198 comp.sys.mac.programmer:11351
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!cs.utexas.edu!sun-barr!lll-winken!ubvax!fred
From: fred@ubvax.UB.Com (Fred Noon)
Newsgroups: alt.religion.computers,comp.sys.mac.programmer
Subject: Re: The 80486 is braindead (was Re: Xerox sues Apple!!!)
Summary: Apple ignores 68000
Keywords: Apple 68000 TAS
Message-ID: <25347@ubvax.UB.Com>
Date: 22 Dec 89 00:17:15 GMT
References: <14960@boulder.Colorado.EDU> <213@amix.commodore.com>
Reply-To: fred@ubvax.ub.com.UUCP (Fredrik Noon)
Organization: Ungermann-Bass Enterprises
Lines: 20

As a programmer, I am more fond of the 68k architecture.  Unfortunately,
Apple seems never to have thought of its main chip as being in any way
a competitive advantage.  After IBM PC compilers had broken the 64k
data segment/array size barrier with the various memory models, and
folks were hard at work breaking the 640k application memory barrier,
Apple was selling 128/512k 68000 machines whose resource loader limited
the first compilers to 32k arrays, etc.  I beleive that I have my
chronology right here, but the point is that Apple thought nothing of
coming up with a resource manager that could only handle 32k (which
has, after customer complaint, been fixed).

A more annoying deficiency (as it will be with us for a while) is that
Apple castrated the 68k test-and-set instruction after the Mac+.  It
expects fancier software (e.g., System 7) to run on the strength of MHz
and MMUs alone?  Not all Macs have the latter, but I know of no good
reason why all Macs can't execute a TAS anymore (can somebody else?).

I wish Apple appreciated the building blocks they have (or have had
and have squandered) instead of trying to fix everyone up with
CAD stations and multi-media spreadsheet servers.