home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!ogicse!uwm.edu!cs.utexas.edu!devnull!rrt
- From: rrt@mpd.tandem.com (Robert Teisberg)
- Newsgroups: comp.arch
- Subject: Re: CISC Microcode (was Re: RISC Mainframe)
- Message-ID: <2105@devnull.mpd.tandem.com>
- Date: 23 Jul 92 15:09:27 GMT
- Article-I.D.: devnull.2105
- References: <BrM8Gv.E3r@zoo.toronto.edu> <ADAMS.92Jul21011202@PDV2.pdv2.fmr.maschinenbau.th-darmstadt.de> <Brsx7o.G69@zoo.toronto.edu> <2369@nic.cerf.net>
- Sender: news@devnull.mpd.tandem.com
- Reply-To: rrt@amadeus.UUCP (Robert Teisberg)
- Organization: /etc/organization
- Lines: 23
-
- In article <2369@nic.cerf.net> davsmith@nic.cerf.net (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.
-
- The CDC 6600 and its descendants did this (why does it seem that every
- clever idea in machine architecture was invented many years ago by
- Seymour Cray :-). To load from memory, you stuffed an address in
- register A1, A2, A3, A4 or A5 and sometime later the contents of that
- address appeared in the corresponding X register. To store, you
- stuffed an address in A6 or A7 and eventually the contents of X6 or X7
- found its way to memory at that address. As I recall (do any other
- old CDC hands know better?), the only reason the CPU stalled due to
- memory access was a scoreboard conflict or a memory bank conflict. If
- your memory access pattern was either sequential and contiguous or
- random, bank conflicts were rare, since the 6600 used interleaved
- memory just as davsmith recommends elsewhere in his article.
-
- --
- Bob Teisberg @ Tandem Computers, Inc. | rrt@mpd.tandem.com
- 14231 Tandem Blvd. | (512) 244-8119
- Austin, Texas 78728 |
- Any resemblance to the opinions of a real person or corporation is concidental.
-