[Assembly] Curiosità linguaggio e assembler

[Ryuzaki_Eru]

Sono sempre stato curioso di studiare e imparare un pò di assembly. Nella F.A.Q tra le varie cose dice:

Ecco perche' il compilatore assembly in realta' si chiama assemblatore (assembler).
Proprio perche' non effettua alcuna traduzione, ma "assembla" cio' che avete scritto in un formato binario leggibile dalla macchina e dipendente dal sistema operativo.

Ma il codice binario non dovrebbe essere "universale"? E' il codice assembly che dovrebbe dipendere dall'architettura del processore no? E il S.O in tutto questo cosa c'entra?

Infine:

avete bisogno
di un assemblatore.
Gli unici due ad essere veramente aggiornati sono lo GNU Assembler (as, anche detto gas) e Nasm (Netwide Assembler).
Il primo e' stato progettato per assemblare l'output dei compilatori.NASM invece e' considerato dai piu' come l'apoteosi dell'assemblatore per codifica manuale. Non vi sembrera' infatti di possedere un assemblatore, ma un compilatore vero e proprio! Ha una gestione degli errori veramente degna di nota, inoltre supporta l'assemblaggio in diversi formati
binari (tra cui il COFF, l'ELF e via dicendo). La sua sintassi inoltre e' pulita e semplice da capire (per quanto semplice si possa definire la sintassi di un linguaggio assembly, ovviamente ).

1)cosa significa la parte in grassetto?
2)cosa c'entra NASM con la sitassi dell'assembly? Non dovrebbe essere un assemblatore? Da quello che ho incollato sembra che NASM abbia una propria sintassi, ma la sintassi dell'assembly non cambia sempre a seconda dell'architettura su cui deve essere scritto?

Sono domande da newbie totale, ma è quello che sono per quanto riguarda assembly e basso livello Da qualche parte si deve pur iniziare però

[<Gabrik>]

Originariamente inviato da Ryuzaki_Eru

Sono sempre stato curioso di studiare e imparare un pò di assembly. Nella F.A.Q tra le varie cose dice:

Ma il codice binario non dovrebbe essere "universale"? E' il codice assembly che dovrebbe dipendere dall'architettura del processore no?

da quel poco che ho studiato il binario non è propio universale perché ad ogni architettura corrispondono istruzioni diverse per la stessa sequenza di bit
per esemio:
in x86 00F4 potrebbe essere una mov
mentre in ARM potrebbe essere qualche altra cosa tipo una add o un jmp
(ovviamente ho preso un valore a caso )

[Ryuzaki_Eru]

Originariamente inviato da <Gabrik>

da quel poco che ho studiato il binario non è propio universale perché ad ogni architettura corrispondono istruzioni diverse per la stessa sequenza di bit
per esemio:
in x86 00F4 potrebbe essere una mov
mentre in ARM potrebbe essere qualche altra cosa tipo una add o un jmp
(ovviamente ho preso un valore a caso )

Ok, grazie. Ora forse ho capito cosa voleva quella parte della F.A.Q(non è che sia proprio chiarissima è, si deve interpretare).

Ora aspetto chiarimenti sulla seconda parte, anch'essa poco chiara a mio parere.

[cdimauro]

Originariamente inviato da Ryuzaki_Eru

Sono sempre stato curioso di studiare e imparare un pò di assembly. Nella F.A.Q tra le varie cose dice:

Ma il codice binario non dovrebbe essere "universale"?

Assolutamente no. Anzi, è il meno universale che ci possa essere.

E' il codice assembly che dovrebbe dipendere dall'architettura del processore no?

Sì.

E il S.O in tutto questo cosa c'entra?

Perché s.o. diversi hanno ABI diverse, e di conseguenza il codice assembly può essere anche abbastanza diverso, pur essendo per lo stesso processore.

Infine:

1)cosa significa la parte in grassetto?

Che i compilatori di linguaggi ad alto livello generano codice assembly, e quest'ultimo finisce poi in pasto a un assemblatore come (g)as che fornirà effettivamente il codice oggetto.

2)cosa c'entra NASM con la sitassi dell'assembly? Non dovrebbe essere un assemblatore? Da quello che ho incollato sembra che NASM abbia una propria sintassi, ma la sintassi dell'assembly non cambia sempre a seconda dell'architettura su cui deve essere scritto?

