Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!amdcad!crackle!tim
From: tim@crackle.amd.com (Tim Olson)
Newsgroups: comp.arch
Subject: Re: Intel/MIPS Dhrystone ratio
Message-ID: <24889@amdcad.AMD.COM>
Date: 17 Mar 89 16:39:54 GMT
References: <1552@vicom.COM> <15690@cup.portal.com> <1562@vicom.COM> <37196@bbn.COM> <1989Mar16.190043.23227@utzoo.uucp>
Sender: news@amdcad.AMD.COM
Reply-To: tim@amd.com (Tim Olson)
Organization: Advanced Micro Devices, Inc. Sunnyvale CA
Lines: 47
Summary:
Expires:
Sender:
Followup-To:

In article <1989Mar16.190043.23227@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
| In article <37196@bbn.COM> slackey@BBN.COM (Stan Lackey) writes:
| >I predict that the next hardware features to come back will be
| >auto-increment addressing and the hardware handling of unaligned data.
| 
| Again, why?  Auto-increment addressing is useful only if instructions
| are expensive, because it sneaks two instructions into one.  However,
| the trend today is just the opposite:  the CPUs are outrunning the
| main memory.  Since instructions can be cached fairly effectively,
| they are getting cheaper and data is getting more expensive.  Doing
| the increment by hand often costs you almost nothing, because it can
| be hidden in the delay slot(s) of the memory access.  Autoincrement
| showed up best in tight loops, exactly where effective caching can be
| expected to largely eliminate memory accesses for instructions.  Why
| bother with autoincrement?

Also, auto-incrementing addressing modes imply:

	- Another adder (to increment the address register in parallel)

	- Another writeback port to the register file

Unless you wish to sequence the instruction over multiple cycles :-(

I'm certain that most people can find something better to do with these
resources than auto-increment. 


| As for hardware handling of unaligned data, this is purely a concession
| to slovenly programmers.  Those of us who have lived with alignment
| restrictions all our professional lives somehow don't find them a problem.
| Mips has done this right:  the *compilers* will emit code for unaligned
| accesses if you ask them to, which takes care of the bad programs, while
| the *machine* requires alignment.  High performance has always required
| alignment, even on machines whose hardware hid the alignment rules.
| Again, why bother doing it in hardware?

The R2000/R3000 can also trap unaligned accesses and fix them up in a
trap handler.  This is what the Am29000 does, as well.  This is mainly a
backwards compatibility problem (FORTRAN equivalences, etc.) It is
infrequent in newer code, mainly appearing in things like packed data
structures in communication protocols.


	-- Tim Olson
	Advanced Micro Devices
	(tim@amd.com)