Newsgroup: it.comp.programmare
Titolo: studiare il linguaggio macchina del commodore 64

salve, avrei una domandina da porvi. sono un nostalgico dei vecchi arcade 
degli anno 80. per intenderci , quelli che giravano sul commodore 64. ho 
sempre desiderato di cimentarmi nella programmazione di questi giochini 2d. 
non mi va' l'idea di servirmi di quei software per la creazione semplificata 
di videogames. ma vorrei realizarli in linguaggio macchina, propio come 
venivano fatti originalmente. ma haime non conosco assolutamente questo tipo 
di linguaggio.e quindi dovrei iniziare a studiarlo. la mia domanda e', lo 
studio di questo linguaggio puo' servire anche ad altro? ,cioe' 
professionalmente in qualche campo?.o al limite per capire meglio alcuni 
concetti di programmazione dei linguaggi moderni?. chiedo questo perche' mi 
sembra tempo sprecato studiarlo solo per realizzare vecchi giochini.

 sembra tempo sprecato studiarlo solo per realizzare vecchi giochini.
I concetti di programmazione li impari anche con l'assembly per 8088.
Se vuoi un consiglio procurati un vecchio libro di Sacha-Norton
(quello dell'antivirus) che si chiama "Linguaggio Assembly per PC
IBM". E' molto datato ma è la migliore introduzione che abbia mai
letto sull'argomento. Se hai difficoltà nel trovarlo clicca su questo
link: 
http://www.elettropedia.org/assembly.htm
dove troverai delle lezioni in gran parte prese paripari dal libro in
questione.
Poi se vuoi approfondire l'argomento: "The Art of Assembly Language"
di Randall Hyde (2003)
ciao.


Puoi programmare in C (tanto è quasi la stessa cosa :-) ).
Comunque l'assembly può servire quando si programmano routine di basso
livello relative ad uno specifico processore (generalmente per embedded
o per alcuni tipi di device driver).
Anche la regola del "lo faccio in assembly per avere migliori
prestazioni" ha iniziato a perdere valore. Scrivere un programma in C
permette di avere del codice veloce e snello quasi quanto scriverlo in
assembly (nel caso di un programmatore assembly che conosca il suo
lavoro) o decisamente migliore (nel caso di un programmatore assembly
alle prime armi). I compilatori, infatti, sono molto ottimizzati e fanno
il loro sporco lavoro abbastanza bene.
Dal punto di vista didattico, invece, reputo che imparare a programmare
in assembly abbia molto valore. Nessun artificio dei linguaggi di alto
livello come garbage collection, tipi per le stringhe, ecc (il C non è
un linguaggio di alto livello, ma si piazza poco sopra l'assembly).
Implementare algoritmi (o per iniziare semplici funzioni) in assembly è
una buona scuola per capire bene come funziona il processore e quindi
trattarlo come si deve.
Se poi volessi cimentarti sui vecchi Commodore, prova a vedere Vice. È
un emulatore di C64 C128 C16 e Vic20. (bei ricordi :-) )
Luca

triller ha scritto:

Lo studio del linguaggio macchina dei microprocessori e' interessante, 
anche se oggio come oggi non mi sentirei di consigliare a nessuno di 
perderci troppo tempo.
Chi ha avuto la fortuna di aver vissuto quel periodo d'oro e ha appreso 
il modo di scrivere in codice macchina, ne avra' avuto giovamento negli 
anni seguenti, ma mettersi ora a ripercorrere quelle orme e' un po' come 
mettersi a fare dei graffiti sui muri cercando di imitare quelli 
preistorici.
In ogni caso l'utilita' di scrivere procedure in codice macchina puo' 
avere senso nella misura in cui non pretendi di leggere input dalla 
tastiera e di scrivere output a video, perche' queste funzionalita' sono 
maledettamente legate all'hardware delle macchine dell'epoca.
E pretendere di scrivere un videogame vuol dire proprio fare queste 
cose: leggere la tastiera (o il joystick) e produrre un output a video.
Oggi come oggi il linguaggio macchina puro serve per scrivere codici di 
controllo su impianti che utilizzano quei processori, quindi tutt'altro 
che videogames.

 che videogames.
