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. Cheers, Matt _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
