Re: [stella] Stella conditional breakpoint support RFC

Subject: Re: [stella] Stella conditional breakpoint support RFC
From: Jeremy Penner <jeremy@xxxxxxxxxxxxxx>
Date: Mon, 11 Jul 2005 22:36:57 -0400
> 1. Re-parse the conditional(s) before each 6502 instruction  
> executes, or..

What are you doing, man!  Don't ever parse more than once!  Put it  
into a data structure!

> 2. Write a compiler for the conditionals (a "bytecode" type of  
> compiler,
> not a native one, since Stella is meant to be portable), and a  
> bytecode
> interpreter (hopefully one that's faster than the lexer/parser is!),
> and interpret the compiled conditional(s) before each 6502  
> instruction.

You really don't need bytecode to evaluate simple expressions; all  
you need is an executable parse tree, which is pretty trivial to do  
and probably much more efficient.

Stella's C++, right?  You could pretty trivially write a virtual  
"expression" class, with an overridable "evaluate" method, and  
subclass your operations: EqualityExpression, PCExpression, etc.   
EqualityExpression's constructor takes two expressions as arguments,  
PCExpression's evaluate method grabs the PC from the CPU state, etc.   
Build up this tree in yacc, and just call evaluate after every  
instruction to figure out whether or not to break.  (Make your ANDs  
and ORs shortcut; it'll save you from having to do anything else on  
those PC==myLabel checks.)

In any case, you should absolutely be building a simple data  
structure and interpreting that, rather than re-parsing every time.

> Of course, there's no reason I couldn't do both: arbitrary  
> conditions that
> come at the cost of slowing down the emulator (maybe a lot), or  
> conditions
> tied to an address that let the emulator run at (99% of) full speed.

Arbitrary conditional breakpoints are really useful in certain  
annoying situations.  ("Just when does that value get overwritten?!   
Argh!") They are also slow; it's a fact and has always been one.   
Thankfully, in the case of emulation, timing-sensitive things don't  
break when things slow down.  When you're tracking down that kind of  
problem, emulation speed is probably last thing on your mind.  If it  
helps you find the bug, who cares if the sound cuts out?

Archives (includes files) at
Unsub & more at

Current Thread