> No problem. I will alter that, since I've got a bunch of other minor > changes to make that get this all working with O3CPU. What's the best > thing for me to do - add everything into this patch and repost or create > separate patches for the new stuff that can be applied after this one? Sorry I didn't get back sooner. In general, I think it is better to fix patches that have code that you want fixed, but I do prefer keeping separate changes in separate patches. Reposting works. An alternative is to add a patch to your queue on top of the one that you want to fix, fix the problems in the new patch, e-mail that patch out, then you can qfold it back in later before it is committed. Whichever is easier for you.
> Ah, right. The disassembly code is one area that could do with some > improvement. To tell you the truth, I put this together in dribs and drabs > so the choice of << or ccprintf was just whatever was quick to get it > working, then I didn't fix it up properly. Again, I can fix this so it's > consistent, but at the same time I'd like to also change the disassembly > output so that it is fairly similar to what gdb or objdump prints out. > This means fixing some of the mnemonics under certain constraints and is > kinda off my critical path at the moment. But it would be useful to do. No problem. I just really wanted to know if something was broken with cprintf. It seems that things are pretty close to done, so I don't think we need to spend forever perfecting this set of patches. You could fix future issues in the tree. Thanks, Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
