4 ms·

That reverse debugging feature looks cool. At a high level, how does it work?

jart 4y ago
Very simply. Took three hours to code. Blink just takes a "screenshot" of the ANSI terminal display, gzips it, and appends it to a ring buffer with 64,000 entries. Each screenshot is a full frame. There's no delta encoding or anything smart like that. 64k gzipped frames takes a few hundred megs of memory once it fills up, depending on how big your terminal display is. My favorite part is that, when you press the 'c' button to continue execution, Blink will only transmit 60 FPS to your terminal. In-between frames, it's still capturing screenshots in the background, which get added to the ring buffer. It'll save thousands of frames per second, so you can skim through execution pretty quickly, like a tv show, and then maybe you'll see something happen, smash ctrl-c, and scroll backwards slowly with fine-grained per-instruction granularity, thus illuminating the event you saw fly by earlier. It's so nice. Especially if you're used to tools like GDB TUI, which permits scroll-wheeling down the assembly display, but it won't let you scroll-wheel back up to the thing you were just looking at!
- britneybitch 4y ago
  Oops, maybe not that high-level. I meant, underneath the UI layer, how is the state/execution path of the emulated CPU efficiently recorded during execution and later rewound? Any approaches I can think of would destroy the performance. I have a toy emulator project that dumps the entirety of RAM every frame and I'm trying to come up with ideas to improve its efficiency.
  - jart 4y ago
    Blink's reverse debugging is implemented purely at the user-interface level. It doesn't have anything to do with the execution engine. While Blink does have near-perfect knowledge of memory, I considered doing the thing you proposed, where deltas are stored and reconstructed. I decided that it wouldn't offer compelling benefits beyond just capturing and rewinding screenshots. For Blink's use case, screenshots are arguably superior, since it preserves perfectly the UI states previously observed by the user. I understand this might not be an option for your project, since you might not have a display that's visualizing program memory and execution. In that case, I'd suggest why not build that first?
    - britneybitch 4y ago
      That's a really slick approach. I reread your first post again and you explained it perfectly, I just didn't grok it the first time around for some reason. Maybe I thought it couldn't be that simple... but it is! Thanks for patiently explaining twice.

jart 4y ago

Very simply. Took three hours to code. Blink just takes a "screenshot" of the ANSI terminal display, gzips it, and appends it to a ring buffer with 64,000 entries. Each screenshot is a full frame. There's no delta encoding or anything smart like that. 64k gzipped frames takes a few hundred megs of memory once it fills up, depending on how big your terminal display is. My favorite part is that, when you press the 'c' button to continue execution, Blink will only transmit 60 FPS to your terminal. In-between frames, it's still capturing screenshots in the background, which get added to the ring buffer. It'll save thousands of frames per second, so you can skim through execution pretty quickly, like a tv show, and then maybe you'll see something happen, smash ctrl-c, and scroll backwards slowly with fine-grained per-instruction granularity, thus illuminating the event you saw fly by earlier. It's so nice. Especially if you're used to tools like GDB TUI, which permits scroll-wheeling down the assembly display, but it won't let you scroll-wheel back up to the thing you were just looking at!

britneybitch 4y ago
Oops, maybe not that high-level. I meant, underneath the UI layer, how is the state/execution path of the emulated CPU efficiently recorded during execution and later rewound? Any approaches I can think of would destroy the performance. I have a toy emulator project that dumps the entirety of RAM every frame and I'm trying to come up with ideas to improve its efficiency.
- jart 4y ago
  Blink's reverse debugging is implemented purely at the user-interface level. It doesn't have anything to do with the execution engine. While Blink does have near-perfect knowledge of memory, I considered doing the thing you proposed, where deltas are stored and reconstructed. I decided that it wouldn't offer compelling benefits beyond just capturing and rewinding screenshots. For Blink's use case, screenshots are arguably superior, since it preserves perfectly the UI states previously observed by the user. I understand this might not be an option for your project, since you might not have a display that's visualizing program memory and execution. In that case, I'd suggest why not build that first?
  - britneybitch 4y ago
    That's a really slick approach. I reread your first post again and you explained it perfectly, I just didn't grok it the first time around for some reason. Maybe I thought it couldn't be that simple... but it is! Thanks for patiently explaining twice.