Newsgroup: it.comp.lang.c++
Titolo: assembler

ciao!
imparare l'assembler e' utile ?
grazie

 grazie
prego
-- 
Abruzzo SIlvio
studente, 16 anni
goku_...@libero.it
silvi...@aruba.it
Linux Machine 219721
^_____^

 ha scritto nel messaggio
news:m0bg7.14705$i9.6...@news.infostrada.it...


 prezioso.
Sulla prima parte sono concorde, ma sulla seconda... e' tempo perso solo se
non lo si sfruttera' mai, il che e' da vedere ;-)
Per fare software gestionale probabilmente no?!? Ma non esiste solo il
gestionale, no ?!?
Alex

 imparare l'assembler e' utile ?
Come ti hanno gia' risposto dipende da quello che devi fare e cosa devi
programmare. Programmare in assembly qualche anno fa (all'epoca dei 386)
era molto utile se l'obiettivo era quello di ottenere codice efficiente.
Mentre ai tempi del 386 per scrivere un codice efficiente ti bastava
conoscere soltanto l'instruction set del processore, oggi se vuoi
programmare in assembly su un processore moderno (internamente RISC
superscalari) oltre all'instruction set devi conoscere anche molti
dettagli architetturali in modo che il codice assembly che scrivi sia
ottimizzato. Sicuramente un buon compilatore C produce mediamente un
codice assembly molto piu' ottimizzato di quello che riuscirebbe a fare
un buon programmatore. 
Maurizio

 Alex
Ciao, Ramses

 sia veramente complesso.
Per gestionale intendo software per la gestione delle aziende: magazzino,
contabilita', personale, stipendi etc...
Riguardo all'uso dell'assebly per interi programmi, beh, per grossi
programmi non se ne parla nemmeno !!!
Come dici tu assebly viene usato per alcune funzioni.
Normalmente piu' che per la velocita' (che e' tutto da vedere) lo si usa per
dialogare direttamente con l'hardware.
Alex

 dialogare direttamente con l'hardware.
Per tornare al C++  è spesso utile guardare il codice asm generato dal
compilatore C++.
Magari anche solo per capire quali ottimizzazioni implementa e come.
Un volta trovai un baco del compilatore Borland C++ 3.0 che veniva generato
a partire
da un sorgente C corretto, ma per renderemene conto dovetti analizzare il
sorgente asm
dato che è dura dover ammettere che è il compilatore a sbagliare (una sorta
di fratello?)
--
----------
Lello Mele
HOMEPAGE:
http://www.lellomele.it
eMAIL:
v...@libero.it
-------------
"Esistono due modi per elaborare il progetto di un software.
 Il primo consiste nel renderlo semplice al punto tale che non
 manifesti lacune evidenti. Il secondo consiste nel renderlo
 complicato al punto tale che non manifesti lacune evidenti.
 Il primo metodo e' di gran lunga piu' difficile." [C.A.R. Hoare]

Se posso esprimere la mia tutto è utile dipende da quello che devi fare
,soprattutto è inutile dire se è meglio studiarlo oppure no . Siamo nel 2000
e la programmazione a oggetti ,in tutti i sensi, è ormai basilare e noi
siamo qui a chiederci se è più utile un programma o un altro ?  :)))
Credo che le uniche domande importante sono: "Con che compilatore faccio
quel programma ? " ,"Quali oggetti usare ?","Dove posso trovare qualcosa gia
fatto?"....
Insomma basta chiedersi cosa è meglio usare in assoluto è assolutamente
stupido :))
ciao
--
-------
sito: 
www.dadev.it
ultime: Ocx per irc testi freeware
-------

 E allora spopolavano i guru.
Le uniche routine in assembler che ho mai scritto erano per cancellare
lo schermo e posizionare il cursore. Ne e' passato di tempo...
Ciao,
Nicola

 un buon programmatore.
ma infatti la teoria è quella... scrivi la funzione in C, fai generare
il codice assembly al compilatore e poi rimaneggi quello! almeno,
questo è il mio consiglio.

rimaneggi quello! almeno, questo è il mio consiglio.
No. A volte la differenza di velocita' si ottiene se
pensi a soluzioni radicalmente lontane da quanto e'
possibile ottenere in C/C++.
Andrea
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

 possibile ottenere in C/C++.
Su questo sono pienamente d'accordo con Andrea. Non solo le vere ottimizzazioni
non si ottengono con i ritocchi ma con i cambi di soluzione/algoritmo (e ci sono
soluzioni che non si possono scrivere in C). Ma e' anche vero che un algoritmo
scritto in C/C++ e compilato da un compilatore moderno con le ottimizzazioni
spinte, difficilmente potra' essere velocizzato ritoccandolo in assembler. Molto
difficilmente. E' piu' probabile che tu finisca con il rallentarlo.
--
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556

 ha scritto nel messaggio
news:3b86bb6f...@news.interbusiness.it...

