dav@abvax.icd.ab.com (Dave A. Vasko) (01/05/89)
Does anyone know of a program to analyze 68020 machine code to determine the number and type of instructions executed ? Please reply by mail. Any help would be appreciated. -- **************************************************************************** * Dave Vasko Allen-Bradley Highland Hts. Ohio 44139 * * (216) 646-4695 ...!{decvax,pyramid,cwjcc,masscomp}!abvax!dav * ****************************************************************************
schmitz@fas.ri.cmu.edu (Donald Schmitz) (01/05/89)
In article <542@abvax.icd.ab.com> dav@abvax.icd.ab.com (Dave A. Vasko) writes: > >Does anyone know of a program to analyze 68020 machine code to determine >the number and type of instructions executed ? Please reply by mail. Any help >would be appreciated. For some reason our news software died trying to reply to you, so I'm posting. One possible solution, if you are running on a dedicated system (no OS), is to write an instruction tracer. This is just an exception handler that looks at the exception frame, figures out which instruction was being executed, and increments an entry in a big array which is indexed by the instruction opcode. I think the 10 MSBs of an opcode are sufficient to determine what a CPU instruction was, but you have to look at part of the second word to figure out a coprocessor instruction. You probably want to detect coprocessor instructions and keep track of these separately, indexing this array with the significant part of the second word. After installing this exception handler, turn on instruction tracing by setting the trace bit in the status register, run the test code, and turn the bit off. Finally, examine the instruction count array and figure out how many of each instruction were executed. This may take a little work, since sometimes only the first few bits specify the instruction, and the rest specify a register or condition code, so for example a seperate count will be kept for each sort of "bcc", and each of the 2^8 variations of "move" that will be detected. When I did this, I was only interested in profiling floating point instructions, which are much more regular to decode. One problem with this, the program will run much slower while tracing, as the CPU traps after EVERY instruction. Also, if the program has the equivalent of system calls, tracing gets turned off when the processor goes into supervisor state, so these instructions don't get counted. By the way, if you find a way to do this on a workstation, or via a program that reads the object file, I'd like to hear about it. Don Schmitz schmitz@fas.ri.cmu.edu --