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
