Dynamic ASM linking

[aineros85]

This idea is aimed at reducing the size of the compiled ASM to make more room for samples / music. Within a given ROM, how much of the ASM code is actually used, and would elimination of the code for that particular ROM be worth it?

The general idea is to break the command implementations into separate, labeled procedures referenced by a dispatch table. The dispatch table would be different for each ROM, depending on what commands are actually used. For example, if $F4$01 is never used, then the code is never emitted. This approach has a few other implications:

• New command codes could be added with little to no penalty for ROMs that don't require them.
• Two-byte commands could be reduced to single-byte commands, if there are unused single-byte commands within a given ROM.
• The compiler would need to track which commands are used, most likely in something like a bit field or bit array, then build the dispatch table.
• Commands could be more modularized and specified per-project, rather than modifying the global ASM.

And most importantly, this would require support from Asar. Namely, compiling the ASM to an intermediate object file (similar to COFF linkers), and then linking those dynamically into the final .bin. This also means that, provided the object files, AMKFF wouldn't need to recompile the .asm and ship Asar.exe in the source tree.

The question is, would something like this be worth it?

[KungFuFurby]

See #134, which I believe is the core of what you're going after. I actually don't want to make the C++ side too messy, so I want to do #229 and completely refactor the music output to .asm files instead before doing something like this.

I have a two-pass system implemented in my own sound driver (separate from AddmusicKFF), and that is done by generating defines, sending them to a file, then executing the same file again with a special define indicating that it is the second pass. I actually have the table being fully generated there.

See this SMWCentral post (and some preceding posts) about what I was thinking about. Some of them only need the command code filtered out: others have extra defines attached to them that activate specific sections of code that are otherwise not used.