When you add an I-cache (the docs say nothing of specific implemtations
yet) things will get even faster (but they also change a bit - it's no
longer quicker to blow through a 12 instruction stream). I can't see any
reason that a multi-unit processor would come into existance any time
soon. It basicly defeats the purpose of the architecture which is to get
_away_ from superscalar processors and put the parallelism work into the
compiler.
-Rob
On Sun, 6 Jun 1999, Matti Aarnio wrote:
> Date: Sun, 6 Jun 1999 19:21:35 +0300
> From: Matti Aarnio <matti.aarnio@sonera.fi>
> To: David S. Miller <davem@redhat.com>
> Cc: linux-kernel@vger.rutgers.edu
> Subject: Re: EPIC
>
> On Sun, Jun 06, 1999 at 09:08:28AM -0700, David S. Miller wrote:
> > You have precluded the possibility of dispatching multiple bundles per
> > clock cycle, and I am rather sure this will be a characteristic of
> > various EPIC processors. ...
>
> 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.
>
> Definitely not cheap systems.
>
> > Later,
> > David S. Miller
> > davem@redhat.com
>
> /Matti Aarnio <matti.aarnio@sonera.fi>
>
> -
> 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/
>
-
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/