Struct Mips

[Titti92]

Ciao a tutti. Ho dei dubbi sull'uso delle struct nell'assembly MIPS. se ad esempio ho il seguente codice C:
struct elem{
char c;
int i[2];
int *next;
}type_elem;
type elem h;

come posso tradurlo in assembly? Soprattutto ho dubbi sulla dichiarazione.
h: .space 13
va bene? ho considerato 1 char (1B), e due int, di cui uno è un vettore di due elementi (8B+4B): 1+8+4=13B

[Titti92]

Nessuno??

[sottovento]

Non conosco il processore in questione, ma dubito che l'occupazione di memoria per quella struttura sia di 13 byte.
Qui: https://en.wikibooks.org/wiki/MIPS_Assembly/MIPS_Instructions ho trovato che i processori MIPS devono allineare le strutture (farle cominciare ad un indirizzo - in generale - multiple di due). Siccome hai messo un byte all'inizio, ne dovrai saltare almeno 3 per allineare sui 4 bytes. Non sono sicure se devi allineare a 2 o 4 byte, purtroppo. Cmq occuperai piu' memoria di 13 byte.

Quando mi trovo a lavorare con un processore che non conosco e voglio tradurre una struttura c.... lo faccio fare al compilatore :D

Normalmente esiste un'opzione del compilatore per vedere il codice assembly generato, qualcosa tipo cc -S (non ricordo mai se maiuscolo o minuscolo). Trova l'opzione, fai generare la struttura e copiala

[cdimauro]

Ciao a tutti. Ho dei dubbi sull'uso delle struct nell'assembly MIPS. se ad esempio ho il seguente codice C:
struct elem{
char c;
int i[2];
int *next;
}type_elem;
type elem h;

come posso tradurlo in assembly? Soprattutto ho dubbi sulla dichiarazione.
h: .space 13
Non conosco l'assembly MIPS. Probabilmente è una direttiva per riservare spazio, partendo all'attuale indirizzo.
va bene? ho considerato 1 char (1B), e due int, di cui uno è un vettore di due elementi (8B+4B): 1+8+4=13B
No, perché, come giustamente riportato da sottovento, devi tenere conto dell'allineamento.

La questione è, però, complessa, perché dipende dal modello di processore (se a 32 o 64 bit), e dall'ABI utilizzata da s.o. e compilatore (inclusi gli assemblatori).

Assumendo che il processore sia a 32 bit, interi e puntatori occupano 4 byte per l'appunto, per cui i compilatori allineeranno questi tipi a multipli di 4 byte.

Questo significa che, come detto da sottovento, il al primo byte per il char c ne verranno aggiunti altri 3 di padding. Il resto è come hai già calcolato. Quindi il totale fa 16 byte.

Con l'assembly sei tu a definire gli offset dei singoli cambi, e dunque la dimensione dell'intera struttura, per cui se non stai attento puoi effettivamente allocare 13 byte, ma il programma solleverà un'eccezione quando tenterai di accedere ai campi int o puntatore, perché si troveranno a un indirizzo disallineato, mentre i processori MIPS sono in grado di leggere interi o puntatori (che sono la stessa cosa per loro) soltanto se sono allineati a 4 byte.
cdimauro e' l'esperto..
Purtroppo conosco poco i MIPS, e non ho mai letto nulla sulla sintassi dell'assemblatore. :stordita:

[Titti92]

Ho capito. Grazie a tutti per le risposte!

[Titti92]

Scusate se continuo ma mi trovo davanti a situazioni che mi restano complicate...
se ho il seguente codice c:
typedef struct nodo {
void *data;
struct nodo *prossimo;
} Nodo;
typedef struct lista {
Node *testa;
Node *coda;
Node *current;
} Lista;
.
.
.
typedef Lista Stack;
Stack *stack
Nodo *nodo;
stack->testa = stack->testa->prossimo;
Va bene se traduco in Mips così?
stack: .space 12 #in quanto formato da 3 puntatori
nodo: .space 8 #in quanto formato da 2 puntatori
.
.
.
la $s0,stack
la $s1,nodo
lw $t0,0($s0) #stack->testa
lw $t1,4($t0) #stack->testa->prossimo
sw $t1,0($s0) #stack->testa=stack->testa->prossimo
Questi puntatori mi stanno facendo diventare pazzo xD

[cdimauro]

Va bene, ma $s1 non lo usi.

[Titti92]

Si, era un pezzo di esercizio e quell's1 é rimasto lí per sbaglio. Comunque grazie mille!