[assembly] divisione

[Teo@Unix]

Cerco un piccolo chiarimento...

dando un occhio su come gcc mi traduce l'istruzione C:

area = width * height/2

trovo questo:

       imul   0xc(%ebp),%edx
       mov    %edx,%eax
       shr    $0x1f,%eax
       add    %edx,%eax
       sar    %eax

non capisco bene come viene fatta la divisione... mi è chiaro imul che moltiplica. Ma non sono sicuro del resto...

grazie.

[Kenger]

Hai preso l'esempio sbagliato per vedere come si fa la divisione.
La divisione per due viene ottimizzata dal compilatore come uno shift a destra. Se fai una divisione per qualsiasi numero che non sia 2 vedi una divisione vera.

[Teo@Unix]

ok, so che viene fatta con uno shift, ma non ho capito in questo caso cosa viene fatto.
In particolare io vedo
uno shift di EAX >> 31
poi ad EAX viene aggiunto EDX
e poi sar io ero convinto avesse due operandi invece qui ne ha uno.

Il mio obiettivo è capire questo esempio.

[cdimauro]

Originariamente inviato da Teo@Unix

ok, so che viene fatta con uno shift, ma non ho capito in questo caso cosa viene fatto.
In particolare io vedo
uno shift di EAX >> 31

Prende il bit del segno del risultato della moltiplicazione e lo mette in EAX. Quindi EAX = 0 -> risultato positivo, EAX = 1 -> risultato negativo.

poi ad EAX viene aggiunto EDX

Esatto. Quindi ci sono due casi:
Risultato positivo -> EAX = risultato (nessun cambiamento)
Risultato negativo -> EAX = risultato + 1.

e poi sar io ero convinto avesse due operandi invece qui ne ha uno.

Sì, lo shift di 1 è implicito.

Il mio obiettivo è capire questo esempio.

Il problema è che non si possono usare shift aritmetici (quindi con segno) senza tener conto di alcuni casi speciali.

Per i positivi, come vedi non cambia nulla. Il problema è coi negativi.

Se invece sono negativi, in particolare nel caso in oggetto bisogna controllare se per caso il risultato da dividere per 2 vale -1 oppure è < -1.

Se vale -1 sappiamo che la divisione deve valere 0. Infatti in questo caso EAX = risultato + 1 = -1 + 1 = 0. E lo shift ritorna correttamente 0.

Se invece è < -1, lo shift aritmetico a destra ricopierà sempre il bit del segno, per cui il risultato rimarrà sempre negativo.
Esempio: -2 + 1 = -1 sar 1 = -1.
-3 + 1 = -2 sar 1 = -1.
-4 + 1 = -3 sar 1 = -2. E così via.

[Teo@Unix]

aa.. ora dovrei esserci, si potevo immaginare che ove c'era sar era implicito 1.

Originariamente inviato da cdimauro

Se invece è < -1, lo shift aritmetico a destra ricopierà sempre il bit del segno, per cui il risultato rimarrà sempre negativo.
Esempio: -2 + 1 = -1 sar 1 = -1.
-3 + 1 = -2 sar 1 = -1.
-4 + 1 = -3 sar 1 = -2. E così via.

ho capito, tutto viene fatto per mentenere il segno in modo corretto.
Infatti... infatti.... se uso variabili unsigned int.... la traduzione è ben diversa.
Non c'è tutto il procedimento sopra detto...

Vorrei chiederti un'altra cosa... poco chiara..

La riga di codice C che ho riportato fa parte di una funzione che poi ritorna
il valore area.

Noto che le ultime due istruzioni prima di ret apparentemente non servono a nulla...

....
0x0000002e <triangle+46>:       imul   0xc(%ebp),%edx
0x00000032 <triangle+50>:       mov    %edx,%eax
0x00000034 <triangle+52>:       shr    $0x1f,%eax
0x00000037 <triangle+55>:       add    %edx,%eax
0x00000039 <triangle+57>:       sar    %eax
0x0000003b <triangle+59>:       mov    %eax,-0x4(%ebp) // << --- ??
0x0000003e <triangle+62>:       mov    -0x4(%ebp),%eax // << --- ??
0x00000041 <triangle+65>:       leave
0x00000042 <triangle+66>:       ret