Dimentichi la scrittura di parti di firmware di dispositivi vari o di
embedded (PIC e quant'altro).
Comunque concordo, tutt'altro che videogiochi.
Però era bello il mondo delle 4kIntro :-)
LP

 un linguaggio di alto livello, ma si piazza poco sopra l'assembly).
si ho deciso che mi dedichero anche a imparare assembly, pero' darei
precedenza a uno di questi 3  c/c++/c#, cosi faro' anche un investimento :-)
ma il c++ e' da ritenersi un linguaggio a baso livello come il c ?



pardon volevo scrivere indipendente :-)

 imperativi.
Anche se partire da C o peggio da C++ è la strada più dura.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 Anche se partire da C o peggio da C++ è la strada più dura.
Partire dal C o dal C++ e poi passare ad altro e' dura perche' una volta 
acquisita la padronanza con il C e col C++ il resto disgusta.

 acquisita la padronanza con il C e col C++ il resto disgusta.
Mi pare un punto di vista assai miope. Pur non reputandomi un guru di
C++, mi ritengo discretamente skillato, e in effetti ancora piů in C.
Eppure il resto, lungi dallo schifarmi, mi attrae e lo apprezzo assai.
Adoro Haskell, per esempio. Non sono un Lisper, ma č un'altro linguaggio
che apprezzo tantissimo. Sono perfino riuscito a farmi piacere Prolog.
E adoro Python e Ruby. Ah, e sicuramente me ne sono scordati parecchi
fra quelli che 'apprezzo'.
Non solo: su icl.c++ un po' di tempo fa ci si lamentava scherzosamente
della 'fuga' di molti poster storici verso it.comp.lang.python. Tanto
per dire.


 acquisita la padronanza con il C e col C++ il resto disgusta.
Esagerato, ci son tanti di quei linguaggi e paradigmi là fuori che è un
peccato ignorarli in toto ;) 
-- 
Lawrence, 
oluyede.org
 - 
neropercaso.it
"It is difficult to get a man to understand 
something when his salary depends on not
understanding it" - Upton Sinclair

 Mi pare un punto di vista assai miope. 
Quando ti abitui a poter fare tutto e il contrario di tutto, e poi ti 
ritrovi ad avere a che fare con linguaggi pesanti e limitativi, altro 
che disgusto.

 
Forse dura, ma non inutile.
Luca

 Forse dura, ma non inutile.
Bisogna poi vedere quale sia lo scopo. Per 'imparare a programmare'
(qualunque cosa voglia dire), per esempio mi chiedo se è veramente il
caso. Per 'imparare a progettare' (cosa IMHO inscindibile) forse un
linguaggio più snello e agile aiuterebbe. Per 'vedere' i dettagli
implementativi certo, C aiuta. Ma siamo sicuri che non siano una cosa da
affrontare 'con calma'.
C++ mi sento invece di escluderlo come linguaggio didattico. È troppo
facile imparare ad usarlo in modo atroce, per capire cosa usare quando è
utile un po' di esperienza.


 che disgusto.
Io trovo limitativo dovere scrivere diverse linee di codice per quello
che con un altro linguaggio faccio con una, per dire.
Per non parlare di quanto trovo limitante il tentativo di C++ di
convincermi che devo essere paranoico *verso* i miei colleghi
sviluppatori (il buon vecchio Naggum non perdona).
Detto questo per considerare 'pesante' e 'limitativo' Python o Ruby, ce
ne vuole. Per non parlare delle stesse considerazioni applicate a Lisp,
Haskell o OCaml. Ma direi soprattutto a Lisp. 
Permettimi di dire che da quanto scrivi sembrerebbe che forse hai molta
esperienza con C++, ma altro non hai visto.


 che disgusto.
