[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 :D Da qualche parte si deve pur iniziare però :)

[<Gabrik>]

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?

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]

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]

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. :D
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 (http://en.wikipedia.org/wiki/Application_binary_interface) 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 :D).
Sono domande da newbie totale, ma è quello che sono per quanto riguarda assembly e basso livello :D Da qualche parte si deve pur iniziare però :)
Chiedere non costa nulla. ;)

[Ryuzaki_Eru]

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

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 :D).

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]

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]

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]

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 :D

[!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 :D

[Ryuzaki_Eru]

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 :D

Grazie mille per i consigli :D

[!fazz]

Grazie mille per i consigli :D

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]

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 :D
In alternativa c'è pure l'emulatore 6502 online (http://www.6502asm.com/), con tanto di assemblatore integrato ed esempi (anche giochi!). :cool:

Processori più semplici di un 6502 è difficile trovarne. :)

[pabloski]

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 :D

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]

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]

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 :D 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 :D).

[rеpne scasb]

■

[cdimauro]

l'assemblatore ma non il linguaggio assembly
La differenza sarebbe? L'assemblatore quale linguaggio compila/traduce in codice oggetto?
avere le macro in nasm non implica che l'assembly x86 ( cioè l'isa x86 ) ha le macro
Non confondere le etichette che ogni produttore di CPU assegna agli opcode della sua ISA, con il linguaggio assembly del relativo assemblatore che viene poi definito e utilizzato.

Esempio (http://software.intel.com/en-us/articles/introduction-to-x64-assembly/), proprio dal sito di Intel.

Come puoi vedere tu stesso negli esempi, si fa uso di direttive ed etichette per gli indirizzi dei salti.
un assemblatore che implementa cose che vanno oltre le istruzioni del processore sta implementando delle estensioni
Questo vale soltanto quando un assemblatore va oltre le specifiche del linguaggio assembly della casa madre. Che NON è un mero traduttore di mnemonici. Vedi anche il link di cui sopra.

Inoltre, prova a immaginare cosa succederebbe se un produttore di CPU si limitasse a definire soltanto le etichette per gli opcode, ignorando tutte le altre direttive e costrutti sintattici che in genere sono necessari per assemblare correttamente il codice: ci sarebbe il caos.

E, soprattutto, non oso immaginare quanto diventerebbe complicato lavorare per i programmatori. Basti pensare che lo stesso concetto di etichetta assegnata a un indirizzo per i salti è una sovrastruttura che va oltre la mera traduzione mnemonico -> opcode. Idem per le costanti, che dovrebbero essere calcolate a mano (quindi non ADD EAX, 3*5, ma ADD EAX,15; tanto per fare un esempio semplice).

Insomma, si dovrebbe tornare praticamente ai tempi in cui si lavorava col linguaggio macchina, perché l'assembly, alle tue condizioni, non sarebbe altro che un banale (perché è banale) mascheramento degli opcode. Un inferno.

Fortunatamente non è così, e l'assembly ha una sua dignità come linguaggio di più alto livello rispetto a quello macchina.

[pabloski]

No. Come piu' volte ribadito in questo stesso forum, "in generale", non esiste alcuna corrispondenza biunivoca tra lo mnemonico assembly e la sua corrispondente traduzione in linguaggio macchina.

Ad esempio, in assembly x86, lo mnemonico:


ADD EAX,1h


puo' essere tradotto sia con 05,01,00,00,00 che con 83,C0,01 (tutti i valori sono esadecimali). Per conferma, inserite tali sequenze numeriche in una porzione di RAM tramite un debugger (per esempio), e poi andate a disassemblare la relativa area di memoria. Noterete che le due sequenze vengono tradotte tutte e due con "ADD EAX,1", a riprova che non esiste "in generale", una piena corrispondenza biunivoca tra opcode e relativo linguaggio macchina. Ed in effetti gli assemblatori piu' avanzati sono in grado di utilizzare traduzioni diverse per lo stesso opcode, in modo, ad esempio da ottimizzare l'allineamento del codice (evitando uno o piu' "nop" ossia uno o piu xchg eax,eax (90h)). Esiste quindi la, tutt'altro che remota possibilita', che a parita' di sorgente assembly, il codice generato sia diverso in funzione dell'assemblatore stesso.

ovviamente io mi riferisco ad una corrispondenza tra l'istruzione assembly e l'operazione svolta dal processore, non mi riferisco alla codifica che quell'operazione avrà

add eax,1h sarà sempre tradotta come un'operazione di addizione ed è questo che intendo per corrispondenza

voglio dire che "mov eax, 00h" non sarà mai tradotta come "xor eax,eax", anche se sappiamo che funzionalmente sono equivalente

[rеpne scasb]

■

[cdimauro]

