Dr. Dobb's Journal August, 2004
More readTSC Optimization
Dear DDJ,
Tim Kientzle's fascinating article "Optimization Techniques" (DDJ, May 2004) contains a rather complicated definition for readTSC() in GCC. The simple way to do it in GCC is:
inline long long readTSC(void)
{
long long result;
__asm__ volatile ("rdtsc" : "=A"(result));
return result;
}
(Of course, you may as well use "inline" here because there's no point in making a call to a single-instruction subroutine!)
The "=A" constraint tells GCC that the result is returned in EDX:EAX, as per the GCC documentation for machine constraints:
"A" specifies the "a" or "d" registers. This is primarily useful for 64-bit integer values (when in 32-bit mode) intended to be returned with the "d" register holding the most significant bits and the "a" register holding the least-significant bits.
The volatile is essential because it tells GCC that the result might change; without this, GCC may only invoke readTSC() once.
Andrew Haley
aphgcc.gnu.org
Editor's Note: Also, see Mark Rustad's letter in DDJ, July 2004.
Bugs Aren't a Laughing Matter
Dear DDJ,
In regard to Jonathan Erickson's May 2004 "Editorial," it is worth noting that software bugs are a serious problem. After all, the lead systems programmer at Warner Brothers ("bugs" Bunny) was continually asking, "What's up, doc?".
On a more serious note, bugs can be extremely expensive. I worked on two embedded systems projects (to produce new hardware and the software to run it) that failed. On one, the software was the primary cause of failure. On the other, both hardware and software were faulty. Both projects burned more than $35 million in funding. On both projects, management wanted to "get it out the door" as soon as it was "good enough," in the face of efforts by several technical people to get support for correcting the faults.
Nevertheless, I do not consider management to be the sole cause of the failures. We do not live in a culture that values pride of workmanship. Technical people are still able to do reliable work, but their managers are sometimes under great pressure to cut corners, particularly when mistakes have been made early in a project.
So, we need tools that reduce the cost of checking our work, but we also need to recognize the primary guarantee of high quality: the pride of the builders.
Ian Gorman
http://www.gorman.ca/
Mtlib Library
Dear DDJ,
It seems that everything old is new again. The technique described by Marco Tabini in "The Mtlib Memory-Tracking Library" (DDJ, October 2003) has been around in various guises for as long as memory has been allocated. It's a worthwhile technique, though, so it certainly is worth introducing to a new generation of programmers.
Marco is correct in identifying the process of hijacking memory-management calls as the core problem. In the "good" old days we had access to source of everything, so it was easy to modify the routines. These days, it's not so simple, but there are a few alternative techniques and considerations that can be useful.
The most valuable is the direct editing of object code and libraries. It is possible, with a suitable binary editor, to rename pretty much anything known externally. When doing this, you must follow the simple rule that you can replace characters in a name, but never add or delete them: The new name must be the same length as the old. Renaming things this way opens up interesting possibilities: You can substitute your own memory-allocation routines for those in a third-party library, particularly useful when a vendor's code has bugs. You can build a replacement for the standard library that uses your own functions for all memory allocation, by changing the library's names for those functions and supplying your own to the linker. (Contrary to Marco's assertion, it is often useful to have access to all memory allocation in a program, not just what takes place in a specific block of code.)
An unrelated technique that is commonly used with debugging-version memory-allocation routines is to add checks for overruns or uninitialized data bugs. A simple approach is to bracket each allocated block of memory with additional bytes initialized to some known but uncommon value. When the memory is released (or more often) a check is made to see that the values have not been changed. Allocation routines can also initialize allocated memory to a different uncommon value, or a random number, to detect the use of uninitialized memory.
Implicit in this is the concept of allocating more memory than was requested for use by the debugging routines. Doing so removes the need to build structures to save debugging information and opens the door for all sorts of interesting techniques.
Jim Connell
jimconnellaol.com
Broader C++ Compiler Coverage
Dear DDJ,
In the article "C/C++ Compiler Optimization" (DDJ, May 2004), Matthew Wilson compares the optimization for different C/C++ compilers. However, he didn't include the C/C++ compilers on UNIX platforms, such as xlC for AIX, aCC for HP-UX, and the C/C++ compiler with Sun Forte for Solaris. Many programmers develop software on UNIX platforms and, therefore, cannot benefit from Matthew's article.
Reza Asghari
reza_asghariyahoo.com
Matthew responds: Thanks for taking the time to write Reza. The simple answer is that the only UNIX flavor I currently have access to is Linux and I only have two compilers—GCC and Intel—for that platform. Wouldn't be much of a story, would it? I'd love to be able to get hold of other compilers on other platforms, but most people these days seem circumspect about allowing any remote access into their systems.
Simulation versus the Real Deal
Dear DDJ,
Jerry Pournelle's column "Simulation & Modeling" (DDJ, April 2004) correctly shows the weaknesses of computer simulations. However, I think he misses one important difference between climate and football-match simulations: If a football simulation results in a slight hint towards an expected outcome of a match, we can safely ignore it. It won't cause much damage if the match will, in reality, end this or the other way. But if several climate simulations give us a hint that not reducing our CO2 emissions may have fatal consequences for life on earth, we might better be careful and take precautions, just to be sure to prevent the possible (though not sure) catastrophic ending that the simulations predict.
Manfred Keul
mkkeullabs.de
DDJ