| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
VICE debug interface
i want to add some simple mechanisms to VICE that will help with automatic regression testing (there are over 800 test programs now, running them all manually takes several hours) - this stuff might be interesting for coders writing c64 software as well, so before i start i am looking for some more ideas on what might be useful.... the whole thing would be implemented as either a cartridge or some special i/o device, so basically everything should be triggered by writing to certain registers. the minimal functionality i came up with looks like:
- exit vice with exit code (to signal the test suite success or error)
- print a string to console (with some kind of "printf" like functionality, so you can print contents of registers/memory easily)
what else may be useful? |
|
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Well, the proposed debugging console certainly would be helpful..
Beyond that I'd not mind some means of informing VICE that a particular overlay has been (un-)loaded. Manually installing the appropriate labels and breakpoints can get a bit hairy with multiple dynamically loaded slots.
The holy grail would be to let tracepoints trigger a (Lua?) script capable of inspecting/modifying the state of the system. E.g. to be able to litter the code with "free" assertions (with access to information hard to inspect unobtrusively like timing and CPU/drive-synchronization), pretty-print data-structures or to prototype algorithms in a high-level language. |
| |
Peiselulli
Registered: Oct 2006
Posts: 81 |
Backward stepping, breakpoints triggers on processor register values, breakpoints to screen positions, a "next line" instruction to step forward one line of the raster beam and a window for listing the current code for all platform (like the windows port) or even better. Maybe the debug interface of "stella" for the atari 2600 may be an example.
But that are things that wouldn't help for your regression testing problem ... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
sometimes i really wonder if people actually read before they write an answer.... this is all stuff that has very little to do with "basically everything should be triggered by writing to certain registers". i am NOT touching the monitor or adding any related features, thats something completely different =)
(you can already trigger breakpoints depending on register values, btw) |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting Groepazsometimes i really wonder if people actually read before they write an answer.... this is all stuff that has very little to do with "basically everything should be triggered by writing to certain registers". Yeah, sorry about going off-topic there and drooling over unrelated debugging features.
The overlay proposal was meant as a serious suggestion for a virtual debugging cartridge though as it requires cooperation from the code being emulated. I envisage an array of virtual bank-switching register which when poked would bring in the labels/breakpoints tagged with the written value (and unload whatever overlay was there previously.) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
- passing arguments to the guest program
- an IO register which prints emulation state info to stdout/stderr upon access
- equivalent features for drive code (except argument passing) |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
I approve of this discussion. :D |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:- passing arguments to the guest program
like a commandline switch that will let you pass a value, which then can be seen in some i/o register?
Quote:- an IO register which prints emulation state info to stdout/stderr upon access
ie like the output you get in the monitor when tracing code?
those should be fairly easy to do indeed :) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting Groepazlike a commandline switch that will let you pass a value, which then can be seen in some i/o register? I was thinking of passing a complete string. Writing to the register would reset the character index to 0, and reading would return the current character and increase the index. The terminating character may be a 0, and after that, the string would either wrap or return 0 until writing to the register again. To keep parsing complexity low, you could simply pass a single-character string, but the possibility for more complex parameters is there.
Quote:ie like the output you get in the monitor when tracing code? Basically yes, but maybe with more information than just raster position and CPU state. There could be a register for every chip, such as VIC, SID, CIA1, CIA2 etc., and the value written to it could be a bitfield or enum value to determine how detailed the output should be. The idea is that you could check for more than just test passed/failed from the regression test script, diffing VICE's terminal output with a reference. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:The idea is that you could check for more than just test passed/failed from the regression test script
well, thats not really useful. for most of those tests even a full register dump wouldnt help - you'll have to examine wth happened in all detail anyway. for the regression-testing alone what i listed in the first post is more than sufficient already :) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
True. But maybe it would help further debugging after a failed regression test, such that you can insert these writes at strategic points to find out where it breaks. |
... 32 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
