[assembly] architettura IA-32

[misterx]

Originariamente inviato da StateCity

La CPU esegue le istruzioni indirizzate da CS:IP
e IP viene incrementato automaticamente alla frequenza di clock..

x Gli altri registri e' compito del sistema operativo dare i valori iniziali per il programma..
in modo che non vadano ad interferire con altri processi della cpu

e in assenza di un SO, caso tipico dei programmi DOS, ci deve pensare il programma stesso ad indirizzare la CPU nel segmento appropriato per prelevare i dati(parametri) corretti ?

[StateCity]

partiamo dall' inizio...

* La cpu si "risveglia" sempre con dei valori predefiniti dei registri, imposti dalla fabbrica..
ed esegue subito la prima istruzione indirizzata da CS:IP....

* IP viene sempre incrementato alla frequenza di clock, per eseguire
le istruzzioni successive e nn si ferma mai ! (almeno fin quando c'e' la corrente o nn crasha.. )

* le prime istruzioni che la CPU esegue sono solitamente routine di bios..
che una volta eseguite passano a caricare il boot sector dell' hard disk..

* il progtramma del boot sector cerca di mandare in esecuzione i files del
sistema operativo

* il sistema operativo prende il controllo della macchina...

* nel caso di esecuzioni di programmi utente e' compito del sistema operativo
impostare i registri che il programma trovera' pronti da utilizzare..

quindi e' il sistema operativo che imposta i valori di ES,DS,SS ecc. ecc.
che possono variare di volta in volta a secondo dell' area assegnata (dal SO)
ai programmi untente...

[StateCity]

Originariamente inviato da misterx

e in assenza di un SO, caso tipico dei programmi DOS, ci deve pensare il programma stesso ad indirizzare la CPU nel segmento appropriato per prelevare i dati(parametri) corretti ?

il DOS significa appunto Disk Operating System.

al lancio di un programma il DOS imposta automaticamente ES SS CS DS
in modo da assegnare un area di memoria libera al programma utente..

[misterx]

Originariamente inviato da StateCity

il DOS significa appunto Disk Operating System.

al lancio di un programma il DOS imposta automaticamente ES SS CS DS
in modo da assegnare un area di memoria libera al programma utente..

scusa ma per DOS intenedvo la solita finestra(ehm...schermo) nero
Una domanda che ho trovato su un libro recita: è strettamente necessario un SO per far girare un programma ?
La risposta è no!
Da qui è scaturita la mia domanda.

Ad ogni modo ho capito che la CPU attraverso IP punta alla prossima istruzione nel segmento istruzioni partendo da CS; per indirizzare i dati ci deve pensare il programma stesso.

[StateCity]

Originariamente inviato da misterx

scusa ma per DOS intenedvo la solita finestra(ehm...schermo) nero
Una domanda che ho trovato su un libro recita: è strettamente necessario un SO per far girare un programma ?
La risposta è no!
Da qui è scaturita la mia domanda.

Ad ogni modo ho capito che la CPU attraverso IP punta alla prossima istruzione nel segmento istruzioni partendo da CS; per indirizzare i dati ci deve pensare il programma stesso.

perfettamente..

il bios, il boot sector, il so stesso sono programmi che funzionano senza SO
il SO e' un "manager" che facilita l'utilizzo della macchina e si occupa
di assegnare ai programmi delle aree libere di memoria,
di organizzare i dati sull' hard disk in files,
e altre utilita' di questo tipo...

in effetti un floppy disk formattato dos, ma vuoto, ha in realta' sempre un piccolo
programma dentro.. e' il programma di boot sector..

bye

[cdimauro]

Originariamente inviato da StateCity

Tu saresti capace di mettere eseguibili in memoria video..

Certo. Tutto fa brodo, quando si fa metal bashing.

Originariamente inviato da StateCity

Ma siccome i file *.com di tipo eseguibile sono stati implementati la prima volta nel CP/M
che nn poteva indirizzare piu' di 64k ecco che e' rimasto il limite del segmento...

Ma il DOS non è il CP/M.

il supero della capacita' e' stato dato solo dalle facilitazioni del dos..

