[assembly] architettura IA-32

[misterx]

da quanto ne ho capito, intel segmenta la memoria ram in un certo numero di segmenti. Quando si esegue un programma, le istruzioni vengonon copiate in un segmento ed i dati in un altro segmento.
Quindi i registri CS e DS contengono l'indirizzo di questi due segmenti. Ipotizzo ora che se viene letto dalla CPU una istruzione che prevede due operandi, si va nel segmento dei dati e si prelevano due dati e così via. Ovviamente ogni volta si incrementa il PC per conoscere la prossima istruzione da eseguire.
Detto alla spicciolata ma il concetto dovrebbe essere questo, giusto ?

[71104]

Originariamente inviato da misterx

da quanto ne ho capito, intel segmenta la memoria ram in un certo numero di segmenti. Quando si esegue un programma, le istruzioni vengonon copiate in un segmento ed i dati in un altro segmento.
Quindi i registri CS e DS contengono l'indirizzo di questi due segmenti. Ipotizzo ora che se viene letto dalla CPU una istruzione che prevede due operandi, si va nel segmento dei dati e si prelevano due dati e così via. Ovviamente ogni volta si incrementa il PC per conoscere la prossima istruzione da eseguire.
Detto alla spicciolata ma il concetto dovrebbe essere questo, giusto ?

