Niroshan Rajadurai

Cache Lookup Strategies

Let's say we have a 32KB cache with 32-byte blocks (lines).  This gives us 1024 blocks which can be held in the cache.  When we want to look in the cache to see if a particular block is present, we can use one of 3 basic strategies:

1. look in every one of the 1024 blocks to see if the block's tag matches our access address.  This is known as a "fully-associative" cache, because any block from memory can reside in any block in the cache.
2. use 10 bits of the access address as a selection index to one of the 1024 blocks, then compare that block's tag with our access address. This is known as a "direct-mapped" cache, where a particular block in memory can only go into one particular block in the cache.  All the memory blocks that go to the same cache block are said to be in the same "congruence class".
3. use a fewer number of bits of the access address as a selection index into a "set" of cache blocks, then search each element of that set for a tag match.  This method is somewhere between a) and b), above, and is known as "set-associative".  For example, if I divide the cache up into 128 sets of 8 blocks each, I have an 8-way set-associative cache which is indexed by 7 bits of the access address. A particular block in memory can then go into any of the 8 blocks in its associated set.

The importance of completely testing software applications, and achieving it cost effectively is currently one of the major growth areas in the software development tools industry. There are many tools that offer solutions for automating the unit and unit integration test process for our application code. These tools can parse our code, and from a few simple options automatically create test drivers to stimulate our code under test, and test stubs for our dependencies. While these tools vary in capability and automation, they all offer an improvement on current manual testing processes that are in place.

One of the areas that is relatively poorly understood, and perhaps glossed over in the selection of these tools, is the process they go through to parse the code under test and automatically build the test framework. Every unit test automation tool in the market today needs to parse the source code under test to determine types, and interfaces for functions to be tested, and implement stubs for its dependencies. As a result all of these parsers understand standard C or C++ code, however every compiler not only supports the standard C or C++ language, they have extensions.

TCP/IP networks are rarely homogenous; they usually consist of a wide variety of machines, architectures, and operating systems - each storing binary data in various forms. The actual storage format is transparent as long as you access data locally (i.e., on the same machine). However, you must consider the data storage format differences when transmitting or receiving data across machines and networks.

Any data larger than a single byte can be store its bytes at least two ways: big endian order and little endian order.

One of the challenges with developing software is to know when the software is at a sufficient quality such that we consider it ready to ship to our customers. The only provable way of ensuring that the our software will not contain any defects is to test it. Testing can occur at many stages, it could be unit testing, where we test a single class or source file in isolation to the rest of the system, integration testing, where we test the interaction of several units, while isolating others, or finally system testing where we test all of the software running as the final system. The challenge that software projects are faced with is to know when testing should stop. Is it sufficient to ensure every requirement has been tested?