Newsgroup: it.comp.lang.c
Titolo: azzeramente di una variabile.

Salve a tutto il NG,
oggi facendo alcuni semplici test ho notato che azzerando una
variabile tramite uno XOR si risparmia 1 byte rispetto
all'assegnazione classica "variabile = 0";
Tramite una veloce ricerca su deja non ho trovato nulla di
significativo su questo mio dubbio.
Riporto qui i miei test svolti su linux x86 con gcc da egcs-1.1.2-30,
kernel 2.2.19 su rh 6.2:
+ test1.c
int main()
{
   int a;
   a ^= a;
   return 0;
}
- test1.c
(gdb) disas main
Dump of assembler code for function main:
0x80483a0 <main>:       push   %ebp
0x80483a1 <main+1>:     mov    %esp,%ebp
0x80483a3 <main+3>:     sub    $0x4,%esp
0x80483a6 <main+6>:     mov    0xfffffffc(%ebp),%edx
0x80483a9 <main+9>:     xor    %edx,0xfffffffc(%ebp)
0x80483ac <main+12>:    xor    %eax,%eax
0x80483ae <main+14>:    jmp    0x80483b0 <main+16>
0x80483b0 <main+16>:    leave  
0x80483b1 <main+17>:    ret    
End of assembler dump.
(gdb) 
Con la XOR pare vengano occupati 17 bytes. Ora ecco l'altro test:
+ test2.c
int main()
{
   int a;
   a = 0;
   return 0;
}
- test2.c
(gdb) disas main
Dump of assembler code for function main:
0x80483a0 <main>:       push   %ebp
0x80483a1 <main+1>:     mov    %esp,%ebp
0x80483a3 <main+3>:     sub    $0x4,%esp
0x80483a6 <main+6>:     movl   $0x0,0xfffffffc(%ebp)
0x80483ad <main+13>:    xor    %eax,%eax
0x80483af <main+15>:    jmp    0x80483b1 <main+17>
0x80483b1 <main+17>:    leave  
0x80483b2 <main+18>:    ret    
End of assembler dump.
(gdb) 
Qui pare vengano usati 18 bytes... a questo punto mi viene un
dubbio... perchč in tutti i programmi viene sempre usata la forma "var
= 0" che certamente risulta piu leggibile ma occupa pur sempre un byte
in piů?  Puň essere considerata una buona ottimizzazione?
Saluti.
--- awayzzz <awayzzz at digibel dot org>

in piů?  Puň essere considerata una buona ottimizzazione?
Per almeno 3 buoni motivi:
1. Il risparmio di un byte non e' assolutamente
significativo.
2. Non tutti tipi di variabilie contemplano l'operazione
xor.  Se addirittura allarghi un po' il campo, sino a
comprendere linguaggi di programmazione orientati agli
oggetti, e' probabile che l'operazione di xor non sia
definita per determinate classi (anche perche', a volte, non
definibile).
3. E' molto piu' importante, in programmazione, esprimere
concetti in forma leggibile e manutenibile (anche se
rallenta minimamente le prestazioni), piuttosto che
complicare la vita a coloro che metteranno mano sul codice.
I programmi seri quasi mai sono mantenuti da una persona
sola ed e' importante che almeno la base di leggibilita' del
codice sorgente sia assicurata.
-- 
Andrea Laforgia - walkietalkie(at)
libero.it

significativo su questo mio dubbio.
zip...
Tecnicamente cio' che dici e' vero ed e' normalmente sfruttato nei
listati assembler (programmi e/o routine) dove il byte in piu' o in
meno puo' fare la differenza. Viceversa in un programma scritto in C
magari di parecchie migliaia di righe, cio' che ha piu' importanza e'
provabilmente la leggibilita' del codice....
Andrea

 Puň essere considerata una buona ottimizzazione?
concordo con quanto hanno detto gli altri, no.
Se poi e' il compilatore che ottimizza, ben venga, ma scriverlo nel
codice certamente no.
ciao
donCiccio

 Puo` essere considerata una buona ottimizzazione?
IMHO  no. Oltre  alle  considerazioni  gia` fatte  dagli  altri,  vorrei
aggiungere che il tuo compilatore e` in grado di fare ottimizzazioni del
genere da se`. Compilando  con -O3 il risultato e` questo  in entrambi i
casi:
(gdb) disas main
Dump of assembler code for function main:
0x80483c4 <main>:       push   %ebp
0x80483c5 <main+1>:     mov    %esp,%ebp
0x80483c7 <main+3>:     xor    %eax,%eax
0x80483c9 <main+5>:     mov    %ebp,%esp
0x80483cb <main+7>:     pop    %ebp
0x80483cc <main+8>:     ret
0x80483cd <main+9>:     nop
0x80483ce <main+10>:    nop
0x80483cf <main+11>:    nop
End of assembler dump.
Come vedi tutto il programma si riduce a 5 opcodes, di cui 4 servono per
salvare/ripristinare lo stack pointer ;)
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Ci sono due cose che l'uomo non puo` nascondere:
essere ubriaco ed essere innamorato.

casi:
[OT] Quando compili con l'opzione "-O3" mi pare tu dia liberta' al
compilatore di reinterpretare quello che hai scritto. Con "-O2" invece
il codice sarebbe stato portato con il vero e proprio assegnamento a 0
in un caso e con l'XOR nell'altro.
Se volevi provare per es la differente velocita' di esecuzine (che
come ricordava qualcuno su un altro NG si calcola dividento lo spazio
percorso dal programma per il tempo percorso) del programma scritto
nei 2 modi (ah, le ore e ore passate a testare la complessita'
sperimentale con il gprof si fanno sentire :P) con questa
ottimizzazione non avresti potuto. In genere quindi si usa "-02" che
e' il livello piu' alto di ottimizzazione che garantisce aderenza tra
quello che hai scritto e l'assemblato.
Questo ovviamente vale per il GCC (e probabilmente i porting) non e'
assolutamente standard... e siamo OT :)
Paolo (sempre a litigare con la macchina di Turing)

Paolo (sempre a litigare con la macchina di Turing)
Sempre meglio delle mappe di Karnaugh


 quello che hai scritto e l'assemblato.
No, non  e` cosi! Dovresti omettere lo  switch -O per essere  sicuro che
quello che viene compilato e` proprio il tuo codice.
Il  senso  del  mio  messaggio  era che  in  genere  il  compilatore  e`
abbastanza  furbo   da  prendere   simili  accorgimenti  senza   che  il
programmatore li usi esplicitamente.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Not an editor command: Wq