Kleidemos
03-09-2003, 10:17
Come' è l' asm degli integrati elettronici rispetto al quello del PC???
P.S: di puo parlare di programmazione in questo campo?
Tk 10k
P.S: di puo parlare di programmazione in questo campo?
Tk 10k
View Full Version : Assembly degli integrati(EPROM, EEPROM)
Kleidemos
03-09-2003, 14:25
:muro:
cionci
03-09-2003, 15:29
Certo, ma dipende non dal tipo di chip su cui memorizzi il codice (EPROM, EEPROM, FLASH ROM), ma dalla CPU o microcontrollore a cui lo de4vi dare in pasto... Nella FLASH ROM del BIOS ad esempio c'è normale codice x86 a 16 bit...
Kleidemos
03-09-2003, 15:36
ma un asm cmq + limitato di instruzioni...........e quindi + facile da imparare.......
O sbaglio tutto a pensarla cosi?
P.S: lo so che sono gnucco..ma sono cosi:D
O sbaglio tutto a pensarla cosi?
P.S: lo so che sono gnucco..ma sono cosi:D
cionci
03-09-2003, 15:49
Originariamente inviato da Kleidemos
ma un asm cmq + limitato di instruzioni...........e quindi + facile da imparare.......
O sbaglio tutto a pensarla cosi?
Sbagli...dipende tutto a quale CPU vuoi dare in pasto le istruzioni...ed a quel punto puoi usare tutto l'istruction set di quella CPU...
Bisogna rpecisare che, ovviamente, nella RAM come nelle ROM ci va codice compialto...
Le ROM sono come le RAM soltante che il codice che vi è dentro non si può riscrivere con i metodi di scrittura tradizionali...
Il BIOS non è altro che un programma scritto in ASM x86 a 16 bit poi messo all'interno di queste memorie...
Quando una CPU x86 si accende viene messo nell'istruction pointer 0000 e nel Data Segment FFFF... In quella locazione c'è una istruzione mappata in hardware (cioè non residente in una memoria, quando sul bus a 20 bit viene fatta una lettura di istruzioni all'indirizzo FFFF0 automaticamente questa istruzione viene inviata in hardware alla CPU ed eseguita)... Questa istruzione è una JMP lunga che indica l'indirizzo di memoria in cui è mappato il BIOS... E da lì in poi viene eseguito il BIOS...
ma un asm cmq + limitato di instruzioni...........e quindi + facile da imparare.......
O sbaglio tutto a pensarla cosi?
Sbagli...dipende tutto a quale CPU vuoi dare in pasto le istruzioni...ed a quel punto puoi usare tutto l'istruction set di quella CPU...
Bisogna rpecisare che, ovviamente, nella RAM come nelle ROM ci va codice compialto...
Le ROM sono come le RAM soltante che il codice che vi è dentro non si può riscrivere con i metodi di scrittura tradizionali...
Il BIOS non è altro che un programma scritto in ASM x86 a 16 bit poi messo all'interno di queste memorie...
Quando una CPU x86 si accende viene messo nell'istruction pointer 0000 e nel Data Segment FFFF... In quella locazione c'è una istruzione mappata in hardware (cioè non residente in una memoria, quando sul bus a 20 bit viene fatta una lettura di istruzioni all'indirizzo FFFF0 automaticamente questa istruzione viene inviata in hardware alla CPU ed eseguita)... Questa istruzione è una JMP lunga che indica l'indirizzo di memoria in cui è mappato il BIOS... E da lì in poi viene eseguito il BIOS...
Kleidemos
03-09-2003, 15:52
x 0xFFFF intendi 65.535 decimale?
Mi spieghi meglio la faccenda del BIOS?
Mi spieghi meglio la faccenda del BIOS?
cionci
03-09-2003, 16:02
Sì...65535...
Il BIOS è mappato da un certo indirizzo di memoria in poi (mi sembra nello spazio compreso fra 640 Kb e 1 Mb)...
Facendo una MOV da quella zona di memoria (solo sotto DOS, non in Windows) leggi i dati contenuti nel BIOS...che poi in realtà sono istruzioni x86...
Il BIOS è mappato da un certo indirizzo di memoria in poi (mi sembra nello spazio compreso fra 640 Kb e 1 Mb)...
Facendo una MOV da quella zona di memoria (solo sotto DOS, non in Windows) leggi i dati contenuti nel BIOS...che poi in realtà sono istruzioni x86...
jolanda_81
03-09-2003, 20:14
L'assembler lo usi per i processori, una EEPROM è una memoria, non centra niente..
x110
04-09-2003, 16:51
considera che lo zilog z80 il predecessore degli 8086 non ha l'istruzione per la
moltiplicazione e quindi te la devi fare a mano come somma dello stesso numero per n volte.
qui si dimostra che il codice per processori come il pentium puo' essere piu' semplice in cose semplici. certo per esempio i processori pentium mmx hanno anche il set dii istruzioni mmx che lo z80 non ha.
esistono due tipi principali di processori i risc e i 8086.
i risc hanno poche istruzioni veloci. che stanno generalmente dentro una parola(a 14-16-18bit).
igli 8086 hanno piu' istruzioni che necessitano di piu' spazio e sono piu' specifiche.
degli attrezzi interessanti sono i processori PIC della microchip.
oltre ad essere veri processori hanno una ram interna,,, una eeprom che contiene il programma e un'altro spazio eeprom che puo' contenere i dati a macchina spenta,
dei timer programmabili interni, uscite specifiche per la comunicazione seriale con il pc,
e tantissime funzionalita.
le istruzioni sono molto semplici. sono processori risc.
moltiplicazione e quindi te la devi fare a mano come somma dello stesso numero per n volte.
qui si dimostra che il codice per processori come il pentium puo' essere piu' semplice in cose semplici. certo per esempio i processori pentium mmx hanno anche il set dii istruzioni mmx che lo z80 non ha.
esistono due tipi principali di processori i risc e i 8086.
i risc hanno poche istruzioni veloci. che stanno generalmente dentro una parola(a 14-16-18bit).
igli 8086 hanno piu' istruzioni che necessitano di piu' spazio e sono piu' specifiche.
degli attrezzi interessanti sono i processori PIC della microchip.
oltre ad essere veri processori hanno una ram interna,,, una eeprom che contiene il programma e un'altro spazio eeprom che puo' contenere i dati a macchina spenta,
dei timer programmabili interni, uscite specifiche per la comunicazione seriale con il pc,
e tantissime funzionalita.
le istruzioni sono molto semplici. sono processori risc.
cionci
05-09-2003, 09:37
Solo un appunto per "gli Z80 predecessori degli 8086" intendi solo dal punto di vista temporale, vero ?
BountyKiller
06-09-2003, 07:26
piccola aggiunta: le macchine risc hanno istruzioni corte ( anche se non necessariamente "semplici") unicamente per poter realizzare facilmente le pipeline di queste macchine contenendo i pipeline hazard :)
cionci
06-09-2003, 09:18
Certo...e non solo corte, ma anche a lunghezza fissa... Approccio poi ripreso anche dalle CPU x86 moderne (K6, K7, K8, P4)...dotandole di una unità di traduzione da x86 in un linguaggio intermedio...è poi questo linguaggio che viene dato in "pasto" alle unità di controllo ed esecuzione... Il P4 è andato addirittura oltre mantenendo nella cache L1 (trace cache), non le istruzioni x86, ma direttamente le istruzioni nel linguaggio intermedio, risparmiando così ulteriori decodifiche... Purtroppo l'unità di decodfica occupa ormai quasi il 30% del core (esclusa la cache) e questo porta a problemi di "spazio" e di calore...
La soluzione a questo è fare la traduzione tramite un layer software che sta sopra la CPU...approccio preso da Transmeta...
La soluzione a questo è fare la traduzione tramite un layer software che sta sopra la CPU...approccio preso da Transmeta...
x110
06-09-2003, 10:30
x cionci puoi dire che uno z80e' piu' vicino ad un risc che non ad un 8086?
il senso era questo,
certo e' una caccola di processore,con molte meno funzionalita' con tanti anni sulle spalle,
ma e' stato fatto anche un computer con questo processore, e' stato utilizzato anche sui controlli di lavatrici, insomma onore allo z80. in piu' costa 2 euro.
il senso era questo,
certo e' una caccola di processore,con molte meno funzionalita' con tanti anni sulle spalle,
ma e' stato fatto anche un computer con questo processore, e' stato utilizzato anche sui controlli di lavatrici, insomma onore allo z80. in piu' costa 2 euro.
cionci
06-09-2003, 10:37
Certo onore allo z80...ma io intendevo dire che il predecessore, non solo in senso temporale, del 8086 era l'8008...ed ancora prima il 4004...
cionci
06-09-2003, 10:54
Senza contare che lo Z80 è nato dal nostro Federico Faggin padre anche di 4004, 8008 e 8080...
BountyKiller
08-09-2003, 08:24
Originariamente inviato da cionci
Certo...e non solo corte, ma anche a lunghezza fissa... Approccio poi ripreso anche dalle CPU x86 moderne (K6, K7, K8, P4)...dotandole di una unità di traduzione da x86 in un linguaggio intermedio...è poi questo linguaggio che viene dato in "pasto" alle unità di controllo ed esecuzione... Il P4 è andato addirittura oltre mantenendo nella cache L1 (trace cache), non le istruzioni x86, ma direttamente le istruzioni nel linguaggio intermedio, risparmiando così ulteriori decodifiche... Purtroppo l'unità di decodfica occupa ormai quasi il 30% del core (esclusa la cache) e questo porta a problemi di "spazio" e di calore...
La soluzione a questo è fare la traduzione tramite un layer software che sta sopra la CPU...approccio preso da Transmeta...
eh eh..sottoscrivo in pieno! era stato fatto lo Z-DOS per lo z80 :)
è stata la prima macchina che ho imparato a programmare con l'assembly:cry:
Certo...e non solo corte, ma anche a lunghezza fissa... Approccio poi ripreso anche dalle CPU x86 moderne (K6, K7, K8, P4)...dotandole di una unità di traduzione da x86 in un linguaggio intermedio...è poi questo linguaggio che viene dato in "pasto" alle unità di controllo ed esecuzione... Il P4 è andato addirittura oltre mantenendo nella cache L1 (trace cache), non le istruzioni x86, ma direttamente le istruzioni nel linguaggio intermedio, risparmiando così ulteriori decodifiche... Purtroppo l'unità di decodfica occupa ormai quasi il 30% del core (esclusa la cache) e questo porta a problemi di "spazio" e di calore...
La soluzione a questo è fare la traduzione tramite un layer software che sta sopra la CPU...approccio preso da Transmeta...
eh eh..sottoscrivo in pieno! era stato fatto lo Z-DOS per lo z80 :)
è stata la prima macchina che ho imparato a programmare con l'assembly:cry:
recoil
08-09-2003, 13:05
Originariamente inviato da cionci
Certo...e non solo corte, ma anche a lunghezza fissa... Approccio poi ripreso anche dalle CPU x86 moderne (K6, K7, K8, P4)...dotandole di una unità di traduzione da x86 in un linguaggio intermedio...è poi questo linguaggio che viene dato in "pasto" alle unità di controllo ed esecuzione...
i nuovi processori a 64bit come si comportano? sono completamente RISC?
lasciamo stare per un momento l'Opteron che deve avere retrocompatibilita', mi interessano i processori che verranno subito dopo.
io avevo capito che, non essendoci piu' l'obbligo di compatibilita' con il passato, avevano cambiato parecchie cose e per questo ho pensato a un approccio RISC.
Certo...e non solo corte, ma anche a lunghezza fissa... Approccio poi ripreso anche dalle CPU x86 moderne (K6, K7, K8, P4)...dotandole di una unità di traduzione da x86 in un linguaggio intermedio...è poi questo linguaggio che viene dato in "pasto" alle unità di controllo ed esecuzione...
i nuovi processori a 64bit come si comportano? sono completamente RISC?
lasciamo stare per un momento l'Opteron che deve avere retrocompatibilita', mi interessano i processori che verranno subito dopo.
io avevo capito che, non essendoci piu' l'obbligo di compatibilita' con il passato, avevano cambiato parecchie cose e per questo ho pensato a un approccio RISC.
cionci
08-09-2003, 13:41
Se guardi nel futuro dell'x86 l'approccio sarà sempre classico...
Per i nuovi e i vecchi processori a 64 bit l'approccio è sia VLIW (Itanium e Transmeta) che RISC...
Comunque ora la differenza fra l'appriccio x86 e quello RISC si è assottigliata molto...con l'istruction set dei vari RISC che aumenta e con l'architettura interna degli x86 che ha acquisito caratteristiche fino a poco tempo proprie delle CPU RISC...
Per i nuovi e i vecchi processori a 64 bit l'approccio è sia VLIW (Itanium e Transmeta) che RISC...
Comunque ora la differenza fra l'appriccio x86 e quello RISC si è assottigliata molto...con l'istruction set dei vari RISC che aumenta e con l'architettura interna degli x86 che ha acquisito caratteristiche fino a poco tempo proprie delle CPU RISC...
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.