NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/arch/8234

Text File | 1992-07-23 | 2.9 KB | 52 lines

Newsgroups: comp.arch
Path: sparky!uunet!cs.utexas.edu!torn!utzoo!henry
From: [e-mail] (Henry Spencer)
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Message-ID: <[e-mail]>
Date: Thu, 23 Jul 1992 17:42:13 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: U of Toronto Zoology
Lines: 41

In article <[e-mail]> [e-mail] (David Smith) writes:
>All CPUs I have seen to date (not every CPU by any means - if you know
>of counter examples, please post) cannot do asynchronous address
>generation.  When they request a word of memory they want it *NOW* or
>within a cycle or two and will block until it arrives...

Uh, you are very much behind the times.  Few modern CPUs will block waiting
for a memory access unless/until they actually need the data.  Admittedly,
a lot of them can't initiate another memory access meanwhile -- or at
least, another data access -- but some can, and buses that support multiple
simultaneous memory transactions are old news.  The SBI bus on the VAX 780
could do this, for example.

Moving back to the global issue, it's trivially obvious that you can always
build a memory system that a given CPU can't use fully, just by stacking up
more and more parallelism in the memory.  But next year's CPU will go a
long way toward catching up with your memory, and parallelism is expensive.
You don't normally spend lots of money just to justify a pre-established
decision to include a DMA box.  You buy memory bandwidth to meet your needs.
My contention is that making all of it available to your CPU, and choosing
a CPU that can use all of it, tends to leave no room for a DMA box to be
cost-effective... unless you've got response-time constraints (my item 3)
that the CPU can't conveniently meet.

>Caches on interleaved memory systems can do pre-fetching, however there
>is a trade-off that must be made between pre-fetching too little and
>too much.  Caches tend to fetch in blocks so the start-up latency is
>spread across a number of words, but the size of the block must be
>large to make the latency cost trivial.  There are a number of problems
>with fetching large blocks.  Thus, it is difficult to get full bandwidth
>out of an interleaved memory system while going through the cache.

No, it is difficult to get full bandwidth out of an interleaved memory
system while going through an *uninformed* cache.  There is no reason
the cache can't vary its fetch size depending on the requirement.
Fetching too much is not an issue if you know how much you'll want
and can communicate this to the cache.  Simply telling it "normal" or
"bulk transfer" ought to be adequate.
--
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  [e-mail]  utzoo!henry