può darsi, ma se mi viene in mente una soluzione completamente
diversa, generalmente riesco a esprimerla grossomodo anche in
linguaggio C/C++, almeno per l'esperienze che ho avuto è così (ma le
mie esperienze sono tutt'altro che onnicomprensive): Una volta
individuato l'algoritmo che ha la complessità migliore, si cerca di
aggiustare quello in modo da limare via qualche ciclo di clock. Il
problema principale è trovare quell'algoritmo e comunque, ripeto, *per
quella che è la mia esperienza* non sono mai riuscito a trovare un
algoritmo che non fosse esprimibile in C. Da qui il mio consiglio che,
come tutti i consigli, può anche essere una fesseria, ma senz'altro a
scopo didattico vale la pena di essere provato.

 wrote in message
news:XXMh7.5428$%a4.2...@news.infostrada.it...

Vedo di chiarire alcuni concetti.
E' vero che un algoritmo, in se e per se, e' esprimibile anche in C/C++.
Ed e' anche vero che ci sono oggi dei compilatori fantastici (vedi i compilatori
prodotti dalla Intel stessa, per esempio) e che e' quasi certo che non convenga
lavorare in assembler perche' il rischio di farsi male e' veramente alto.
Pero' e' anche vero in C/C++ ci sono MODI DI ESEGUIRE L'ALGORITMO che possono
non essere espressi. In molti (moltissimi) casi ci sono dei compilatori che sono
talmente intelligenti da saper ottimizzare al meglio eseguendo una scelta fra i
vari MODI di eseguire il lavoro. Ma in alcuni, pochi, casi questo non e' vero.
Alcune cose che non si possono esprimere in C/C++ sono:
-) Jump all'interno di una funzione
-) Funzioni con punti di ingresso multipli
-) Common function tail
-) Utilizzo esplicito ed efficiente dello stack di sistema per un semplice
algoritmo LIFO e per tail recursion
-) Accesso allo stack frame (variabili e parametri) del chiamante senza doverle
passare singolarmente al chiamato (questo lo si puo' fare, per esempio, in
Pascal).
-) Uso di registri superscalari
Alcune cose che *di solito* i compilatori NON FANNO ma che si possono fare in
assembler:
-) Uso di registri superscalari
-) Uso di istruzioni superscalari e/o speciali
-) Fine Tuning delle istruzioni di prefetching delle cache
Alcune cose che di solito i compilatori fanno meglio del programmatore
assembler:
-) Instruction Reordering
-) Tenere conto dello "speculative execution"
-) Tenere conto dei timing di Pipeline
Inoltre c'e' da dire che l'ottimizzazione a questi livelli ha senso solo per
codice che viene eseguito in cicli stretti (inner loops) e che fa accesso a
medio/grosse quantitaà di dati.
Per esempio:
-) Digital Signal Processing
-) Riconoscimento Voce e OCR
-) FFT, Calcoli Matriciali "tosti" e simili
-) Texture Mapping con Shading
-) Alcuni casi di calcolo di Spline (cose come il calcolo di una derivata
seconda di una matriciale di terzo o quarto grado non razionale!)
La decisione di "lavorare in assembler" ha senso solo se *strizza* il massimo
dall'architattura. Il che significa che una cosa facile facile che si scrive in
C in 3 minuti netti, debug compreso, puo' eseguire in assembler molto piu'
velocemente ma per scriverla bene bisogna:
1) lavorarci per alcune settimane
2) scrivere versioni diverse a seconda non solo del processore ma anche del
chipset della mainboard, del tipo di cache e del tipo di memoria
3) mantenere versioni diverse per tutte le combinazioni
4) continuare ad aggiornare la cosa per ogni nuova piattaforma che esce
E il tutto per un guadagno che magari e' di pochi punti percentuali.
La cosa ha senso in POCHISSIMI CASI.
E per la maggior parte di questi esistono:
-) HW che lo fanno meglio (esempio OpenGL, chip DSP etc.)
-) Device Drivers che emulano gli HW e che sono già scritti (esempio OpenGL e
DirectX)
-) Librerie pronte di codice assembler ottimizzato e già scritto (per esempio
emulazione DSP, FFT, JPEG, matematica Matriciale e Polinomiale, riconosimento SW
voce, Image Processing etc.).
Quindi dubito, ma dubito veramente, che oggi abia senso scrivere codice in
assembler per un PC.
Ovviamente la musica cambia (in parte) se si sta scrivendo il FW di un dato HW
custom o cose simili.


 [segue discussione interessante e illuminante]
ok, grazie del tempo che mi hai dedicato, mi piacerebbe che chiarissi
quel paio di dubbi che ho espresso sopra. Mi è sempre piaciuta questa
disciplina dell'informatica riguardante l'ottimizzazione spinta, anche
se non ho mai avuto occasione di lavorarci professionalmente sopra (e
probabilmente non capiterà mai).

 e i goto sono spariti?
Il goto si puo' usare solo all'interno di una stessa funzione.
Ciao,
Nicola

 probabilmente non capiterà mai).
Io ero affascinato dalla cosa quando ancora aveva un senso. Ovvero fino al 486
(che gia' era da mal di testa).
Ma se dai un'occhiata all'ottimizzazione in ambiente IA32 (Pentiun III e Pentium
IV) gia' cominci a capire che fai prima a scrivere un ottimizzatore che a
ottimizzare a mano!! Per non parlare di Itanium che a prima vista sembra quasi
semplificare le cose (dopotutto basta gestire il reordering per evitare uno
stall, giusto) e poi ti rendi conto che la cosa e' facilissima a dirsi, da
suicidio a farsi (a mano).
