I've decided to add Z80 syntax highlighting into my asm source documentation generator so I decided to see if I could make a really fast opcode mnemonic matcher. Somehow doing a strcmp() for every possible opcode didn't seem that efficient!
This is what I have come up with. Perhaps someone else might find it useful. Note that I know I have omitted at least one opcode (an undocumented one: SL1/SLL), so if anyone spots any more, please let me know. Also report any bugs, please
This code only detects the actual opcode mnemonic, not the operands (except the conditionals of the JP/JR/CALL/RET opcodes, but I'm not sure if they count as operands or not).
It's lightning fast, using hand-coded state tables for the matching. It's kinda like a hand-coded regular expression matcher.
By default, it will only search the start of the string, skipping any horizontal whitespace characters (TAB & SPACE). There is a #define in mnemonic.c (SEARCH_STRING) which will allow you to ignore all characters until a match is made or the end of the line/string is reached. This is probably the most useful mode for syntax highlighting purposes.
I hope someone finds this useful or at least interesting.
header
implementation
console mode test program
EDIT:
One other thing I should mention in case it causes confusion, atomic instructions (those with no operands) will match if the next character is NULL, CR or LF. Because they don't need operands, it doesn't matter.
The other instructions will not match on NULL/CR/LF - only on TAB/SPACE (this is why there is a SPACE after the XOR in the test string in test.c). Since they need operands, it can't be a valid instruction if we are at the end of the string/line! But I'm thinking it might be more useful - or at least consistent - to have all opcodes match on NULL/CR/LF. The calling program can do further testing if required. What does everyone think?
[C] Fast Z80 opcode matching
Moderator: MaxCoderz Staff
[C] Fast Z80 opcode matching
Last edited by qarnos on Thu 24 Apr, 2008 10:41 am, edited 3 times in total.
"I don't know why a refrigerator is now involved, but put that aside for now". - Jim e on unitedti.org
avatar courtesy of driesguldolf.
avatar courtesy of driesguldolf.
-
- Calc King
- Posts: 1513
- Joined: Sat 05 Aug, 2006 7:22 am
I forgot it existed.King Harold wrote:May I ask why you omitted SLL/SL1?
Plus, the opcode list I was using didn't list it.
It's ok - I will fix it
If you've downloaded the code already, try again 'cos I made some changes to make it more user friendly (added the STRING_SEARCH #define).
"I don't know why a refrigerator is now involved, but put that aside for now". - Jim e on unitedti.org
avatar courtesy of driesguldolf.
avatar courtesy of driesguldolf.
*bump* (sorry)Dwedit wrote:Yay, finite state machines! It's a good way to recognize instructions.
The other good way is to just use a hashtable.
Yeah, I agree with that. And for the less experienced, or ones without libraries for that, there is always the binary search. All you need to do is sort the list.
-
- Calc King
- Posts: 1513
- Joined: Sat 05 Aug, 2006 7:22 am