[hatari-devel] start and break question

[Nicolas Pomarède]

Le 12/06/2011 00:51, Eero Tamminen a écrit :
>> Personnaly, I really don't like the "?" syntax ; I'd rather use {} to
>> enclose expression ; it's not used in asm coding as far as I remember,
>
> MonST uses {} for indirect addressing in its own expressions.
> Hatari debugger uses () for that, similarly to disassembly.

Hi,

Well, we don't necessarily have to follow monst usage, I think () is 
better as it's widely used by any asm coder (using devpac or other 
assemblers)

> Well, in expressions it might be nice to use () for changing precedence
> instead of indirect addressing, but that would require using something
> else than () for indirect addressing...
>
> But I guess everybody's already gotten used to using () for indirect
> addressing and doesn't need changing of operator precedence in expressions?
>

Yes, better leave it this way for now.

>
>> As {} is also used in C or many other languages to delimit a block of
>> code, I think it would also make sense to use this to enclose
>> breakpoints' expressions/conditions.
>
> So:
> 	b VBL = {VBL+4}
> ?

Yes, or VBL = {VBL} + 4


>> In the case of expression used in breakpoints, I think they should
>> always be run-time evaluated each time a breakpoint condition is tested.
>>
>> As I wrote in another thread I prefer the {} notation to add an
>> expression/condition to a pc breakpoint (instead of the ?xxx? notation),
>
> That thread was about marker for arithmetic expressions that will be
> immediately evaluated when a command is entered by the user.
>
> The ?foo? syntax was proposal for stuff that's evaluated whenever
> breakpoint is checked at run-time.  Conditional breakpoints can already
> evaluate registers[1]&  variables at run-time, but they don't support
> conditions with arithmetic operations being calculated at run-time:
> 	a0 + a1 + 4 = (a2) - 5
>
> You can only use immediately evaluated arithmetic operations in them:
> 	b "a0 + a1 + 4" = "(a2) - 5"
>
> (quoted parts are evaluated before the command itself is parsed i.e.
> this works for all debugger commands.)
> 	
>
> You need different identifiers for both of these evaluation modes
> so that they can be differentiated and run-time evaluated stuff can
> include immediately evaluated things if needed.

I don't think there's a big need for breakpoints with parts of the 
condition not being run-time evaluated (ie at the time the command is 
parsed).
In the specific case of breakpoint, if the user really wants the value 
used at the time the breakpoint is parsed, then I think it's up to the 
user to replace for example the register with its content.

But maybe we could have a syntax that allows both run time and parse 
time value breakpoints ; what about saying that :
  - a register/internal variable is always run time evaluated when 
provided directly with its name
  - when the reg/variable is enclosed in {} then the current value of 
the reg/variable is substituted at parse time.

So, if D0=12
b D0=40  will break when D0 reach 40
b {D0}=40 will break when 12=40 (ie never)

b VBL={VBL}+4  will break after 4 VBLs
b VBL=VBL+4  will never break because the same variable can't have 2 
different values


Nicolas