DOMANDA Linguaggio Assembly

[pabloski]

Avrei voluto non dover chiedere, però ieri abbiamo fatto il compito, e mi serviva urgentemente un aiuto.

Curioso che si faccia un compito sull'Assembly x86 senza prima aver spiegato l'architettura x86. Ad esempio, il termine "modi di indirizzamento" ti dice nulla?

 

[Nicola.Mariano]

Allora, ci sono stati parecchi "problemi". Ci hanno spiegato le basi del processore 8086 e dell'architettura x86 a inizio Dicembre, però per via delle incessanti nevicate, guasti, scioperi, assemblee, malattie, scuola-lavoro e tanto altro, siamo riusciti a fare il compito solo ieri.
Dopo quasi due mesi, ovviamente la maggior parte degli argomenti sono andati persi.

 

[Utente 16812]

Ti ringrazio per la precisione!

Ah ah ah ... di nulla ... chiedi quello che vuoi ... ;)

 

[rctimelines]

Allora, ci sono stati parecchi "problemi". Ci hanno spiegato le basi del processore 8086 e dell'architettura x86 a inizio Dicembre, però per via delle incessanti nevicate, guasti, scioperi, assemblee, malattie, scuola-lavoro e tanto altro, siamo riusciti a fare il compito solo ieri.
Dopo quasi due mesi, ovviamente la maggior parte degli argomenti sono andati persi.

Beh, in due mesi! Non è che si riesca a fare molto.

In ogni caso, al di là di ciò che ti è stato detto finora, che comunque è correttissimo: tieni presente che, indipendentemente dalla specifica architettura della CPU, i concetti basilari per la programmazione sono analoghi per ogni processore.
Cioè, tanto per non farla troppo difficile, ci sono delle cose fondamentali che sono: i registri, il PC counter, lo stack, le famiglie di istruzioni (spostamento, caricamento, incremento, salto, shift, comparazione ecc) ed i metodi di indirizzamento (fondamentali perché sono una sorta di "sintassi" delle istruzioni).


Inviato dal mio Nexus 5 utilizzando Tapatalk

 

[Nicola.Mariano]

Beh, in due mesi! Non è che si riesca a fare molto.

In ogni caso, al di là di ciò che ti è stato detto finora, che comunque è correttissimo: tieni presente che, indipendentemente dalla specifica architettura della CPU, i concetti basilari per la programmazione sono analoghi per ogni processore.
Cioè, tanto per non farla troppo difficile, ci sono delle cose fondamentali che sono: i registri, il PC counter, lo stack, le famiglie di istruzioni (spostamento, caricamento, incremento, salto, shift, comparazione ecc) ed i metodi di indirizzamento (fondamentali perché sono una sorta di "sintassi" delle istruzioni).


Inviato dal mio Nexus 5 utilizzando Tapatalk

Bene, perciò cambieranno ad esempio gli interrupt?

 

[DispatchCode]

Bene, perciò cambieranno ad esempio gli interrupt?

Sotto 8086 chiami le INT software; in modalità protetta non puoi chiamarle direttamente.
Gli interrupt HW sotto 8086 sono gestiti da un microcontrollore chiamato PIC (Programmable Interrupt Controller).
La chiamata di tutte queste interrupt (hardware e software) in 8086 provoca un salto in una tabella, chiamata IVT (Interrupt Vector Table). Qui si trova l'indirizzo della procedura che eseguirà il compito per la quale è stata chiamata; la procedura si chiama ISR (Interrupt Service Routine). Le ISR sono installate dal BIOS e dal sistema operativo (il DOS ad esempio).

Le cose oggi sono più complesse. Ora la tabella non è più come prima, si chiama IDT, ma il concetto è più o meno quello. La chiamata non avviene con una INT per le interrupt software.
Per le interrupt HW il microcontrollore è l'APIC (ci può essere ancora il PIC per compatibilità, ma sotto x86); ci sono più APIC, master e slave. L'interrupt ricevuto dal master viene affidato a uno degli slave e fatto eseguire da uno dei core (quello con meno carico etc etc).

