[Matthew Davis]

The program choosen was chamelion file encryption (cenc and cdec.)

Chameleon is an experimental file encryption tool using a
password-generated, plaintext-feedbacked 2048 bit key, feedbacked
xor-chains, and a dummy-header system. It is designed to give the
encrypted files a better security against brute-force and known-plaintext
attacks.

      Stable Version:
                          0.1
               Author:
                          Ulli Meybohm <ulli at meybohm.de>
               License:
                          GPL
            Category:
                          Console/Encryption
           Project ID:
                          9071
           Download:
                          http://www.meybohm.de/os/chameleon.tar.gz (194
hits)
          Homepage:
                          http://www.meybohm.de/os/chameleon.html (436
hits)

It was choosen because it should need allot of looping and integer
arithmetic. (There is no fp.)  Also, file acceses should happen only twice
to read and write.


===============================================================================

Input sequence for cenc:

PASSWORD (Step 1/3)
....
Enter Password:blarg

DUMMY-HEADER SIZE (Step 2/3)
.....
Enter Dummy-Header Size (PIN) [0-n]:
0

RANDOM GERNERATOR INITIALISATION (Step 3/3)
To create the dummy-header, we need to create some data-junk with a
random...
Type something random:bbb

Encoding TR_1342.ps.enc. Please wait...
DONE

===============================================================================

sim: ** simulation statistics ** BEFORE OPTIMIZATION **
sim_num_insn               62230081 # total number of instructions
executed
sim_num_refs               31059048 # total number of loads and stores
executed
sim_elapsed_time                 57 # total simulation time in seconds
sim_inst_rate          1091755.8070 # simulation speed (in insts/sec)

sim: ** simulation statistics ** AFTER OPTIMIZATION -O2 **
sim_num_insn               37966539 # total number of instructions
executed
sim_num_refs               12754454 # total number of loads and stores
executed
sim_elapsed_time                 29 # total simulation time in seconds
sim_inst_rate          1309191.0000 # simulation speed (in insts/sec)


#          index      count    pdf        count    pdf
load               26393642  42.41      9861065  25.97
store               4665406   7.50      2893389   7.62
uncond branch       2590007   4.16      2283241   6.01
cond branch         4305957   6.92      4305876  11.34
int computation    24274864  39.01     18622764  49.05
fp computation            0   0.00            0   0.00
trap                    204   0.00          203   0.00

Overall, optimization halved the running time and almost halved the
dynamic instruction count, while increasing simulation speed 30%. (ADDED:
This speed is inaccurate.  It reflects how long I took to input the
parameters.
Optimization got rid of more than half the loads, the alu instructions
decreased by less (down ~ 1/5.)  The over all affect is that loads are
down ~15% and alu ops are up ~10%.  Conditional and unconditional branches
are affected much less by the changes.



Instruction Ussage:
Instruction     optitmized      unoptimized     book values
  lbu             13.94           13.25           see lw
  addu            13.91           14.25            8 %
  lw              12.01           28.22           22 %
  addui            8.40            7.93           see addu
  bne              6.79            4.59           20 % (all cond
branching)
  xor              5.45            3.32           <1 %
  andi             5.34            1.36            6 %
  sb               4.64            4.27           see sw
  subu             3.84            3.79            5 %
  sw               2.96            3.23           12 %
  ori              2.95            1.80           <1 %


Optimization greatly reduced the number of loads needed by the app. more
than halving the lw instructions (lbu % goes up but remember that the #
has been ~ halved.)  The code uses aproximately the same number of alu ops
as the x86 benchmark except for the xor.  This is probably because xoring
is one of the primary operations in the encoding process.  Stores are
comparatively low compared with the benchmark.  Data was probably written
directly to the file as opposed to back into memory.