Re: [hatari-devel] Debugger command improvements (was: Native feature proposal) |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
Attached patch:
* add word & long write support to memwrite command
* implements temp / fake registers for debugger,
(which can be used for user calculations)
For example, to accumulate a sum of values at address $ffff00
to fake register t0, and count of these increments in t1:
r t0 = "t0 + ($ffff00)"
r t1 = "t1 + 1"
One can then get average for the increments:
e = t0 / t1
Or with rounding:
r t0 = "t0 + t1/2"
e = t0 / t1
Note: One cannot do rounding in single step because calculations
respect operation precedence, and there currently isn't any
support for changing the precedence ('()' is used for indirect
addressing, not precedence).
And to write that average back to the program, to a long
variable represented by symbol zzz:
memwrite l zzz "t0 / t1"
Any thoughts?
- Eero
PS. User variables which names user could specific himself
are likely to be nicer, but extra "registers" were much
easier to add to debugger.
On 05/04/2018 01:18 AM, Eero Tamminen wrote:
On 05/03/2018 11:11 AM, tin@xxxxxxxxx wrote:
Note that this could be done with the debugger too, and that way
overhead would be zero cycles for the emulated code.
Had thought about that, but my main caveat was that I didn't see a way
of having code output a a warning, if certain timing constraints are
not met,
If your code has a symbol for address at which point the timing
constraint needs to be checked, and a symbol for a variable that
contains the constraint value, you can have breakpoint using that:
b pc = _checkpoint && LineCycles > (_constraint) :trace
compute the average etc.
You can have a breakpoint that invokes debugger script
that outputs the value. You then just extract the values
from saved debugger output and calculate their average with
something like python.
You could also have a counting breakpoint to trigger after
certain number of frames, e.g. 200:
b pc = _checkpoint :200 :file average.ini
So the divisor is 200, and you can calculate the average
in "average.ini" if your program sums the value to be
averaged somewhere.
To help doing all of that in the debugger, I'm thinking that
I should add few new features to debugger:
* "register" command can assign values also to debugger
internal "registers". E.g. t0-t9 ("t" for "temp).
* or support to assigning values to arbitrarily named
variables with "evaluate" command
* "w" command option to write words (w) and longs (l)
to memory, in addition to bytes
So that things like this would be possible:
r t0="(_some_value_addr) + ($200)"
e sum = sum + (_counter)
w l _average_addr "sum/200"
(It's a bit annoying that () is reserved for indirect
addressing so one cannot use that for precedence, and
using '"' chracters for indicating expressions to
evaluate might not have been best choice.)
- Eero
"Never underestimate the Hatari debugger" as the saying goes - so I
wouldn't be surprised at all if even that is possible atm with the
current debugger implementation.
So the only thing speaking /for/ a new Natfeat here is the ability to
compute sth with and react to the results. The debugger approach
clearly beats NatFeats in the timing department.
Did I mention that the debugger is really awesome?
Eero Tamminen <mailto:oak@xxxxxxxxxxxxxx>
2. Mai 2018 um 23:48
Hi,
I don't think that in itself is a problem, as long as API doesn't
overlap with the other NF APIs, or other ways of doing the same.
Note that this could be done with the debugger too, and that way
overhead would be zero cycles for the emulated code.
One can just add a symbol to a place in the code where one
wants these values to be output, and them add tracing
breakpoint for that symbol in the debugger:
b pc = show_values :quiet :lock
Breakpoint ":lock" option shows the info (that has been "locked"
to be show on debugger entry), without actually stopping:
CPU=$fc1572, VBL=413, FrameCycles=160334, HBL=0, LineCycles=78, DSP=$0
If that's not enough, one can use this instead:
b pc = show_values :quiet :trace :file show-values.ini
And do the desired outputs in "show-values.ini" file, e.g:
e VBL
e HBL
e LineCycles
e FrameCycles
e CycleCounter
If additional emulation state info variables are needed,
adding those isn't a problem.
Output of above isn't very concise though. If that's a problem,
I accept proposals on what to do to improve that. :-)
- Eero
Thorsten Otto <mailto:admin@xxxxxxxxxxx>
2. Mai 2018 um 08:49
On Dienstag, 1. Mai 2018 20:59:34 CEST tin@xxxxxxxxx wrote:
Hi,
here's a proposal for two very handy NF calls I've patched into my
Hatari branch for a while now:
NF_STDERR_NUM: output a number without the need to convert it to a
string on the ST.
There is already a more general version of something like this:
DEBUGPRINTF.
It takes a printf-like string and a variable number of arguments,
just like
printf. Drawback: since the natfeats interface requires all
parameters to be
longs, you have to be careful that all arguments really fulfill that
requirement. Not a problem when using GCC, but maybe when using
compilers like
Pure-C with 16-bit ints. Also, floating point is not supported by that
interface. So i normally take a different approach: provide a wrapper
function
nf_debugprintf(), that prints to a static string, then outputs that
using
NF_STDERR.
NF_FRAMEPOSITION: copies frame info (nVBLs, nHBL, nScanlinesPerFrame,
nCyclesPerLine and CyclesPerVBL) into a memory area given by the guest
program. This makes it very easy to time code parts cycle-exact at
runtime and do a quick check on optimizations as well as the average
time a code part takes between frames. Also it's easier to check where
exactly a code runs (relative to the frame start).
That would be very Hatari specific.
Any objections?
Yes. Please don't forget that there are other emulators around, and
that the
NatFeats interface is meant to be a general enhancements for those.
So please
don't wildly invent NatFeats that won't be documented, especially
when they
duplicate already existing functionality.
tin@xxxxxxxxx <mailto:tin@xxxxxxxxx>
1. Mai 2018 um 20:59
Hi,
here's a proposal for two very handy NF calls I've patched into my
Hatari branch for a while now:
NF_STDERR_NUM: output a number without the need to convert it to a
string on the ST. I often output internal state variables of a
running programm using NF_STDERR (e.g. taken frames per render,
clock-cycles of specific parts, control variables etc.). This way
printing these taking almost no cpu time and the developed programs
run-time behaviour isn't changed too much.
NF_FRAMEPOSITION: copies frame info (nVBLs, nHBL, nScanlinesPerFrame,
nCyclesPerLine and CyclesPerVBL) into a memory area given by the
guest program. This makes it very easy to time code parts cycle-exact
at runtime and do a quick check on optimizations as well as the
average time a code part takes between frames. Also it's easier to
check where exactly a code runs (relative to the frame start).
Any objections?
diff -r 0b167d350b14 src/debug/debugcpu.c
--- a/src/debug/debugcpu.c Sun May 06 17:34:51 2018 +0300
+++ b/src/debug/debugcpu.c Mon May 07 00:34:34 2018 +0300
@@ -42,6 +42,8 @@
static Uint32 disasm_addr; /* disasm address */
static Uint32 memdump_addr; /* memdump address */
+static Uint32 temp_regs[8]; /* temporary debugger "registers" */
+static bool bTempRegsUsed; /* whether to show temp regs */
static bool bCpuProfiling; /* Whether CPU profiling is activated */
static int nCpuActiveCBs = 0; /* Amount of active conditional breakpoints */
@@ -220,7 +222,8 @@
static const char* regs[] = {
"a0", "a1", "a2", "a3", "a4", "a5", "a6", "a7",
"d0", "d1", "d2", "d3", "d4", "d5", "d6", "d7",
- "pc", "sr"
+ "pc", "sr",
+ "t0", "t1", "t2", "t3", "t4", "t5", "t6", "t7"
};
return DebugUI_MatchHelper(regs, ARRAY_SIZE(regs), text, state);
}
@@ -228,24 +231,28 @@
/**
* Set address of the named 32-bit register to given argument.
- * Return register size in bits or zero for uknown register name.
- * Handles D0-7 data and A0-7 address registers, but not PC & SR
- * registers as they need to be accessed using UAE accessors.
+ * Handles T0-7 temp variables, D0-7 data and A0-7 address registers,
+ * but not PC & SR registers as they need to be accessed using UAE
+ * accessors.
+ *
+ * Return register size in bits or zero for unknown register name.
*/
int DebugCpu_GetRegisterAddress(const char *reg, Uint32 **addr)
{
- char r0, r1;
+ char r0;
+ int r1;
+
if (!reg[0] || !reg[1] || reg[2])
return 0;
-
+
r0 = toupper((unsigned char)reg[0]);
- r1 = toupper((unsigned char)reg[1]);
+ r1 = toupper((unsigned char)reg[1]) - '0';
if (r0 == 'D') /* Data regs? */
{
- if (r1 >= '0' && r1 <= '7')
+ if (r1 >= 0 && r1 <= 7)
{
- *addr = &(Regs[REG_D0 + r1 - '0']);
+ *addr = &(Regs[REG_D0 + r1]);
return 32;
}
fprintf(stderr,"\tBad data register, valid values are 0-7\n");
@@ -253,14 +260,25 @@
}
if(r0 == 'A') /* Address regs? */
{
- if (r1 >= '0' && r1 <= '7')
+ if (r1 >= 0 && r1 <= 7)
{
- *addr = &(Regs[REG_A0 + r1 - '0']);
+ *addr = &(Regs[REG_A0 + r1]);
return 32;
}
fprintf(stderr,"\tBad address register, valid values are 0-7\n");
return 0;
}
+ if(r0 == 'T') /* Temp regs? */
+ {
+ if (r1 >= 0 && r1 < ARRAY_SIZE(temp_regs))
+ {
+ *addr = &temp_regs[r1];
+ bTempRegsUsed = true;
+ return 32;
+ }
+ fprintf(stderr,"\tBad temp register, valid values are 0-7\n");
+ return 0;
+ }
return 0;
}
@@ -278,6 +296,8 @@
if (nArgc == 1)
{
uaecptr nextpc;
+ int idx;
+
/* use the UAE function instead */
#ifdef WINUAE_FOR_HATARI
m68k_dumpstate_file(debugOutput, &nextpc);
@@ -285,6 +305,19 @@
m68k_dumpstate(debugOutput, &nextpc);
#endif
fflush(debugOutput);
+ if (!bTempRegsUsed)
+ return DEBUGGER_CMDDONE;
+
+ fputs("Debugger temp registers:\n", debugOutput);
+ for (idx = 0; idx < ARRAY_SIZE(temp_regs); idx++)
+ {
+ if (idx && idx % 4 == 0)
+ fputs("\n", debugOutput);
+ fprintf(debugOutput, " T%c %08x",
+ '0' + idx, temp_regs[idx]);
+ }
+ fputs("\n", debugOutput);
+ fflush(debugOutput);
return DEBUGGER_CMDDONE;
}
@@ -336,7 +369,8 @@
return DEBUGGER_CMDDONE;
error_msg:
- fprintf(stderr,"\tError, usage: r or r xx=yyyy\n\tWhere: xx=A0-A7, D0-D7, PC or SR.\n");
+ fprintf(stderr,"\tError, usage: r or r xx=yyyy\n"
+ "\tWhere: xx=A0-A7, D0-D7, PC, SR, or T0-T7.\n");
return DEBUGGER_CMDDONE;
}
@@ -425,41 +459,92 @@
*/
static int DebugCpu_MemWrite(int nArgc, char *psArgs[])
{
- int i, numBytes;
+ int i, arg, values;
Uint32 write_addr, d;
- unsigned char bytes[256]; /* store bytes */
+ union {
+ Uint8 bytes[256]; /* store bytes */
+ Uint16 words[128]; /* store words */
+ Uint32 longs[64]; /* store longs */
+ } store;
+ char mode;
if (nArgc < 3)
{
return DebugUI_PrintCmdHelp(psArgs[0]);
}
+ arg = 1;
+ mode = tolower(psArgs[arg][0]);
+
+ if (psArgs[arg][1])
+ /* not single mode char */
+ mode = 'b';
+ else if (mode == 'b')
+ arg += 1;
+ else if (mode == 'w')
+ arg += 1;
+ else if (mode == 'l')
+ arg += 1;
+ else
+ /* not mode char */
+ mode = 'b';
+
/* Read address */
- if (!Eval_Number(psArgs[1], &write_addr))
+ if (!Eval_Number(psArgs[arg++], &write_addr))
{
fprintf(stderr, "Bad address!\n");
return DEBUGGER_CMDDONE;
}
- numBytes = 0;
-
- /* get bytes data */
- for (i = 2; i < nArgc; i++)
+ /* get the data */
+ values = 0;
+ for (i = arg; i < nArgc; i++)
{
- if (!Eval_Number(psArgs[i], &d) || d > 255)
+ if (!Eval_Number(psArgs[i], &d))
{
- fprintf(stderr, "Bad byte argument: '%s'!\n", psArgs[i]);
+ fprintf(stderr, "Bad value '%s'!\n", psArgs[i]);
return DEBUGGER_CMDDONE;
}
-
- bytes[numBytes] = d & 0x0FF;
- numBytes++;
+ switch(mode)
+ {
+ case 'b':
+ if (d > 0xff)
+ {
+ fprintf(stderr, "Illegal byte argument: 0x%x!\n", d);
+ return DEBUGGER_CMDDONE;
+ }
+ store.bytes[values++] = (Uint8)d;
+ break;
+ case 'w':
+ if (d > 0xffff)
+ {
+ fprintf(stderr, "Illegal word argument: 0x%x!\n", d);
+ return DEBUGGER_CMDDONE;
+ }
+ store.words[values++] = (Uint16)d;
+ break;
+ case 'l':
+ store.longs[values++] = d;
+ break;
+ }
}
/* write the data */
- for (i = 0; i < numBytes; i++)
- STMemory_WriteByte(write_addr + i, bytes[i]);
-
+ for (i = 0; i < values; i++)
+ {
+ switch(mode)
+ {
+ case 'b':
+ STMemory_WriteByte(write_addr + i, store.bytes[i]);
+ break;
+ case 'w':
+ STMemory_WriteWord(write_addr + i*2, store.words[i]);
+ break;
+ case 'l':
+ STMemory_WriteLong(write_addr + i*4, store.longs[i]);
+ break;
+ }
+ }
return DEBUGGER_CMDDONE;
}
@@ -735,10 +820,11 @@
false },
{ DebugCpu_MemWrite, Symbols_MatchCpuAddress,
"memwrite", "w",
- "write bytes to memory",
- "address byte1 [byte2 ...]\n"
- "\tWrite bytes to a memory address, bytes are space separated\n"
- "\tvalues in current number base.",
+ "write bytes/words/longs to memory",
+ "[b|w|l] address value1 [value2 ...]\n"
+ "\tWrite space separate values (in current number base) to given\n"
+ "\tmemory address. By default writes are done as bytes, with\n"
+ "\t'w' or 'l' option they will be done as words/longs instead",
false },
{ DebugCpu_LoadBin, NULL,
"loadbin", "l",