Ti lascio il link ad un mio vecchio intervento: https://forum.tomshw.it/threads/in-che-modo-vengono-realizzate-le-system-call.598525/#post-5703717

 

[Nicola.Mariano]

Sotto 8086 chiami le INT software; in modalità protetta non puoi chiamarle direttamente.
Gli interrupt HW sotto 8086 sono gestiti da un microcontrollore chiamato PIC (Programmable Interrupt Controller).
La chiamata di tutte queste interrupt (hardware e software) in 8086 provoca un salto in una tabella, chiamata IVT (Interrupt Vector Table). Qui si trova l'indirizzo della procedura che eseguirà il compito per la quale è stata chiamata; la procedura si chiama ISR (Interrupt Service Routine). Le ISR sono installate dal BIOS e dal sistema operativo (il DOS ad esempio).

Le cose oggi sono più complesse. Ora la tabella non è più come prima, si chiama IDT, ma il concetto è più o meno quello. La chiamata non avviene con una INT per le interrupt software.
Per le interrupt HW il microcontrollore è l'APIC (ci può essere ancora il PIC per compatibilità, ma sotto x86); ci sono più APIC, master e slave. L'interrupt ricevuto dal master viene affidato a uno degli slave e fatto eseguire da uno dei core (quello con meno carico etc etc).

Ti lascio il link ad un mio vecchio intervento: https://forum.tomshw.it/threads/in-che-modo-vengono-realizzate-le-system-call.598525/#post-5703717

Precisissimo, grazie!

 

[rctimelines]

Precisissimo, grazie!

Si, ma se non sai le istruzioni, la e nemmeno la teoria della programmazione in assembly, le precisazioni sugli interrupt cosa ti rappresentano?

Inviato dal mio Nexus 5 utilizzando Tapatalk

 

[Nicola.Mariano]

Si, ma se non sai le istruzioni, la e nemmeno la teoria della programmazione in assembly, le precisazioni sugli interrupt cosa ti rappresentano?

Inviato dal mio Nexus 5 utilizzando Tapatalk

Forse mi sono fatto capire male io.
Cercavo un'altra infarinatura generale, perché istruzioni, interrupt e un po' di teoria l'avevo, però mi serviva un qualcosa di simile all'approfondimento di @DispatchCode per "comprendere" dato che è differente da "conoscere".

 

[pabloski]

Forse mi sono fatto capire male io.
Cercavo un'altra infarinatura generale, perché istruzioni, interrupt e un po' di teoria l'avevo, però mi serviva un qualcosa di simile all'approfondimento di @DispatchCode per "comprendere" dato che è differente da "conoscere".

Purtroppo l'assembly opera al livello del processore e i processori si evolvono e nemmeno tanto lentamente. Gli interrupt sono un esempio di cose che puoi studiare e poi non riuscire ad applicare. Studi l'architettura x86 e probabilmente ti hanno insegnato a lavorare in modalità reale ( quelle dei chip a 8 e 16 bit per capirci ). Lì effettivamente esiste il concetto di interrupt come lo studi sul libro, con l'istruzione INT e tutto il resto e la tabella chiamata IVT in una posizione fissa in memoria.

Poi ti accorgi che un processore x86 moderno, in modalità protetta o long, ragiona ( dal punto di vista software ) in maniera differente. E ti compare l'IDT, che non è fissa in memoria, ma il registro IDTR ti dice dove sta. E il contenuto? Ma ovviamente punta alle entry nella GDT e per non farsi mancare nulla sono distinte in interrupt, task e trap gates. E poi c'è il lato hardware che illustrava DispatchCode, con un PIC sostituito da più APIC.

Per questo dicevo che è importante la parte teorica. Almeno diventa chiaro il contesto, cioè di cosa si sta parlando. E ripeto, almeno ai miei tempi, si studiava x86 in modalità reale.

 

[Nicola.Mariano]

