Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!bloom-beacon!mintaka!yale!cs.utexas.edu!wuarchive!decwrl!elroy.jpl.nasa.gov!jarthur!spectre.ccsf.caltech.edu!tybalt.caltech.edu!toddpw
From: toddpw@tybalt.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple
Subject: Re: 68000 bits (was Re: Nintendo)
Message-ID: <1990Mar3.114420.20534@spectre.ccsf.caltech.edu>
Date: 3 Mar 90 11:44:20 GMT
References: <2482@ttardis.UUCP> <52023@microsoft.UUCP>
Sender: news@spectre.ccsf.caltech.edu
Organization: California Institute of Technology
Lines: 22

brianw@microsoft.UUCP (Brian WILLOUGHBY) writes:

>If you look at the 65C816, you'll notice that I said the ALU is 8 bit.
>I believe I read this in Lichty and Eyes _Programming_the_65C816_.
>I would think that a small performance improvement could be made to the
>65C816 by adding a 16 bit ALU and cutting the number of cycles for
>certain operations in half.  With a good pre-fetch queue on the processor,
>you might not need a 16 bit bus to see at least some improvement.

Mensch's data sheet sez that it is 16 bit. The cycles you're talking about
are for indexed operations and it's hard to get around them.

Actually, they could be used for a one byte instruction prefetch. That would
be pretty easy to implement in the ASIC 65816 (in native mode only of course)
and would shave off a few cycles. If they let implied (1 byte) operations only
take 1 cycle then it would also help. Caching direct page on chip and harvard
architecturing it with the ALU would be even better.

The list goes on.

Todd Whitesel
toddpw @ tybalt.caltech.edu