Hi Denis, > On May 25, 2016, at 3:12 AM, Denis Kudriashov <[email protected]> wrote: > > Hi. > > Look at AST-Interpreter project which includes AST-Debugger > http://smalltalkhub.com/#!/~Pharo/AST-Interpreter. Code is so simple > comparing to "bytecode simulation" approach of current debugger. > AST debugger are independent from bytecode set. It just visit AST-nodes to > simulate code execution. > > But current debugger simulates bytecode. It depends on current bytecode set. > There are few kinds of BytecodeEncoders. To understand how current debugger > is working you need to know many VM details.
That's simply not true. In fact the amount known of the VM in both the bytecode debugger and the AST debugger is the same; both use VM primitives that aren't specified at the image level. Both the AST interpreter and the bytecode interpreter include the interpreter in Smalltalk in the image. Look at Context and InstructionStream to find the Smalktalk definitions of both the interpreter routines and the implementations of the bytecodes. > > So my question is why our debuggers are not based on AST interpreter? Why it > is bad idea? (if it is bad). One area where you'll find the AST debugger worse is in performance. The bytecode debugger uses perform: to execute at full speed when possible (it does interpret when doing step into or through, but not when doing over). In fact this part of the system, because it has to catch no local returns and exceptions, is the most complex, but it's not because of VM details, it's because of the use of perform: to run code being debugged to run at full speed. Not to mention, if it isn't broke don't fix it. But seriously, the system is based on bytecode, and that bytecode is pretty straightforward and easy to learn. Why not put in the effort of learning it? Criticizing something in ignorance is not wise IMO. > Best regards, > Denis _,,,^..^,,,_ (phone)