Purtroppo l'assembly opera al livello del processore e i processori si evolvono e nemmeno tanto lentamente. Gli interrupt sono un esempio di cose che puoi studiare e poi non riuscire ad applicare. Studi l'architettura x86 e probabilmente ti hanno insegnato a lavorare in modalità reale ( quelle dei chip a 8 e 16 bit per capirci ). Lì effettivamente esiste il concetto di interrupt come lo studi sul libro, con l'istruzione INT e tutto il resto e la tabella chiamata IVT in una posizione fissa in memoria.

Poi ti accorgi che un processore x86 moderno, in modalità protetta o long, ragiona ( dal punto di vista software ) in maniera differente. E ti compare l'IDT, che non è fissa in memoria, ma il registro IDTR ti dice dove sta. E il contenuto? Ma ovviamente punta alle entry nella GDT e per non farsi mancare nulla sono distinte in interrupt, task e trap gates. E poi c'è il lato hardware che illustrava DispatchCode, con un PIC sostituito da più APIC.

Per questo dicevo che è importante la parte teorica. Almeno diventa chiaro il contesto, cioè di cosa si sta parlando. E ripeto, almeno ai miei tempi, si studiava x86 in modalità reale.

Comprendo.
Beh, per motivi logistici non siamo proprio riusciti a tenere salda la teoria, ma dovrebbe essere tutto più chiaro da ora in avanti.

 

[DispatchCode]

Comprendo.
Beh, per motivi logistici non siamo proprio riusciti a tenere salda la teoria, ma dovrebbe essere tutto più chiaro da ora in avanti.

Tante cose le vedrai all'università e su testi di architettura ed OS.

 

[Utente 16812]

Bene, perciò cambieranno ad esempio gli interrupt?

E' pacifico assistere, di pari passo con l'avanzamento tecnologico nel campo delle micro-architetture hardware, ad una "mutazione" che riguarda le modalità (@DispatchCode ne ha illustrate alcune) di gestione dell'I/O, del trasferimento dei dati, dell'interfacciamento delle periferiche e così via ma se dovessi, per ipotesi, progettare un semplice sistema a microprocessore (magari in seguito vedremo come si progetta un computer), la soluzione inerente alla gestione "hardware" dell'Interrupt sarebbe molto semplice :sisi:
Qual è questa soluzione ? :asd:
Si tratta di ricorrere ad un sistema "combinatorio" come quello del Priority Encoder (il codificatore a priorità), ad es. il chip 74147, che ha alcune linee in ingresso e altre linee in uscita che codificano, in binario, il valore corrispondente all'ingresso selezionato:
http://www.elemania.altervista.org/digitale/combinatorio/comb2.html :sisi:
La logica interna (su cui non mi soffermerò per ora) è in grado di "prevedere" una "priorità" fra gli ingressi, anche contemporaneamente abilitati :shock:
In parole povere, in caso di abilitazione contemporanea di più ingressi, viene codificato soltanto uno di questi e più precisamente quello che presenta il valore binario più alto :D
Una porta logica OR s'incarica di "generare" la richiesta di Interrupt al microprocessore, mentre le uscite potranno essere lette da una porta di I/O :sisi:
A questo punto tu potresti "obiettare" su una soluzione, per così dire, "rigida" come quella proposta ma la risposta a tale obiezione è immediata: qualora si ritenga necessaria una gestione più "dinamica", ossia programmabile, degli Interrupt, si può fare ricorso a speciali chip LSI (a larga scala di integrazione) chiamati PIC (ad es. l'8259), in grado di gestire, anche in modo software, più linee di interruzione:
http://xoomer.virgilio.it/ramsoft/asmavan/pic8259.html :sisi:

P.S. Sulle reti combinatorie e le reti sequenziali leggi qui:
https://forum.tomshw.it/threads/approccio-allelettronica-digitale.389539/post-4755129 (e seguenti)
Altri miei interventi qui:
https://forum.tomshw.it/threads/domande-della-vita.743231/post-7046977 (sotto c'è anche un link in cui spiego il funzionamento della porta OR in logica DL a diodi) ;)

Post unito automaticamente: 1 Febbraio 2019

Ho dimenticato i microcontrollori … vedi qui:
https://forum.tomshw.it/threads/arduino-101-tutorial-n°1-cosè-arduino.354938/post-6316616 (e seguenti) ;)