int foo(int a, int b, int c, int d, int e, int f, int g, int h, int i, int j, int k, int l) {
    
}
    

Good evening.
I would like to know how to have a function with many parameters. Let's imagine this in C :

Code:

int foo(int a, int b, int c, int d, int e, int f, int g, int h, int i, int j, int k, int l) {
    
}
    

Okay, it's stupid, but it's for example.
So how do you implement this in FASM? Because, of the registers, one does not have an infinity of them...
Any ideas ?

proc foo c\
     a, b, c, d, e, f, g, h, i, j, k, l
     ...
endp    

When you don't have enough registers, you use stack. Push pop.

Ha, okay, I get it

But could you elaborate a little on the "proc", to see to what extent it is possible to deploy this method. Thanks

; calling function with all parameters on the stack
; note parameters pushed in reverse order since stack grows down
push l
push k
push j
push i
push h
push g
push f
push e
push d
push c
push b
push a
call foo


; in foo, access parameters from esp if you want (each is 4 bytes here)
; the location at esp+0  (i.e. [esp]) is the return ADDRESS of the function
; [esp+4] skips that and accesses a, [esp+8] accesses b, and so on
foo:
mov eax, [esp+4*3]  ; accesses c, 3rd parameter, puts it in eax

; at end of function, you should "clean" all the parameters (restore stack pointer above them) so that the caller doesn't have to (this is stdcall)
ret 4*12  ; because you have 12 parameters, this simply returns and then ADDS 4*12 to esp (moves it up, which is "back")    

Code:

; in foo, access parameters from esp if you want (each is 4 bytes here)
; the location at esp+0  (i.e. [esp]) is the return ADDRESS of the function
; [esp+4] skips that and accesses a, [esp+8] accesses b, and so on
foo:
mov eax, [esp+4*3]  ; accesses c, 3rd parameter, puts it in eax

; at end of function, you should "clean" all the parameters (restore stack pointer above them) so that the caller doesn't have to (this is stdcall)
ret 4*12  ; because you have 12 parameters, this simply returns and then ADDS 4*12 to esp (moves it up, which is "back")    

Another option that almost no one uses is to pass a single pointer to an array of arguments. I like the ENTER instruction because it also can copy part of the previous stack frame - almost no one uses that anymore either.

This led to a perception of ENTER as bloated ...

MACRO ENTER num,k
  LOCAL level,temp
  level = k MOD 32
  push rbp
  mov [temp],rsp    ; temp is internal to the CPU 
  REPEAT level - 1  ; skip for K = 0,1
    lea rbp,[rbp-8] ; don't effect flags
    push qword [rbp]
  END REPEAT
  IF level > 0
    push [temp]
  END IF
  mov rbp,[temp]
  sub rsp,num
END MACRO    

I figured this is important since you said you want to write a (toy?) compiler :p

Code:

MACRO ENTER num,k
  LOCAL level,temp
  level = k MOD 32
  push rbp
  mov [temp],rsp    ; temp is internal to the CPU 
  REPEAT level - 1  ; skip for K = 0,1
    lea rbp,[rbp-8] ; don't effect flags
    push qword [rbp]
  END REPEAT
  IF level > 0
    push [temp]
  END IF
  mov rbp,[temp]
  sub rsp,num
END MACRO    

RBP doesn't need to be on the stack - could be any memory buffer. The first parameter can be zero.

; stack aligned MOD 16
    lea rbp,[_APIs] ; no alignment required on this buffer

    enter 0,4*3
    pop rbp
    pop rcx rdx r8 r9
    retn

    dq 0 ; hWnd
    dq lpText
    dq lpCaption
    dq 0 ; uType
    dq _jmp__MessageBoxW
    dq _continue
    rq 5
_APIs:

lpText du "(K)not in a tree.",0
lpCaption du "What?",0

_jmp__MessageBoxW: jmp [user32.MessageBoxW]

_continue:
    leave ; not needed we know where RBP/RSP is    

bitRAKE wrote:

I like the ENTER instruction because it also can copy part of the previous stack frame - almost no one uses that anymore either.

I think this may be a side-effect of everyone switching to a faster sequences like PUSH EBP / MOV EBP,ESP / SUB ESP,X in place of ENTER X,0. This led to a perception of ENTER as bloated and deprecated so we stopped thinking about it and forgot that it does in fact have a second parameter.

The thought of ENTER being bloated is weird. It is shorter than the PUSH/MOV/SUB sequence.

Only barely.

push ebp
mov ebp, esp
sub esp, 1024    

My point is that it saves a few bytes in very limited environments