Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!jarthur!spectre.ccsf.caltech.edu!tybalt.caltech.edu!toddpw
From: toddpw@tybalt.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple
Subject: Re: 65816 as a Harvard machine (was Re: 68000 bits (was Re: Nintendo))
Keywords: Harvard Architecture, CPU, hardware, 65816, caching
Message-ID: <1990Mar10.114250.14719@spectre.ccsf.caltech.edu>
Date: 10 Mar 90 11:42:50 GMT
References: <2482@ttardis.UUCP> <52023@microsoft.UUCP> <1990Mar3.114420.20534@spectre.ccsf.caltech.edu> <1155@madnix.UUCP>
Sender: news@spectre.ccsf.caltech.edu
Organization: California Institute of Technology
Lines: 24

jason@madnix.UUCP (Jason Blochowiak) writes:

>toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes:
>> [Deleted discussion of the '816's ALU size, etc.]
>> Caching direct page on chip and harvard architecturing it with the ALU would
>>be even better.

>	Harvard on an '816? Do you know how many programs that would kill?
>I shudder at the thought... Perhaps a mode for it, but given my (minimal)
>understanding of the matter, that'd be mighty difficult to do. 

>	On-chip caching in basically any form, though, would be great.

I meant harvarding the CACHE with the ALU. As long as you allow the separate I
and D cahces to act like standard memory as well, it breaks nothing and allows
many operations (especially zero page and stack) to execute in parallel, thus
shaving off quite a few cycles on the most commonly used instructions.

Executing code out of the D cache would slow things down, sure, but would be
not be hard to do on chip. (Ok, so the cache coordination could get a bit messy
... It looked like a cheap win if it could be done so I thought I'd mention it.)

Todd Whitesel
toddpw @ tybalt.caltech.edu