Subversion Repositories or2k

                        Instruction analysis program

This application reads in a binary list of instructions, and analyses it with a
set of functions looking at various parameters in each instruction.

Right now it's not so user friendly. Everything is hardcoded, and only support
for the OR1K instruction set exists.

It has been written in a way that should allow other instructinos to be added
easily. It remains to be seen how much would be reusable between the sets but
for now, at least it would be easy enough to take the OR1K instruction 
analysis functions and drop in a different instruction set.

The types of information given for OR1K instruction analysis is instruction
frequency, immediate frequency for each instruction, branch distance value
frequency, and register usage frequency. For each instruction, the most common
n-tuple sets of instructions, finishing with that instruction, are presented, 
for pairs, triples and quadruples. Additionally output is the most common
overall n-tuples.

Compile the program with:

$ make all

And run a test (it needs the or32-elf- toolchain) with:

$ make test

Static analysis:

To generate a raw binary representation of the instructions that end up in
something like the Linux kernel, take the ELF file that results from compilation
and pass it to or32-elf-objcopy like the following:

$ or32-elf-objcopy -O binary -j .text -S vmlinux vmlinux.text.bin

Use the -f flag to indicate the input file, and -o to indicate the output file.

$ ./insnanalysis -f vmlinux.text.bin o vmlinux.insnanalysis

Dynamic analysis with binary execution log from or1ksim:

As of revision 202 of the OpenRISC repository, or1ksim is capable of generating
an execution trace log in binary format, logging each instruction executed. 
This log file can be given to insnanalysis.

In the or1ksim config file ensure the line "exe_bin_insn_log = 1" is in the 
sim section. This will enable the binary instruction logging. The resulting
output file is then given to insnanalysis in the same manner as above.

Output:

Currently there are only two output formats, human readable string and CSV.

The output can be switched between human readable strings and CSV format (ready
to be imported into a spreadsheet application) by uncommenting one of  the 
"#define DISPLAY_" defines in the instruction set header. The program must be
recompiled if this is changed.

Individual instruction analysis:

Instead of only breaking the instruction up and recording statistics on an 
opcode basis - the instructions can be tracked in their entireity and statistics
on the most frequently seen entire instruction presented. Use the -u flag when
running the program. Note that this will make execution time longer. For a 
binary trace of Linux booting 1.7GB in size, a 2.5GHz Intel Core 2 Duo machine 
took 30 minutes to parse with the -u option.


TODO:
 o Collect and display information about l.j and l.jal instruction immediates
 o Add an easy way to switch between human readable and CSV output
 o Figure out how to tack this thing onto a simulator (or1ksim for now) to give
   results of execution when that finishes executing, or just how to get the
   simulator to output a binary dump of executed instructions to be fed through 
   this
 o Add support for a list of binary files to be specified at the command line
 o Allow statistics to be collated over different files - this would allow each
   function to be broken out of a library, or application, and in that regard
   the instruction sequence data would then be accurate for static analysis.


July 25, 2010 - Julius Baxter