Attention: This exercise, like all others, is individual. This means that you cannot, under any circumstances, look at the code of one of your colleagues. You can take questions away from the computer or ask the teacher for help.
You should remember the concepts related to performance measures. Try to think of answers to the following questions (you do not need to include them in your report):
It is important that you know how to answer these questions before continuing the activity.
In this activity, as well as several others in the discipline, we will use a MIPS processor simulator, made in the language ArchC. During the semester you will learn more about this language and the ability to implement different simulators. But in this first moment, the important thing is to understand the basic notions of the simulator, how to invoke it, how to compile programs and how to generate a correct execution result.
ArchC is a language for describing processor architectures. The main purpose is to facilitate the work of the processor and systems designer, accelerating the development of simulators and other necessary tools for the evaluation of an idea, before moving on to the hardware prototyping phase.
All the files you will need to use in this exercise are available in my IC3 homedir, at / home / staff / rodolfo / mc723. In the download folder there are versions ready to unzip and install.
Let's use the processor model MIPS, which is an expanded version of the processor studied in the MC722 discipline, with extra instructions. The template is available in the download folder (mips1-v0.7.8.tgz). Unzip this file and read the README that accompanies it. It contains specific instructions on copying the processor simulator. For this, you will need the simulator generator so, which is already installed in / home / staff / rodolfo / mc723 / archc / bin / acsim (add to PATH to facilitate future uses). Three commands are required:
acsim mips1.ac -abi
make -f Makefile.archc
mips1.x --load =[args]
The first command creates the simulator files, based on the description contained in mips1.ac (main ArchC processor description file). The second command compiles the simulator, generating an executable called mips1.x. The third command is to use the simulator to run a program compiled for MIPS. As we have no MIPS program, create a file called hello.c with the classic "Hello World" and we will compile it.
Due to the characteristics of the IC-3 installation, only the xaveco machine has the MIPS compiler installed. Thus, whenever you need to compile a program for MIPS, you must execute the commands on the xaveco machine. Add the / l / archc / compilers / bin path to your PATH as well.
mips-elf-gcc -specs = archc hello.c -o hello.mips
Similar to the gcc you are used to, this is a version of gcc compiled to generate binaries for the MIPS architecture. All other development tools also exist in a version with the prefix mips-elf. It is called cross compiler a compiler that runs on one platform (x86 in this case) and generates programs to run on another (MIPS in our example). The -specs = archc parameter reports some ArchC-specific rules, which must be followed by the compiler. The last parameters indicate the file to be generated and we are generating the program with the architecture suffix to facilitate understanding. With the new executable in hand, now you just need to invoke the simulator and watch your program running.
mips1.x --load = hello.mips
Another tool that can be useful is the objdump (in the form mips-elf-objdump for MIPS). It is able to show various information about the program (see the manual for options). An example usage for listing assembly code is:
mips-elf-objdump -d hello.mips
Did you recognize any instructions? Did you understand a little of the code?
The instructions implemented by the simulator are described in two files: mips1_isa.ac e mips1_isa.cpp. The first describes what instructions the processor will have and their encoding. The second file contains an implementation of the statement's behavior (a C ++ code snippet that describes the statement's functionality). Open the second file and search for ac_behavior (add), does this code snippet seem intuitive?
Now that you know how to generate the simulator, the first task is to count how many times the instruction add happens during the execution of your "Hello World". For this, you must edit the file mips_isa.cpp and include a global accountant. You can edit the ac_behavior (add) and you also need to edit the ac_behavior (begin) e ac_behavior (end) that are executed at the beginning and end of the simulation, respectively. Recompile the simulator and run your program. Did the results go as you expected? If there were no add statements, can you modify the program's source code so that at least one appears? Tip: use the objdump to try to understand what's going on.
As each statement has a different piece of C ++ code to implement it, the simulation time is not directly related to the execution time of a program. For this reason, instead of measuring the execution time of the simulator, we will compute the time in cycles for the execution of the program. The table below indicates the average CPI for the instruction categories:
| Category | Average CPI |
|---|---|
| Memory access | 10 |
| Multiplication and Division | 20 |
| Other | 1 |
Rather than having to change the entire simulator code, the so has the option -s to generate simulation statistics. One of the statistics is the count of the number of times that each instruction executed. Regenerate your simulator with this option, collect statistics, and calculate how many cycles were spent to run your program.
Run 3 programs from the table below, one from each column, and indicate the number of cycles required to run each one. The programs are taken from the MiBench benchmark package, which is already compiled and ready to be unzipped on my IC-3 homedir. Use the last 3 digits of your RA (fourth, fifth and sixth) to select the program.
| Digit of RA | room | fifth | sixth |
|---|---|---|---|
| (small) | (small) | (large) | |
| 0 | basic math | stringsearch | susan corners |
| 1 | qsort | rijndael coder | jpeg coder |
| 2 | susan corners | rijndael decoder | dijkstra |
| 3 | susan edges | sha | patricia |
| 4 | susan smoothing | adpcm encoder | gsm coder |
| 5 | jpeg coder | adpcm decoder | rijndael coder |
| 6 | jpeg decoder | crc32 | gsm coder |
| 7 | paralytic | fft | adpcm encoder |
| 8 | dijkstra | gsm coder | sha |
| 9 | patricia | gsm decoder | stringsearch |
See detailed instructions on executing and checking program results in the README file within the folder for each program.
Everyone must submit a 1-page report, in PDF format, through the Susy. Keep the source code until the end of the semester.