sarebbe stato giusto fino a vent'anni fa, nell'epoca dei 16 bit e della transizione ai 32 bit; oggi di norma i sistemi operativi schiaffano codice e dati di ogni processo nello stesso segmento (nello specifico Windows utilizza in maniera effettiva la segmentazione solo nelle transizioni tra kernel mode e user mode, che significa che il kernel space sta in un segmento diverso dallo user space ma per il resto tutti i processi stanno nello stesso segmento).
fai un esperimento: scrivi un programma a 32 bit che ti stampa sullo standard output il contenuto dei registri CS e DS (e anche ES se vuoi); dovrebbero essere tutti uguali e non dovrebbero cambiare neanche riavviando il programma piu volte; la cosa non funziona nei programmi a 16 bit, i quali invece girano in modalitá virtuale x86 e quindi usano il vecchio sistema di segmentazione (quello di vent'anni fa di cui parlavo prima).

[misterx]

Originariamente inviato da 71104

sarebbe stato giusto fino a vent'anni fa, nell'epoca dei 16 bit e della transizione ai 32 bit; oggi di norma i sistemi operativi schiaffano codice e dati di ogni processo nello stesso segmento (nello specifico Windows utilizza in maniera effettiva la segmentazione solo nelle transizioni tra kernel mode e user mode, che significa che il kernel space sta in un segmento diverso dallo user space ma per il resto tutti i processi stanno nello stesso segmento).
fai un esperimento: scrivi un programma a 32 bit che ti stampa sullo standard output il contenuto dei registri CS e DS (e anche ES se vuoi); dovrebbero essere tutti uguali e non dovrebbero cambiare neanche riavviando il programma piu volte; la cosa non funziona nei programmi a 16 bit, i quali invece girano in modalitá virtuale x86 e quindi usano il vecchio sistema di segmentazione (quello di vent'anni fa di cui parlavo prima).

quindi hanno trovato un metodo per nella mischia di trovare istruzioni e dati ?

[71104]

Originariamente inviato da misterx

quindi hanno trovato un metodo per nella mischia di trovare istruzioni e dati ?

ricominci ad essere incomprensibile per me.

[misterx]

Originariamente inviato da 71104

ricominci ad essere incomprensibile per me.

ok, scusa: torno a parlare in modo scolastico
Se non ho capito male, 20 anni fa i byte che rappresentavano il programma venivano memorizzati in un segmento mentre i byte che rappresentavano i dati venivano memorizzati in un altro segmento, DS e CS poi contenevano gli indirizzi ai rispettivi segmenti.
Oggi le cose non stanno più così, da quanto ho appreso la memoria viene ancora frammentata ma codice e dati non sono più mantenuti separati ma sono nello stesso segmento: mi chiedo come fa il processore a determinare quale sequenza di byte rappresenta un dato e quale un dato.

Intuitivamente mi viene in mente che forse in fase di compilazione, codice e dati vengono intercalati in modo opportuno in quanto il processore se li aspettain questo modo: ma è solo una ipotesi.

[71104]

premessa: i files esegubili (sia quelli di Windows, formato PE, sia quelli di Linux, formato ELF) sono divisi in parti dette "sezioni" che ricordano vagamente i segmenti dell'architettura Intel; comunque, come abbiamo detto, su Windows quando un file eseguibile viene caricato in memoria virtuale tutte le sue sezioni stanno nello stesso segmento x86, cosi come le sezioni di qualunque altro programma eseguibile in esecuzione in qualunque altro processo. fine premessa.

tanto per cominciare esistono diversi tipi di dati: i dati globali, i dati allocati in memoria automatica e i dati allocati dinamicamente in un heap.

i dati globali sono le variabili che in C/C++ dichiari nello scope globale oppure nello scope di una funzione ma usando il modificatore static; questi dati vengono si suddividono a loro volta in dati inizializzati e non: le variabili inizializzate vengono allocate in fase di compilazione in una apposita sezione dell'eseguibile che di norma su Windows (eseguibili PE) si chiama ".idata" o ".rdata" (".rdata" é per le variabili a sola lettura); le variabili non inizializzate invece vengono allocate "virtualmente" in un'altra sezione dell'eseguibile (".data" nei file PE) che ha dimensione nulla sul file fisico e dimensione non nulla in memoria virtuale: quando Windows mappa in memoria il file eseguibile alloca la dimensione richiesta per la sezione ".data" e la riempie di zeri.

i dati allocati in memoria automatica sono quelli allocati sullo stack, anche detta memoria automatica grazie al fatto che tali dati vengono deallocati automaticamente non appena vanno fuori scope; ad esempio una variabile intera dichiarata localmente in una funzione (senza il modificatore static) viene deallocata non appena l'esecuzione della funzione termina.
lo stack (o gli stack, visto che ogni thread ha il suo) viene gestito da Windows con un semplice meccanismo basato sul virtual memory manager; il virtual memory manager permette di allocare pagine di memoria virtuale e anche di riservarne altre per possibili allocazioni future. quando il subsystem Win32 deve allocare uno stack per un thread non fa altro che richiedere l'allocazione di una pagina di memoria virtuale e il reserve di altre N-1 pagine immediatamente seguenti, dove N viene definito in fase di linking (solitamente i programmi hanno 1 MB di stack per ogni thread e inizialmente di questo MB solo i primi 4 KB, cioé la prima pagina, sono effettivamente allocati); ti risparmio i dettagli su cosa accade quando lo stack di un thread cresce oltre la prima pagina (se ti interessa studiati i page guards).

infine ci sono i dati allocati dinamicamente in un heap, che sono quelli che in C allochi con malloc o calloc e in C++ con new. un programma Win32 puó avere zero o piu heaps che sono gestiti dall'heap manager di Windows, anch'esso basato sul virtual memory manager. ciascun heap permette di allocare dinamicamente blocchi di memoria virtuale di dimensione arbitraria; l'heap manager implementa gli algoritmi necessari a far funzionare un simile sistema al di sopra del virtual memory manager, il quale ha una differenza fondamentale dall'heap manager: permette di allocare blocchi di dimensione non arbitraria, bensi multipla di 4 KB. ti risparmio i dettagli sul problema della frammentazione, che viene risolto dai runtime C e C++ di Visual C++ implementati al di sopra dell'heap manager di Windows.

questo é il contesto generale e ti dovrebbe dare un'idea piu precisa di come vivono i diversi tipi di dati all'interno di un programma per Windows, considerando che su Linux la situazione é del tutto analoga. ora, cosa vorresti sapere? leggendo questa frase:

"mi chiedo come fa il processore a determinare quale sequenza di byte rappresenta un dato e quale un dato."

immagino di poterla reinterpretare in questo modo:

"mi chiedo come fa il processore a determinare quale sequenza di byte rappresenta un dato e quale un istruzione."

ma non capisco perché secondo te il processore dovrebbe avere il bisogno di determinare questa cosa; che intendi con "determinare"?

[misterx]

Originariamente inviato da 71104

ma non capisco perché secondo te il processore dovrebbe avere il bisogno di determinare questa cosa; che intendi con "determinare"?

la risposta me la hai già data dicendomi che i dati vengono disposti in un certo modo in fase di compilazione.

Con "determinare" intendevo tale fatto: se penso a quando i dati e le istruzioni venivano mantenute in segmenti separati mi vinene facile pensare come la cpu potesse accedere solo ad istruzioni e non a dati in quanto aveva un'area di memoria specifica.
Se ora i dati stanno nello stesso segmento, mi chiedevo come facesse la cpu a capire quale byte rappresenta un dato e quale una istruzione, banalmente: D8 potrebbe essere sia un dato che una istruzione.

Comunque hai risolto il mo dubbio dicendomi che il compilatore posiziona i dati in un certo modo e quindi esiste una sorta di accordo tra la cpu ed il software: queso per dirla alla mia maniera

grazie 1000 per l'approfondimento

[71104]

in realtá l'accordo non coinvolge la CPU; la CPU, molto ignorantemente, non fa altro che seguire il flusso di codice, va dove la portano le istruzioni; poi chiaramente il codice dell'eseguibile é fatto in maniera tale da non portarla nelle zone di memoria contenenti dati, a meno che quella non sia la specifica intenzione del programmatore.

[Tesinevb]

[quote=misterx;27214792]...mi chiedo come fa il processore a determinare quale sequenza di byte rappresenta un dato e quale un dato...
QUOTE]

E' scritto nel capitolo 11...

11.2.3 Campo Opcode: con i codice mnemonici il computer capisce se si tratta di un istruzione o un dato

per l'altra domanda... 20 anni fà l'architettura era a 16 bit poi con pc + nuovi aumentarono il bus address a 20 linee e gli ingegneri ebbero il colpo di genio di indirizzare 1 mb prendendolo con lo spiazzamento dell'offset il +10 andano all'altro paragrafo su architettura a 16 bit... questo fece in modo che i programmi potessero girare su tutti i pc in commercio dell'epoca

[misterx]

[quote=Tesinevb;27227513]

Originariamente inviato da misterx

...mi chiedo come fa il processore a determinare quale sequenza di byte rappresenta un dato e quale un dato...
QUOTE]

