newRPL: [UPDATED April 27-2017] Firmware for testing available for download

[Bruno]

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 :

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
- ??