Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!ccut!wnoc-tyo-news!cs.titech!titccy.cc.titech!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.arch
Subject: Re: endian etc
Message-ID: <199@titccy.cc.titech.ac.jp>
Date: 17 May 91 03:41:05 GMT
References: <186@titccy.cc.titech.ac.jp> <173@armltd.uucp>
Sender: news@titccy.cc.titech.ac.jp
Distribution: comp
Organization: Tokyo Institute of Technology
Lines: 40

In article <173@armltd.uucp> abaum (Allen Baum) writes:

>>>As a sweeping generalization, the path from cache to registers/forwarding
>>>path is THE critical path
>>>wrong, or have a CISC architecture)

First, I have noticed that R3000 has LWL and LWR instruction which means
MUX of arbitrary flipping of bytes already exists on your "THE ciritical
path".

So, comments below has nothing to do with endian.

>>No. THE critical path is on register/ALU loop, which determines the maximuum
>>clock speed (see Jouppi).

>So, another way of saying what I meant to say is: if both ALU and Cache access
>are going to fit into a cycle, the cache access will be the limiting case.

I think cache access is much slower than ALU operation.

>Perhaps not true with a trivial cache, but true for sizes that are useful.

Are you sure?

Don't you know that access time increases with the size increase of cache?

It should also be noted that for a large cache to be useful (fast context
switch etc.), it should be tagged with physical address. So, you must also
do TLB lookup.

For example, on R4000, an ALU operation takes only 1 internal cycle
(10ns) but cache access takes three internal cycle including tag check.

>Again, assuming that you intend everything to run in a single cycle, anything
>that you put into that path will therefore lengthen your minimum cycle time.
>Which was the point I was trying to make about sign extension.

With todays technology, it is a bad idea to access cache in a single cycle.

							Masataka Ohta