In
this post, byuu mentioned that "very few people have the firmware" for the DSP included in several Super NES games. Thus many emulators have a high-level emulation (HLE) that performs the same calculations. Has anyone looked into modeling how long the authentic DSP-1's calculations take so that games run closer to the proper speed even with HLE? I can run tests on my SNES PowerPak because it has a DSP, presumably pulled from some cheap game that had one.
If you want to deduce approximate timings for functions, it's sufficient to use higan's uPD7725 core with the DSP-n firmware for that.
It'd be much better if we could just get firmware included with games. The LLE isn't really much of a performance penalty, will allow a future where homebrew devs can make hypothetical DSP-5+ and ST-012+ modules, and is about 20x less emulator code for a uPD7725 core than a DSP-1 + DSP-2 + DSP-4 + ST-010 core (with no playable DSP-3 + ST-011 cores available in HLE.)
As a final alternative, an open source, redistributable DSP-1 firmware file would go a long way in covering every case most people care about other than Top Gear 3000. The program ROM is 6KiB of 24-bit instruction words, meaning it's "only" 2048 (VLIW) opcodes for a full DSP-1 implementation.
But if someone's in the market to make a homebrew alternative for something, please make a complete GBA BIOS replacement instead :D
Determining execution time of the DSP program is similar to the classic computer science Halting Problem.
Not saying it can't be approximated, but by the time you take into account all the values of all the possible matrices and function input values, you're better off just executing the code directly and seeing how many ticks go by until it halts with the answer.