home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!mcsun!Germany.EU.net!nixpbe!uranium!uranium!not-for-mail
- From: Josef Moellers <mollers.pad@sni.de>
- Newsgroups: sci.electronics
- Subject: Re: 68000 and Cache?
- Date: 10 Nov 1992 09:48:47 +0100
- Organization: Siemens Nixdorf Informationssysteme AG, Paderborn, Germany
- Lines: 32
- Sender: josef@uranium.sto.pdb.sni.de
- Message-ID: <1dnt1fINNk0f@uranium.sto.pdb.sni.de>
- References: <1992Nov6.225506.1973@nntp.hut.fi>
- Keywords: 68000
-
- In <1992Nov6.225506.1973@nntp.hut.fi> sakaria@vipunen.hut.fi (Sakari Aaltonen) writes:
-
- >Several accelerator boards with cache RAM are available for Atari ST
- >computers that use the 68000 processor. As the 68000 doesn't seem to
- >have any provision for a cache, I've been idly wondering how the cache
- >is implemented.
-
- >Does anyone have an idea?
-
- You don't need any provisions for a cache, i.e. none in particular.
- All You need is a means to temporarily suspend operation of the CPU
- while You process a cache miss.
-
- Obviously a mechanism like this already exists, otherwise the CPU would
- run a full speed and there is no need for a cache.
- Usually, a special input to the CPU signals whether the CPU should
- suspend operation (WAIT).
- With MC68Ks it's done sort of the other way round: The CPU _will_
- suspend operation _until_ a certain signal is asserted (DTACK).
-
- The cache is placed between the CPU and main memory.
-
- If the CPU accesses a location, the cache decides whether it holds this
- information
- If the information is not in the cache, the cache fetches the
- information (and more, depending on the cache line size).
- Now the information is in the cache and so the cache hands it to the CPU
- and asserts DTACK.
- --
- | Josef Moellers | c/o Siemens Nixdorf Informationssysteme AG |
- | USA: mollers.pad@sni-usa.com | Abt. STO-XS 113 | Riemekestrasse |
- | !USA: mollers.pad@sni.de | Phone: (+49) 5251 835124 | D-4790 Paderborn |
-