Repository navigation
Conversation
5b8d1f4 to
4b7b64e
Compare
For scripted tests and profiling of programs: read and write memory, hold a key while inspecting the calculator, see where a program is stuck (registers, IX frames), and read the cycle counters, flash cache misses included, which show how much time a program loses to the revision M serial flash. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Builds without the debugger (cemu-headless, the autotester) drop what programs write to the debug console ports. With the new opt-in define DEBUG_CONSOLE_SUPPORT (see core/Makefile), they print it through gui_console_printf / gui_console_err_printf, as the debugger build does when soft commands are on, so test scripts can read a program's dbg_printf output. It is off by default, so other consumers of the core are not affected. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… timing Since revision M, code runs from serial flash through an 8 KB cache, and a miss costs about 197 cycles: a large program can spend a third of its time there. The core can now count, per 32-byte flash line, the entries and the misses (flash_line_profile), or report every line entered (flash_line_hook), and cemu-headless exposes both (line-profile, line-trace). flash-cycles gives every flash read a fixed cost instead, close to a pre-revision-M calculator with n=10. Measured with them on KhiCAS: misses were ~30% of its cycles, and a cache simulation of its trace showed that even a perfect code layout would remove only about a quarter of them. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
4b7b64e to
1be9bfb
Compare
As suggested in review: #if defined(DEBUG_CONSOLE_SUPPORT) || defined(DEBUG_SUPPORT) instead of && !defined(DEBUG_SUPPORT). A build with the debugger now prints what programs write to the debug console ports through this code too, before the debugger's soft commands are looked at, so whatever the soft commands setting; opening the debugger and clearing the console are still soft commands.
|
Meat proxying Codex's tests with this PR checked out: Preserve the software-command setting when handling debug-console writesThe new console handler executes whenever either #if (defined(DEBUG_SUPPORT) && defined(DBG_SOFT_COMMANDS)) || defined(DEBUG_CONSOLE_SUPPORT))Other findings:
|
This branch has not been deployed
3 participants
These are the emulator tools I used while speeding up FlowCE (a KhiCAS fork), rewritten for upstream. Three commits, each usable on its own:
peek,poke,keydown,keyup,regs,statsandlcd-dma. Read and write memory, hold a key while inspecting the calculator, see where a program is stuck (registers and IX frames), and read the cycle counters, flash cache misses included.DEBUG_CONSOLE_SUPPORT, prints the debug console without DEBUG_SUPPORT, sodbg_printfoutput can reach cemu-headless and the autotester (on stderr). It is off by default (a commented-out line in core/Makefile, like DEBUG_SUPPORT), so other consumers of the core are unaffected, as calc84maniac suggested.line-profile), an ordered trace of the lines entered for cache simulations (line-trace), andflash-cycles <n>to approximate pre-revision-M flash timing with a revision M ROM.Everything is documented in headless_protocol.md. Tested on Linux with a TI-84 Plus CE ROM: each command on a running program; the line profile and the trace agree (same number of line entries);
flash-cycles 10makes a KhiCAS computation about 2.4 times slower;dbg_printfoutput appears on stderr when the core is built with-DDEBUG_CONSOLE_SUPPORT, and not without it.For what it's worth, on KhiCAS cache misses were about 30% of the cycles, but a cache simulation of its trace showed that even a perfect code layout would remove only about a quarter of them.
Assisted by Claude code (plz don't discriminate just trying to help ;)