Tra l'altro avevamo già parlato di recente (http://www.hwupgrade.it/forum/showpost.php?p=35147915&postcount=102) proprio di quest'esempio.

La memoria fa cilecca...

[pabloski]

Sei abbastanza sfortunato. Con tanti esempi, hai preso uno dei rari esempi errati. Le due istruzioni "mov eax,0" e "xor eax,eax" sono diverse:

la prima e' indifferente rispetto ai flag, la seconda oltre a settare a zero C,S,O e A, setta a uno P e Z. Per capirci, se hai:


certo ma non mi sono soffermato sui dettagli

rimane il punto che ogni istruzione macchina ha una sua rappresentazione mnemonica, non mi pare di star dicendo chissà che di strano


La differenza sarebbe? L'assemblatore quale linguaggio compila/traduce in codice oggetto?

esempio banale, prendi nasm e l'assembler vatte-la-pesca

il primo supporta le macro, il secondo no, ma entrambi sono assemblatori x86

dunque l'assembly qual'è? quello del primo o quello del secondo?

è un banale esempio per capire che l'assembly ( almeno come lo intendo io ) è la rappresentazione mnemonica delle istruzioni del processore

tutto ciò che viene aggiunto a livello di linguaggio e non mappabile direttamente in linguaggio macchina è un'estensione

se invece vuoi considerare tutte le varie aggiunte, allora dobbiamo dire che nasm e vatte-la-pesca implementano due linguaggi assembly differenti

[cdimauro]

certo ma non mi sono soffermato sui dettagli
Perché hai scarsa esperienza con l'assembly.
rimane il punto che ogni istruzione macchina ha una sua rappresentazione mnemonica, non mi pare di star dicendo chissà che di strano
Ancora una volta, NON è vero. E gli esempi forniti sia da me che da repne lo dimostrano (ma non sono i soli).
esempio banale, prendi nasm e l'assembler vatte-la-pesca

il primo supporta le macro, il secondo no, ma entrambi sono assemblatori x86

dunque l'assembly qual'è? quello del primo o quello del secondo?
L'assembly è quello definito da Intel, che entrambi devono supportare.
è un banale esempio per capire che l'assembly ( almeno come lo intendo io ) è la rappresentazione mnemonica delle istruzioni del processore

tutto ciò che viene aggiunto a livello di linguaggio e non mappabile direttamente in linguaggio macchina è un'estensione
E' una tua opinione, e infatti è sbagliata. Vedi sopra.
se invece vuoi considerare tutte le varie aggiunte, allora dobbiamo dire che nasm e vatte-la-pesca implementano due linguaggi assembly differenti
L'importante è che siano in grado di compilare il codice assembly che fa uso della sintassi Intel.

E' chiaro che, in ogni caso, estendere il linguaggio assembly "ufficiale" comporta i suoi problemi di Embrace, Extend, Extinguish, di cui abbiamo già discusso altre volte, come ben sai.

In ogni caso il nocciolo della questione è che se l'assembly ufficiale supporta le macro e altri costrutti sintattici, NON ci troviamo di fronte a "estensioni" rispetto a un tuo personalissimo assembly 1:1 col linguaggio macchina.

[pabloski]

Perché hai scarsa esperienza con l'assembly.

può darsi


L'assembly è quello definito da Intel, che entrambi devono supportare.


quindi non ci sono costrutti aggiuntivi ma la pura e semplice rappresentazione mnemonica delle istruzioni macchina


L'importante è che siano in grado di compilare il codice assembly che fa uso della sintassi Intel.


e infatti è quello che ho detto, i costrutti sintattici aggiuntivi che citavi non fanno parte dell'assembly quindi ma dell'assembler


In ogni caso il nocciolo della questione è che se l'assembly ufficiale supporta le macro e altri costrutti sintattici, NON ci troviamo di fronte a "estensioni" rispetto a un tuo personalissimo assembly 1:1 col linguaggio macchina.

e infatti è quello che dicevo

l'assembly lo definisce chi fa il processore non chi fa l'assemblatore e per avere quei costrutti vuol dire che c'è il modo di rappresentarli a livello macchina

fino ad oggi nessun produttore di cpu ha creato un assembly che andasse oltre le capacità del codice macchina

[rеpne scasb]

■

[eraser]

Oggi e' sicuramente il tuo giorno sfortunato. Neanche questo e' vero. Sempre in linguaggio macchina x86-32 la sequenza: 10010000b e' sia "nop" che "xchg eax,eax".

Assolutamente confermato. In realtà non esisteva una vera e propria operazione NOP nei primi processori 8086, veniva tradotto come xchg ax,ax che comunque non fa niente, contrariamente ad un xchg ax,r16 che implica 3 cicli di clock. La funzione xchg eax,eax invece utilizza solo un ciclo di clock e dai processori 486 in su (mi sembra) viene tradotta come NOP per comodità, invece di far riferimento al registro eax che potrebbe causare eventuali stalli.

