ASM Quali sono le istruzioni più utili?

[Minimalist]

Quali sono le istruzioni più utili e più utilizzate per programmare in assembly?

Secondo me:
mov
add
int
inc
div
sub
jmp e le altre
cmp
ret

voi cosa dite?

 

[St3ve]

Eccotele qui:

È la media uscita dallo SPECint92. Un dato vecchiotto, ma comunque validissimo visto le cifre ben più che rilevanti.

 

[Minimalist]

Eccotele qui:

È la media uscita dallo SPECint92. Un dato vecchiotto, ma comunque validissimo visto le cifre ben più che rilevanti.

8% sull'istruzione and?? Io l'ho usata di rado, si è no 1-2 volte.
Bisognerebbe facessero un'altro sondaggio aggiornato..

Grazie dell'immagine comunque!

 

[St3ve]

8% sull'istruzione and?? Io l'ho usata di rado, si è no 1-2 volte.
Bisognerebbe facessero un'altro sondaggio aggiornato..

Grazie dell'immagine comunque!

Devi pensare anche alle ottimizzazioni, le operazioni bitwise sono tipicamente (dipende dall'architettura) veloci da eseguire. Se puoi rigirare il codice per eseguire una and invece che un sub è conveniente farlo. Prova a decompilare un programma a caso e guarda le prime 100 istruzioni, qualche and è facile che la trovi.

Fidati che se aggiornassero il grafico ad oggi le cose non cambierebbero più di tanto, questi dati sono ancora attendibili. Comunque il succo del discorso è la stragrande maggioranza del codice è formato da quella decina di istruzioni elementari, poco importa sapere se l'6% (non 8, hai letto male) sono and e l'8% sono add. L'importante è che quelle 10 istruzioni messe assieme passano il 95% delle righe di codice!
Per i progettisti dei processori questo è un dato molto importante perché possono aumentare le performance reali (dei programmi veri, non di benchmark su misura) ottimizzando l'esecuzione di quelle 10 istruzioni, poco importa se le altre istruzioni non sono particolarmente ottimizzate, tanto vengono usate di rado.

Per quanto le cose possano essere cambiate con il passare degli anni, non credo che ci sia stato un cambiamento così rilevante da far entrare o uscire un'istruzione da quel grafico, a maggior ragione se mi parli di un'istruzione che aveva ben il 6% del totale.

 

[_ _]

Interessante come nella tua lista ci sia RET ma non CALL

Comunque il titolo del tuo topic e' "piu' utili", non piu' usate, quindi io direi tutto il set AVX, fa davvero la differenza come performance

In ogni caso dati del '92 sono vecchissimi, ci sono molte piu' istruzioni adesso e le CPU (sopratutto x86-64) dispongono di piu' registri quindi non mi stupirebbe di vedere un aumento nei "mov register-register".

 

[Minimalist]

Interessante come nella tua lista ci sia RET ma non CALL

Comunque il titolo del tuo topic e' "piu' utili", non piu' usate, quindi io direi tutto il set AVX, fa davvero la differenza come performance

In ogni caso dati del '92 sono vecchissimi, ci sono molte piu' istruzioni adesso e le CPU (sopratutto x86-64) dispongono di piu' registri quindi non mi stupirebbe di vedere un aumento nei "mov register-register".

Si mi son dimenticato.

CALL,
PROC - ENDP

 

[_ _]

@iPizza:
PROC-ENDP non fanno parte del set di istruzioni x86, sono solo direttive supportate da alcuni (non saprei quali) assembler, tu quale usi?

@steve:
I dati che hai postato si riferiscono a programmi scritti in assembly o a programmi che un compilatore ha tradotto in assembly?

 

[Minimalist]

@iPizza:
PROC-ENDP non fanno parte del set di istruzioni x86, sono solo direttive supportate da alcuni (non saprei quali) assembler, tu quale usi?

Uso l'x8086.
la sintassi di RPOC e ENDP è:

CALL 1a

1a PROC

; istruzioni
RET
1a ENDP

 

[_ _]

Lo si come si usa un PROC-ENDP, quello che intendevo dire e' che non sono istruzioni definite dalla intel nel set di istruzione x86 e in quanto tali non vengono tradotte in un preciso opcode, ma sono direttive che l'assembler mette a disposizione per facilitarti la vita.

E con "quale assembler usi" intendevo dire quale programma usi per assemblare il tuo source? MASM, NASM, YASM, FASM, TASM o cosa?

 

[St3ve]

In ogni caso dati del '92 sono vecchissimi, ci sono molte piu' istruzioni adesso e le CPU (sopratutto x86-64) dispongono di piu' registri quindi non mi stupirebbe di vedere un aumento nei "mov register-register".

Concorderai che per quanto le cpu possano essere cambiate e per quanto i compilatori siano capaci di ottimizzare molto meglio prima di rendere irrilevante quel dato ne passa. Ho già detto che non è quell' 1-2% a fare la differenza in una statistica che mostra che il 96% delle righe di codice sono formate da 10 istruzioni diverse.

@steve:
I dati che hai postato si riferiscono a programmi scritti in assembly o a programmi che un compilatore ha tradotto in assembly?

I dati sono presi dai benchmark ufficiali usati per misurare la performance delle cpu in un modo abbastanza imparziale, quelli del 92 mi pare che siano tutti scritti in C. Tra gli altri programmi c'è in mezzo anche GCC quindi non si parla di poche righe di codice, inoltre se fossero scritti in ASM non sarebbero più imparziali.
Quei test non sono stati pensati per fare una statistica sulle istruzioni più usate, ma non è una statistica campata in aria: tra gli altri programmi del benchmark c'è in mezzo pure GCC (ti lascio immaginare la quantità di istruzioni asm che saltano fuori decompilandolo).

SPECint tests are carried out on a wide range of hardware, with results typically published for the full range of system-level implementations employing the latest CPUs. For SPECint2006, the CPUs include Intel and AMD x86 & x86-64 processors, Sun SPARC CPUs, IBM POWER CPUs, and IA-64 CPUs.

 

[_ _]

dati più recenti ma, purtroppo, basati su solo 3 programmi.
E che comunque non includono tutte le istruzioni disponibili ora, infatti non ci sono statistiche su istruzioni a 3 operandi

Se vuoi fare statistiche sul C usi dei programmi scritti in C o programmi scritti in un altro linguaggio il cui compilatore traduce in C e poi lascia fare il.lavoro a gcc o qualsiasi altro compilatore C libero? Quindi perchè sarebbe imparziale usare programmi scritti in ASM per fare statistiche sull'ASM?

Per i progettisti dei processori questo è un dato molto importante perché possono aumentare le performance reali (dei programmi veri, non di benchmark su misura).

I dati sono presi dai benchmark ufficiali usati per misurare la performance delle cpu

 

[St3ve]

Se vuoi fare statistiche sul C usi dei programmi scritti in C o programmi scritti in un altro linguaggio il cui compilatore traduce in C e poi lascia fare il.lavoro a gcc o qualsiasi altro compilatore C libero? Quindi perchè sarebbe imparziale usare programmi scritti in ASM per fare statistiche sull'ASM?

Ho già spiegato che quei codici sono utilizzati per dei benchmark prestazionali, che senso ha scrivere un programma super ottimizzato per il processore X, ma che gira alla cavolo sul processore Y? Hanno scelto un linguaggio compilato per il semplice fatto che è l'unico modo sensato di paragonare delle cpu con delle architetture differenti.
Perché i benchmark sulle schede video li fanno sui videogames più pesanti? Perché ai consumatori è quello che interessa, non importa se una video è tecnicamente superiore alle altre, quello che mi frega è che faccia girare i giochi come si deve.
Lo stesso discorso lo si fa con la cpu: non importa se la cpu X se spinta al massimo rende tantissimo, importa la resa effettiva che si ha sui programmi di uso comune. Il cell della ps3 è stato un mezzo flop perché per sfruttarlo a dovere bisognava reimplimentare molte cose che invece funzionavano bene sugli x86, mica per niente con la ps4 si è scelto di fare un passo indietro per andare incontro agli sviluppatori.
Il modo migliore per valutare un pezzo hardware è vedere come si comporta su strada.

Io ho semplificato "più utili" con "più utilizzate" e visto che i dati parlano di 10 istruzioni che formano una grossissima fetta del programma non mi è sembrato così sbagliato farlo.

dati più recenti ma, purtroppo, basati su solo 3 programmi.

Questi sono più recenti, ma mica di tanto: nel 2003 c'era 7zip 3.13 stable, nel test si parla di 7zip 2.30 beta. Comunque imho 3 programmi sono sufficienti se ottimizzati a dovere e se hanno la loro buona dose di righe di codice, anche perché la percentuale d'uso di quella decina (circa) di istruzioni è nettamente superiore alle altre, non vedo la necessità di avere dati più accurati.