E' scritto nel capitolo 11...

11.2.3 Campo Opcode: con i codice mnemonici il computer capisce se si tratta di un istruzione o un dato

per l'altra domanda... 20 anni fà l'architettura era a 16 bit poi con pc + nuovi aumentarono il bus address a 20 linee e gli ingegneri ebbero il colpo di genio di indirizzare 1 mb prendendolo con lo spiazzamento dell'offset il +10 andano all'altro paragrafo su architettura a 16 bit... questo fece in modo che i programmi potessero girare su tutti i pc in commercio dell'epoca

grazie.

Difatti stavo leggendo la struttura ad esempio di una istruzione 80386 dove ogni byte o gruppo di byte rappresentano informazioni diverse per la cpu.
Se ho contato bene, la struttura è ambia 16 byte, quindi sia che usi o non usi certi byte, la dimensione rimane sempre di 16 byte, un esempio in questa pagina in basso dove i campi che si notano sono fissi.
Ricorda molto una struct del C.

[cdimauro]

Assolutamente no. La famiglia x86 è costituita da microprocessori CISC, che notoriamente utilizzano opcode a lunghezza variabile.

16 byte è la dimensione massima che può avere un opcode, ma la minima è costituita da 1 solo byte.

Soltanto i RISC hanno opcode a lunghezza fissa, ma il "taglio" in genere è 16 o 32bit, quindi 2 o 4 byte.

Esistono poi delle varianti dei RISC, chiamati VLIW, che hanno opcode a lunghezza fissa ma di notevole dimensione. Questo perché, in realtà, codificano PIU' istruzioni nello stesso opcode, che vengono eseguite tutte in una volta.
Esempi ne sono l'Itanium di Intel, che ha opcode di 128 bit (16 byte, contenenti 3 istruzioni), o l'Efficeon della defunta Transmeta, che addirittura aveva opcode di 256 bit (32 byte, contenenti 8 istruzioni).

[misterx]

Originariamente inviato da cdimauro

Assolutamente no. La famiglia x86 è costituita da microprocessori CISC, che notoriamente utilizzano opcode a lunghezza variabile.

16 byte è la dimensione massima che può avere un opcode, ma la minima è costituita da 1 solo byte.

Soltanto i RISC hanno opcode a lunghezza fissa, ma il "taglio" in genere è 16 o 32bit, quindi 2 o 4 byte.

Esistono poi delle varianti dei RISC, chiamati VLIW, che hanno opcode a lunghezza fissa ma di notevole dimensione. Questo perché, in realtà, codificano PIU' istruzioni nello stesso opcode, che vengono eseguite tutte in una volta.
Esempi ne sono l'Itanium di Intel, che ha opcode di 128 bit (16 byte, contenenti 3 istruzioni), o l'Efficeon della defunta Transmeta, che addirittura aveva opcode di 256 bit (32 byte, contenenti 8 istruzioni).

ah ecco, al link che mi è stato fornito non si parlava di campi opzionali!

[71104]

Originariamente inviato da Tesinevb

