Final Report: A Random Test Generator for a hardware model of an x86 processor

Transcription

1 Francois Toguo Fotso University of Illinois at Urbana-Champaign 08/20/2009 Final Report: A Random Test Generator for a hardware model of an x86 processor Abstract: This paper discusses the design and the implementation of and the use of a random test generator tool for an X86 Intel Processor under development. The development of the tool was completed during the Distributed Research for Underrepresented internship during the summer 2009 under the supervision of Dr Russ Joseph. Dr Russ Joseph is an Assistant Professor at Northwestern University in Evanston, IL I. Introduction Random Test Generators are program used to generate code or series of instructions to test the functionality of a processor. The goal of our project was to develop a tool that a user can utilize to generate a script made of instructions in assembly language. The script is expected to be similar to the file generated by GCC after the compilation of a C program for example. The generated script is to be used later as an input to the X86 Intel processor being tested. A good understand of the assembly language and the Instruction Set Architecture of the x86 is required in order to complete the task.

2 II. Design Strategies A-Use of two files: The code of the tool is spread in two files: repository.py and instructions.py. The repository.py file contains the general functions used in the programs and the all the lists used throughout the program. The instructions.py file contains the main function, the interface s code and the functions that build the header and the bottom of the assembly file as well as the function that initializes the registers and the memory s. B-The interface The program is to be called by a command line. The command line has arguments that specify the format(s) of the instructions to be generated, the number of instructions per format. In the first stage of its development the program didn t allow the user to specify a probability of dependency between registers and between memories s, thus the dependency was forced. As follow: Opcode1 reg1, reg2 Opcode1 reg2, reg3 Opcode1 reg3, reg3 During the last week of the research program, the interface was changed to allow the user to specify a probability of dependency between registers. C-Data structure Because the tool was written in Python, there was a wide variety of data structures to be chosen from what the language offers: list, tuples, sequences, dictionaries and sets. The easier to manipulated and most convenient to use, for the purpose of our project, is the list data structure. It is the main container used to store registers, memory addresses, integers, floats, generated instructions and different types of elements. Occasionally lists containing other lists are used. D-Functions After spending a few weeks on the project, it became clear that there will be lot of subtasks to will be recurrently done throughout the whole project, therefore the choice was made to break down the tasks into several small functions.

3 III. Test Generator Architecture A-Specifications Registers: The original Intel 8086 and 8088 have fourteen 16-bit registers among which AX, BX, CX, DX can be accessed as two separate bytes. For purpose of concision our test generator will use only 8 8-bits registers, 6 16-bits registers, and 6 32-bits registers. Even though some versions of the X86 ISA include 64-bits registers, our instructions will only use the 6, 16 and 32 bits registers listed as follow: 8-bits registers: 'al','bl','cl','dl','ah','bh','ch','dh' 16-bits register: 'ax','bx','cx','dx','si','di' 32-bits registers: 'eax','ebx','ecx','edx','esi','edi' Integers, memory addresses, opcodes and instruction formats: The integers generated also are 8, 16 or 32 bits integers. At the beginning of the output assembly file registers and memory located are all loaded with the value 0. To ease this initialization process, we have limited the range of addresses used throughout the program from 0X0 to X32. All instructions, except for jumps instructions, have two operands: opcode source, destination. The x86 instruction architecture contains more than 100 opcodes. Our random test generator use a few of them instead of the the whole set. Here is the list of the possible opcodes that can b generated by our program: addl,subl,andl,orl,xorl,movl, addw,subw,andw,orw,xorw,movw, addb,subb,andb, orb,xorb,movb, ja,jae,jb,jbe,jc,je,jg,jge, jl,jle,jna,jnae,jnb,jnbe,jnc,jne,jnl,jnle, jno,jnp,jns,jnz, jo,jp,jmp,jpe,js,jz B-Command reader The command reader is a set of conditional code used to parse the options passed to the program through the command line. Three general forms of instructions can be generated: instructions using jumps, instructions with memory reference and simple instructions. The command line used to run the program can include up to three options. Each option specifies the form and the number of the instructions to be generated for that form. The command reader checks if the options entered by the user are valid, and then uses a series of if statements to determine the correct function to call. The valid options are: "-s" or "--simple" will generate simple instructions "-m" or "--memref will generate instructions with memory reference

