Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ukma!usenet.ins.cwru.edu!tut.cis.ohio-state.edu!sei.cmu.edu!firth
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.arch
Subject: Re: Low End NeXTs (was Re: Desktop publishing)
Message-ID: <23724@as0c.sei.cmu.edu>
Date: 7 Apr 91 19:44:36 GMT
References: <27fa3350.6bc2@petunia.CalPoly.EDU> <1991Apr03.232400.1560@kithrup.COM> <1991Apr4.125122.1@capd.jhuapl.edu> <1991Apr5.172533.6717@agate.berkeley.edu> <1991Apr7.065105.25586@zoo.toronto.edu>
Reply-To: firth@sei.cmu.edu (Robert Firth)
Organization: Software Engineering Institute, Pittsburgh, PA
Lines: 11

In article <1991Apr7.065105.25586@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:

>Actually, on the 040, by the published descriptions, the situation is very
>simple:  the 68000 subset, plus 32-bit absolute addresses, minus indexed
>addressing, is fast.  Everything else -- all the goo the 020 added -- is slow.

My rough calculations (again, based on the documentation) agree with
Henry's.  As with the 68020, the indexed address modes are on balance
slower than the equivalent naive code using only the 68000 address
modes.  Once in a while, you'll be able to avoid an extra register
save and restore, for a marginal gain; but in general, forget them.