On Mon, 11 Jul 2005, Eric Ball wrote:
> Hmmm, is all that really necessary? I'd think all you'd need to do is
> preprocess the conditional breakpoints into a set of simple comparisons,
> e.g.
> PC = val
> A op val
> X op val
> Y op val
> etc
> where op is > = < or don't care, maybe with some special ops for BIT style
> operations and combinations with an address watch. Each emulated CPU cycle
> you check PC first, then test the rest of the conditions.
Well, the thing that turns expressions into this set of comparisons...
that's a compiler :)
How would you express (a==1 || x==2), as opposed to (a==1 && x==2), in your
scheme? How about ((a==10 || a==20 || a==30) && (x==1 || y==1))?
OK, they're fairly contrived examples (especially the last one)... but
you really might want to use (@address+y & 0x80). @address means "16-bit
word pointed to by address", and +y of course adds Y... so that simulates
(indirect),y addressing. We'd be telling it to break when an indirect
address is about to load a negative number (well, assuming we're in a
loop where Y changes.)
But your scheme is a good idea, and could be made to work, I just dunno
how yet (my fault, that is). Everything I just said sounds like I'm
trying to poke holes in it, but I'm really not (well, if I am, not in
a negative way).
My #1 biggest question though, was: should I even try to support
conditions that aren't tied to a PC-based breakpoint or address-based
trap? Your answer implies that I shouldn't ("check PC first..."), so I
guess that counts as one vote against arbitrary conditions...?
--
B.
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://stella.biglist.com
