Newsgroup: it.comp.lang.visual-basic
Titolo: [OT] Assembler.................................

Qualcuno ci ha bazzicato e sa consigliarmi un libro decente per imparare a
programmare in questo linguaggio?

 writes:
RZ> Non so se vada bene per imparare, ma "Assembler 80386 e 80486" di Murray
RZ> & Pappas era uno dei migliori in giro, non so se esiste qualcosa di piu'
RZ> aggiornato e migliore.
Oddio, se  si ferma  al 486  allora non tratta  tutte le  storie sullo
scheduling  delle   istruzioni...  Beh,  i  compilatori   C  ora  sono
sufficentemente  bravi  da  lasciar  perdere l'assembler  (salvo  rari
casi).
--
Gian Uberto| main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}
Lauri      |                        David Korn, 1987 ioccc best one liner 
(aka saint)|-------------------------------------------------------------------
em@ail: 
sa...@eng.it
 ( vedere X-nospam nello header - see X-nospam in header )

 programmare in questo linguaggio?
Qui trovi un po' di tutorial, da livello basso a livello medio:
http://ringzer0.goldrake.com/tut.htm
Qui c'è un bel tutorial su come programmare in assembler sotto Win32
(livello medio alto)
http://www.eskimo.com/~htak/win32asm/win32asm.htm
Qui c'è l'assembly programming Journal, purtroppo ormai chiuso, ma con
articoli bellissimi (livello alto).
http://asmjournal.freeservers.com/
Sul sito Intel trovi tutti i manuali che vuoi sugli Opcode di ciascun
processore
http://isearch.intel.com/scripts-search/search.asp?isoCode=en&q1=assembler&S
earchCrit=ALL&category=ALL&mh=25&MimeType=ALL
Ciao
*Roby*
P.S.
Beato te che puoi ancora lavorare in assembler. Curiosità, cosa ci fai?

 Beato te che puoi ancora lavorare in assembler. Curiosità, cosa ci fai?
mi posso inserire nel discorso? sì, tanto già mi sono inserito.
per quale tipo di programma, o per quale esigenza, oggi, si può sentire la
necessità di programmare in assembly per Win32 ?
io ricordo che circa un annetto fa usai un pochino di assembly (quelle 3-4
istruzioni che conoscev, e che ora ho dimenticato...) per fare una DLL che
aveva una funzione (una sola, perche non ho mai capito come si includono piu
funzioni in una DLL asm...) che si poteva fare pari pari in VB, con 1 rigo
di codice, ma che er apiu lenta di quella in asm, che richiedeva qualcosa
come 15 righe di codice... figuratevi...
quello che voglio dire è questo: quali sono i vantaggi derivanti dall'uso
dell'asm, oltre quelli qui di seguito elencati?
1) velocità di esecuzione (ad es., di una DLL)
2) dimensioni ridotte di un exe scritto in asm.
3) ....... stop...!!!!!!
correggetemi se sbaglio.
con l'asm per win32 NON si possono richiamare gli interrupt, vero? nè quelli
del dos ne quelli di win95...
ancora, se uno vuole costruire un form, con dei controlli, con l'asm deve
fare un lavoro che non finisce piu, usando sendmessage per ogni cacchio di
quadratino di form da riempire...
su winNT mi hanno detto che diversi programmini scrtti in asm (sfido
chiunque a fare programmoni e non programmini...) danno diversi problemi,
per i meno esperti...
è così o no ??
MarioH

 per i meno esperti...
Anche i programmi VB che usano le API possono dare problemi sotto NT,
soprattutto se usi API che sotto NT non sono supportate. ;-)
Ciao
*Roby*

L'ho trovato quì:
http://www.internetbookshop.it/ser/serdsp.asp?shop=1&c=KMCSODTP7LHMM
Ne vale la pena Roal? Si riesce a scrivere un HELLO WORLD alla fine? ;)


 programmare in questo linguaggio?
ho visto diversi piccoli tutorial su 
http://www.manuali.net
Ciao
Faber

 Sbagliato.
