Newsgroup: it.comp.lang.c
Titolo: Tempi di accesso alle variabili.

Un saluto a tutti. Oggi mi chiedo (meglio vi chiedo...) se accedere ad
un elemento di una struct sia più faticoso che accedere ad una
variabile. Mi spiego meglio:
typedef struct
{
   int campo1;
   char campo2;
} esempio;
esempio prova;
int var;
Adesso prova.campo1 come variabile richiede più tempo macchina per
l'accesso di var? Ve lo chiedo in quanto ho questa preoccupazione: sto
scrivendo un programma in cui passo degli argomenti ad una funzione.
Tale funzione li deve modificare, e quindi ritornarli al programma
chiamante modificati.
Per ora l'unico modo che conosco per far ciò in C è di passare come
argomento alla funzione il puntatore ai dati; poiché nella fattispecie
uno degli argomenti è una struttura, mi chiedevo se le continue
operazioni che coinvolgono gli elementi della struttura all'interno
della funzione non influiscano negativamente sulle prestazioni
dell'eseguibile. A questo proposito mi chiedevo:
Se la funzione è
void funz(esempio* p);
e all'interno di funz uso un sacco di p->campo1 e p->campo2, potrei
eliminare la struttura e passare tutti i puntatori alle variabili che
ne costituivano gli elementi,
int campo1;
char campo2;
e poi
void funz(int* p1, char* p2);
 ma devo sempre anteporre l'asterisco per accedere alle variabili
tramite i puntatori, e anche questo farà senz'altro perdere tempo.
Volevo creare degli alias, ipotizzando che il compilatore fosse
abbastanza furbo da segnarsi l'indirizzo delle variabili una volta per
tutte alla definizione dell'alias, ma mi avete detto che in C non
esistono. Così per ora faccio delle copie locali delle variabili della
struttura, uso quelle e prima di uscire dalla funzione le metto a
posto, ma non mi piace molto.
Se però scopro (grazie a voi) che i tempi per queste operazioni sono
molto bassi potrei sempre fregarmene di tutto ciò e scrivere un
programma che secondo me è migliore.
Non so se sono stato molto chiaro, ma non vorrei esagerare con la
lungaggine...
Grazie e ciao, Piero.

Di logica no perche' tutto dovrebbe essere risolto a compile-time.
Tempi diversi di accesso ad aree di memoria possono essere dovuti
all' allineamento alla word per variabili di sizeof maggiore di 1.
Se pero' qualche compilatore decide di generare codice che riparti-
sce la memoria per le strutture in modo diverso (per usare due
memory manager di complessita' diversa) deve essere documentato
sul manuale del compilatore specifico. Dai capitolati C standard
cio' non si intuisce.
ciao.


lungaggine...
Guarda un po che post prolisso.... alla fin fine sono io che mi sono
dilungato troppo :-)
Ciao, Giuseppe
---------------------------------------------------------------------------
_Guybrush su IRCNet canale #programmazione
ICQ: 42227764
---------------------------------------------------------------------------

delle strutture.
Giustissimo! E poi se ci sono bisognerà pure usarle, sennò tanto vale
scrivere direttamente in assembler
Ciao
--
Alessandro Monti

delle strutture.
Si in effetti a qust'ora lascio un po'andare. E' ovvio che l'overhead
č quasi insignificante, perň mi sono lasciato trasportare dalla mania
di ottimizzare la velocitŕ di esecuzione, visto che la funzione č un
emulatore di una CPU, e la strttura che le passo per chiamarla č lo
stato.
Di solito la funzione la chiamo una volta, e l'emulazione va avanti
per migliaia di cicli del processore, quindi torno indietro e salvo lo
stato. Mi sembrava stupido perdere un po' di tempo per migliaia e
migliaia di volte, ma credo che lascerň tutto cosě visto che devo
consegnare il programma martedě...
Grazie e ciao, Piero.

consegnare il programma martedì...
Hai perfettamente ragione, soprattuto ora che il tempo stringe.


    mov eax, [prova + spiazzamento campo]
Non mi trovi d'accordo. Che nelle architetture Intel sia possibile avere uno
spiazzamento nell'istruzione è indubbio ma la tua riga di codice non ha
senso. "prova" è un puntatore e quando scrivo mov eax, [prova] carico il
valore del puntatore nel registro eax. Con la riga che hai scritto tu andrei
a leggere "spiazzamento campo" bytes dopo la posizione in memoria dove si
trova il mio puntatore, addirittura col pericolo di una Page Fault oltre
all'inesattezza del valore prelevato.


 all'inesattezza del valore prelevato.
Hai "quasi" ragione.
In effetti l'istruzione che ho scritto io non aveva senso, perche
presupponeva che 'prova' fosse la variabile, non un puntatore ad esso (ed in
effetti avevo usato il nome proposto all'inizio del thread), mentre si
specificava che l'utilizzo era all'interno di una funzione a cui era passato
il puntatore. (uffa, dovrei cercare di fare meno giri di parole)
Si potrebbe perņ supporre che il compilatore usi uno dei registri "magici"
per passare il puntatore, per cui si potrebbe scrivere:
    mov ax, [SI/DI/BP/BX] + spiazzamento campo
Ma forse sarebbe chiedere troppo al compilatore :-)
Scusa per l'erronea correzione.
--
Alessandro Monti

 all'inesattezza del valore prelevato.
Hai "quasi" ragione.
In effetti l'istruzione che ho scritto io era errata (per le parentesi
quadre) e non aveva senso, perche
presupponeva che 'prova' fosse la variabile, non un puntatore ad esso (ed in
effetti avevo usato il nome proposto all'inizio del thread), mentre si
specificava che l'utilizzo era all'interno di una funzione a cui era passato
il puntatore. (uffa, dovrei cercare di fare meno giri di parole)
In pratica ho fatto in gran c@***o.
Si potrebbe perň supporre che il compilatore usi uno dei registri "magici"








AAAARGH!
Quadruplicazione della lettera!!!!!!
Voglio morire!

Quadruplicazione della lettera!!!!!!
Leggo "Outlook Express" nei tuoi header..........


Scusa per l'erronea correzione.
Di nulla.
