Post Reply 
newRPL: [UPDATED April 27-2017] Firmware for testing available for download
10-04-2016, 12:16 PM (This post was last modified: 10-04-2016 12:53 PM by Bruno.)
Post: #401
RE: newRPL: [UPDATED September-17-16] Firmware for testing available for download
Thank you Claudio, now I can try and learn funny stuffs Smile
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
- ??

please, excuse my poor english
Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
RE: newRPL: [UPDATED September-17-16] Firmware for testing available for download - Bruno - 10-04-2016 12:16 PM



User(s) browsing this thread: 1 Guest(s)