 application as macros from an I/O or packet- processing library just to implement the necessary packet-processing functions. This proposition would entail many wasted cycles every time these programs were invoked. In fact, even if the direct cost (in the RISC programmer's time), the indirect cost (in the extra memory foot- print of the embedded implementation), and the inconvenience of writing extra code for these packet-processing functions were discarded, and if the overall problem is considered purely from a performance standpoint, the idea is absolutely unacceptable when confronted with wire-speed pro- cessing requirements. More importantly, however, the MIPS RISC cores are unable to handle multithreading. Every packet being processed is associated with a computational context (thread) that is usually stored in tem- porary locations, which are usually on-chip registers. These contain parameters, return values, and lookup table pointers that associate packets with classification results, stack and heap pointers, timers, counters, and SO on. A certain level of register sets is available inside the network-process- ing chip, but the main execution unit will often require that some overhead be spent before the hard- ware switches context from one thread to another. This implies a waste of clock cycles while the thread is being switched. Some network processors require the programmer to manually insert special instructions to switch the thread context at a specific point in time or under specific conditions. Others automatically switch the thread in one clock cycle even when a thread is simply waiting for data to be fetched from memory. Downloaded from Digital Engineering Library @ McGraw-Hill (www.digitalengineeringlibrary.com) Copyright © 2004 The McGraw-Hill Companies. All rights reserved. Any use is subject to the Terms of Use as given at the website. ALTERNATIVE APPROACHES TO NETWORK PROCESSING: NET ASICS AND DESIGNING WITH IP CORES 164 NETWORK PROCESSORS However, the inability to support multithreading is n