Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ames!amdahl!amdcad!diablo!phil
From: phil@diablo.amd.com (Phil Ngai)
Newsgroups: comp.arch
Subject: Re: Fast DRAMs and caches (was Re: cache speed)
Message-ID: <27013@amdcad.AMD.COM>
Date: 29 Aug 89 17:59:07 GMT
References: <26964@amdcad.AMD.COM> <1989Aug25.225511.828@mentor.com>
Sender: news@amdcad.AMD.COM
Reply-To: phil@diablo.AMD.COM (Phil Ngai)
Organization: Advanced Micro Devices, Inc. Sunnyvale CA
Lines: 30

In article <1989Aug25.225511.828@mentor.com> mbutts@mentor.com (Mike Butts) writes:
|I take it you are proposing using the VRAM serial port for instruction fetches.
|That would work out fine for linear code sequences, but would cost you a full
|RAM cycle to do a branch.  Delayed branch architectures could mitigate that
|cost somewhat, but it would still cost you.  It's cheaper than a cache, but not
|as fast as a good one. 

We started this discussion by talking about fast DRAMs which
approached the speed of rather fast SRAMs. So if this same high speed
DRAM technology were applied to VRAMs, then your "full RAM cycle
branch" would be comparable to a cache also. 

Also, some processors such as the Am29000 have a special Branch Target
Cache (tm) which further mitigate the cost of branches. 

On the other hand, it might be interesting to apply VRAM technology
to SRAMs...

| Has anyone tried using VRAMs like that in a real system?

Depends on what you mean by "real". If you mean something with as many
applications as a PC, not that I'm aware of. If you mean special boxes
that can run BSD and System V and DOS bridges etc, yes, I've built
hundreds. I'm also aware of other companies that have done so, I'm not
at liberty to talk about them but rumors have already been published
in widely circulated magazines. 

--
Phil Ngai, phil@diablo.amd.com		{uunet,decwrl,ucbvax}!amdcad!phil
"Today surgeons are highly respected but they were once just grave robbers."