Se rimaniamo vincolati ai soli 8086, sì. E però così non fai che darmi ragione ancora una volta.

come la memoria maggiore di un mega in modo 8086 del 386

No, in questo caso il DOS non c'entra, se non per i primi 64KB - 16 byte posti a $10000, nei quali esso poteva piazzare alcune sue componenti e driver.

C'entrano però alcune succulente capacità del 386 che permettevano di andare ben oltre.

Originariamente inviato da StateCity

non vedo perche' utilizzare pop e lds
quando si puo' fare direttamente con mov ds,ax..
forse si risparmia qualche ciclo di clock..

il segmento ds e' implicito se si scrive :

0000:0100 8B04 mov ax,[si]

la cpu prende implicitamente il segmento DS per formare l'indirizzo in memoria DS:SI

altrimenti si deve specificare direttamente..

0000:0102 368B04 mov ax,[ss:si]

(si nota che 36hex e' il prefisso di segmento.. )

e in debug verrebbe scritto solo cosi' :

0000:0102 36 ss:
0000:0103 8B04 mov ax,[si]

essedo il resto dell'opcode uguale al primo sopra..

in questo caso e' l'indirizzo e' formato da SS:SI

Questo si studia nei 7 modi di indirizzamento delle cpu 8086.. du

ma sono sicuro che cdimauro avra' qualcosa da ridire..

No, proprio su questo non ho nulla di dire. Spiegazione da manuale.

Originariamente inviato da StateCity

La CPU esegue le istruzioni indirizzate da CS:IP
e IP viene incrementato automaticamente alla frequenza di clock..

Su questo invece sì, ma non ti dico il perché.

[misterx]

parlando di boot sector

               START:                        START OF BOOT SECTOR PROGRAM

0000:7C3E FA          CLI                          interrupts off
0000:7C3F 33C0        XOR     AX,AX                set AX to zero
0000:7C41 8ED0        MOV     SS,AX                SS is now zero
0000:7C43 BC007C      MOV     SP,7C00              SP is now 7c00
0000:7C46 16          PUSH    SS                   also set ES
0000:7C47 07          POP     ES                      to zero

fonte: http://www.ata-atapi.com/hiwdos.html#T10

la prima istruzione parte che dall'indirizzo 7C3E, la CPU vi trova FA; a questo punto IP si incrementa della dimensione dell'istruzione in quanto è ampia 1 byte ?
Quindi IP conosce la dimensione dell'istruzione.
L'esempio mostra poi che la prossima istruzione si trova al byte successivo e che è formata questa volta da 2 byte, quindi IP avanza di 2 byte in quanto sa che l'istruzione che è stata eseguita era di due byte.
Arrivati alle MOV queste sono ampie due byte, le PUSH 1 byte, idem per le POP che sono di 1 byte: come fa IP sostanzialmente a sapere di quanto deve avanzare ?
Chi glielo dice ?

Purtroppo le risposte non si trovano nei libri

[StateCity]

http://212.189.172.195/corso/labsite...8086/80861.pdf
http://home.comcast.net/~fbui/intel.html

in pratica l' IP si incrementa sempre di 1 ...
(salvo se non viene modificato da istruzioni di salto o altri casi)
sara' poi la CPU a decidere cosa fare del dato indirizzato da CS:IP..
potrebbe essere un OpCode di un istruzione, oppure un dato numerico da elaborare..

[StateCity]

altre info sull' argomento.. Istruction Pointer o Program Counter..

http://it.wikipedia.org/wiki/Program_counter
http://it.wikipedia.org/wiki/Ciclo_di_fetch-execute
http://en.wikipedia.org/wiki/Program_counter
http://en.wikipedia.org/wiki/Instruction_cycle

[StateCity]

0000:7C3E FA CLI
0000:7C3F 33C0 XOR AX,AX
0000:7C41 8ED0 MOV SS,AX
0000:7C43 BC007C MOV SP,7C00
0000:7C46 16 PUSH SS
0000:7C47 07 POP ES

Qui il disassemblatore, (tipo debug o altri) fa' vedere solo il primo offset della memoria (in rosa)
relativo all' istruzione da eseguire...

ma in pratica sarebbe :
0000:7C3E FA
0000:7C3F 33
0000:7C40 C0
0000:7C41 8E
0000:7C42 D0

ecc ecc

[misterx]

Originariamente inviato da StateCity

0000:7C3E FA CLI
0000:7C3F 33C0 XOR AX,AX
0000:7C41 8ED0 MOV SS,AX
0000:7C43 BC007C MOV SP,7C00
0000:7C46 16 PUSH SS
0000:7C47 07 POP ES

Qui il disassemblatore, (tipo debug o altri) fa' vedere solo il primo offset della memoria (in rosa)
relativo all' istruzione da eseguire...

ma in pratica sarebbe :
0000:7C3E FA
0000:7C3F 33
0000:7C40 C0
0000:7C41 8E
0000:7C42 D0

ecc ecc

quindi è solo un problema di visualizzazione!
Allora si che si spiega l'incremento di 1 byte alla volta

[StateCity]

Originariamente inviato da cdimauro

Certo. Tutto fa brodo, quando si fa metal bashing.

Ma il DOS non è il CP/M.

Se rimaniamo vincolati ai soli 8086, sì. E però così non fai che darmi ragione ancora una volta.

No, in questo caso il DOS non c'entra, se non per i primi 64KB - 16 byte posti a $10000, nei quali esso poteva piazzare alcune sue componenti e driver.

C'entrano però alcune succulente capacità del 386 che permettevano di andare ben oltre.

avessi una ragazza che mi sta' cosi attaccata...

Originariamente inviato da cdimauro

No, proprio su questo non ho nulla di dire. Spiegazione da manuale.

Detto da te' e' sicuramente un grosso complimento !

Originariamente inviato da cdimauro

Su questo invece sì, ma non ti dico il perché.

restero' nella mia ignoranza..

[StateCity]

Originariamente inviato da misterx

quindi è solo un problema di visualizzazione!
Allora si che si spiega l'incremento di 1 byte alla volta

Perfettamente..

il debugger tenta di interpretare i codici esadecimali e ricavare le istruzioni...
se vede la sequenza BC 00 7C la interpreta come MOV SP,7C00
anche se quei valori potrebbero essere i colori di una foto..
oppure una sequenza di caratteri ascii..

la memoria e' sempre organizzata in questo modo..

Indirizzo ... dato (byte)
00001 ....... xx
00002 ....... xx
00003 ....... xx

ecc. ecc.

bye

[cdimauro]

Originariamente inviato da StateCity

avessi una ragazza che mi sta' cosi attaccata...

Tranquillo: per quello bastano anche altre doti.

Detto da te' e' sicuramente un grosso complimento !

Beh, è la verità.

restero' nella mia ignoranza..

Vabbé, dai, per così poco. Il punto errato è questo:

"IP viene incrementato automaticamente alla frequenza di clock"

IP viene incrementato quando la sezione di fetch & decode ha terminato il suo lavoro.

Quindi quest'operazione è legata strettamente all'implementazione, e alla particolare istruzioni prelevata. Può avvenire una sola volta in un ciclo di clock, più volte (visto che le CPU moderne possono prelevare, decodificare ed eseguire più istruzioni per ciclo di clock) per ciclo di clock, o anche nessuna volta.

[misterx]

Originariamente inviato da StateCity

Perfettamente..

il debugger tenta di interpretare i codici esadecimali e ricavare le istruzioni...
se vede la sequenza BC 00 7C la interpreta come MOV SP,7C00
anche se quei valori potrebbero essere i colori di una foto..
oppure una sequenza di caratteri ascii..

la memoria e' sempre organizzata in questo modo..

Indirizzo ... dato (byte)
00001 ....... xx
00002 ....... xx
00003 ....... xx

ecc. ecc.

bye

quel tenta è preoccupante

[cdimauro]

No, è normale, perché quello fornito col DOS è molto vecchio e riconosce soltanto una piccola porzione degli opcode delle CPU moderne. E' fermo agli 8086.