beh aspetta, so che in teoria si puo fare, ma diventa lento e complicato.
io intendevo dire che se ad es. scrivo una DLL in ASM, e ci metto dentro
"direttamente" un'istruzione int, anche le piu innocente di tutte (tipo
quella per stampare lo schermo, che non ha mai ammazzato nessuno), e poi la
richiamo da VB, mi crasha (l'ho provato). come ci tolgo l'int funziona
benissimo.
cmq io la DLL che avevo scritto e funzionava, poi non ce l'go messa nel
programma finale, in VB, ho preferito scriverla in VB e fargli perdere
tempo, perche avevo davvero troppa paura che l'asm facesse problemi su altri
computer, e non ho voluto rischiare...
in futuro se dovessi usare qualche routine asm lo farei solo per operazioni
matematiche NON complesse, ma ricorsive, ripetitive, e per funzioni di
confronto di testo, e operazioni su stringhe, che magari in VB sono lente.
MarioH

 l'interfaccia utente.
Parlo solo per sentito dire, ma a parte il Gibson ricordato anche più
su nel 3ad, ho visto ultimamente questi link:
http://home.intekom.com/entro-p/VisualASM/
http://www.pbq.com.au/home/hutch/masm.htm
magari a qualcuno interessano :-)
Bye, G.

 writes:
RZ> Qualche esempio:
RZ> - calcoli matematico/fisici/statistici super ottimizzati (anche piu' del
RZ> Fortran)
Ne sei  proprio sicuro  ?  Ovvero  sei più bravo  di un  compilatore a
mettere  le istruzioni  nell'ordine giusto  per uno  scheduling ottimo
delle istruzioni per una CPU intel?  Io ci avevo provato una volta con
un  loop con matematica  FP ma  il compilatore  aveva fatto  meglio di
me... (oddio, non mi ritengo un programmatore assembre i386...)


> 
RZ> Io no, naturalmente, ma altri si.
Pochi altri per  le CPU recenti. Bisongna sapere  alla perfezione come
si comportano  tutti i  vari livelli dal  compilatore interno  in rop,
alle politiche di schedulazione alle varie unità, considerando i tempi
in cicli di ogni istruzione.
Devo  ammettere che  una volta  provai a  migliorare il  risultato del
compilatore con  in mano un manuale  (che a sua detta)  doveva dare le
informazioni di cui  sopra. Considero i vari tempi  di istruzioni FP e
intere, guardo  le tabelle di  accoppiamento per le due  pipeline... E
poi il risultato non era migliore di quello del compilatore...
RZ> E sicuramente chi ha scritto gli ottimizzatori dei compilatori di
RZ> linguaggi a medio/alto livello e' in grado di applicare _come minimo_ le
RZ> stesse regole, ma anche migliorarle in base alle necessita' specifiche.
Alt, io  parlavo di mandare le  istruzioni al processore,  una cosa di
bassisimo  livello e molto CPU specifica. 
Altre cose come l'allocazione in  registri delle variabili (in cpu non
intel, che  sotto intel dire  "register" o no non  cambia praticamente
nulla), srotolamento di loop (vedi duff's device) et similia le riesco
a fare.


 a fare.
Oggi ottimizzare è molto più difficile, ma un sistema che funziona sempre
c'è ancora:
Eliminare le chiamate a funzione e sostituirle con macro che ripetono sempre
lo stesso codice. Per lo meno l'overhead del classico PUSH CALL POP RET lo
eviti.
Comunque si tratta di guadagni minimi, che paghi in termini rischio di
uscita del codice dalla cache del processore, ed in maggiore dimensione
dell'eseguibile.
Ciao
*Roby*

 writes:
RP> Eliminare le chiamate a funzione e sostituirle con macro che ripetono sempre
RP> lo stesso codice. Per lo meno l'overhead del classico PUSH CALL POP RET lo
RP> eviti.
Ovvero chiamate inline del C++ :)


 Ovvero chiamate inline del C++ :)
Si, ma con le inline non hai modo di sapere se il tuo codice resta dentro la
cache del processore o esce, mentre con il codice assembler si.
Ciao
*Roby*

 writes:
RP> Si, ma con le inline non hai modo di sapere se il tuo codice resta dentro la
RP> cache del processore o esce, mentre con il codice assembler si.
Hmmm, non so,  non son certo ma credo ci sia  una certa possibilità di
controllare  l'allineamento  del  codice...  (BTW comunque  anche  non
allineando bene il codice già togliere il salto è una bella cosa).


 controllare  l'allineamento  del  codice...
Non è tanto una questione di allineamento. Immagino che anche il C++ allinei
il codice ai 4 byte (o agli 8 per le istruzioni FP). Una volta il trucco era
usare dei NOP tra il RET e l'ingresso della funzione successiva, poi col
MASM è arrivata la metaistruzione ALIGN ed è diventato tutto facile.
Il problema sta nella cache di primo livello del processore. Poniamo che
siano 8K di cache, se fai l'unroll di un loop e trasformi una chiamata a
funzione che lo contiene in una macro ripetuta 10 volte, fai in fretta ad
uscire dalla cache (btw ora che ci sono la branch prediction e il prefetch
delle istruzioni, l'unroll non serve quasi più a niente).
Un altro problema è la parallelizzazione. ci sono diverse istruzioni che
possono essere eseguite in parallelo, quando non lavorano sullo stesso
registro e non riguardano la stessa ALU. Questo significa che devi lavorare
sparigliando le istruzioni. Per esempio il pentium ha 2 pipeline e conviene
molto di + fare:
ADD EAX,1
ADD EBX,1
ADD EAX,ECX
Piuttosto che :
ADD EAX,1
ADD ECX,EAX
ADD EBX,1
Perchè in questo modo le prime 2 add vanno sullo stesso registro e non si
possono parallelizzare (anche se ci sono dei trucchi legati all'uso
dell'istruzione LEA)
.
Nello specifico nello sviluppo del P4 hanno risparmiato su uno dei livelli
di logica, e quello è il motivo principale per cui l'Athlon è più
performante (oltre ad una incomprensibile ampiezza di banda di bus occupata
dal P4 rispetto a quella dell'Athlon).
Se vuoi farti una cultura sulle magagne del P4, dai un occhio qui (in
inglese, lungo e molto tecnico):
http://www.emulators.com/pentium4.htm
Comunque nel caso di stall di una delle due pipeline, viene invalidata anche
la cache di prelettura delle istruzioni, e si perde parecchio tempo. Ancora
più tempo lo perdi quando fai dei salti fuori dalla logica pensata dalla
Jump Prediction interna del processore.
Ormai l'ottimizzazione di basso livello del codice Assembler è una roba
decisamente astrusa, ma proprio per questo dubito che un compilatore sappia
far meglio di un ottimo assemblerista (anche se magari ci vuole un ingegnere
della Intel). 8-)
Ciao
*Roby*

> controllare  l'allineamento  del  codice...
RP> Non è tanto  una questione di allineamento. Immagino  che anche il
RP> C++  allinei il  codice ai  4  byte (o  agli 8  per le  istruzioni
RP> FP).
Mi  sono spiegato  male.  Non  intendevo l'allineamento  delle singole
istruzioni,  ma  l'allineamento  alla  "pagina"  delle  procedure  per
utilizzare al meglio la mappatura in cache.
Tra l'altro in  tutto il discorso hai pensato  solo alle istruzioni, e
non ai dati  :) :) :) :), ho assistito alla  presentazione di un paper
in  cui indicavano  metodi  davvero "simpatici"  per  la mappatura  in
memoria degli array al fine di evitare usi inefficenti della cache L1.
RP> Ormai l'ottimizzazione di basso livello del codice Assembler è una roba
RP> decisamente astrusa, ma proprio per questo dubito che un compilatore sappia
RP> far meglio di un ottimo assemblerista 
Hmmm, indubbiamente  l'intelligenza umana  è migliore, ma  le macchine
non si distraggono e sopratutto vanno meglio.
RP> (anche se magari ci vuole un ingegnere della Intel). 8-)
Hanno  avuto una  brutta  sorpresa dalla  FFTW  :). E  se devo  dirlo,
l'architettura Intel è orrida. Non vedo  l'ora di mettere le mano o su
un PPC o su una Sparc.