Io trovo limitativo dovere scrivere diverse linee di codice per quello
che con un altro linguaggio faccio con una, per dire.
Per non parlare di quanto trovo limitante il tentativo di C++ di
convincermi che devo essere paranoico *verso* i miei colleghi
sviluppatori (il buon vecchio Naggum non perdona).
Detto questo per considerare 'pesante' e 'limitativo' Python o Ruby, ce
ne vuole. Per non parlare delle stesse considerazioni applicate a Lisp,
Haskell o OCaml. Ma direi soprattutto a Lisp. 
-- 


 che con un altro linguaggio faccio con una, per dire.
Esatto.
E' molto limitativo dover scrivere
   MID(a$, 3, 1)
quando puoi scrivere
   a[2];
che e' anche molto piu' comprensibile.
Oppure e' limitativo dover scrivere
   IF a=1 THEN
     b=1
   ELSE
     b=0
   END IF
quando in una sola riga puoi scrivere
   b = (a==1) ? 1 : 0;
Quindi concordi con me quando dico che una volta raggiunta la padronanza 
del C il resto e' pesante e limitativo.

 del C il resto e' pesante e limitativo.
ROTFL. Io ci ho anche provato a fare un discorso serio.
Comunque il mondo non è fatto solo di C++ e Basic, eh. Ma fa lo stesso.


 Comunque il mondo non è fatto solo di C++ e Basic, eh. Ma fa lo stesso.
Al di la' della facile ironia, pure io sono disposto a fare un discorso 
serio.
Riesci a pormi qualche esempio concreto in cui si riesca a fare qualcosa 
con qualche linguaggio in modo piu' semplice che in C?
Parliamone.
Intanto nel frattempo mi e' pure venuto in mente quanto sia potente la 
printf per produrre un output formattato, cosa che ho sempre sofferto in 
tutti i linguaggi che non implementano una funzione in grado di 
interpretare la formattazione come fa la printf(), tanto per spezzare 
un'altra lancia in favore del C e affini.

 con qualche linguaggio in modo piu' semplice che in C?
Cioč, č una domanda seria questa? Dimmi che stai scherzando.


 un'altra lancia in favore del C e affini.
Ti faccio alcuni esempi. Python, Perl e Ruby *non* sono linguaggi affini
al C. Ruby *ha* una funzione printf che si comporta come quella del C.
Idem Perl. Python va oltre: la stringa stessa ha un operatore % che data
una stringa di formattazione 'printf-style' e gli argomenti ti genera la
stringa. In pratica č la snprint built-in nel linguaggio.
Questo solo per nominarne alcuni. Haskell pure ha una printf. 


 Cioč, č una domanda seria questa? Dimmi che stai scherzando.
Io credo che si faccia prima con un esempio. Ma non me ne vengono in
mente di buoni. O troppo piccolo o troppo 'scripting' o troppo grossi.
Pensavo al quicksort in Haskell, ho pensato pure ad una traccia di
webspider in Python. Se no avrei da recuperare una macchina virtuale +
compilatore di espressioni aritmetiche per suddetta macchina virtuale in
Prolog (il tutto in meno di 100 righe).


 Questo solo per nominarne alcuni. Haskell pure ha una printf. 
Sono infatti linguaggi piu' recenti che hanno preso dal C le cose buone.
Pure per la manipolazione di stringhe Python e compagnia hanno preso 
spunto dal C, migliorando immensamente la gestione degli array di 
caratteri, vedi gli indici negativi per contare i caratteri dalla fine 
della stringa.
Solo il basic e' rimasto indietro di oltre 20 anni con quella 
fetentissima funzione MID, e l'ASP dietro a ruota.

 fetentissima funzione MID, e l'ASP dietro a ruota.
Vero.
