Newsgroups: comp.arch
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: Intel/MIPS Dhrystone ratio
Message-ID: <1989Mar16.190043.23227@utzoo.uucp>
Organization: U of Toronto Zoology
References: <1552@vicom.COM> <15690@cup.portal.com> <1562@vicom.COM> <37196@bbn.COM>
Date: Thu, 16 Mar 89 19:00:43 GMT

In article <37196@bbn.COM> slackey@BBN.COM (Stan Lackey) writes:
>The trend in computer evolution is truly toward greater hardware
>complexity.  This has been demonstrated countless times.  The
>reversion back to too much simplicity did happen in the late 70's, but
>here we are again, back on the same curve...

Except, this time the complexity added will be *useful* complexity, with
any luck.  No, we are not headed back towards CISC.

>... The million transistors will NOT be used entirely for
>large caches, but for more instructions, addressing modes, faster
>floating point, elegant exception handling, etc...

Faster floating pooint, okay.  More instructions and addressing modes?
*Why?*  They don't gain you anything, unless you start talking about
VLIW or other such significant departures.  Elegant exception handling?
Frankly, the relatively simple exception handling on many of the current
RISCS is much more elegant than all the garbage that showed up on the
CISC machines.

>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?

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?
-- 
Welcome to Mars!  Your         |     Henry Spencer at U of Toronto Zoology
passport and visa, comrade?    | uunet!attcan!utzoo!henry henry@zoo.toronto.edu