View Full Version : [Assembler]ha devvero senso impararlo?
ragazzi sto avvicinandomi per motivi di studio a questo linguaggio. Lo trovo complesso e molto affascinante. So che non è un linguaggio superato e che trova utilità in ristretti ambiti elettronici/informatici.
Ma la domanda che mi sono posto è: ha davvero senso imparare un tale linguaggio?
insomma: quali sono gli impieghi reali dell'assembly e mi potrà mai servire (anche in qualità di ingegnere informatico)???
insomma: quali sono gli impieghi reali dell'assembly e mi potrà mai servire (anche in qualità di ingegnere informatico)???
Credo (ma parlo per sentito dire) che l'assembly sia ancora ampiamente utilizzato per la programmazione dei microcontrollori: alcuni fanno cosette interessanti.
Credo (ma parlo per sentito dire) che l'assembly sia ancora ampiamente utilizzato per la programmazione dei microcontrollori: alcuni fanno cosette interessanti.
sisi questo è indubbio...anche comunque la programmazione di compilatori, bios, firmware o programmi molto spinti per ambiti specifici!!
però sarebbe interessante scoprire qual'è il riscontro lavorativo per un prgrammatore di così ''basso livello''(intendo architetturalmente:) )...
utile x fare reversing
bhè questa è una buona ragione...ma in che modo? c'è della documentazione apposita o qualche sito 'illuminante'??
si siti ci sono basta cercare ;) , io ormai sono fuori dal giro come si dice HO SMESSO
cdimauro
20-08-2007, 09:16
ragazzi sto avvicinandomi per motivi di studio a questo linguaggio. Lo trovo complesso e molto affascinante. So che non è un linguaggio superato e che trova utilità in ristretti ambiti elettronici/informatici.
Ma la domanda che mi sono posto è: ha davvero senso imparare un tale linguaggio?
insomma: quali sono gli impieghi reali dell'assembly e mi potrà mai servire (anche in qualità di ingegnere informatico)???
Diciamo che non ha senso impararlo a meno che non sei costretto a lavorarci.
Leggi: fa di tutto per evitare di averci a che fare.
Meglio spendere diversamente (e più proficuamente) il proprio tempo imparando linguaggi decisamente più produttivi (e molto meno rognosi).
Fenomeno85
20-08-2007, 11:16
Diciamo che non ha senso impararlo a meno che non sei costretto a lavorarci.
Leggi: fa di tutto per evitare di averci a che fare.
Meglio spendere diversamente (e più proficuamente) il proprio tempo imparando linguaggi decisamente più produttivi (e molto meno rognosi).
dipende che devi fare dai .. non puoi mettere su un controllore java :D .. al massimo ci sono delle versioni simil-C :D
~§~ Sempre E Solo Lei ~§~
Ormai non ha + molto senso, difficilmente dovrai lavorarci.
Oltre ai casi già riportati, potrebbe tornarti comodo nel caso in cui volessi inserire codice asm in qualche funzione per renderla più efficiente ma saranno ben poche le persone in grado di apprezzare lo sforzo, tipicamente sarà sconsigliato.
Se vuoi sapere fino in fondo come lavora una CPU e un computer dovresti impararlo o se non altro capire come funziona ;)
cdimauro
20-08-2007, 14:36
dipende che devi fare dai .. non puoi mettere su un controllore java :D .. al massimo ci sono delle versioni simil-C :D
Infatti l'avevo scritto e anche sottolineato: soltanto se è veramente indispensabile ha senso farlo.
Oggi, come suggerivi pure tu, anche per i microcontrollori esistono delle validissime alternative. ;)
ragazzi sto avvicinandomi per motivi di studio a questo linguaggio. Lo trovo complesso e molto affascinante. So che non è un linguaggio superato e che trova utilità in ristretti ambiti elettronici/informatici.
Ma la domanda che mi sono posto è: ha davvero senso imparare un tale linguaggio?
insomma: quali sono gli impieghi reali dell'assembly e mi potrà mai servire (anche in qualità di ingegnere informatico)??? in ambito PC l'assembly è usato solo nelle primissimissime fasi della programmazione di un sistema operativo per scrivere il codice che imposta i settaggi del processore all'avvio del sistema (entrata in modalità protetta, setup del memory model, ecc.). sempre nella programmazione di un sistema operativo, l'assembly si usa molto raramente più avanti per creare routines ottimizzate, vedi ad esempio le InterlockedXxx di Win32. inutile dire che l'assembly di una macchina per forza di cose viene anche utilizzato dai programmatori che creano compilatori per quella macchina. con questi due esempi credo di averti elencato praticamente tutti gli usi dell'assembly nel mondo odierno, e considera che in un sistema operativo sarà in assembly qualcosa come l'1% del codice, o anche meno, mentre in un compilatore facciamo tra il 30% e il 50%, a seconda di quanto è complesso il linguaggio da parsare. tutte stime empiriche eh!! :p
EDIT - serve una GROSSA rettifica: ho erroneamente dato ad intendere che buona parte di un compilatore sia scritta in assembly... ovviamente mi sono sbagliato :D
volevo piuttosto dire che buona parte del codice di un compilatore deve avere a che fare con l'assembly, che è tutt'altra cosa. nemmeno una riga di codice di un compilatore necessita di essere scritta in assembly visto che tutto ciò che un compilatore deve fare è... scrivere un file :p
ragazzi sto avvicinandomi per motivi di studio a questo linguaggio. Lo trovo complesso e molto affascinante. So che non è un linguaggio superato e che trova utilità in ristretti ambiti elettronici/informatici.
Ma la domanda che mi sono posto è: ha davvero senso imparare un tale linguaggio?
Non è un linguaggio superato. Guarda masm32 per esempio che è aggiornato frequentemente.
insomma: quali sono gli impieghi reali dell'assembly e mi potrà mai servire (anche in qualità di ingegnere informatico)???
Con l'assembly fai tutto ciò che fanno gli altri linguaggi e un 10% in + che non possono fare gli altri linguaggi di + alto livello.
Se sei un programmatore curioso, (...Lo trovo complesso e molto affascinante...), dovresti perlomeno avere la voglia di capire cosa succede.
L'assembly è molto più concreto degli altri linguaggi. Gurdandone un sorgente si capisce benissimo cosa succede.
Mentre + i linguaggi sono "alti" + sono astratti, per questo, a prima vista, meno comprensibili dell'assembly.
Il mio punto di vista.
Non è un linguaggio superato. Guarda masm32 per esempio che è aggiornato frequentemente. e molto usato specialmente devo dire...
L'assembly è molto più concreto degli altri linguaggi. Gurdandone un sorgente si capisce benissimo cosa succede.
Mentre + i linguaggi sono "alti" + sono astratti, per questo, a prima vista, meno comprensibili dell'assembly.
Il mio punto di vista. bon Dieu, che punto di vista soggettivo, mi sa tanto che hai scoperchiato il vaso di Pandora. speriamo solo che PGI-Bis e cdimauro non leggano... :asd:
cdimauro
20-08-2007, 16:22
in ambito PC l'assembly è usato solo nelle primissimissime fasi della programmazione di un sistema operativo per scrivere il codice che imposta i settaggi del processore all'avvio del sistema (entrata in modalità protetta, setup del memory model, ecc.). sempre nella programmazione di un sistema operativo, l'assembly si usa molto raramente più avanti per creare routines ottimizzate, vedi ad esempio le InterlockedXxx di Win32. inutile dire che l'assembly di una macchina per forza di cose viene anche utilizzato dai programmatori che creano compilatori per quella macchina. con questi due esempi credo di averti elencato praticamente tutti gli usi dell'assembly nel mondo odierno, e considera che in un sistema operativo sarà in assembly qualcosa come l'1% del codice, o anche meno,
Facciamo molto meno. :D
L'1% di milioni di righe di codice (80 per XP, se non ricordo male) è un valore enorme. ;)
mentre in un compilatore facciamo tra il 30% e il 50%, a seconda di quanto è complesso il linguaggio da parsare. tutte stime empiriche eh!! :p
EDIT - serve una GROSSA rettifica: ho erroneamente dato ad intendere che buona parte di un compilatore sia scritta in assembly... ovviamente mi sono sbagliato :D
volevo piuttosto dire che buona parte del codice di un compilatore deve avere a che fare con l'assembly, che è tutt'altra cosa. nemmeno una riga di codice di un compilatore necessita di essere scritta in assembly visto che tutto ciò che un compilatore deve fare è... scrivere un file :p
Il 30-50% è comunque un valore enorme. Un compilatore fa PARECCHIO lavoro per quanto riguarda il parsing e per crearsi gli abstract tree da cui generare poi il codice.
Prima di generare il codice, esiste anche una (eventuale, perché non è necessaria) fase di ottimizzazione delle informazioni presenti nell'abstract tree.
La generazione del codice vero è proprio è una parte molto piccola di un compilatore. ;)
cdimauro
20-08-2007, 16:36
Non è un linguaggio superato. Guarda masm32 per esempio che è aggiornato frequentemente.
Il che non vuol dire che non sia superato per la stragrandissima maggioranza delle applicazioni.
Frequenza di aggiornamento e obsolescenza sono due fattori non intrisencamente legati.
Con l'assembly fai tutto ciò che fanno gli altri linguaggi e un 10% in + che non possono fare gli altri linguaggi di + alto livello.
Il 10% assumo che sia una stima personale. Per il resto, è vero che fai tutto, ma bisogna vedere in quanto tempo.
Se sei un programmatore curioso, (...Lo trovo complesso e molto affascinante...), dovresti perlomeno avere la voglia di capire cosa succede.
Essendoci passato, mi passa la voglia soltanto a pensarci. Meglio affinare le proprie capacità con qualcosa di più alto livello.
Un programmatore deve pensare innanzitutto a risolvere problemi, e per far questo non è assolutamente necessario conoscere l'architettura su cui girano le applicazioni che li risolvono.
L'assembly è molto più concreto degli altri linguaggi. Gurdandone un sorgente si capisce benissimo cosa succede.
A parte il fatto che il sorgente può (e spesso ho trovato che lo fosse) scritto coi piedi, guardando un listato assembly si capisce facilmente quello che fa la macchina (posto che se ne sia studiata bene l'architettura), ma non l'algoritmo che implementa, che è decisamente la cosa più importante (vedi sopra sul discorso di risolvere problemi).
Con linguaggi più ad alto livello, al contrario, è più facile comprendere l'algoritmo che implementano.
Non a caso viene spesso studiato lo pseudocodice, i diagrammi di flusso, quelli Backus Naur, ecc.
Mentre + i linguaggi sono "alti" + sono astratti, per questo, a prima vista, meno comprensibili dell'assembly.
Dipende quello che vuoi vedere. Io voglio vedere l'algoritmo. Di come funziona la macchina non me ne frega assolutamente niente.
Il mio punto di vista.
Idem.
Comunque in parte l'argomento è stato trattato qui http://www.hwupgrade.it/forum/showthread.php?t=1530518 e qui http://www.hwupgrade.it/forum/showthread.php?t=1530900
cdimauro
20-08-2007, 16:40
e molto usato specialmente devo dire...
Se sei costretto a lavorarci, sicuramente.
Ma oggi è puro masochisismo autolesionista continuare a sviluppare in assembly per applicazioni che si possono realizzare con linguaggi di livello molto più elevato. :D
bon Dieu, che punto di vista soggettivo, mi sa tanto che hai scoperchiato il vaso di Pandora. speriamo solo che PGI-Bis e cdimauro non leggano... :asd:
Troppo tardi (e poi avevo già partecipato al thread). :Prrr:
Facciamo molto meno. :D
L'1% di milioni di righe di codice (80 per XP, se non ricordo male) è un valore enorme. ;) hai ragione, infatti già l'1% è una sparata :D
facciamo lo 0.1% del solo kernel.
Il 30-50% è comunque un valore enorme. Un compilatore fa PARECCHIO lavoro per quanto riguarda il parsing e per crearsi gli abstract tree da cui generare poi il codice.
Prima di generare il codice, esiste anche una (eventuale, perché non è necessaria) fase di ottimizzazione delle informazioni presenti nell'abstract tree.
La generazione del codice vero è proprio è una parte molto piccola di un compilatore. ;) devi contare però che l'ottimizzazione avviene in gran parte sulla base di cosa possono fare le istruzioni della macchina. per esempio il compilatore leggendo del codice che debba azzerare un blocco di memoria, anziché generare un loop con dei MOV può generare una sola istruzione REP STOS. ero tentato di fare un esempio con l'istruzione REPNE SCASB se non fosse che dovrei leggere il manuale e Acrobat Reader ci mette un secolo ad aprirsi :asd:
cdimauro
20-08-2007, 17:05
hai ragione, infatti già l'1% è una sparata :D
facciamo lo 0.1% del solo kernel.
Può darsi, ma naso, a parte l'operazione di task switch, c'è ben poco da fare con l'assembly.
Da decenni linguaggi come C e Pascal permettono di scrivere handler per gli interrupt e leggere/scrivere le porte di I/O "nativamente".
devi contare però che l'ottimizzazione avviene in gran parte sulla base di cosa possono fare le istruzioni della macchina. per esempio il compilatore leggendo del codice che debba azzerare un blocco di memoria, anziché generare un loop con dei MOV può generare una sola istruzione REP STOS. ero tentato di fare un esempio con l'istruzione REPNE SCASB se non fosse che dovrei leggere il manuale e Acrobat Reader ci mette un secolo ad aprirsi :asd:
Si tratta comunque di piccoli esempi, e inoltre considera che oggi (ma anche 10 anni fa :D) un compilatore per x86 che genera istruzioni REP per processori dal Pentium in avanti è da prendere a picconate sulle gengive, visto che sono meno efficienti dell'equivalente codice "unrolled". :D
In genere le istruzioni più usate (e veloci) sono pure quelle più semplici, e c'è poco da andare a caccia di pattern negli abstract tree per cercare di utilizzare una qualche rara funzionalità che mette a disposizione una particolare architettura. ;)
insomma: quali sono gli impieghi reali dell'assembly e mi potrà mai servire (anche in qualità di ingegnere informatico)???
se vuoi diventare ingegnere informatico non ci sono santi :O devi come minimo sapere le basi
mi hanno insegnato la convezione forzata in un condotto... per cui penso che l'ASM sia di gran lunga più utile :D
variabilepippo
21-08-2007, 14:35
insomma: quali sono gli impieghi reali dell'assembly
Nel mercato mainstream l'Assembly è morto da tempo immemore, ma nel mondo "embedded", dove il C è spesso un lusso che non ci si può permettere e l'Embedded C++ (http://www.caravan.net/ec2plus/) un progetto velleitario, non puoi farne assolutamente a meno.
Considerando che "negli ultimi cinque anni, sono in media sei miliardi i device delle nostre improvvisate classi A e B consegnati ogni anno per il mercato embedded, e l'IEEE stima che attualmente siano in funzione oltre 50 miliardi di dispositivi embedded, con complessità variabile senza soluzione di continuità tra il portachiavi cinese con giochi di luci a led ed i sistemi di comando e controllo a bordo della Stazione Spaziale Internazionale, passando per centrali nucleari, raffinerie, controlli di processo, controllori del traffico aereo etc. Queste cifre rendono insignificante il numero di CPU desktop e server destinate al mainstream." la conoscenza dell'Assembly non è un propriamente un optional (http://forum.ioprogrammo.it/thread.php?threadid=9553&boardid=46).
Nel mercato mainstream l'Assembly è morto da tempo immemore, ma nel mondo "embedded", dove il C è spesso un lusso che non ci si può permettere e l'Embedded C++ (http://www.caravan.net/ec2plus/) un progetto velleitario, non puoi farne assolutamente a meno.
Considerando che "negli ultimi cinque anni, sono in media sei miliardi i device delle nostre improvvisate classi A e B consegnati ogni anno per il mercato embedded, e l'IEEE stima che attualmente siano in funzione oltre 50 miliardi di dispositivi embedded, con complessità variabile senza soluzione di continuità tra il portachiavi cinese con giochi di luci a led ed i sistemi di comando e controllo a bordo della Stazione Spaziale Internazionale, passando per centrali nucleari, raffinerie, controlli di processo, controllori del traffico aereo etc. Queste cifre rendono insignificante il numero di CPU desktop e server destinate al mainstream." la conoscenza dell'Assembly non è un propriamente un optional (http://forum.ioprogrammo.it/thread.php?threadid=9553&boardid=46). a questo punto allora dovremmo anche chiarire di quale assembly si sta parlando: dubito che l'assembly del portachiavi cinese sia complesso come quello di un Itanium... :asd:
e forse lui quando parlava di assembly aveva in mente più che altro quello dei PC, o uno di complessità analoga.
variabilepippo
21-08-2007, 14:52
dubito che l'assembly del portachiavi cinese sia complesso come quello di un Itanium...
A parte il fatto che nella citazione il "portachiavi cinese" veniva proposto *esclusivamente* come esempio di applicazione embedded semplice e low-cost vorrei comprendere quale sia l'esatta definizione di "complesso come quello di un Itanium". Ci riferiamo al confronto tra architetture RISC/CISC? Ci riferiamo semplicemente al numero di opcodes? In altri termini: COME si misura la "complessità" di un dialetto Assembly?!
A parte il fatto che nella citazione il "portachiavi cinese" veniva proposto *esclusivamente* come esempio di applicazione embedded semplice e low-cost vorrei comprendere quale sia l'esatta definizione di "complesso come quello di un Itanium". Ci riferiamo al confronto tra architetture RISC/CISC? Ci riferiamo semplicemente al numero di opcodes? In altri termini: COME si misura la "complessità" di un dialetto Assembly?! a ocio :huh:
variabilepippo
21-08-2007, 14:56
a ocio :huh:
Ma stiamo impostando una discussione tecnica oppure si scrive solo "per sentito dire"?! :confused:
Ma stiamo impostando una discussione tecnica oppure si scrive solo "per sentito dire"?! :confused: OH SCIAGURA!!! dovrebbe essere bannato (con tutta la sottomaschera dell'IP) chi posta per sentito dire, che Dio ti scampi da un uomo si' scellerato :eek:
comunque guarda io non credo che tutti e 50 i miliardi di dispositivi embedded di questo mondo necessitino di segmentazione, paginazione, renaming dei registri, task switch... :fagiano:
variabilepippo
21-08-2007, 15:06
comunque guarda io non credo che tutti e 50 i miliardi di dispositivi embedded di questo mondo necessitino di segmentazione, paginazione, renaming dei registri, task switch..
Tranquillo, nella programmazione in Assembly di dispositivi embedded incontri problematiche MOLTO più stringenti e complesse della gestione della memoria, senza neanche dover prendere in considerazione le complessità di certe toolchain... :fagiano: In ogni caso la domanda iniziale era un'altra, l'utente chiede se un ingegnere informatico debba conoscere la programmazione low-level.
IMHO la risposta è: se intendi sviluppare applicazioni Web e/o desktop puoi ignorare l'esistenza dell'Assembly, se invece ti interessa entrare in un mercato ad alta specializzazione (=poca concorrenza) da 50 miliardi di dispositivi allora forse dovresti farci un pensierino.
cdimauro
21-08-2007, 15:15
Nel mercato mainstream l'Assembly è morto da tempo immemore, ma nel mondo "embedded", dove il C è spesso un lusso che non ci si può permettere e l'Embedded C++ (http://www.caravan.net/ec2plus/) un progetto velleitario, non puoi farne assolutamente a meno.
Considerando che "negli ultimi cinque anni, sono in media sei miliardi i device delle nostre improvvisate classi A e B consegnati ogni anno per il mercato embedded, e l'IEEE stima che attualmente siano in funzione oltre 50 miliardi di dispositivi embedded, con complessità variabile senza soluzione di continuità tra il portachiavi cinese con giochi di luci a led ed i sistemi di comando e controllo a bordo della Stazione Spaziale Internazionale, passando per centrali nucleari, raffinerie, controlli di processo, controllori del traffico aereo etc. Queste cifre rendono insignificante il numero di CPU desktop e server destinate al mainstream." la conoscenza dell'Assembly non è un propriamente un optional (http://forum.ioprogrammo.it/thread.php?threadid=9553&boardid=46).
Da tempo immemore perfino per quegli schifosi PIC di MicroChip esistono compilatori C che funzionano molto bene.
Infatti l'uso dell'assembly è ridotto all'osso anche nei sistemi embedded.
quello di cui stiamo parlando non si attiene specificamente a un'Itanium o a uno Zilog Z80...il fatto è che come dice variabilepippo un senso questo assembler ancora lo ha! dai sistemi operativi ai dispositivi embedded ...basti pensare ai cellulari e ai software che li fanno avviare per capire che ogni 6 mesi qualcuno che scrive codice a quel livello c'è!
poi se imparato l'assembler ai tempi dell' 8088 non credo che si trovino troppe difficoltà con un Core2Duo o con un dispositivo embedded qualunque...può cambiare qualche registro e tutto il set di istruzioni....ma insomma credo che sia più importante il metodo...
La mia curiosità è sopratutto rivolta al mercato del lavoro...indi le basi dell'assembler prendono importanze non solo a livello didattico...ma anche a livello pratico...
certo, se volessi scrivere un programma per me stesso non mi sognerei neppure di farlo in assembler...piuttosto Phyton o Java o C++ o chessò...resta comunque una difficoltà ogettiva nell'imparare l'assembler...che programma mi faccio per imparare???
cdimauro
21-08-2007, 15:17
A parte il fatto che nella citazione il "portachiavi cinese" veniva proposto *esclusivamente* come esempio di applicazione embedded semplice e low-cost vorrei comprendere quale sia l'esatta definizione di "complesso come quello di un Itanium". Ci riferiamo al confronto tra architetture RISC/CISC? Ci riferiamo semplicemente al numero di opcodes? In altri termini: COME si misura la "complessità" di un dialetto Assembly?!
Più che altro si potrebbe particolare di "complessità" dell'architettura di un processore, ma in ogni caso non esiste una metrica oggettiva allo scopo, per cui è inutile porsi la domanda.
cdimauro
21-08-2007, 15:26
quello di cui stiamo parlando non si attiene specificamente a un'Itanium o a uno Zilog Z80...il fatto è che come dice variabilepippo un senso questo assembler ancora lo ha! dai sistemi operativi ai dispositivi embedded ...basti pensare ai cellulari e ai software che li fanno avviare per capire che ogni 6 mesi qualcuno che scrive codice a quel livello c'è!
Secondo te un s.o. per telefonini, come il Symbian di Nokia, è scritto interamente in assembly? Ne dubito FORTEMENTE.
Al più lo saranno alcune sue parti, come quella relativa al boot, ad esempio.
poi se imparato l'assembler ai tempi dell' 8088 non credo che si trovino troppe difficoltà con un Core2Duo o con un dispositivo embedded qualunque...può cambiare qualche registro e tutto il set di istruzioni....ma insomma credo che sia più importante il metodo...
Cambia, e non poco, invece: l'8088 è un processore profondamente diverso da un Core2Duo, pur essendo quest'ultimo compatibile col primo.
Programmando in assembly acquisisci la mentalità "di base" (lo metto tra virgolette che è meglio), ma le architetture possono essere anche molto diverse (anche all'interno della stessa famiglia; vedi sopra) e richiedere notevoli sforzi per "adattarcisi". Perché non basta semplicemente sapere quanti sono i registri, come si chiamano, l'elenco delle istruzioni, per sfruttare decentemente un'architettura.
La mia curiosità è sopratutto rivolta al mercato del lavoro...indi le basi dell'assembler prendono importanze non solo a livello didattico...ma anche a livello pratico...
Ancora oggi si lavora con l'assemblY (non assembler), per cui il lavoro c'è, anche se di nicchia (è un settore molto specializzato).
certo, se volessi scrivere un programma per me stesso non mi sognerei neppure di farlo in assembler...piuttosto Phyton o Java o C++ o chessò...
Esattamente, e visto che è anche il mercato più grosso, se vuoi lavorare è più facile se impari uno dei linguaggi che hai citato, che conoscendo l'assembly di una qualche architettura.
resta comunque una difficoltà ogettiva nell'imparare l'assembler...che programma mi faccio per imparare???
Se proprio vuoi iniziare con l'assembly, ti consiglio l'architettura Motorola 68000 che è molto semplice (56 istruzioni, se non ricordo male), ma potente.
Comunque, per quanto già detto, te lo sconsiglio fortemente.
variabilepippo
21-08-2007, 15:32
Da tempo immemore perfino per quegli schifosi PIC di MicroChip esistono compilatori C che funzionano molto bene.
Compilatori C esistono (IAR, SourceBoost e via dicendo) e funzionano discretamente, ma per PIC16 ed inferiori (ma non solo) ha poco senso, almeno su progetti non banali, impiegare il C. La richiesta di memoria e l'impatto sulle prestazioni sono decisamente superiori rispetto a quella ottenibili con codice Assembly. Dunque se si vuole minimizzare il time-to-market la scelta del C89 è un passo obbligato (sempre che il sistema lo supporti), in molti altri casi si deve fare ricorso all'Assembly. E comunque per programmare dispositivi embedded è necessario conoscerne a fondo l'architettura, quindi un progettista dovrebbe in ogni caso studiare il relativo Assembly. Non fosse altro che a volte il C presenta limiti prestazionali incompatibili con l'ottimizzazione del codice, altrimenti programmeremmo tutti in MikroBasic (http://www.mikroelektronika.co.yu/en/). :D
quello di cui stiamo parlando non si attiene specificamente a un'Itanium o a uno Zilog Z80...il fatto è che come dice variabilepippo un senso questo assembler ancora lo ha! dai sistemi operativi ai dispositivi embedded ...basti pensare ai cellulari e ai software che li fanno avviare per capire che ogni 6 mesi qualcuno che scrive codice a quel livello c'è!
poi se imparato l'assembler ai tempi dell' 8088 non credo che si trovino troppe difficoltà con un Core2Duo o con un dispositivo embedded qualunque...può cambiare qualche registro e tutto il set di istruzioni....ma insomma credo che sia più importante il metodo...
La mia curiosità è sopratutto rivolta al mercato del lavoro...indi le basi dell'assembler prendono importanze non solo a livello didattico...ma anche a livello pratico...
certo, se volessi scrivere un programma per me stesso non mi sognerei neppure di farlo in assembler...piuttosto Phyton o Java o C++ o chessò...resta comunque una difficoltà ogettiva nell'imparare l'assembler...che programma mi faccio per imparare???
Per il fascino che dà l'assembly il rapporto 1 a 1:
Questo link è dove ho imparato io... tutto in italiano 80x86 per tool tasm e nasm 16 e 32bit. Secondo me il migliore in assoluto. Sempre in aggiornamento continuo.
http://xoomer.alice.it/ramsoft/
ciao
Edit:
qui un po di esempi per il tasm:
http://www.twork.it/programmazione/assembler/asmlistati.html
dimmi cosa ne pensi...
Secondo te un s.o. per telefonini, come il Symbian di Nokia, è scritto interamente in assembly? Ne dubito FORTEMENTE.
mai detto che symbian è scritto in assembly...ho solo detto che una 'bios' (per fare il paragone coi pc) ce la devono avere pure i cellulari per accendersi...
Per il fascino che dà l'assembly il rapporto 1 a 1:
Questo link è dove ho imparato io... tutto in italiano 80x86 per tool tasm e nasm 16 e 32bit. Secondo me il migliore in assoluto. Sempre in aggiornamento continuo.
http://xoomer.alice.it/ramsoft/
ciao
Edit:
qui un po di esempi per il tasm:
http://www.twork.it/programmazione/assembler/asmlistati.html
dimmi cosa ne pensi...
Interessanti...quegli esempi su che architettura sono fatti?io per i miei primi passi mi sono scaricato emu8086 da emu8086.com che ti fa vedere graficamente lo stato di tutti i registri per ogni istruzione...didatticamente mi è molto utile...
Il problema è che affinche i miei sforzi non siano applicabili a un qualche progetto è difficile applicarsi e imparare sul serio...non credete?
franksisca
21-08-2007, 15:47
mi intrometto per dire la mia:D:D:D
secondo me, da ingegnere, l'assembly lo devi conoscere, per cultura più che per lavoro.
anche perchè quando farai (parlo da studente universitario ancora ;)) Sistemi operativi e Linguaggi ti sarà utile.
ma ripeto, secondo me, serve più per conoscenza personale che per entrare nel mondo del lavoro.
Io che conosco l'assembly ma non parlo l'inglese ho meno possibilità di chi l'assembly lo chiama assembler e invece parla correttamente inglese.
Poi, naturalmente, dipende dagli scopi personale, se nella vita vorrai fare esclusivamente microcontrollori e microcose (:D:D:D) allora diventa quasi fondamentale ;)
cdimauro
21-08-2007, 15:48
Compilatori C esistono (IAR, SourceBoost e via dicendo) e funzionano discretamente, ma per PIC16 ed inferiori (ma non solo) ha poco senso, almeno su progetti non banali, impiegare il C. La richiesta di memoria e l'impatto sulle prestazioni sono decisamente superiori rispetto a quella ottenibili con codice Assembly. Dunque se si vuole minimizzare il time-to-market la scelta del C89 è un passo obbligato (sempre che il sistema lo supporti), in molti altri casi si deve fare ricorso all'Assembly. E comunque per programmare dispositivi embedded è necessario conoscerne a fondo l'architettura, quindi un progettista dovrebbe in ogni caso studiare il relativo Assembly. Non fosse altro che a volte il C presenta limiti prestazionali incompatibili con l'ottimizzazione del codice, altrimenti programmeremmo tutti in MikroBasic (http://www.mikroelektronika.co.yu/en/). :D
Si tratta comunque di casi particolari, per sistemi embedded dotati di processori "non particolarmente versatili" (tant'è che per sistemi embedded di discreta potenza si vede spesso utilizzare Java per le applicazioni, e da qualche tempo anche Python), e come dici anche tu dipende dal progetto.
Tra l'altro il codice generato da un compilatore C/C++ di questi tempi è abbastanza buono in generale, e ottimo con architetture out-of-order (in questi casi mediamente superiore a quello di un programmatore che lavora in assembly).
Inoltre per programmare sistemi embedded non è necessario conoscere l'assembly, ma eventualmente l'architettura del processore (o per meglio dire del SoC, come capita spesso).
cdimauro
21-08-2007, 15:49
Per il fascino che dà l'assembly il rapporto 1 a 1:
Il rapporto 1:1 ce l'hai (quasi esclusivamente) col linguaggio macchina.
Interessanti...quegli esempi su che architettura sono fatti?io per i miei primi passi mi sono scaricato emu8086 da emu8086.com che ti fa vedere graficamente lo stato di tutti i registri per ogni istruzione...didatticamente mi è molto utile...
Il problema è che affinche i miei sforzi non siano applicabili a un qualche progetto è difficile applicarsi e imparare sul serio...non credete?
Leggiti dal 1° capitolo come è l'architettura 80x86 come ragiona la cpu ecc ecc. spiegato in modo molto ma molto semplice e approfondito. Poi i linguaggi di + alto livello te li mangi...
fai un batch così per compilare (esempio il file okay.asm):
@echo off
d:\archivio\tasm\bin\tasm /zi /l d:\archivio\tasm\batch16\temp\okay
d:\archivio\tasm\bin\tlink /v d:\archivio\tasm\batch16\temp\okay
ogni volta che lanci il batch ti compila il tutto.
con l'opzione v (seconda riga vai in modalità debug) per debuggare in realtime.
Buon studio.
Cmq sul sito che ti ho passato ti spiega tutto e di +.
ciao
cdimauro
21-08-2007, 15:51
mai detto che symbian è scritto in assembly...ho solo detto che una 'bios' (per fare il paragone coi pc) ce la devono avere pure i cellulari per accendersi...
Non è assolutamente necessario un bios / firmware: potrebbe essere lo stesso kernel del s.o. a occuparsi dell'avvio. Nulla vieta di infilare il kernel (ma anche tutto il s.o. e pure le applicazioni principali, eventualmente) nel firmware. ;)
cdimauro
21-08-2007, 15:55
Interessanti...quegli esempi su che architettura sono fatti?
TASM = 8086 (e successori).
io per i miei primi passi mi sono scaricato emu8086 da emu8086.com che ti fa vedere graficamente lo stato di tutti i registri per ogni istruzione...didatticamente mi è molto utile...
Certamente. Peccato per l'architettura: quella 8086 fa veramente schifo. Se devi iniziare è di gran lunga preferibile quella 68000. ;)
Il problema è che affinche i miei sforzi non siano applicabili a un qualche progetto è difficile applicarsi e imparare sul serio...non credete?
Già. In tal caso potresti anche unire l'utile al dilettevole: studiati l'architettura ARM (oggi diffusissima nei sistemi embedded) e sviluppa qualche giochino per Nintendo DS. ;)
Interessanti...quegli esempi su che architettura sono fatti?
Intel
io per i miei primi passi mi sono scaricato emu8086 da emu8086.com che ti fa vedere graficamente lo stato di tutti i registri per ogni istruzione...didatticamente mi è molto utile...
http://www.twork.it/programmazione/assembler/assembler.html#cap1
quì scaricati il tasm 5.0 preparato da me.
e sempre quì scaricati la documentazione degli interrupt del BIOS e del DOS
Infine usa un editor di testo, il NOTEPAD di windows và + che bene.
buon studio
ciao
e sempre quì scaricati la documentazione degli interrupt del BIOS e del DOS molto utili :fagiano:
Già. In tal caso potresti anche unire l'utile al dilettevole: studiati l'architettura ARM (oggi diffusissima nei sistemi embedded) e sviluppa qualche giochino per Nintendo DS. ;) in assembly? ne dubito... :asd:
non so in che linguaggio li programmino, ma dubito che facciano grafica 3D in assembly... :huh:
cdimauro
21-08-2007, 16:21
in assembly? ne dubito... :asd:
non so in che linguaggio li programmino, ma dubito che facciano grafica 3D in assembly... :huh:
La fanno, la fanno: qualche pazzo che vuol spremere per bene l'architettura lo si trova sempre, ma ovviamente tutto ciò ha un costo (nei tempi di sviluppo) non indifferente. :D
P.S. Infatti per NDS c'è un ottimo ambiente di sviluppo in C++. ;)
Sisupoika
22-08-2007, 12:44
Ormai non ha + molto senso.
Le basi hanno sempre senso, soprattutto quando sono molto piu' che "basi". :mbe:
Le basi hanno sempre senso, soprattutto quando sono molto piu' che "basi". :mbe: non vedo perché l'assembly dovrebbe costituire didatticamente la base per imparare a programmare. l'assembly non è stato certo la prima cosa che ho imparato, ne' quella che tutti imparano per prima, salvo forse rarissimi casi.
non vedo perché l'assembly dovrebbe costituire didatticamente la base per imparare a programmare. l'assembly non è stato certo la prima cosa che ho imparato, ne' quella che tutti imparano per prima, salvo forse rarissimi casi.
non sono le basi per imparare a programmare, ma sono le basi per un ingegnere informatico IMHO
Sisupoika
22-08-2007, 13:13
non vedo perché l'assembly dovrebbe costituire didatticamente la base per imparare a programmare. l'assembly non è stato certo la prima cosa che ho imparato, ne' quella che tutti imparano per prima, salvo forse rarissimi casi.
Per "basi" non intendevo il punto di partenza, ma "fondamenta". Per me una conoscenza ottimale di tutta la storia non puo' prescinderne :)
non sono le basi per imparare a programmare, ma sono le basi per un ingegnere informatico IMHO
Concordo...imho è da imparare...o se non imparare almeno da capirne i meccanismi.
Io ora come ora difficilmente saprei scrivere un programmino in assembly, ma sicuramente se mi mettessero davanti qualsiasi processore o microcontrollore in pochissimo tempo sarei in grado di diventare produttivo. Uno che non ha mai visto un assembly credo proprio di no.
Ma se uno volesse studiarsi l'architettura dei calcolatori non sarebbe meglio prendere in esame l'acquisto di un libro sull'architettura dei calcolatori, ad esempio il classico Patterson Hennessy, anzichè trastullarsi con lingue cotte, stracotte, muffe stantìe come gli assembly?
chiaro è cheil patterson hennessy è la bibbia dei calcolatori elettronici...io da parte mia ho letto ''Architettura e organizzazione dei calcolatori elettronici'' di G.Bucci...
però l'assembly è tutt'altra cosa insomma...poi tra l'altro la questione va oltre alla domanda del post iniziale ...vedo che è sentita da molta gente, molti dicono che non serve, altri (come me) sono convinti che una nicchia dei programmatori mondiali lo usa ancora...ora il fatto sta che l'assembly anche se a poche persone servirà sempre...mentre linguaggi come il ruby o chessò sono facilmente sostituibile e potranno diventare davvero obsoleti tra qualche anno....
questo è il mio pensiero almeno...
Ma se uno volesse studiarsi l'architettura dei calcolatori non sarebbe meglio prendere in esame l'acquisto di un libro sull'architettura dei calcolatori, ad esempio il classico Patterson Hennessy, anzichè trastullarsi con lingue cotte, stracotte, muffe stantìe come gli assembly?
Certo non basta l'assembly, ma serve anche quello.
non dimentichiamo il fatto che l'architettura di un elaboratore è caratterizzata anche dal suo set di istruzioni...
Ps:è appena uscita la notizia che a novembre escono i peryn con SSE4...
cdimauro
22-08-2007, 14:35
Per "basi" non intendevo il punto di partenza, ma "fondamenta". Per me una conoscenza ottimale di tutta la storia non puo' prescinderne :)
Il programmatore per definizione deve risolvere problemi, e per fare questo non serve conoscere i dettagli di una qualunque architettura.
Purtroppo si tende troppo spesso a confondere le basi della programmazione con la conoscenza dei dettagli di più basso livello.
Niente di più falso, ovviamente (e andando in fondo non sarebbe l'assembly, ma il linguaggio macchina la scelta che meglio si addice a questo pensiero).
cdimauro
22-08-2007, 14:41
chiaro è cheil patterson hennessy è la bibbia dei calcolatori elettronici...io da parte mia ho letto ''Architettura e organizzazione dei calcolatori elettronici'' di G.Bucci...
però l'assembly è tutt'altra cosa insomma...
E cosa sarebbe, se non una visione (limitata) dell'architettura di una macchina. L'assembly di per sé NON è assolutamente sufficiente a conoscere bene come funziona un'architettura. Tutt'altro.
poi tra l'altro la questione va oltre alla domanda del post iniziale ...vedo che è sentita da molta gente, molti dicono che non serve, altri (come me) sono convinti che una nicchia dei programmatori mondiali lo usa ancora...
Non è questo che è stato detto: l'estrema sintesi ti sta portando a falsare i concetti che sono stati esposti.
Io, ad esempio, ho detto che è molto meglio farne a meno SE NON E' ASSOLUTAMENTE NECESSARIO per il progetto che si deve realizzare. Che è una cosa ben diversa, se permetti.
Questo perché, se non lo è (necessario), esistono delle validissime alternative che permettono di essere MOLTO più produttivi.
ora il fatto sta che l'assembly anche se a poche persone servirà sempre...
Certamente, e la tendenza è di essere sempre meno usato per venire confinato in particolarissimi settori.
mentre linguaggi come il ruby o chessò sono facilmente sostituibile e potranno diventare davvero obsoleti tra qualche anno....
questo è il mio pensiero almeno...
Ed è un pensiero un po' troppo "forte", perché linguaggi come il Fortran, che è il primo ad alto livello che è stato scritto, vengono tutt'ora utilizzati (non ci crederai ma c'è ancora gente che usa il COBOL).
Possono cambiare le tendenze / preferenze per i particolari linguaggi, sicuramente, ma è sicuro che per quelli ad alto livello ci sarà sempre più posto, e sempre meno verrà riservato a quelli di più basso livello.
cdimauro
22-08-2007, 14:44
non dimentichiamo il fatto che l'architettura di un elaboratore è caratterizzata anche dal suo set di istruzioni...
Certamente, ma vorrei sapere quanti hanno utilizzato istruzioni come AAA, XLATB, ecc. dell'ISA degli x86. Tanto per fare un esempio.
Ovviamente NON per programmini dimostrativi, ma in progetti di un certo spessore.
Ps:è appena uscita la notizia che a novembre escono i peryn con SSE4...
Già, che saranno sfruttate grazie agli eccellenti compilatori Intel che permetteranno ai programmatori di sfruttarle senza conoscere una sola istruzione assembly che le riguarda.
Il programmatore per definizione deve risolvere problemi, e per fare questo non serve conoscere i dettagli di una qualunque architettura.
Ma conoscere almeno una architettura serve...non tanto per lavorare su quella architettura, ma per capire fino in fondo come funziona un processore e potersi adattare in futuro a lavorare a basso livello su architetture diverse.
Sisupoika
22-08-2007, 14:56
Il programmatore per definizione deve risolvere problemi, e per fare questo non serve conoscere i dettagli di una qualunque architettura.
Purtroppo si tende troppo spesso a confondere le basi della programmazione con la conoscenza dei dettagli di più basso livello.
Niente di più falso, ovviamente (e andando in fondo non sarebbe l'assembly, ma il linguaggio macchina la scelta che meglio si addice a questo pensiero).
Punti di vista :)
cdimauro
22-08-2007, 15:08
Ma conoscere almeno una architettura serve...non tanto per lavorare su quella architettura, ma per capire fino in fondo come funziona un processore e potersi adattare in futuro a lavorare a basso livello su architetture diverse.
Capire fino in fondo come funziona un processore non serve per risolvere un problema.
Le applicazioni Python possono girare tranquillamente senza che sia necessario conoscere se sotto c'è un x86, 680x0, ARM, PPC, ecc. ecc.
Io nemmeno mi pongo il problema se una mia applicazione (in Python) girerà su una particolare architettura: me ne frego assolutamente.
Quanto al futuro... si valuterà in futuro, appunto, SE si dovesse necessariamente presentare l'occasione di lavorare a basso livello.
cdimauro
22-08-2007, 15:10
Punti di vista :)
Senza argomentazioni a sostengo ognuno può dire quello che vuole...
un informatico che non ha mai visto l'assembly è come un meccanico che non ha mai visto un bullone
un informatico che non ha mai visto l'assembly è come un meccanico che non ha mai visto un bullone bella questa metafora, poetica :asd: ma ci faccio poco :rolleyes:
edit - pardon, era una similitudine :O :asd:
Punti di vista :) ma che gentiluomo, anche il sorriso alla fine eh, vorrei far notare :asd:
io dico che non erano argomentazioni soggettive: avevano una certa pretesa di oggettività e mi sembravano anche piuttosto corrette.
cdimauro
22-08-2007, 17:02
un informatico che non ha mai visto l'assembly è come un meccanico che non ha mai visto un bullone
Io dico che un informatico che non conosce gli studi e le tesi di:
http://en.wikipedia.org/wiki/Alonzo_Church
http://en.wikipedia.org/wiki/Goedel
http://en.wikipedia.org/wiki/Kleene
http://en.wikipedia.org/wiki/Alan_Turing
non può definirsi tale, visto che sono i padri dell'informatica e con l'assembly c'hanno avuto ben poco a che fare (erano matematici). ;)
Io dico che un informatico che non conosce gli studi e le tesi di:
http://en.wikipedia.org/wiki/Alonzo_Church
http://en.wikipedia.org/wiki/Goedel
http://en.wikipedia.org/wiki/Kleene
http://en.wikipedia.org/wiki/Alan_Turing
non può definirsi tale, visto che sono i padri dell'informatica e con l'assembly c'hanno avuto ben poco a che fare (erano matematici). ;)
purtroppo nessuno di questi fu un informatico e quindi non vedo per quale motivo dovevano conoscere l'assembly. dietro all'informatica c'è una marea di matematica, quindi non mi stupisce che bisogna sapere la matematica per comprendere l'informatica.
ma a parte questo.. il quesito iniziale era più o meno: "serve imparare l'assembly dato che sarò ingegnere informatico?"
la risposta è sì, ma non serve scrivere un programma per la gestione del magazzino in assembly... basta capire come funziona perchè è inutile concentrarsi su una particolare architettura
cdimauro
22-08-2007, 17:23
purtroppo nessuno di questi fu un informatico e quindi non vedo per quale motivo dovevano conoscere l'assembly. dietro all'informatica c'è una marea di matematica, quindi non mi stupisce che bisogna sapere la matematica per comprendere l'informatica.
Leggiti la loro biografia almeno (e meglio ancora sarebbe seguire un corso di teoria della computabilità).
Tra l'altro l'informatica è nata (e per me lo è ancora) come branca della matematica. ;)
ma a parte questo.. il quesito iniziale era più o meno: "serve imparare l'assembly dato che sarò ingegnere informatico?"
la risposta è sì, ma non serve scrivere un programma per la gestione del magazzino in assembly... basta capire come funziona perchè è inutile concentrarsi su una particolare architettura
Dove sta scritto che un ingegnere informatico deve necessariamente conoscere l'assembly? Da nessuna parte mi pare.
Per il resto, vale quanto ho scritto: se è indispensabile lo si impara, altrimenti è tempo perso.
ma a parte questo.. il quesito iniziale era più o meno: "serve imparare l'assembly dato che sarò ingegnere informatico?"
la risposta è sì, ma non serve scrivere un programma per la gestione del magazzino in assembly... basta capire come funziona perchè è inutile concentrarsi su una particolare architettura
Perfettamente d'accordo :O
Sisupoika
22-08-2007, 17:26
ma che gentiluomo, anche il sorriso alla fine eh, vorrei far notare :asd:
:confused:
Se non ho "argomentato" come suggerito e' perche' ho gia' detto quello che penso nel post precedente, non vedo cosa altro potrei aggiungere.
Leggiti la loro biografia almeno (e meglio ancora sarebbe seguire un corso di teoria della computabilità).
cosa ti fa pensare che non li conosco? o meglio ancora che non ho sostenuto un esame su tale argomento? :mbe: me lo ricordo come fosse ieri :D
Tra l'altro l'informatica è nata (e per me lo è ancora) come branca della matematica. ;)
l'informatica ha le sue basi teoriche nella matematica ma non è matematica, altrimenti quasi tutto sarebbe matematica
Dove sta scritto che un ingegnere informatico deve necessariamente conoscere l'assembly? Da nessuna parte mi pare.
nel piano di studi :read:
Per il resto, vale quanto ho scritto: se è indispensabile lo si impara, altrimenti è tempo perso.
perchè insegnare i linguaggi di programmazione all'università allora? quando serviranno li si imparano :muro:
cdimauro
22-08-2007, 20:27
:confused:
Se non ho "argomentato" come suggerito e' perche' ho gia' detto quello che penso nel post precedente, non vedo cosa altro potrei aggiungere.
Il tuo post è questo: http://www.hwupgrade.it/forum/showpost.php?p=18355239&postcount=49 e ti ho già fatto notare che le "fondamenta" di cui parli non sono certamente rappresentate dalla conoscenza di un qualunque linguaggio assembly.
cdimauro
22-08-2007, 20:43
cosa ti fa pensare che non li conosco? o meglio ancora che non ho sostenuto un esame su tale argomento? :mbe: me lo ricordo come fosse ieri :D
Dunque dovresti avere ben chiaro cos'è un software e cosa significa programmare. ;)
l'informatica ha le sue basi teoriche nella matematica ma non è matematica, altrimenti quasi tutto sarebbe matematica
E' matematica invece. Sempre per gli studi di cui sopra, un qualunque programma altro non è che che una funzione che opera su numeri naturali. Nulla di più.
nel piano di studi :read:
Eh? Vuoi dirmi che in ingegneria informatica ci sono corsi OBBLIGATORI che trattano specificamente di architetture e richiedono lo studio (ed eventualmente l'uso) di un linguaggio assembly?
In informatica (non ingegneria) il corso di architetture degli elaboratori fa parte delle materie completari, e sono stato io a inserirlo nel piano di studi (ovviamente perché mi conveniva :D), altrimenti ci si può tranquillamente laureare senza conoscere nessuna architettura e/o linguaggio assembly.
perchè insegnare i linguaggi di programmazione all'università allora? quando serviranno li si imparano :muro:
Io ne ho imparati tanti perché erano rappresentanti di diversi paradigmi di programmazione (strutturato/procedurale, funzionale, logico, a oggetti), e almeno questi bisogna conoscerli per avere una visione dei diversi approcci che si possono avere quando si affronta un problema (questo per un informatico, che ha un approccio più "teorico" all'informatica; per ingegnere informatico forse sarà diverso).
Oggi però c'è la tendenza ad abbandonare i primi paradigmi per studiare quasi esclusivamente quella a oggetti (si studia quasi esclusivamente Java, che va di moda), ma personalmente, almeno per il corso di studi che ho fatto, non sono d'accordo, e mi ritengo fortunato per averli appresi (e se Python integrasse qualcosina relativamente alla programmazione logica non mi dispiacerebbe affatto, perché diverrebbe un linguaggio completo che coprirebbe qualunque paradigma; speriamo bene per il futuro :)).
Ritornando alla parte che t'ho quotato, un linguaggio per poter passare dalla teoria alla pratica serve, e visto che si tratta di imparare, meglio un linguaggio al più alto livello possibile, appunto. D'altra parte se all'inizio si studiano pseudocodice e diagrammi di flusso un motivo ci sarà.
In ogni caso si può benissimo imparare a programmare, ma anche lavorare seriamente senza conoscere alcun dettaglio dell'architettura su cui gira l'applicazione, come dicevo anche prima.
Secondo me bisogna evidenziare l'argomento: "assembly per un ingegnere informatico".
Un ingegnere informatico può essere anche un progettista di chip, scritti magari in Verilog o VHDL. Diglielo se vai a lavorare in un ambiente del genere che non hai mai visto un assembly e sicuramente ti cacceranno deridendoti :D
IMHO Ingegnere informatico è DIVERSO da Informatico. Ed una maggiore conoscenza del "basso livello" è una delle differenze principali.
Dunque dovresti avere ben chiaro cos'è un software e cosa significa programmare. ;)
spero di sì! altrimenti prenderei in considerazione l'idea di zappare la terra :p
E' matematica invece. Sempre per gli studi di cui sopra, un qualunque programma altro non è che che una funzione che opera su numeri naturali. Nulla di più.
da quel che ricordo un programma descrive un algoritmo :fagiano:
Eh? Vuoi dirmi che in ingegneria informatica ci sono corsi OBBLIGATORI che trattano specificamente di architetture e richiedono lo studio (ed eventualmente l'uso) di un linguaggio assembly?
certamente, abbiamo usato l'architettura della JVM ma solo una parte.. quella che riguarda i numeri interi
oltre al microcodice ovviamente :p
In informatica (non ingegneria) il corso di architetture degli elaboratori fa parte delle materie completari, e sono stato io a inserirlo nel piano di studi (ovviamente perché mi conveniva :D), altrimenti ci si può tranquillamente laureare senza conoscere nessuna architettura e/o linguaggio assembly.
questo non vale per l'ingegneria perchè si deve avere una conoscenza un pò di tutto.
Io ne ho imparati tanti perché erano rappresentanti di diversi paradigmi di programmazione (strutturato/procedurale, funzionale, logico, a oggetti), e almeno questi bisogna conoscerli per avere una visione dei diversi approcci che si possono avere quando si affronta un problema (questo per un informatico, che ha un approccio più "teorico" all'informatica; per ingegnere informatico forse sarà diverso).
perchè l'approccio di basso livello non è diverso da quello di alto livello?
Oggi però c'è la tendenza ad abbandonare i primi paradigmi per studiare quasi esclusivamente quella a oggetti (si studia quasi esclusivamente Java, che va di moda), ma personalmente, almeno per il corso di studi che ho fatto, non sono d'accordo, e mi ritengo fortunato per averli appresi (e se Python integrasse qualcosina relativamente alla programmazione logica non mi dispiacerebbe affatto, perché diverrebbe un linguaggio completo che coprirebbe qualunque paradigma; speriamo bene per il futuro :)).
io ho studiato C, java, python, ADA.. qualche linguaggio logico a seconda delle situazioni, e poi non ricordo (sicuramente dimentico qualcosa)
Ritornando alla parte che t'ho quotato, un linguaggio per poter passare dalla teoria alla pratica serve, e visto che si tratta di imparare, meglio un linguaggio al più alto livello possibile, appunto. D'altra parte se all'inizio si studiano pseudocodice e diagrammi di flusso un motivo ci sarà.
anche per le architetture dei calcolatori serve un modo per passare dalla teoria alla pratica... o forse è meglio comprare una manciata di condensatori e rimboccarsi le maniche? tanenbaum docet :O
In ogni caso si può benissimo imparare a programmare, ma anche lavorare seriamente senza conoscere alcun dettaglio dell'architettura su cui gira l'applicazione, come dicevo anche prima.
per un ingegnere è diverso.. esso non lavora mai su qualcosa che non conosce :O
senza nulla togliere allo scienzato ovviamente.. si tratta di figure diverse
Secondo me bisogna evidenziare l'argomento: "assembly per un ingegnere informatico".
Un ingegnere informatico può essere anche un progettista di chip, scritti magari in Verilog o VHDL. Diglielo se vai a lavorare in un ambiente del genere che non hai mai visto un assembly e sicuramente ti cacceranno deridendoti :D
IMHO Ingegnere informatico è DIVERSO da Informatico. Ed una maggiore conoscenza del "basso livello" è una delle differenze principali.
già ho dimenticato il VHDL :stordita:
In informatica (non ingegneria) il corso di architetture degli elaboratori fa parte delle materie completari, e sono stato io a inserirlo nel piano di studi (ovviamente perché mi conveniva :D), altrimenti ci si può tranquillamente laureare senza conoscere nessuna architettura e/o linguaggio assembly.
No, perlomeno non nella mia facoltà di informatica (non parlo di ingegneria informatica, ma informatica (http://www.informatica.unipg.it)). I corsi di architettura degli elaboratori I e II sono obbligatori e il I è propedeutico per il II.
^TiGeRShArK^
23-08-2007, 02:28
OH SCIAGURA!!! dovrebbe essere bannato (con tutta la sottomaschera dell'IP) chi posta per sentito dire, che Dio ti scampi da un uomo si' scellerato :eek:
comunque guarda io non credo che tutti e 50 i miliardi di dispositivi embedded di questo mondo necessitino di segmentazione, paginazione, renaming dei registri, task switch... :fagiano:
No..
ad esempio molti PLC si programmavano in.... LADDER :D
che è ben + a basso livello dell'assembly :asd:
funziona tutto con contatti e bobine essenzialmente (+ qualche altro operatore che ora non ricordo :p) e solitamente prima si scriveva il listato in SFC e quindi veniva tradotto in Ladder..
solo io ero l'unico masochista che preferiva scrivere direttamente il codice in Ladder :fagiano:
^TiGeRShArK^
23-08-2007, 02:31
Se proprio vuoi iniziare con l'assembly, ti consiglio l'architettura Motorola 68000 che è molto semplice (56 istruzioni, se non ricordo male), ma potente.
Comunque, per quanto già detto, te lo sconsiglio fortemente.
zizzì :O
ed è infinitamente + semplice e lineare dell'incasinatissimo assembly x86 :fagiano:
Oh San Giuseppe, a quest'ora di notte pensavo di essere l'unico lupo mannaro ancora davanti al PC! :D
^TiGeRShArK^
23-08-2007, 02:40
perchè insegnare i linguaggi di programmazione all'università allora? quando serviranno li si imparano :muro:
e perchè all'università insegnano a programmare? :confused:
Se non ti metti a programmare per conto tuo andando ben oltre quello ke ti insegnano in qualche progettino all'univ.. bhè... dubito che uscirai come programmatore :p
^TiGeRShArK^
23-08-2007, 02:42
Oh San Giuseppe, a quest'ora di notte pensavo di essere l'unico lupo mannaro ancora davanti al PC! :D
sono tornato poco fa dopo le classiche birrette con gli amici :O
è normale sparare cazzate in questa sezione .. concilia il sonno :O
:sofico:
cdimauro
23-08-2007, 08:08
Secondo me bisogna evidenziare l'argomento: "assembly per un ingegnere informatico".
Un ingegnere informatico può essere anche un progettista di chip, scritti magari in Verilog o VHDL. Diglielo se vai a lavorare in un ambiente del genere che non hai mai visto un assembly e sicuramente ti cacceranno deridendoti :D
IMHO Ingegnere informatico è DIVERSO da Informatico. Ed una maggiore conoscenza del "basso livello" è una delle differenze principali.
OK, ma bisogna vedere se i corsi in cui si studia l'architettura degli elaboratori sono obbligatori o facoltativi. Nel primo caso hai ragione. Nel secondo non sei tenuto a conoscere l'assembly.
cdimauro
23-08-2007, 08:17
spero di sì! altrimenti prenderei in considerazione l'idea di zappare la terra :p
da quel che ricordo un programma descrive un algoritmo :fagiano:
E' l'algoritmo che descrive la soluzione del problema. Il programma ne è la sua implementazione.
Controlla qui http://it.wikipedia.org/wiki/Algoritmo in particolare questo http://it.wikipedia.org/wiki/Algoritmo#Approccio_Matematico e quest'altro http://it.wikipedia.org/wiki/Algoritmo#Modelli_formali non noti qualcosa di "schifosamente" matematico? :D
certamente, abbiamo usato l'architettura della JVM ma solo una parte.. quella che riguarda i numeri interi
oltre al microcodice ovviamente :p
OK, se è questi corsi sono obbligatori, nulla da dire.
questo non vale per l'ingegneria perchè si deve avere una conoscenza un pò di tutto.
Quindi sono ambiti diversi.
Io preferisco una specializzazione.
perchè l'approccio di basso livello non è diverso da quello di alto livello?
Dove lo vedi che è diverso? Si può benissimo ricondurre alla programmazione strutturata modello "spaghetti BASIC" che andava di moda una trentina d'anni fa.
io ho studiato C, java, python, ADA.. qualche linguaggio logico a seconda delle situazioni, e poi non ricordo (sicuramente dimentico qualcosa)
Ottimo.
anche per le architetture dei calcolatori serve un modo per passare dalla teoria alla pratica... o forse è meglio comprare una manciata di condensatori e rimboccarsi le maniche? tanenbaum docet :O
Ovvio. Se hai nel programma di studiare l'architettura degli elaboratori, è naturale imparare anche un linguaggio assembly.
per un ingegnere è diverso.. esso non lavora mai su qualcosa che non conosce :O
senza nulla togliere allo scienzato ovviamente.. si tratta di figure diverse
Vabbé, ma è un'esagerazione: se deve realizzare un gestionale (per dirne una), mica deve conoscere per forza di cose l'architettura della macchina su cui girerà.
cdimauro
23-08-2007, 08:22
già ho dimenticato il VHDL :stordita:
Hai fatto bene a dimenticarlo: http://myhdl.jandecaluwe.com/doku.php/overview :sofico:
Link gentilmente fornito da ilsensine. :p
cdimauro
23-08-2007, 08:28
No, perlomeno non nella mia facoltà di informatica (non parlo di ingegneria informatica, ma informatica (http://www.informatica.unipg.it)). I corsi di architettura degli elaboratori I e II sono obbligatori e il I è propedeutico per il II.
Noto che c'è una certa libertà nell'organizzazione dei programmi dello stesso corso di laurea: nella mia facoltà non era obbligatoria (Architetture degli elaboratori l'ho data col vecchio ordinamento, quando era una materia annuale).
Ho appena controllato e adesso il primo corso di architetture degli elaboratori è obbligatorio col nuovo ordinamento all'università di Catania.
Che confusione... :|
architetture I e II erano obbligatori anche da me.
OK, ma bisogna vedere se i corsi in cui si studia l'architettura degli elaboratori sono obbligatori o facoltativi. Nel primo caso hai ragione. Nel secondo non sei tenuto a conoscere l'assembly.
Ovviamente tutti obbligatori.
DarkSiDE
23-08-2007, 10:50
ci sono tante cose che non "serve imparare" ma che aprono letteralmente la mente. L'asm è una di queste, IMO.
Hai fatto bene a dimenticarlo: http://myhdl.jandecaluwe.com/doku.php/overview :sofico:
Link gentilmente fornito da ilsensine. :p
ora che ci penso c'è anche il TCL nella lista dei linguaggi che ho dimenticato ;)
cdimauro
23-08-2007, 14:04
ci sono tante cose che non "serve imparare" ma che aprono letteralmente la mente. L'asm è una di queste, IMO.
Potrei dire la stessa cosa per LISP, Prolog, SmallTalk, ecc.
Potrei dire la stessa cosa per LISP, Prolog, SmallTalk, ecc. infatti ha avuto l'ottima accortezza di aggiungere "IMO", anche se si è scordato la H :D
cdimauro
23-08-2007, 14:41
Il problema è che riportando soltanto le proprie opinioni personali senza argomentarle non risolviamo niente.
Per quanto riguarda questo thread, penso che abbia ormai esaurito il suo ruolo. Appurato che un ingegnere deve obbligatoriamente seguire corsi che prevedono lo studio delle architetture degli elaboratori, è ovvio che deve conoscere anche l'assembly (di una qualche famiglia di processori).
si conoscerlo ok...ma a che livello? anche nella mia università calcolatori elettronici è obbligatorio...ma il livello di assably che ti insegnano è davvero mooolto basso...sull'esame pesa circa 4punti su trenta:confused:
cdimauro
23-08-2007, 16:18
Mi spiace, ma non conosco il tuo corso, e non posso valutare.
ma non c'è bisogno di conoscere il corso...se dico che il livello è basso è basso veramente !!! :D
cdimauro
23-08-2007, 20:22
M'hai messo curiosità: hai da passarmi un link al programma della materia in questione, cortesemente? :)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.