Crides de funció: CPU, registres i stack
Bloc 1 · Desenvolupament de Programari en Espai d’Usuari
On ens vam quedar?
int main(void)
{
foo();
}Però què fa la CPU quan executem aquesta crida?
Un programa és una seqüència d’instruccions
La CPU executa instruccions una darrere l’altra sequencialment.
Les instruccions poden ser de diferents tipus (aritmètiques, de salt, de càrrega,…) i la seva mida no és sempre la mateixa: en x86-64 és variable (entre 1 i 15 bytes segons la instrucció); en AArch64 és fixa, sempre 4 bytes.
Per això en AArch64 la instrucció següent sempre és PC + 4. En x86-64, RIP + 4 no funciona en general — cal conèixer la longitud real de la instrucció actual per saber on comença la següent.
Com sap la CPU quina instrucció ha d’executar?
RIP: Instruction Pointer
- x86-64:
RIP: Instruction Pointer. - AArch64:
PC: Program Counter.
El nom canvia, però el concepte és el mateix: indicar on continua l’execució.
Ara fem foo()
{
foo();
printf("fi\n");
}Quan foo() acaba, com sap la CPU on ha de tornar?
Return address
Return address: la instrucció a la qual cal tornar un cop acabada la funció cridada.
Una crida de funció necessita conservar el punt al qual haurà de tornar.
call i ret (x86-64)
BL i RET (AArch64)
BL foo salta a foo i desa l’adreça de retorn a X30 (Link Register).
El mecanisme físic canvia (pila vs. registre), però C no en sap res: foo() és foo() en ambdues arquitectures. L’ABI i el maquinari decideixen com es representa la crida. El llenguatge només veu l’abstracció crida una funció i torna. Aquesta separació entre abstracció i mecanisme és la mateixa raó per la qual el mateix codi C es pot compilar per a qualsevol de les dues.
I si foo() mateixa crida bar()? BL bar torna a escriure X30 — qui preserva llavors l’adreça de retorn original de foo()? (hi tornarem amb caller-saved / callee-saved)
RSP / SP
RSP/SP identifica la posició actual del stack: push i pop (x86-64) el modifiquen.
Per a AArch64 no parlem de push/pop com a instruccions literals — el model conceptual és el mateix, però la implementació és diferent.
Una funció necessita espai
void foo(void)
{
int x = 10;
int y = 20;
}Què passa amb RSP quan reservem i alliberem aquest espai?
El stack frame — recordatori
Stack frame: la part del stack associada a una activació d’una funció (Sessió 1).
No existeix un únic format universal de stack frame. Depèn de l’arquitectura, l’ABI/calling convention, el compilador i les opcions d’optimització.
El problema de RSP
void foo(void)
{
int x = 10;
int y = 20;
...
}RSP es mou constantment. Podem tenir un punt de referència estable per al frame?
x86_64 i set instruccions AT&T
RBP: Frame Pointer
RBP — Frame Pointer (x86-64).
RSP→ posició actual del stack.RBP→ referència estable al frame.RSPpot moure’s.RBPes manté fix mentre dura l’activació.
Construint el frame (x86-64)
Aquest és el patró clàssic. Els compiladors moderns poden ometre el frame pointer (frame pointer omission, típic amb -O2).
Destruint el frame
System V AMD64: pas d’arguments
Arguments 1–6 (enters/punters) → RDI, RSI, RDX, RCX, R8, R9. Valor de retorn → RAX.
AArch64: pas d’arguments
Arguments 1–8 (enters/punters) → X0–X7. Valor de retorn → X0.
La calling convention és específica de l’ABI: 6 registres en System V AMD64, 8 en AArch64.
I si no caben als registres?
Model simplificat: el tractament real també depèn del tipus i de la classificació dels arguments (p. ex. enters vs. punt flotant) definida per l’ABI.
AArch64: caller / callee saved
Posem-ho tot junt
int suma(int a, int b)
{
int resultat = a + b;
return resultat;
}main()posa arguments aRDIiRSIi facall suma. (2)suma()crea frame, executa i deixa el resultat aRAX. (3)rettorna amain(),RIPapunta amain()iRAXconté el resultat.
