10-04-2016, 12:16 PM
Thank you Claudio, now I can try and learn funny stuffs
This is very impressive all the work you've done !!! Congrats.
Let's talk about the code from now, and here is my first question (Don't worry, I'll try to not flood you !) :
Why did you use a slow O(n) switch/case structure in the library handlers instead of a fast O(1) structure like an array of function pointers ?
(remember the linktable from our old and so loved RPL)
An dirty example to be sure you understand me :
I do not find any 'bad' reason for that :
- the enum will generate appropriate index for an array
- the system opcodes could be handled outside the array
- ??
This is very impressive all the work you've done !!! Congrats.
Let's talk about the code from now, and here is my first question (Don't worry, I'll try to not flood you !) :
Why did you use a slow O(n) switch/case structure in the library handlers instead of a fast O(1) structure like an array of function pointers ?
(remember the linktable from our old and so loved RPL)
An dirty example to be sure you understand me :
Code:
#define LIBRARY_NUMBER 1234
#define COMMAND_LIST \
CMD(CMD1,MKTOKENINFO(4,TITYPE_NOTALLOWED,1,2)), \
...
CMD(CMDN,MKTOKENINFO(4,TITYPE_NOTALLOWED,1,2))
...
// One function per exported command
void l1234_cmd1 (void) {
...
}
...
void l1234_cmdN (void) {
...
}
void LIB_HANDLER() {
...
// Here is the command's array of function pointers
void (*cmds[N]) (void) = {
l1234_cmd1,
...,
l1234_cmdN
}
if (OPCODE(CurOpcode) < N) {
// Direct call to the command's function
cmds[OPCODE(CurOpcode)](void);
return;
}
// Add here the switch/case to handle system opcodes
rplError(ERR_INVALIDOPCODE);
return;
}
I do not find any 'bad' reason for that :
- the enum will generate appropriate index for an array
- the system opcodes could be handled outside the array
- ??