4 "-j" or "--jump" will generate instructions with jump "-h" or "--help" will generate a manual describing how to use the Random test generator Each option is followed by a number representing the number of instructions. The command reader also checks that an option (especially the jump option) is not repeated in the list of options. C-Header file and initialization In order to be compiled by the GCC a header file similar to the one generated by the compilation of a C file is simulated and inserted into the final script. The instructions in the header file are generated and stored in a list. The list is printed in the output file before any other instruction. It is important that if the script is ran with a set of values in the registers and addresses, the final results always be the same set of input data, that s the reason why there is a need to initialize all registers and memories addresses to be used with the value 0. This is accomplished using movl movb or movw instructions. D-Format selection After the parsing of the options a specific function is to be called in order to generate the specific format of instructions requested by the command line. Each format has specific sub-format. The main formats and sub-formats handled by the program are listed in the table1. E-Registers and memory dependencies Create dependencies between registers and between memory s was one of the tedious tasks of the program development. Here against the flexibility attach with the use of data structures, such as list, came be very handy. Once created the dependency between registers had to be modifies in order to discard invalid dependencies such as the one between an 8-bit register and a 16-bits register for example. This is one example of several cases where a fully functional code had to be modified during the testing phase. Table1

5 Main format Sub-format Example Description Imm8,mem8 movb $32, 0x2a Move an 8-bits number into the 8- bits section of a 32-bits memory Imm8,mem16 movb $175, 0x1f Move an 8-bits number into the 16- bits section of a 32-bits memory Imm8,mem32 movb $165, 0x1f Move an 8-bit number into the 32- bits section of a 32-bits memory immx,memy Imm16,mem16 movw $ , 0x6 Move a 16-bits number into the 16- bits section of a 32-bits memory Imm16,mem32 movw $ , 0xA Move a 16-bits number into a 32- bits memory Imm32,mem32 movl $ , 0x1e Move a 16-bits number into a 32- bits memory R8,mem8 movb %ch, 0xce1 Move the content of an 8-bit register into the 8-bits section of a 32-bits memory rx,memy R8,mem16 R8,mem32 movb %ch, 0xce3 movb %ch, 0xce3 Move the content of an 8-bits register into the 16-bits section of a 32-bits memory Move the content of an 8-bits register into a 32-bits memory R16,mem16 movb %ax, 0xce3 Move the content of a 16-bits register into the 16-bits section of a 32-bits memory

6 Mem8_r8 movb 0xA, %ah Move the content of the 8-bits section of a memory into an 8-bits register Mem8_r16 movw 0xB, %ax Move the content of the 8-bits section of a memory into an 16-bits register memx_ry Mem16_r32 movl 0xde, % edx Move the content of the 16-bits section of a memory into an 32-bits register Mem32_r32 movl 0x3e, %edi Move the content of a memory into an 32-bits register offset(r32), r32 movl 0x228(%ebp), %eax scale the content of a 32-bit register and move it into a 32-bits BASE r32,offset(r32) movl %edi, 0x1b8(%ebx) scale the content of a 32-bit register and move the content of another 32-bits into the resulting register

7 IV. Test and results The first test on our random test generator was the test of the validity of all the instructions generated. All tests are executed against the GCC compiler. Initially the suffix b or w was missing from the opcodes of instructions involving 8 or 16-bits registers, so the first set of tests resulted into a lot of error messages generated by GCC. It took some reviewing of the X86 architecture to understand the operational mode of the x86 processor. Once the operations that involve 8 or 16-bits registers and 8 or 16 bits memory s were very well understood, then a modification was made to the function responsible for the generation a single instruction. The second test was the test of the interface. The main difficulty was to make the command reader be able to detect invalid command lines. This difficulty was due to the length of the command line itself, and also to the different possible combination of the available options. Example of an invalid command line that has to be detected during testing: instructions.py j s 3000 m 4000 is a valid command line instructions.py j s 3000 j is not a valid command line because the jump option is repeated. During the last week of the research, the program had to be modified again. The forced dependency between registers and memory had to be modified. The number of options available through the command line had to change to allow the user to specify a probability of creating a dependency between two instructions. Now the dependency is not automatic. Between two instructions a random probability must be generated. If that probability is less than the one generated by the user then the dependency must be created, else no dependency should be established. Therefore the last register or memory used has to be deleted from the list of registers or memory to be use in the next instruction. After all these modifications and changes, our random test generator is complete and fully functional. Several random tests are generated with large and small number of instructions. The output scripts are compiled as regular assembly file using GCC, they compile just fine without error. The random test generator can be use to generate any scripts that will test the functionality of an X86 processor. Our project has been completed successfully.

8 V. Relevant Literature - Automated Micro-architectural Test Generation for Validation of Modern Processors Heon-Mo Koo Prabhat Mishra Department of Computer and Information Science and Engineering University of Florida, Gainesville, -EECS EECS Introduction to Computer Systems Lecture Notes Dr Russ Joseph (Northwestern University) Inc. -Random Test Generators for Microprocessor Design ValidationRandom Test Generators Joel Storm, Staff Engineer, Hardware Technology, Validation, & Test Sun Microsystems -The Generator Construction Set: A New Approach to Random Test Generators OBSIDIAN Software, Inc. -x86 Assembly Language Reference Manual Sun Microsystems, Inc. -Python Tutorial Guido van Rossum,Fred L. Drake, Jr., editor -The Python Language Reference Guido van Rossum,Fred L. Drake, Jr., editor