On Thu, 2010-06-03 at 11:10 +1000, Matt Evans wrote: > Paul Mackerras wrote: > > [snip] > > The second alternative -- emulating the lwarx/stwcx and all the > > instructions in between -- sounds complicated but turns out to be > > pretty straightforward in fact, since the code for each instruction is > > pretty small, easy to verify that it's correct, and has little > > interaction with other code. > > Easy to verify -- visually or logically? > > Having had a little experience with interpreters 'invisibly' operating > behind the scenes I am all for very rigorous testing of these things. > I have lost at least four of my nine lives to incorrect flag values, > odd data problems and hideous heisenbugs etc. of such interpreters. > Looked at another way, you'd be surprised how much one can break in an > interpreter and still successfully run various programs. > > Presumably your first pass is completely correct already, but I'm > thinking that if any future changes are made to it > it would be good to include test code/modes alongside the interpreter > so others can check alterations. E.g. include the "run user program > interpreted" test switch patch, or even better compare the interpreted > state to real hardware execution. There are other more directed test > strategies (e.g. handwritten tests, random code) but these would be a > good start.
Emphatic nod. We all trust Paulus to get this right, but I for one would not be game to touch it without a test suite. It's ripe territory for a boot time selftest IMHO. cheers
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
