From: Spiro Trikaliotis (Trik-news_at_gmx.de)
Date: 2000-01-21 12:33:16
Hi Uz, (you want to be called this way, don't you?) >> 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. > >No way:-) You have solved one problem with this approach and got another: >How do you locate the pointer to the stack frame if it is itself on the >stack, and there is no base pointer? Hm, I've written about a pointer which acts like a base pointer. This pointer must reside somewhere in memory, and there should be a pre- agreed way to access it. Perhaps, we could add an entry to the symbol file which tells the debugger where to access it. I don't think it should be located on the stack! >What's the advantage of using a mouse if you have your hands on the keyboard >anyway? Why not use a set of keys to step through the code or inspect data? >This would allow a text mode interface which is much easier to port to other >operating systems. Apart from that, a windows only solution is no solution >for me. I have a Windows box and vmware running here, but I do not use it >for real work. Just my 0,02DM :-) Well, I don't like the mouse in most cases. Anyway, it's much easier to add the accelerators (= keyboard chars) if you have the commands in a menu or in a status bar, but you're right, it will lack the portability. I'll have to re-think about that. 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