No, cambia. Ad esempio la toolchain di GNU utilizza la sintassi AT&T, che è più adatta a codice generato automaticamente appunto (vedi punto precedente).

Mentre tradizionalmente i programmatori assembly x86 hanno usato la sintassi Intel, che è di gran lunga più semplice da utilizzare per chi, al contrario, scrive il codice manualmente.

Inoltre, a parte la sintassi di base, un assemblatore può fornire costrutti sintattici aggiuntivi per rendere più comoda la vita al programmatore assembly (che di per sé soffre già abbastanza lavorando con questo linguaggio, per cui ogni aiuto è bene accetto ).

Sono domande da newbie totale, ma è quello che sono per quanto riguarda assembly e basso livello Da qualche parte si deve pur iniziare però

Chiedere non costa nulla.

[Ryuzaki_Eru]

Originariamente inviato da cdimauro

Assolutamente no. Anzi, è il meno universale che ci possa essere.

Non lo sapevo, non avendo mai studiato queste cose credevo che il linguaggio binario, essendo compost da 0 e 1, fosse uguale a presindere dall'hardware.

No, cambia. Ad esempio la toolchain di GNU utilizza la sintassi AT&T, che è più adatta a codice generato automaticamente appunto (vedi punto precedente).

Si, infatti ho detto che cambia

Inoltre, a parte la sintassi di base, un assemblatore può fornire costrutti sintattici aggiuntivi per rendere più comoda la vita al programmatore assembly (che di per sé soffre già abbastanza lavorando con questo linguaggio, per cui ogni aiuto è bene accetto ).

Si, ma il linguaggio non dipende dall'architettura del processore? Cosa c'entra con l'assmbler che è uno strumento e non un linguaggio?

[cdimauro]

In realtà non c'è uno standard vero e proprio, e in genere è il produttore di CPU che, rilasciando informazioni a riguardo, definisce la sintassi per il proprio processore.

Ma questo non vuol dire che si debba seguire al 100% quella sintassi. Infatti la si può anche estendere, oppure utilizzarne una completamente diversa (vedi quella AT&T, ad esempio).

[Ryuzaki_Eru]

Originariamente inviato da cdimauro

In realtà non c'è uno standard vero e proprio, e in genere è il produttore di CPU che, rilasciando informazioni a riguardo, definisce la sintassi per il proprio processore.

Ma questo non vuol dire che si debba seguire al 100% quella sintassi. Infatti la si può anche estendere, oppure utilizzarne una completamente diversa (vedi quella AT&T, ad esempio).

Ma il processore deve supportarla una determinata sintassi però. E' questo che non capisco: questo assembler ha una propria sintassi e funziona su tutti i processori? E' una specie di "interprete" allora?

[cdimauro]

Originariamente inviato da Ryuzaki_Eru

Ma il processore deve supportarla una determinata sintassi però.

Il processore supporta l'unica cosa che conosce i binari (già caricati in memoria).

Come si arrivi a ottenere tutto ciò è un altro paio di maniche.

E' questo che non capisco: questo assembler ha una propria sintassi e funziona su tutti i processori? E' una specie di "interprete" allora?

No, l'assembler è un programma a tutti gli effetti e, come tale, deve essere scritto in qualche linguaggio.

Inoltre non è richiesto che l'assemblatore giri sullo stesso processore per cui genererà codice oggetto. Infatti esistono i cosiddetti cross-assemblatori, che girano su una piattaforma e compilano per un'altra.

Poi ci sono assemblatori che supportano più sintassi assembly per lo stesso processore (ad esempio Intel e AT&T per gli x86) e/o per processori diversi (x86, 68000, ARM, ecc.), e che possono girare su piattaforme diverse.

EDIT: l'assemblatore potrebbe anche essere un programma interpretato.

[Ryuzaki_Eru]

Originariamente inviato da cdimauro

Il processore supporta l'unica cosa che conosce i binari (già caricati in memoria).

Come si arrivi a ottenere tutto ciò è un altro paio di maniche.

No, l'assembler è un programma a tutti gli effetti e, come tale, deve essere scritto in qualche linguaggio.

Inoltre non è richiesto che l'assemblatore giri sullo stesso processore per cui genererà codice oggetto. Infatti esistono i cosiddetti cross-assemblatori, che girano su una piattaforma e compilano per un'altra.

