On Fri, May 17, 2013 at 09:16:06PM +0200, Mark Burton wrote: > I wish I could say I understood it better, but at this point any insight > would be gratefully received. However, what does seem clear is that the > intent and purpose of Icount is subtly different, and possibly orthogonal to > what we're trying to achieve. > > And - actually, determinism (or the lack of it), is defiantly an issue, but - > for now - we have spent much of this week finding a bit of code that avoids > any non-determanistic behavior - simply so we can make sure the mechanisms > work - THEN we will tackle the thorny subject of what is causing > non-determanistic behavior (by which, I _suspect_ I mean, what devices or > timers are not adhering to the icount mechanism). > > To recap, as I understand things, setting the icount value in the command > line is intended to give a rough "instructions per second" mechanism. One of > the effects of that is to make things more deterministic. Our overall intent > is to allow the user that has hit a bug, to step backwards. > > After much discussion (!) I'm convinced by the argument that I might in the > end want both of these things. I might want to set some sort of instructions > per second value (and change it between runs), and if/when I hit a bug, go > backwards. > > Thus far, so good. > > underneath the hood, icount keeps a counter in the TCG environment which is > decremented (as Fred says) and the icount mechanism plays with it as it feels > fit. > The bottom line is that, orthogonal to this, we need a separate 'counter' > which is almost identical to the icount counter, in order to count > instructions for the reverse execution mechanism. > > We have looked at re-using the icount counter as Fred said, but that soon > ends you up in a whole heap of pain. Our conclusion - it would be much > cleaner to have a separate dedicated counter, then you can simply use either > mechanism independent of the other. > On this subject - I would like to hear any and all views. > > Having said all of that, in BOTH cases, we need determinism. > > In our case, determinism is very tightly defined (which - I suspect may not > be the case for icount). In our case, having returned to a snapshot, the > subsequent execution must follow the EXACT SAME path that it did last time. > no if's no buts. Not IO no income tax, no VAT, no money back no guarantee…. > > Right now, what Fred has found is that sometimes things 'drift'… we will (of > course) be looking into that. But, for now, our principle concern is to take > a simple bit of code, with no IO, and nothing that causes non-determanism - > save a snapshot at the beginning of the sequence, run, hit a breakpoint, > return to the breakpoint, and be able to _exactly_ return to the place we > came from. > > As Fred said, we imagined that we could do this based on TBs, at least as a > 'block' level (which actually may be good enough for us). However, our > mechanism for counting TB's was badly broken. None the less, we learnt a lot > about TB's - and about some of the non-determaistic behavior that will come > to haunt us later. We also concluded that counting TBs is always going to be > second rate, and if we're going to do this properly, we need to count > instructions. Finally, we have concluded that re-using the icount counters is > going to be very painful, we need to re-use the same mechanism, but we need > dedicated counters… > > > Again, please, all - pitch in and say what you think. Fred and I have been > scratching out head all week on this, and I'm not convinced we have come up > with the right answers, so any input would be most welcome.
Hi, This was a long time ago, but I recall having issues with determenism when hacking on TLMu. Ditching the display timer helped. IIRC, I was getting 100% reproducable runs after that. Cheers, Edgar
