From: Spiro Trikaliotis (Spiro.Trikaliotis_at_gmx.de)
Date: 2000-01-20 23:06:45
Hi Ullrich (and, not to forget, all the others, ;-), >I have worked with the VICE monitor code myself, so I'm pretty sure that the >YACC grammar has nothing to do with line termination. Grmph. You're right, it was only a "wrong" mode parameter with fopen() in VICE which opened a binary file. I just 'fixed' it in VICE, but I'll have to see what the others have to say about this. >> Well, I asked my question about the debug generations because I want >> to extend the VICE monitor for better debugging. >Ahh! Does that mean that I do not have to bug Daniel requesting new >monitor features, but send my mails to you instead? :-) :-) Well, I don't want to take over someone's work ;-), and I'm sure Daniel will be much more familiar with the code than I am, but I will be glad to hear from you, too. I just started with VICE 1 or 2 months ago, so I'm lacking much experience in regard of the code. >Do you know if the fast breakpoint check is now implemented in VICE? [...] Well, I haven't seen something like this (which does _not_ necessarily mean that it's not there), but I'll look for it. >My plan was to use spunk (http://www.von-bassewitz.de/uz/spunk/). [...] I'll have a look at it. >I'm not sure if this is really worth the effort, since the compiler >generated code is really bad without optimization. Yes, sure, but it's better to have not-so-optimal-code which can be debugged in a good manner than having near-to-optimal-code ;-) which is very hard to debug (provided the optimizer does not add new bugs), so it were a good starting point. >And, line information is >only one part. To access local variables, information about the stack offset >of these variables has to be generated. But since the generated code does >not use a base pointer (this would be difficult on the 6502 since it does >only allow positive offsets to an address), stack pointer plus offset is >used to access local variables. This means that the compiler has to emit >debug information with every change of the stack pointer - which is quite >often, since the stack is used in almost any expression that has more than >one operand. Well, what about this solution: You're using a kind of stack frame which solely consists of a pointer to the previous frame, and you add one pointer which points to where the actual stack frame is located on. So, the pointer is a kind of BP on the Intel (which actually needs not to be used by the code, it's maintened only for debugging purposes), so we don't have to change debug info with every change of the stack pointer. The 'stack frame' would allow an easy return to the previous stack frame when returning from a subroutine. >The VICE monitor is nice, but in my eyes it is crafted too much after gdb. >While both (gdb and the VICE monitor) are extremely powerful, one has >problems to find an interface that is more unfriendly to the user. Well, I don't know GDB, but Andreas Boose told me that the interface is intended to be compatible to AR. >What I would like to see is an interface like the one in the old Borland >Turbo Debugger. Stepping through the code is easy with VICE, but you have to >enter commands to look at the stack or a memory area after each step. Having >a fullscreen debugger that allows you to step through the code while stack, >registers and a selectable memory range are in view would be a *great* >improvement. Well, I think about adding a symbol bar to the monitor console (in the WIN32 port), so some commands could be entered more easily. A memory 'window' is on my todo list, too, although I don't know if it should be implemented in an own console window (where I do not know how easily it could be ported), or to split the console in "text-mode-windows" (where we would need something like positioning inside of the console, where I don't know if it's possible to port it either). You see, I have some improvements in my mind, but to be honest, I'm currently not coding at all since I have a deadline by the beginning of next month. Hopefully, I will be able to start at the middle of february, until then, I'm collecting as much information as possible (which is because I got here in this mailing list). Spiro. ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo_at_musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:35 CET