Poi ci sono assemblatori che supportano più sintassi assembly per lo stesso processore (ad esempio Intel e AT&T per gli x86) e/o per processori diversi (x86, 68000, ARM, ecc.), e che possono girare su piattaforme diverse.

EDIT: l'assemblatore potrebbe anche essere un programma interpretato.

Più o meno ho capito, anche se il fatto di conoscere i binari è collegato al linguaggio assembly relativo visto che ogni linguaggio assembly codifica le informazioni in binario in modo diverso.
Imparerò iniziando a partire da qualche parte, il problema è da dove

[!fazz]

se vuoi iniziare con l'assembler ti conviene iniziare con processori semplici che hanno poche istruzioni puoi iniziare cercando qualcosa su z80 ( il celebre processore degli zx spectrum o del più volgare gameboy) oppure con i mips (scarica pc spim)

in alternativa puoi passare al lato oscuro dell'hw e comprare una scheda a microcontrollore ( es la classica ed economica arduino) e programmare quella

[Ryuzaki_Eru]

Originariamente inviato da !fazz

se vuoi iniziare con l'assembler ti conviene iniziare con processori semplici che hanno poche istruzioni puoi iniziare cercando qualcosa su z80 ( il celebre processore degli zx spectrum o del più volgare gameboy) oppure con i mips (scarica pc spim)

in alternativa puoi passare al lato oscuro dell'hw e comprare una scheda a microcontrollore ( es la classica ed economica arduino) e programmare quella

Grazie mille per i consigli

[!fazz]

Originariamente inviato da Ryuzaki_Eru

Grazie mille per i consigli

di niente, se ti servono consigli chiedi pure anche se ultimamente l'assembly lo uso pochissimo visto che faccio tutto in c/c++ anche sui micro

[ingframin]

Io ti consiglio invece di comprare un libro:
"Reti logiche e calcolatori"
Di Fabrizio Luccio e Linda Pagli.
Ci troverai la risposta a tutte le domande che hai postato qui

[cdimauro]

Originariamente inviato da !fazz

se vuoi iniziare con l'assembler ti conviene iniziare con processori semplici che hanno poche istruzioni puoi iniziare cercando qualcosa su z80 ( il celebre processore degli zx spectrum o del più volgare gameboy) oppure con i mips (scarica pc spim)

in alternativa puoi passare al lato oscuro dell'hw e comprare una scheda a microcontrollore ( es la classica ed economica arduino) e programmare quella

In alternativa c'è pure l'emulatore 6502 online, con tanto di assemblatore integrato ed esempi (anche giochi!).

Processori più semplici di un 6502 è difficile trovarne.

[pabloski]

Originariamente inviato da Ryuzaki_Eru

Più o meno ho capito, anche se il fatto di conoscere i binari è collegato al linguaggio assembly relativo visto che ogni linguaggio assembly codifica le informazioni in binario in modo diverso.
Imparerò iniziando a partire da qualche parte, il problema è da dove

Aggiungerei, per chiarire, che tra assembly e linguaggio macchina c'è una corrispondenza biunivoca. L'assembly è la rappresentazione mnemonica del linguaggio del processore cioè il codice binario.

Ogni famiglia di processori c'ha il suo e ogni processore in una data famiglia ha meno o più istruzioni che svolgono vari tipi di operazioni.

L'assembler è semplicemente il programma che trasforma il codice assembly mnemonico in codice binario. Il sistema operativo c'entra per il semplice motivo che gli eseguibili che andrai a creare in assembly dovranno girare, in genere, all'interno del sistema operativo che stai usando. In questo caso dovranno usare l'API dell'OS ( altrimenti non arrivi lontano ) e gli eseguibili dovranno essere nel formato definito dall'OS ( PE per windows, ELF per linux ).

Per iniziare, essendo non proprio facilissimo trovare informazioni su processori vecchi, ti conviene partire con gli x86. C'è un libro di James Coffron che ho usato anni fa ed è molto chiaro. La fregatura è che non tratta la programmazione a 32 bit ( quindi la p-mode ecc... ) ma per iniziare è ottimo perchè fa capire bene molti concetti che stanno alla base dell'architettura x86.

[cdimauro]

