Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!bbn!bbn.com!slackey
From: slackey@bbn.com (Stan Lackey)
Newsgroups: comp.arch
Subject: Re: 68000 architecture
Message-ID: <40938@bbn.COM>
Date: 5 Jun 89 17:41:28 GMT
References: <1989May30.171335.473@utzoo.uucp> <658@geovision.UUCP>
Sender: news@bbn.COM
Reply-To: slackey@BBN.COM (Stan Lackey)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 30

In article <658@geovision.UUCP> gd@geovision.UUCP (Gord Deinstadt) writes:
>In article <1989May30.171335.473@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>>
>>Just to be heretical, one can observe that the same thing is true of
>>addresses.  You can run the 68k family with 16-bit addresses (although
>>they have to be *signed* 16-bit addresses!).
>
>Can anyone tell my why Motorola did such a twisted, sick thing?

I suspect that the reason 16-bit absolute addresses are signed is
because all instruction stream data is sign extended, and the
designers figured that 32Kbytes of scalar addressing was enough
anyway, so why make an exception for addresses.

The reason for the 16-bit absolute addressing mode was because in
1977? when the 68000 was designed, 1) people cared about the amount of
memory their application needed, and 2) lots and lots of applications
used less than 32K bytes for scalar data.  Also, it read the
instruction stream in 16-bit hunks, and a 16-bit quantity took only
one memory cycle whereas a full 32-bit address would take two.  The
68000 was the next generation after the 6800/6809 8-bitters, and was
influenced much by the embedded controller market.  Here, the program
was typically in ROM, and only data was in RAM.  I would bet that
Motorola was pleasantly surprised by how well the chip caught on in
the (then nonexistant) workstation business.

I feel that including 32-bit features at all showed great insight by
its designers, and I also feel that the 68000 family was partially
responsible for the emergence of the workstation as a market entity.
-SAL