Hey Gabe, To answer your testing query, we do have some stuff setup to run python test. We use Python's 'unittest' module for this ( https://docs.python.org/3.8/library/unittest.html).
In our setup "tests/run_pyunit.py" is run as part of our quick/kokoro tests with NULL/gem5.opt (i.e., behind the scenes, `build/gem5/gem5.opt tests/run_pyunit.py` is executed; you can run the tests directly this way). If you look into this script you'll see it's looking for anything matching "pyunit*.py" in the "tests/pyunit" directory. At present, there's only one that matches, "tests/pyunit/util/pyunit_convert_check.py". This checks the `m5.util.convert` utility works as intended. You can look into this file and see how the unittests work, but, to explain it briefly, you create a class which inherits from `unittest.TestCase` and the Python unittest framework will execute any method in that class starting with "test_". I'd be really happy if more Python-level unit tests were written, so please feel free to play with this and add checks as you see fit. Kind regards, Bobby -- Dr. Bobby R. Bruce Room 3050, Kemper Hall, UC Davis Davis, CA, 95616 web: https://www.bobbybruce.net On Sun, Feb 6, 2022 at 4:21 AM Gabe Black via gem5-dev <gem5-dev@gem5.org> wrote: > Hey testing folks (primarily Bobby probably?). I'm revamping the x86 > microcode to extract it from SCons itself, and also just to make it less > painful and annoying to work with. > > Importantly, the microcode basically lists a sequence of microop mnemonics > and a set of arguments. The mnemonic simply selects a python class, and the > arguments are simply used verbatim to instantiate it. Once the assembler > has turned a macroop definition into a sequence of instances of python > microop classes, it goes through and turns those into essentially c++ > arrays (and some other stuff) which get compiled into gem5. The arguments > passed to the microops are generally substituted into the code which > instantiates the microop instances in c++. They often don't *look* like > string constants, but that's because there are a bunch of python variables > defined like t0, dsz, cs, etc, which all actually *hold* string constants. > > In any case, when we have a sequence of python objects which all represent > a complete definition of what microop to use and all its parameters, we are > just a small step away from being able to execute the *python* instances > one by one, and being able to test the behavior of a macroop, assuming the > python microops and the c++ microops do the same thing, and the macroop > spits them into the CPU as expected. > > One key difference is that the arguments of the microops boil down to c++ > or are explicitly c++ string constants. When the arguments are symbolic, it > would be relatively easy to substitute in a different set of variables > which are really true python variables and not secretly c++. There aren't > tons of places where there are raw string constants in the microcode, or at > least not tons of different cases where that happens, so we could avoid the > problem by just selectively defining what macroops to test, and/or by > trying to convert the remaining string constants into variables which can > have a python personality. > > What I'm hoping to accomplish with this email is to, first, just get this > idea out there in case anybody has any feedback. > > Second, I want to find out what provisions we have for running python > based tests. We have googletest to run c++ tests which I'm quite familiar > with using, but I don't know what we have that's equivalent to that for > python. Any pointers/docs? > > Gabe > _______________________________________________ > gem5-dev mailing list -- gem5-dev@gem5.org > To unsubscribe send an email to gem5-dev-le...@gem5.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
