Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!umich!yale!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!gillies
From: gillies@m.cs.uiuc.edu
Newsgroups: comp.arch
Subject: Re: Compiler Costs
Message-ID: <3300143@m.cs.uiuc.edu>
Date: 7 Jul 90 13:36:00 GMT
References: <1797@apctrc.UUCP>
Lines: 15
Nf-ID: #R:apctrc.UUCP:1797:m.cs.uiuc.edu:3300143:000:790
Nf-From: m.cs.uiuc.edu!gillies    Jul  7 08:36:00 1990


It can be hard to find a speedup on CISC machines, since cacheing,
alignment, scoreboarding, and even paging effects may be hard to
predict.  For instance, the Motorola 68020 Manual admits that you can
only hand-wave guesses at the execution time of an instruction stream
-- this forces the dedicated tuner to run hoardes of benchmarks.

This is my greatest complaint about CISC architecture -- from an
optimization standpoint, I sneer religiously at nondeterministic
low-level hardware hacks in high-performance computer design (I don't
even like caches, scoreboards, or paging -- they're just fads).

Maybe it's because I think all future computers should run real-time
operating systems, and because I do research in real-time system
scheduling and optimization, that I hold these views.