Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!apple!vsi1!daver!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: How to use silicon (was Re: Intel/MIPS Dhrystone ratio) Message-ID: <15693@winchester.mips.COM> Date: 22 Mar 89 07:06:44 GMT References: <37196@bbn.COM> <1989Mar16.190043.23227@utzoo.uucp> <24889@amdcad.AMD.COM> <355@bnr-fos.UUCP> <1989Mar21.194914.3284@utzoo.uucp> Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 28 In article <1989Mar21.194914.3284@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: ... >Autoincrement addressing modes simply aren't a worthwhile investment. Really, this isn't an absolutely obvious conclusion. There are certainly intruction encodings, pipelines, register file designs where the incremental cost of this might be almost zero, in which case one would certainly put it in. Of course, there might be later implementations where you'd be sorry. It's just like anything else: you have to simulate it and see if the cost is worth it. Depending on what you already have, it might or might not be worth it. At least HP thought it was OK, I think (HP PA). ... >>Having the H/W be tolerant of alignment means a lot of flexibility in the >>design trade-off. ... >It's just as easy to have the software cope with it (either directly or >via the compiler generating special code) in the rare cases where it is >needed. This lets occasional needy software use it, *without* investing >any hardware complexity in it. The alignment issue is MUCH nastier and more impactful on a design than auto-increment because it's much more likely to complexify critical paths, the pipeline, and the cache design. (Yes, we certainly prefer to provide a few primitives and let the software do it!) -- -john mashey DISCLAIMER: UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086