per l'altra domanda... 20 anni fà l'architettura era a 16 bit poi con pc + nuovi aumentarono il bus address a 20 linee e gli ingegneri ebbero il colpo di genio di indirizzare 1 mb prendendolo con lo spiazzamento dell'offset il +10 andano all'altro paragrafo su architettura a 16 bit... questo fece in modo che i programmi potessero girare su tutti i pc in commercio dell'epoca

misterx, dimentica questa roba: é tutto sbagliato

[cdimauro]

http://www.appuntidigitali.it/3044/8...ura-dominante/

[misterx]

se alcuni campi sono opzionali, come fa la cpu e trovare le istruzioni ?

Forse il mio dubbio nasce dal fatto che on ho ancora letto come vengonon organizzate le istruzioni e i dati nella RAM.

[cdimauro]

Non è un problema insormontabile, anzi. Leggi il primo byte, vedi quali informazioni si porta dietro, e in base a queste capisci se ti servono altri byte. Li leggi, e continui finché non ti è chiaro cosa devi fare.

Questo dal punto di vista del decoder delle istruzioni della CPU.

[StateCity]

Originariamente inviato da misterx

siccome non trovo un piffero da nessuna parte vi chiedo: nei processori intel esistono registri specifici solo per le istruzioni e registri specifici solo per i dati ?

La domanda e' perfettamente pertinente !

il "guaio" e' che anche x i programmatori piu' esperti oramai l'assembler (o assembly nn sottilizziamo.. )
lo considerano superato, e questo e' un errore fatale !

In breve l'architettura x86 ha :
4 registri dati a 16 bit (AX, BX, CX, DX)
4 registri punatori e indici a 16 bit (SP, BP, SI, DI)
4 registri di segmento a 16 bit (CS, DS, SS, ES)

oltre ad altri registri interni, come IP e il FLAG

Ogni registro puo' essere utilizzato per contenere dati generali..
ma solo alcuni sono abilitati per funzioni particolari..
ad esempio IMUL utilizza come destinazione solo il registro AX
oppure LODSW indirizza solo il dato puntato da SI e lo trasferisce in AX
e non puo' utilizzare direttamente altri registri..

http://en.wikipedia.org/wiki/X86

bye

[StateCity]

qualche aggiunta...

I registri generali si utilizzano principalmente per contentere dati e fare elaborazione numerica..
I registri puntatori si utilizzano principalmente per memorizzare la parte bassa (offset)
delle locazioni di memoria..
(e in questi, solo il registro SP e' dedicato ad indicizzare lo stack pointer..)
I registri segmento si utilizzano principalmente per memorizzare la parte alta (segment) delle locazioni di memoria..
(e in questi, il registro CS e' dedicato esclusivamente ad indirizzare il segmento di il codice.. da non toccare assolutamente.. )

Poi volendo e' anche possibile memorizzare un dato numerico in ES,
ma sarebbe meglio utilizzare i registri solo per la loro naturale destinazione d'uso,
evitando di fare confusioni e programmi illegibili..

bye..

[misterx]

mi rimane il dubbio se è la cpu che vede la memoria segmentata oppure è l'SO a segmentarla.

Dico questo perchè ho provato a compilare un programma in C e visualizzare col debugger il corrispettivo codice assembly. Di fatto vedo il contenuto di tutti i registri della CPU e mi aspettavo che eseguendo il programma passo passo, il valore di CS, DS ed SS cambiasse invece rimane fisso.

Mi chiedo se questo comportemtno è dovuto al fatto che:

a) i segmenti sono di dimensione variabile e quindi il compilatore crea una zona di memoria che non verrà mai esaurita nel senso che, il mio programma non userà mai un altro segmento e quindi, non vedo cambiare i registri CS, DS,SS

b) il segmento è fisso ma il mio programma è di dimensioni talmente ridotte che sta comodamente in un segmento e per questo non vedo nessuna variazione

c) le variazioni dei registri DS, CS, SS li vedrei sse debugassi l'SO e non un mio programma

[cdimauro]

Se hai realizzato un'applicazione a 32 bit, allora non hai più segmenti, ma selettori.

Inoltre, come diceva "71104", il modello utilizzato nei moderni s.o. è "flat", ovvero tutti i segmenti sono caricati con lo stesso valore, perché ormai non si usa più la segmentazione per suddividere codice, dati, e stack, ma la paginazione è il modello standard.

I selettori hanno ormai fatto il loro tempo, tant'è che nell'evoluzione a 64 bit (AMD64 o x86-64 che dir si voglia) sono praticamente spariti nella modalità nativa (a 64 bit, appunto), in quanto l'unico modello a disposizione è quello paginato (questo non è del tutto vero perché FS e GS sono utilizzati dal s.o., ma dal punto di vista applicativo è tutto paginato).