A simple framework for testing execution of small programs against the x86isa model.
The asmtest framework is designed to allow us to test many small programs ("snippets"), each many times on different data, and compare the results obtained by the x86 model with those obtained by running the programs on hardware.
A snippet is a C function or a piece of assembly code which reads a fixed-size (per snippet) memory block of input and writes a fixed-size memory block of output. A pointer to the input memory block is given in RDI/the first function argument, and a pointer to the output memory block is given in RSI/the second function argument.
To run a snippet on hardware, we use an executable into which all snippets have been built. This executable chooses a snippet to run, input file to read, and output file to write based on its command line arguments. The input file is read into memory and interpreted as N input memory blocks; the execution then runs the snippet on each input memory block, writing out N output memory blocks to the output file. The executable can also optionally output a "conf" file that describes the test (listing the snippet name, input file, and output file).
To run a snippet on the x86 model, we read that executable into the x86
state using binary-file-load
and can then use the
We provide scripts to automate this process for randomly generated inputs.
You can run
Snippets are listed (along with their input and output block sizes) in snippets.txt (under the asmtest directory, books/projects/x86isa/tools/execution/asmtest). This file is parsed by a script that then generates the file snippets.h, used for building the asmtest executable. Once the executable is built, the same script can be used to build the file snippets.lsp, which tells ACL2 the input/output sizes and entry point addresses of each snippet.
To add and test a new snippet:
Some snippets are generated with
A Python script "text_to_binary.py" is provided to help generate test input files. Mainly it helps write a bunch of numbers into a binary file. See the usage message for that script for details. Currently it only supports either explicitly specified or randomly generated inputs.
If this proves to be a successful framework for testing the x86 model, we'll want to set things up so that we can easily run a regression of the x86 model that includes snippet tests. This could either (a) be part of the ACL2 regression suite or else (b) a separate regression only used when working on the x86isa project.
If (a) we include snippet tests as part of the ACL2 regression, we don't want to require an X86 machine and all the tools used to build and run the snippets for the regression to succeed. So we either need to (1) conditionalize the snippet testing on having an appropriate machine with all the necessarly tools, or (2) include in version control everything necessary to run the tests. (1) seems restrictive and likely prone to errors. (2) would require including the asmtest binary executable, all the input data files we want to regress (or a platform-independent way of recreating them), and output files (so that we don't require an x86 machine to run the asmtest executable). Perhaps instead of having a version-controlled monolithic asmtest executable, we should support multiple such executables based on a shared codebase but containing different sets of snippets. That way some executables could be checked into version control for inclusion in the ACL2 regression but some are source-only, and testing new snippets doesn't require modifying a version-controlled executable.
If (b) we don't include the snippet test regression in the ACL2 regression, perhaps we only include source code in the repository and construct the regression test by creating books in a subdirectory excluded from the main ACL2 books makefile.
We'll need some tools to generate good inputs for testing various sorts of instructions. Should these tools should be written in ACL2 or another language?