How well optimized is my 32 bit NASM BASIC interpreter?

[PyDOS8]

section .text  
    global _start
    global _exit
    global _SyntaxError
    global _Execute
    global _Add
    global _Sub
    global _Mul

section .data
    userInp: db dup (0)
    instructions: db "PRINT", db "EXIT", "ADD"
_start:
    extern _scanf

    ; Output "BASIC > "

    ; Setup the needed registers
    MOV ESI, "BASIC > "
    
    ; Output
    MOV EAX, 4
    MOV EBX, 1
    MOV ECX, ESI
    MOV EDX, 8
    INT 0x80

    ; Get user input
    MOV ECX, userInp
    MOV EDX, 20
    CALL _scanf

    ; Read the user input
    MOV ESI, [userInp]

    ; Check if the user input is valid
    CMP ESI, [instructions]
    JNE _SyntaxError

    CMP ESI, "PRINT"
    JE _PRINT

    CMP ESI, "EXIT"
    JE _exit

    CMP ESI, "ADD"
    JE _Add

    CMP ESI, "SUB"
    JE _Sub

    CMP ESI, "MUL"
    JE _Mul

_PRINT:

    ; Setup the register
    MOV ESI, "Enter > "

    ; Output
    MOV EAX, 4
    MOV EBX, 1
    MOV ECX, ESI
    MOV EDX, 8
    INT 0x80

_SyntaxError:
    
    ; Setup the register
    MOV ESI, "Syntax Error!"

    ; Output
    MOV EAX, 4
    MOV EBX, 1
    MOV ECX, ESI
    MOV EDX, 13
    INT 0x80

_exit:
    MOV EAX, 1
    XOR EBX, EBX
    INT 0x80

_ADD:

    ; Setup the register
    MOV ESI, "Enter a number > "
    
    ; Output
    MOV EAX, 4
    MOV EBX, 1
    MOV ECX, ESI
    MOV EDX, 15
    INT 0x80

    ; Get user input
    MOV ECX, userInp
    MOV EDX, 4
    CALL _scanf

    ; Store user input
    MOV EDI, [ECX]

    ; Output
    MOV EAX, 4
    MOV EBX, 1
    MOV ECX, ESI
    MOV EDX, 15
    INT 0x80

    ; Get user input
    MOV ECX, userInp
    MOV EDX, 4
    CALL _scanf

    ; Store user input
    MOV ESI, [ECX]

    ; Add the result
    ADD EDI, ESI

    ; Output the result
    MOV EAX, 4
    MOV EBX, 1
    MOV ECX, EDI
    MOV EDX, 4
    INT 0x80

_SUB:

    ; Setup the register
    MOV ESI, "Enter a number > "

    ; Output
    MOV EAX, 4
    MOV EBX, 1
    MOV ECX, ESI
    MOV EDX, 15
    INT 0x80

    ; Get input
    MOV ECX, userInp
    MOV EDX, 4
    CALL _scanf


    ; Store input
    MOV EDI, [ECX]

    ; Reset buffer
    MOV BYTE [userInp], 0

    ; Output
    MOV EAX, 4
    MOV EBX, 1
    MOV ECX, ESI
    MOV EDX, 15
    INT 0x80

    ; Get input
    MOV ECX, userInp
    MOV EDX, 4
    CALL _scanf

    ; Store input
    MOV ESI, [ECX]

    ; Subtract the result
    SUB EDI, ESI

    ; Output the result
    MOV EAX, 4
    MOV EBX, 1
    MOV ECX, EDI
    MOV EDX, 4
    INT 0x80

_Mul:
    ; Setup the register
    MOV ESI, "Enter a number > "

    ; Output
    MOV EAX, 4
    MOV EBX, 1
    MOV ECX, ESI
    MOV EDX, 15
    INT 0x80

    ; Get input
    MOV ECX, userInp
    MOV EDX, 4
    CALL _scanf

    ; Store input
    MOV EDI, [ECX]

    ; Output
    MOV EAX, 4
    MOV EBX, 1
    MOV ECX, ESI
    MOV EDX, 15
    INT 0x80

    ; Get input
    MOV ECX, userInp
    MOV EDX, 4
    CALL _scanf

    ; Store input
    MOV ESI, [ECX]

    ; Multiply the result
    MUL ESI, EDI

[CopperEagle]

Nice! Programming in ASM can be satisfying, isn't it. ;)

So what do you want to optimize? Speed of running? Size of the binary? What architecture are you targeting?

As for the speed: I did not profile. But you can argue that the vast amount of processing is system call related (either the call itself or setting up the registers). Otherwhise, your program does not really need much memory and registers are fast. So, if you want to use this piece of code in a tight loop without the user in it, you should try to output less (to reduce interrupts), etc.

For the size of the binary. I kind of don't want to be that guy but technically speaking you could probably reduce the size. The fallowing snippet reappears a lot in your code:

    ; Output the result
    MOV EAX, 4
    MOV EBX, 1
    MOV ECX, EDI ; sometimes ESI
    MOV EDX, 4
    INT 0x80

So you could make that a function (without allocating a stack frame), then call it. There should not really be any performance penalty for that. A call is an unconditional jump and prefetchers on modern machines should be pretty good with those. Also the binary size is small, so it will likely be fully on the cache anyways. Branch prediction for unconditional jumps is trivial too and so the instruction pipeline should be full.

If you spotted anything else, let me know.

[PyDOS8]

Yeah, it is really worth it but it is very hard.

[CopperEagle]

In the end, only write it when necessary. Languages like C allow good integration with Assembly. That way you can be more productive. Assembly keeps us bogged down in details we shouldn't spend too much time on, sometimes/usually.