ti ringrazio.

[cdimauro]

Originariamente inviato da Teo@Unix

aa.. ora dovrei esserci, si potevo immaginare che ove c'era sar era implicito 1.

ho capito, tutto viene fatto per mentenere il segno in modo corretto.
Infatti... infatti.... se uso variabili unsigned int.... la traduzione è ben diversa.
Non c'è tutto il procedimento sopra detto...

Esatto. Con gli unsigned il codice è banale: dopo la mul (che è unsigned), seguirà sicuramente a ruota una semplice shr.

Vorrei chiederti un'altra cosa... poco chiara..

La riga di codice C che ho riportato fa parte di una funzione che poi ritorna
il valore area.

Noto che le ultime due istruzioni prima di ret apparentemente non servono a nulla...

....
0x0000002e <triangle+46>:       imul   0xc(%ebp),%edx
0x00000032 <triangle+50>:       mov    %edx,%eax
0x00000034 <triangle+52>:       shr    $0x1f,%eax
0x00000037 <triangle+55>:       add    %edx,%eax
0x00000039 <triangle+57>:       sar    %eax
0x0000003b <triangle+59>:       mov    %eax,-0x4(%ebp) // << --- ??
0x0000003e <triangle+62>:       mov    -0x4(%ebp),%eax // << --- ??
0x00000041 <triangle+65>:       leave
0x00000042 <triangle+66>:       ret

ti ringrazio.

A naso l'istruzione inutile è la seconda move, per ovvi motivi.

La prima sembra sia necessaria per conservare il valore in qualche variabile. Se si tratta di una variabile, allora anche questa mov è del tutto inutile, in quanto la leave provvederà a ripulire lo stack dallo spazio allocatato per le variabili locali, e a questo punto vuol dire che il risultato viene ritornato usando il registro eax.

[Teo@Unix]

Originariamente inviato da cdimauro

Esatto. Con gli unsigned il codice è banale: dopo la mul (che è unsigned), seguirà sicuramente a ruota una semplice shr.

esattamente.

A naso l'istruzione inutile è la seconda move, per ovvi motivi.

La prima sembra sia necessaria per conservare il valore in qualche variabile. Se si tratta di una variabile, allora anche questa mov è del tutto inutile, in quanto la leave provvederà a ripulire lo stack dallo spazio allocatato per le variabili locali, e a questo punto vuol dire che il risultato viene ritornato usando il registro eax.

Questo rimane un pò un mistero, ma non è ora molto importante... il codice sorgente che ho usato per il test è una sola funzione senza main, ma non credo che questo c'entri.

int triangle(int width,int height) {
	int area;
	area = width * height/2;
	return(area);
}

grazie.

[||ElChE||88]

E' semplice: hai compilato senza ottimizzazioni e il compilatore ha "tradotto" il codice alla lettera usando la variabile locale che non era affatto necessaria.

mov    %eax,-0x4(%ebp)
mov    -0x4(%ebp),%eax

La prima sposta il risultato nella variabile locale area.
La seconda sposta area in eax per usarlo come valore di ritorno.
Sono entrambe inutili perché il risultato in eax c'era già ed area essendo locale non servirà più, e infatti se compili con -O2 (o se scrivi la funzione senza usare variabili locali) non le mette.

[Teo@Unix]

Originariamente inviato da ||ElChE||88

E' semplice: hai compilato senza ottimizzazioni e il compilatore ha "tradotto" il codice alla lettera usando la variabile locale che non era affatto necessaria.

mov    %eax,-0x4(%ebp)
mov    -0x4(%ebp),%eax

La prima sposta il risultato nella variabile locale area.
La seconda sposta area in eax per usarlo come valore di ritorno.
Sono entrambe inutili perché il risultato in eax c'era già ed area essendo locale non servirà più, e infatti se compili con -O2 (o se scrivi la funzione senza usare variabili locali) non le mette.

E' vero! E' esattamente come dici. Non ci ho pensato.
L'ottimizzazione ha ridotto molto l'assembly, pertanto per controllare la traduzione del codice direi che è sempre meglio ottimizzare. Tutto chiaro. Vi ringrazio.