Messages in this thread |  | | Date | Sun, 6 Jun 1999 09:31:55 -0700 | | From | "David S. Miller" <> | | Subject | Re: EPIC |
| |
Date: Sun, 6 Jun 1999 19:21:35 +0300 From: Matti Aarnio <matti.aarnio@sonera.fi>
You are right, but lets see; presumed 1 clock per bundle (or multiple bundles) means the instruction stream must be at least 16 bytes wide, and if two bundles at the time are to be executed, 32 byte memory read width is needed. Gee, that is quite a monster..
Of course having wide cache-cpu bus does not mandate as wide main-memory interface.
Correct, and even dumb UltraSparc provides similar bandwidth.
UltraSparc can inject 16-bytes per clock into the instruction prefetcher, which equals or exceeds the bandwidth of the pipeline (which is 4x4byte instructions max dispatched per clock).
I am sure they will tune EPIC chips in a similar manner, such that instruction cache bandwidth on hits is enough to prevent dispatch starvation.
Thus, if the UltraSparc I-cache has been pushing 16bytes per clock for a few years now, I am very sure 32bytes per clock from some cpu vendor is just around the corner. :-)
Later, David S. Miller davem@redhat.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
|  |