| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Code based breakpoints using ca65 and VICE
Recent discussions about debugging etc made me do this, much like Doynax's stuff:
Macro for ca65:
.macro breakpoint name
.ident (.concat("br_", .string(name))):
.export .ident(.concat("br_", .string(name)))
.endmacro
Link line in your Makefile:
ca65 -C link -m map -Ln symbols $(OBJS) && sed 's/al [0-9A-F]* \.br_\([a-z]*\)/\0\nbreak \.br_\1/' < symbols > symbols2
Basically it tells ca65 to emit all labels into a file called symbols. The sed-script then locates all symbols starting with br_ and adds a breakpoint command after it.
To run in VICE:
x64 -moncommands symbols2 whateva.d64
This enables you to add breakpoints directly into your sourcecode like:
breakpoint flashcolors
inc $d020
jmp *-3
Have fun with future debugging! :)
|
|
... 27 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:watch fuckin whole first side
thats your own fault though, loaders for side 2 could be done in 1997 too (just like part selectors) :) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
that wouldnt make auto disk side change detection work tho. anyway after like the 8th time we tried the loader alone, instead of watching the whole side 1, to speed things up :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
no, but you could have tested only the last part of side 1 and the disk changing :) (you cant imagine how often i did that for artphosis.... argl) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
it comes back as we talk about it, things was we tested the loader seperately aswell, but that test case used a loader with disk change routines included, which was missing in the demo :P :) |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
And how would breakpoints have helped with this pebcak-situation? :-P |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
well, warpmode and modern cross asm env would have sped up the process a lot :) |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
Oswald: Just add "- Use one hour for crunching the file" and i will know what you are talking about ;-) |
| |
soci
Registered: Sep 2003
Posts: 480 |
Quoting BrushBut profiling is a different story.. The closest thing to profiling i've been using was to slam tons of watchpoints around the code part i was optimising, running it in vice, capturing the vice output into a text file and then calculating the "weight" of each instruction with some text based utilities. That was slow but sort of worked. But i would resort to it only in the worst case (that case was my worst case as it was not a simple inner loop optimization but something bigger with a complex flow and branching and i had to figure out the right mix depending on the input data)..
I know it's old thread, but whatever.
The closest I've got to profiling was using kcachegrind like this:
http://singularcrew.hu/temp/2016-09-04-160615_3840x1600_scrot.p..
It shows ~28 seconds of game play on second level as it's less boring than optimizing CFSfsck down from 6:46 to 5:16 for a test set of ~8200 files (147MiB).
But the majority of code here can be "profiled" with border colour changes easily and that's what actually was used for the game. |
| |
Brush
Registered: Apr 2002
Posts: 22 |
@soci would you be so kind to explain a little more what are we having here? How are you feeding kcachegrind? |
| |
soci
Registered: Sep 2003
Posts: 480 |
So what happens is this:
At compile time I write a label file and a line number annotated listing with 64tass. These are used to map instruction addresses and labels to source files and line numbers.
Then I run the binary in VICE and start a trace at the place of interest for as long as necessary. This gets me the usual address, cycle, instruction information along with DMAs and interrupts. No special hacks where done to VICE.
This trace is processed, cycle counts are assigned to instruction locations and branch taken/not taken, jump and call counts are calculated.
In case of a subroutine call all cycles spent in the subroutine are assigned to "functions" whose names are determined from the labels. This works by stack tracking.
Character and sprite DMAs are not counted against the affected instructions otherwise this would be a huge source of error.
Interrupt "entry" cycles are handled specially or else these are wrongly assigned. Also cycles spent in interrupts are assigned to interrupt functions only, but not to the interrupted functions. Unlike simple subroutine calls, where called routine cycles are included.
There's a special case for the automatic "long" branches. For these the taken/not taken counts would be mixed up if naively processed.
With all these stats a ~200 line python script can produce the callgrind.out file. This contains cycle counts for instructions, line number and file assignment, calls/jumps statistics and function locations.
Based on this input kcachegrind can figure out a call graph and how much cycles are spent in routines and how these are used in it's subroutines.
Also it can display spent cycle counts, branches, jump, call numbers and jump arrows right in the source files. This comes especially handy in macro heavy cases, where the source is much different from the disassembly. And of course stuff is clickable and can be navigated through source files.
So that's it. Kcachegrind is a rather nice environment for figuring out where optimization is likely to make a difference and where not.
But apparently it's a massive overkill for optimizing regular 6502 code at least that's what I blame the low interest on.
Anyway, here's a sample callgrind.out file you can try with the Kobo64 source files (r157, sourceforge):
http://singularcrew.hu/temp/callgrind.zip |
| Previous - 1 | 2 | 3 | 4 - Next |