Sorvoliamo sulla questione dello 0x90 sui processori AMD64, dove invece esiste la funzione NOP vera e propria.

[rеpne scasb]

■

[cdimauro]

può darsi
E' quel che traspare da quanto hai scritto finora.
quindi non ci sono costrutti aggiuntivi ma la pura e semplice rappresentazione mnemonica delle istruzioni macchina
Da The Intel® 64 and IA-32 Architectures Software Developer's
Manual (http://download.intel.com/design/processor/manuals/253665.pdf) pag. 30:

"When instructions are represented symbolically, a subset of the IA-32 assembly language is used. In this subset, an instruction has the following format:
label: mnemonic argument1, argument2, argument3"
e infatti è quello che ho detto, i costrutti sintattici aggiuntivi che citavi non fanno parte dell'assembly quindi ma dell'assembler
No, fanno parte dell'assembly. Vedi sopra. E' scritto a chiare lettere.
e infatti è quello che dicevo
Quello a cui ti riferisci è il SOTTOINSIEME del linguaggio assembly che Intel, come pure tutti gli altri produttori di CPU, utilizzano per dare un nome agli opcode della loro ISA.
l'assembly lo definisce chi fa il processore non chi fa l'assemblatore e per avere quei costrutti vuol dire che c'è il modo di rappresentarli a livello macchina
Cioè? Spiegati meglio.
fino ad oggi nessun produttore di cpu ha creato un assembly che andasse oltre le capacità del codice macchina
Il link di cui sopra dimostra il contrario.

Mi spiace soltanto di non avere a portata di mano l'equivalente per i 68000, dove Motorola definiva non soltanto la sintassi delel macro, ma anche delle macro predefinite (push, pop, e altre) che venivano poi espanse in altre istruzioni (che NON trovavi fra quelle descritte nell'ISA).

EDIT. Se la memoria non m'inganna, dovrebbe esistere anche una NOP di 3 byte.

[eraser]

Non solo, posso aggiungere che (questa cosa non la troverete su wikipedia/google ma vi dovrete fidare di me), esisterebbe anche un nop2, si tratta della sequenza 8Dh,00h. E' un nop che occupa 2 byte (utile per allineare il codice al posto di nop nop), tale sequenza non esiste come istruzione ma e' semplicemente un lea eax,[eax] che viene smistata senza intercettazione del registro eax (segue la logica di decodifica di xchg eax,eax).

Confermo anche questo, mi è capitato di intercettare tale decodifica mnemonica svariate volte nel mio lavoro quotidiano di reverse engineering

[eraser]

EDIT. Se la memoria non m'inganna, dovrebbe esistere anche una NOP di 3 byte.

Non ti inganna, se è per questo anche a 4 byte :) Segue la logica del lea espressa prima.

Esempio che dici tu: lea eax,[eax+00h]

[Ryuzaki_Eru]

Mi sento un idiota dopo aver letto tutte queste cose :D Quanto avete di Q.I tutti messi assieme? 30.000? :D

[eraser]

Quanto avete di Q.I tutti messi assieme? 30.000? :D

Intendi il risultato effettuato con il test per il calcolo del Q.I? In tal caso per cdimauro e repne scasb è falsato il risultato: lo hanno creato loro quel test :D

[cdimauro]

ROFL. Comunque io non passo il giorno a fare il reverse engineering di kernel, driver, browser, et similia. E... ce ne vuole in questo campo. ;)

@Ryuzaki_Eru: per imparare a programmare in assembly serve studiare sodo. Come per tutte le cose.

Come hai imparato a programmare forgiandoti la mentalità usando Python, non vedo perché non potresti fare lo stesso con l'assembly (anche se personalmente non lo consiglio, se non è necessario per qualcosa di concreto).

Il "di più" dipende, poi, dalle capacità personali.

[Ryuzaki_Eru]

ROFL. Comunque io non passo il giorno a fare il reverse engineering di kernel, driver, browser, et similia. E... ce ne vuole in questo campo. ;)

@Ryuzaki_Eru: per imparare a programmare in assembly serve studiare sodo. Come per tutte le cose.

Come hai imparato a programmare forgiandoti la mentalità usando Python, non vedo perché non potresti fare lo stesso con l'assembly (anche se personalmente non lo consiglio, se non è necessario per qualcosa di concreto).

Il "di più" dipende, poi, dalle capacità personali.

Io sono dell'idea che uno per imparare bene una cosa ha necessità di usarla e per usarla vuol dire che la deve usare per lavoro o in un proprio progetto. Quindi siamo sempre là, le conoscenze si acquisiscono per "necessità".

Certo è che sapere tutte queste cose, senza considerare chi fa reverse engineering giornalmente, è sicuramente indice di enormi capacità personali.