. Writing low- level RISC code for each RISC or very long instruction word (VLIW) pico/microengine is a theoret- ical option, but it has little if any practical value. The task is daunting and the learning curve is very steep since few software engineers are competent enough to perform the task in a reasonable amount of time and with manageable quantities of bugs. As a result, the software will be difficult to maintain and upgrade. This is a huge price to pay just for the pleasure of efficiently utilizing the processing bandwidth of the NPU. On the other hand, high-level languages such as C/C++ which are widely known and used by engineers in the industry, also offer a series of undesirable trade-offs. Traditional CPU devices do not have the specialized network-related machine instructions to per- form the tasks that are required of them. Enhancing the instruction set architecture to tackle wire- speed requirements immediately hampers the chances that an optimizing compiler will be able to use these extensions transparently without the user noticing. It seems that what is gained in programming ease by abstracting away from the hardware is lost in performance-tuning capabilities of the applica- tion software. The following example illustrates the important ramifications of these issues. Before this chapter went to press, IBM announced that its future generations of network processors will be based on engines that take advantage of the PowerPC instruction set, because the proprietary instruction set approach taken by the microengines in the NPUs such as the NP4GS3 seems to have run into a limited time span compared to the widely accepted PowerPC platform for which SO many tools are available. The problem becomes even more interesting when we consider the use of functional or descrip- tive languages in order to perform coding (such as Agere's Functional Programming Language [FPL] and Intel's Network Classification Language [NCL]) as opposed to procedural languages such C/C+ +. However, we will not expand on this issu