Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Weird things I learned while writing an x86 emulator

timdbg.com

Post reply on HN
Print view View original

71–75 of 75 posts

Re: Weird things I learned while writing an x86 emulator

#71

Post by FullyFunctional »

timmisiak wrote: post #62
FullyFunctional wrote: post #57

Nice article, but nothing really surprising when you follow the progression starting from 8080. One correction though: > EAX is called the “Accumulator register” is not just a convention, it actually makes a difference to the encoding (and potentially the performance, as a result) No. As the decoder doesn't decode byte-by-bytes, but whole strings together and registers are all renamed meaning that %eax isn't really d…

My point is the smaller encoding is what gives you the performance benefit. When done across an entire function/module, you can get a measurable increase in hit rate for the instruction cache. Not that the instruction itself is faster. Apologies if that wasn't clear.

No, I got that point and it's vanishingly small. It _only_ affects miss rate (ie. does nothing if you are hitting in the cache) and the effect on miss rate is minuscule.

Re: Weird things I learned while writing an x86 emulator

#72

Post by menaerus »

ghusbands wrote: post #68
menaerus wrote: post #37

Earlier quoted context omitted.

That's what I thought as well, limited to the single-core race conditions era. Thanks for the evidence.

It's not limited to any era - it's a general-purpose tool that can perfectly reproduce bugs, even most race conditions. The lack of multi-threading will mostly just slow things down. Being able to perfectly reproduce a bug is immensely valuable.

I didn't say anything about the usefulness of rr other than in the context of concurrency bugs so I don't quite understand a defending attitude of yours.

Re: Weird things I learned while writing an x86 emulator

#73

Post by mark_undoio »

timmisiak wrote: post #58
mark_undoio wrote: post #21

Earlier quoted context omitted.

Ha, I was just reading some of the discussion and thinking it sounded quite similar to the JIT we use in our own (Linuxy) Time Travel Debugger. It's similarly am x86-on-x86 JIT / emulator but (and I'm sure WinDbg's TTD is similar) most of what you want to do there is just code copying for any instructions that don't need special instrumentation. And you want to run entirely in the cache of JITted code so you're close…

Funny enough, we tried going down the road of doing a JIT, but for our use cases pure emulation was often fast enough and it wasn't worth the extra complexity to do JIT. Part of that is probably due to the architecture of how TTD works, but part of it is how efficient we were able to get with the emulation mode. Later, a different emulator was created for running x86 code on ARM64, and that one uses an extremely effi…

Very impressive you got such good performance out of straight emulation! And WinDbg TTD runs with truly parallel threaded execution within one process, which we do not (yet).

I'm surprised a JIT wasn't worth it but, from what I'm aware of, I can see a few reasons why the trade offs are different.

Re: Weird things I learned while writing an x86 emulator

#74

Post by mark_undoio »

timmisiak wrote: post #63
mark_undoio wrote: post #23

Earlier quoted context omitted.

IIRC from our similar code, the LEA (load effective address) instruction is useful for doing adds / subtracts of arbitrary integers without updating the flags. Flags turn out to be quite the annoyance for the kind of in-process virtualization needed by Time Travel Debug. You need to instrument code with minimal overhead so, on the one hand, you don't want to save/restore flags all the time .... And on the other hand…

Yes, saving and restoring flags is very expensive. I thought about talking about that in the article but figured that was too much of a detour. Darek Mihocka wrote a really interesting article about how to optimize flag calculations in an x86 emulator: http://emulators.com/docs/nx11_flags.htm Although looking at your username I suspect you may have read this one before...

I had not read it before! Thanks for the link. I don't get too involved with our JIT other than to occasionally peer into some code and go "ooooh"

Re: Weird things I learned while writing an x86 emulator

#75

Post by roca »

menaerus wrote: post #22

Has anyone used TTD, or rr for that purpose in Linux world, to debug a complex multi-threaded application? What is the main use-case of these tools? For example, limitations of rr seem to suggest that it is almost of no use for multi-threaded programs so I have never actually tried it. I don't know about the TTD though. > rr limitations > ... > emulates a single-core machine. So, parallel programs incur the slowdown…

(Disclaimer: rr maintainer.)

As others have said here, in practice rr works very well for debugging a wide range of bugs in multithreaded programs, including race conditions.

Where it falls down:

* It can only use a single core, so highly parallel programs run very slowly when recorded by rr.

* Some race conditions may be difficult or impossible to reproduce under rr recording (but rr's chaos mode helps a lot with this).

* rr imposes sequential consistency on the recorded program, so bugs due to weak memory models do not show up under rr. Such bugs are pretty rare on x86 (because x86's memory model is pretty strong); this may be more of an issue on ARM.

Post reply on HN