Added support for mnemonic mappings #17
Conversation
File format is magic line "eclmap", followed by entries: <opcode> <signature> <mnemonic> # comments "signature" is supposed to describe opcode arguments. It will be unimplemented for now, but it's supposed to be replacing hardcoded id_format_pair_t arrays. "mnemonic" is the usual C identifier [a-zA-Z_][0-9a-zA-Z_]*. Can't start with ins_ for obvious reasons. You can specify "?" as a signature or mnemonic, which basically means "don't touch this entry". The idea is that one eclmap could have: 123 ? my_awesome_mnemonic and another one could have: 123 fff ? but if you load both of them, they will combine into a single entry (also, possibly combining with built-ins) Right now you can only load one eclmap, because arguments in thtk are weird :^)
Originally I wanted there to be checks for when g_eclmap is NULL, but then I forgot. :^) This seems like a better solution, because in the end were gonna have builtins, so it's always going to be allocated.
Someone needs to do the manpages.
|
Incomplete th07 eclmap, based on the th06 one. |
| } | ||
| else { | ||
| ent.signature = ptr; | ||
| if(ptr[0] == '_') ptr[0] = '\0'; /* allow empty strings to be specified with "_" */ |
There was a problem hiding this comment.
Just out of interest, this is for functions that don't take a parameter?
There was a problem hiding this comment.
Looking good so far. (In fact, while testing this, I only found some minor portability issues with thecl itself, not with any of this code.) While I definitely prefer to just hardcode those mappings, this is not only a good compromise until we've reverse-engineered eclmaps for all games, but generally a good idea to allow non-developers to identify both old and new games independently from us. (Compiling still is hard, unfortunately.)
What are the plans for the signature? Three things come to mind:
- Validating incoming eclmaps against the internal tables and immediately throwing an error when a new game changes the format of an instruction introduced in an earlier game.
- Printing pretty function prototypes at the top of dumped files, as an aid to ECL hackers. (Especially if we end up hardcoding them and they end up not having the mapfiles.)
- Supplementing the internal function format tables instructions, allowing others to identify newly introduced functions without writing a single line of C code. (As someone who turned thcrap support for new games into a speedrun, I highly approve of this.)
Don't know if you want to extend the format to also cover the main routines of TH06-TH08. Since they assign different functions to the same opcodes, the format would probably need a second "section" introduced by a new magic word. Or we just hardcode that one as a separate eclmap_t once we get to properly dump and lex it, since it doesn't have that many instructions and we're never going to see it again.
Before releasing this, the manpage also needs to be updated.
This PR adds support for "eclmaps", simple format that I came up with. Here's an example of usage:
$ thecl -d6m my_th6.map ecldata1.ecl ecldata1.ecswill decode ecldata1 and translate the instructions to mnemonics using mappings my_th6.map.
First line is "eclmap" (signature), all the other lines are entries:
<opcode> <signature> <mnemonic>Example:
0 ? noopThe question mark means empty field. (Later you will be able to load multiple mappings and combine them into one.)
Here are some example eclmaps:
map for th06 (source)
map for th13 (source)
fixes #12