There is one school that answers with a resounding "no." According to this argument, CPU architects are so far into the realm of diminishing returns that they have ceased to make meaningful improvements in performance. One instruction set performs just about as well as another on the vast majority of applications. So there is no compelling reason to switch from one brand of CPU to another, particularly if you have a substantial investment in code for one particular CPU.

Some designers take the argument even further. They say that not only are instruction sets pretty much irrelevant, but even implementations don't matter that much. Wait a minute, I hear you saying ... you can't claim that a six-issue superscalar CPU running at a zillion megaHertz is just the same as a little 200 MHz scalar processor. Well, actually on many applications designers claim exactly that.

It's not a question of peak instruction throughput. Obviously six times one-zillion is a lot bigger number than 200 million. But in real applications, performance comes from the interaction of CPU core, caches, memory and peripherals. Often an application is entirely dominated by memory or disk latency. One of Gordon Moore's more succinct comments on the subject is telling; he complained once during an interview that no matter how much faster Intel made the Pentium run, each succeeding generation of Windows PCs booted more slowly than the last.

So can we all save a lot of time by just continuing to use whatever CPU core we used last time? Not so fast, says another school. It surely can't be in vain that an entire industry has sprung up to bring new alternatives to CPU architecture. There are configurable CPUs that allow you to manipulate register depths or data path widths. There are systems that let you add custom instructions. There are VLIW processors that arm you with dozens of specialized execution units to overwhelm your media processing or DSP tasks. And there are dynamically reconfigurable processors that promise to adapt, chameleon-like, to the needs of any particular task and data set.

All of these approaches are based on the irrefutable observation that, if the algorithm will just hold still, dedicated hardware will always be faster than programmable hardware. And often, in the embedded computing world at least, the application will hold still. As Keith Diefendorff, long-time architecture guru and recently chosen vice president of product strategy at MIPS, puts it, ''There is no question that things can be done on top of an existing architecture that make a huge difference in performance on specific tasks.''

Examples of such tasks from current practice include fast-Fourier transforms for signal processing, table lookups for packet switching, and polynomial arithmetic for encryption. There's no doubt at all that dedicated hardware can go much faster than any vanilla instruction set.

The question, according to Diefendorff, is how far to go with the customization. Inside some forthcoming wireless networking chips we will see whole FFT engines hard-wired to implement the modulation scheme. Increasingly, data-plane chips for packet switching are using dedicated, custom engines for table look-up and queue management. But the further down that road the architect goes, the deeper he gets into issues of adaptability and supportability.

Alternatively, Diefendorff argues, a little analysis will often indicate that a particular complex operation or inner loop can be hard-wired, and this custom hardware can be layered on top of an existing CPU. Not surprisingly, Diefendorff argues in favor of the MIPS architecture, claiming that its cleanliness -- admittedly a hard attribute to quantify -- makes the design of the additional hardware much easier.

So how much custom hardware do you actually need, and how much good old fashioned CPU horsepower? The extremes -- a full-custom compute engine or doing everything in software on an off-the-shelf microprocessor -- are easy to define and evaluate. But the vast expanse in between is the domain in which the art of architecture still flourishes.

In future columns, I hope to explore more of the shifting terrain of system architecture. I will look at how increasing silicon capability, new ideas and the trend toward system-level IC design are changing the structure of modern designs, and how those changes are reflected in implementations.

Ron Wilson is editorial director of ISD Magazine and a contributor to EE Times. He has covered chip-related matters for 15 years for various industry publications, and was once, in the distant past, a designer himself.