jason@madnix.UUCP (Jason Blochowiak) (03/10/90)
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. >Todd Whitesel >toddpw @ tybalt.caltech.edu -- Jason Blochowiak - jason@madnix.UUCP or, try: astroatc!nicmad!madnix!jason@spool.cs.wisc.edu "Education, like neurosis, begins at home." - Milton R. Saperstein
toddpw@tybalt.caltech.edu (Todd P. Whitesel) (03/10/90)
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