The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: peter@rulingia.com (Peter Jeremy)
Subject: [TUHS] Bryan Cantrill on bfs & ta
Date: Sat, 20 Oct 2012 09:13:14 +1100	[thread overview]
Message-ID: <20121019221314.GR33428@server.rulingia.com> (raw)
In-Reply-To: <20121019205428.GD6410@mercury.ccil.org>

On 2012-Oct-19 15:44:27 -0500, Clem Cole <clemc at ccc.com> wrote:
>the 68000 and 68010 were 16 bit internals.

It depends whether you are talking implementation or architecture.
The M68000 architecture was basically 32 bits (Motorola initially
skimped on the multiply & divide instructions and referred to it as a
"16-/32-bit architecture"), though the initial implementation used a
16-bit ALU.

To go back further, the IBM System/360 was a 32-bit architecture but
the low-end implementation (360/20) only had 8-bit wide memory and an
8-bit wide ALU and there was also a 16-bit wide implementation.

>the external logic (ie pins) supported 24 bits of address.  moto
>fortunately passed all 32 bits along on the first chip and onto
>storage (thank you Les & Nick) so when later versions had a full 32
>bit shifter everything just worked.

They clearly defined that the programmer's view was a 32-bit address
but some implementations didn't map all the address bits onto pins.
Note that this approach of only physically implementing a subset of
the address bus has continued into the 64-bit chips - most chips only
have 36-40 physical address bits and 40-48 logical address bits.
(Though one big difference is that the unimplemented address bits are
validated instead of ignored).

>PPS. we relived this whole argument with 64 bits and it was
>interesting that we generally came to think LP64 made more sense for
>chips like Alpha

I think a lot of this was also driven by the large amount of software
that was ILP32.  Converting int from 32- to 64-bits would add a lot
of pain for very little benefit.  Just making code work with LP64 was
painful enough.

On 2012-Oct-19 16:54:28 -0400, John Cowan <cowan at mercury.ccil.org> wrote:
>Sounds like the 8088, which used an 8-bit bus but 16-bit registers
>and operations.

The 8088 and 68008 were basically 8086/68000 chips with reworked bus
interface logic so that the external data bus was only 8-bit (and the
68008 also cut the address bus from 24- to 20-bits).  Other than being
slower, they appeared the same as their 16-bit cousins.  They were
aimed at applications where price was more important than performance:
Using the 8088 meant that IBM only needed 8 64Kx1 DRAM chips and the
68008 used a much smaller and cheaper 40-pin DIP instead of the 64-pin
DIP needed for the 68000.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20121020/14da205c/attachment.sig>


  reply	other threads:[~2012-10-19 22:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-18 22:51 Sevan / Venture37
2012-10-18 23:40 ` Greg 'groggy' Lehey
2012-10-19 20:44   ` Clem Cole
2012-10-19 20:54     ` John Cowan
2012-10-19 22:13       ` Peter Jeremy [this message]
2012-10-22  0:33 ` Larry McVoy
2012-10-22 13:01   ` A. P. Garcia
2012-10-22 13:34     ` Larry McVoy
2012-10-22 14:05       ` A. P. Garcia
2012-10-22 14:13         ` Larry McVoy
2012-10-22 14:17           ` A. P. Garcia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121019221314.GR33428@server.rulingia.com \
    --to=peter@rulingia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).