Non è così. L'assembly può prevedere dei costrutti sintattici aggiuntivi, come già detto, oltre che delle macroistruzioni che possono anche non avere una diretta corrispondenza con un opcode dell'architettura target.

Viceversa, è possibile che alcuni opcode non abbiano il corrispondente mnemonico assembly. Basti pensare proprio all'architettura x86 che hai citato; ad esempio INC EAX può benissimo essere rappresentato con due opcode diversi (e, a voler esser pignoli, quasi tutte le istruzioni possono avere opcode diversi). Anche i 68000 hanno opcode duplicati per lo stesso mnemonico (anche se sono pochi i casi rispetto a x86).

Quindi, in generale, il concetto è che l'assembly è un linguaggio di programmazione per una determinata architettura e NON necessariamente si tratta di un "mascheramento" a più alto livello degli opcode del linguaggio macchina.

[pabloski]

Originariamente inviato da cdimauro

Non è così. L'assembly può prevedere dei costrutti sintattici aggiuntivi, come già detto, oltre che delle macroistruzioni che possono anche non avere una diretta corrispondenza con un opcode dell'architettura target.

l'assemblatore ma non il linguaggio assembly

avere le macro in nasm non implica che l'assembly x86 ( cioè l'isa x86 ) ha le macro

un assemblatore che implementa cose che vanno oltre le istruzioni del processore sta implementando delle estensioni

[e-commerce84]

Originariamente inviato da Ryuzaki_Eru

Sono sempre stato curioso di studiare e imparare un pò di assembly. Nella F.A.Q tra le varie cose dice:



Ma il codice binario non dovrebbe essere "universale"? E' il codice assembly che dovrebbe dipendere dall'architettura del processore no? E il S.O in tutto questo cosa c'entra?

Infine:



1)cosa significa la parte in grassetto?
2)cosa c'entra NASM con la sitassi dell'assembly? Non dovrebbe essere un assemblatore? Da quello che ho incollato sembra che NASM abbia una propria sintassi, ma la sintassi dell'assembly non cambia sempre a seconda dell'architettura su cui deve essere scritto?

Sono domande da newbie totale, ma è quello che sono per quanto riguarda assembly e basso livello Da qualche parte si deve pur iniziare però

1) A differenza di tutti gli altri linguaggi ogni istruzione Assembler corrisponde esattamente ad un'istruzione del processore. Quando tu fai un mov di un certo valore in un certo registro della CPU (non ricordo più la sintassi), quell'istruzione corrisponde esattamente ad un'istruzione interpretata dal processore per cui si stà scrivendo il programma...infatti un programma Assembler per X86 non potrà mai essere assemblato e fatto girare su un'altra architettura mentre un programma in C potrà essere COMPILATO per qualsiasi architettura...

Questo perchè quando tu scrivi un programma Assembler stai dando istruzioni direttamente alla CPU e sono istruzioni per quella specifica CPU...se tu scrivi un programma in C lo stai scrivendo in un linguaggio più generale che poi verrà COMPILATO in un'assembler per la specifica architettura che stai usando (ad esempio usando il compilatore C per X86 piuttosto che per SPARC, etcetc) che poi a sua volta verrà assemblato dall'assemblatore che viene sempre usato nella fase finale...

Questo molto a grandi linee ma spero che renda l'idea...

In assembler c'è una corrispondenza uno ad uno tra le istruzioni che scrivi e le istruzioni della CPU

2) Credo (perchè ho usato poco assembler) che GNU Assembler sia lo strumento che fà la seguente cosa: scrivi un programma in un qualche linguaggio (ad esempio C), il compilatore C che hai installato sulla tua macchina ti traduce il tuo programma in codice Assembler adatto alla tua architettura (X86, Sparc, etcetc), a questo punto GNU Assembler assembla tale codice in un eseguibile

Nasm invece dovrebbe essere l'assemblatore che viene generalmente usato quando tu scrivi un tuo programma direttamente in assembler...se sei tu a scrivere il codice assembler (invece di averlo ottenuto da codice scritto in un altro linguaggio), lo dai in pasto a NASM ed ottieni l'eseguibile

Ciao
Andrea

[Ryuzaki_Eru]

Grazie a tutti per i consigli e la disponibilità, appena possibile inizio subito a dare un'occhiata all'argomento(chissà poi da dove mi è venuta sta fantasia dopo essere stato un anno fermo ).

[rеpne scasb]

■