I floppy disk sono obsoleti, ma non per il programma nucleare USA

[Vi7o]

Originariamente inviato da Bellaz89

Ok. resta comunque una tua personale definizione di efficienza e velocita' di un linguaggio di programmazione che il resto del mondo non conosce. Magari se lo avessi specificato prima che era una tua definizione personale si sarebbe finita prima la discussione.

come ti dicevo puoi riscontrarlo anche su libri accademici che parlano di architettura/ingegneria degli elaboratori o linguaggi di programmazione non è solo una mia filosofia

[Vi7o]

proprio per questo mi aspettavo un po' di supporto

[cdimauro]

Originariamente inviato da Vi7o

dal lato macchina, che ha fame, gli conviene ricevere subito la pappa(il binario) o attendere che la mamma gli prepari la compilazione?

Adesso mi spieghi come fa la macchina a ricevere il binario, senza passare da un compilatore ANCHE nel caso del linguaggio macchina?

Detto in altri termini, tu realizzi un programma in linguaggio macchina: come fai da questo a dare in pasto alla macchina il corrispondente codice binario?

Ciò che ho descritto prima su quello che si faceva nella prima metà degli anni '80 è un chiarissimo esempio della situazione in cui ci si trovava quando si doveva scrivere qualcosa in linguaggio macchina.

Ma "stranamente" su quello che ho scritto non hai avuto nulla da dire...

Originariamente inviato da Vi7o

come ti dicevo puoi riscontrarlo anche su libri accademici che parlano di architettura/ingegneria degli elaboratori o linguaggi di programmazione non è solo una mia filosofia

Quei libri li ho letti anch'io, se permetti, che una laurea me la sono sudata.

Adesso dimmi cosa trovi di sbagliato in quello che ho scritto in questo commento, come nei miei precedenti, e in particolare nel #81. Grazie.

[tuttodigitale]

Originariamente inviato da Vi7o

MA io mi stavo solo opponendomi a "assembly=linguaggio macchina",

non mi pare che nessuno abbia detto che il linguaggio assembly == linguaggio macchina...
Essendo la sintassi per forza di cose diverse (i simboli del vocabolario è immensamente più ricco nell'assembly) i 2 linguaggi sono diversi...
La cosa che accomuna il linguaggio macchina e l'assembly è la semantica. il significato delle produzioni del linguaggio...

Originariamente inviato da Vi7o

era tutto un discorso teorico riscontrabile su qualunque libro accademico che tratta l'argomento,

ma nel tuo testo non fa distinzione tra run-time e compile-time....ti pare possibile che devi compilare ogni qual volta che esegui un programma?

Originariamente inviato da Vi7o

dal lato macchina, che ha fame, gli conviene ricevere subito la pappa(il binario) o attendere che la mamma gli prepari la compilazione?

ma il file sorgente, a parte i pc di cdimauro e di altri Programmatori, l'utente a cui saranno destinati nel 99,99999% non li vedranno mai....
ti risulta che il tuo PC prima di eseguire un aggiornamento di Windows effettui la compilazione?
Quindi si, che sia compilato in assembly, in C, in basic, il PC che usufrirà del programma avrà per lo più la pappa pronta...

comunque anche il termine compilazione è errato per l'assembly, visto che si usa un assemblatore (assembler).

Originariamente inviato da Vi7o

Guardate sta slide e spero possiate capirmi:
http://images.slideplayer.it/2/58515...es/slide_5.jpg

cdimauro prendi appunti

scherzo

Originariamente inviato da Vi7o

se il mio costo di programmazione in linguaggio macchina è 5(sono un fenomeno, e non dobbiamo pensare solo come esseri umani)
se il mio costo di programmazione in assembly è sempre 5

ma con l'assembly devi conoscere a fondo l'architettura su cui stai lavorando, i punti di forza e i punti deboli...
ma chi conosce l'assembly di fatto conosce il linguaggio macchina....

Ti faccio un'esempio di un'istruzione MIPS.
add $4, $4, $7; ASSEMBLY
00000000100001000011101101010000 LINGUAGGIO MACCHINA

Non c'è niente di particolarmente difficile passare dall'assembly a linguaggio macchina ( ho qualche dubbio su architetture più complesse in cui le dimensioni dei campi variano continuamente e le istruzioni sono innumerevoli),
certo è impossibile da correggere e difficile da scrivere (nel senso devi contare il numero di zeri e uno....)


detto questo il vero problema è essere capce di usare l'assembly

[cdimauro]

Infatti il problema è con le architetture più complesse, dove passare da assembly a linguaggio macchina non è, diciamo, una passeggiata.

P.S. Sto prendendo appunti.

[tuttodigitale]

Originariamente inviato da cdimauro

Adesso mi spieghi come fa la macchina a ricevere il binario, senza passare da un compilatore ANCHE nel caso del linguaggio macchina?

mi pare che esistevano dei programmatori HW che programmavano direttamente la PROM, ma c'è anche da dire che si introduceva codice esadecimale... Quindi c'era sempre un qualcosa che traduceva....

edit
ho trovato questo:

[cdimauro]

Esatto. Come la breadboard che usavamo al triennio dell'ITIS ('87-90) che integrava un 8086 e un mini display esadecimale con annesso tastierino esadecimale, per introdurre le sequenze che componevano il programma in linguaggio macchina (scritto rigorosamente a manina su qualche quadernone, o stampato su carta se si trattava di roba più complessa).

EDIT. Ma LOL Era qualcosa di simile a quello che hai postato.

[tuttodigitale]

Originariamente inviato da cdimauro

Esatto. Come la breadboard che usavamo al triennio dell'ITIS ('87-90)

io li ho solo viste...programmavamo già a PC...sempre in esadecimalte, ma con windows, credo...

[GTKM]

Vecchi bacucchi

Io in assembly ho programmato su un emulatore del vecchio 8086 e su un microcontrollore della Atmel, ma ora mi sfugge il nome (AT90S qualcosa).

[Vi7o]

cari il mio pensiero l'ho già espresso a più riprese, e assolutamente non voglio imporlo, e molte delle risposte che potrei continuare a dare sarebbero ridondanti.
certamente non è giusto prendere singolarmente i miei commenti e dare interpretazioni a propria convenienza...

non dico assolutamente di perdere tempo, ma se rileggete tutti i miei commenti dal primo all'ultimo senza partire dal presupposto ma questo è utile o inutile, a che serve ecc...distaccandosi dalla praticità/comodità, distaccandosi anche dai computer(mi sembra di non aver utilizzato nemmeno una volta la parola "computer" al massimo "macchina",ho parlato addirittura di "lampadina")ho fatto un discorso teorico con esempi (volutamente esasperati essendo che perlopiù si parlava di un astrazione della realtà), che il buon cdimauro avrà di certo riscontrato sui testi da lui letti

scusami cdimauro ma il commento #81 non era tuo, era un altro numero?

detto questo ribadisco è stato un piacevole confronto

[cdimauro]

@Vi7o: l'81 è il mio.

Comunque di quello che hai scritto non ricordo di aver riscontrato qualcosa sul Tanenbaum, il Patterson, o qualche altro testo.

Per il resto, mi pare di capire che non hai avuto alcuna esperienza sull'argomento.

EDIT: Antonio m'ha fregato per 1 minuto.

[cdimauro]

Surreale direi che sia proprio la parola giusta.

[s-y]

ciao, una curiosita' che mi si e' rinfocolata leggendo il thread: ma i famigerati demo in assembly che qualche era geologica fa giravano su macchine di classe molto-pre-pentium (e che se non ricordo male nacquero sotto amiga) e facevano cascare la mascella, posto che fossero scritti in assembly... era una necessita' per motivi prettamente tecnici o anche ad esempio ancora non esistevano altri linguaggi utili ad ottenere lo stesso risultato?

[Vi7o]

Premesso che mi ero già ritirato da questa discussione, per educazione quindi ti rispondo spero di essere il più esaustivo possibile:

Originariamente inviato da cdimauro

Come pensi di realizzare un programma in linguaggio macchina e caricarlo in memoria?

Non mi sembra centri niente il caricamento in memoria con quanto abbiamo detto, che ovviamente avverrà per mezzo dello strumento di input previsto dalla macchina, non penso ci eravamo mai soffermati sull'IO sino ad ora.

Ciò che supponi è impossibile. Se hai programmato in linguaggio macchina e in assembly per la stessa macchina, dovresti saperlo.

Qui non ho capito la domanda

L'assembly è un linguaggio a bassissimo livello.

l'ho detto anche io a più riprese,anzi vedo che quotandomi successivamente affermo proprio questo, non penso di aver affermato il contrario da qualche altra parte

Non comprende nemmeno il linguaggio macchina se non gli piazzi il codice oggetto/binario DIRETTAMENTE in memoria.

Che io sappia il linguaggio macchina è binario o no?? anche se è un problema secondario piazzarlo in memoria visto che il risultato di LM e Assembly è lo stesso, lo faremo allo stesso modo

E' ESATTAMENTE la stessa cosa.

è inutile gridare decontestualizzando la mia affermazione: non continuate a dire che una volta compilato è la stessa cosa, perchè l'ho detto più volte che a prescindere dalla compilazione è la stessa cosa solo chè c'è un passaggio in più la compilazione attraverso l'assembler

L'unica cosa su cui concordo.

almeno una, il gol della bandiera...

Non è una macchina, ma un tool. In particolare il linguaggio assembly è, al pari di quello macchina, un linguaggio.

qui sei tu che confondi assembler(può essere vista come una macchina astratta fisica o software) con assembly(linguaggio tradotto dall'assembler in linguaggio macchina), non mi sembra di aver confuso da nessuna parte questo punto...

Già fatto, e allora? Solo perché hai messo una slide dovremmo prenderla per vera?

la slide siccome è scritta con il comic sans non l'ho creata per forza io l'ho trovata in rete e sicuramente è di qualche corso universitario, la puoi riscontrare anche sui testi... e dovrebbe esplicare la suddivisione di un elaboratore in livelli con i rispettivi linguaggi, serviva semplicemente a far capire che i livelli in cui sono disposti non sono li tanto per e diceva soprattutto livello macchina sotto livello assembly, due livelli diversi, qui però il tono che hai utilizzato mi è dispiaciuto mi dava tanto di "qualunque cosa dirai di qui in poi è una cavolata e non ti crederò nemmeno se mi dai prova che la Terra non è piatta..."

Io ho iniziato a lavorare in linguaggio macchina 6502 (quello degli home computer Commodore) nell'82 (dopo un inizio col BASIC, che però era troppo limitato), facendo uso di una opcode table (presa da poster contenuto in un numero di Commodore Computer Club, se non ricordo male), e i programmini in questo linguaggio me li facevo su carta, producendo una sfilza di sequenze esadecimali.
Queste sequenze venivano poi caricate in memoria facendo uso di programmi come quello di cui ho postato l'immagine prima.
Una volta eseguito, le sequenze esadecimali diventavano byte caricati in precise locazioni di memoria.
Infine con una SYS potevo eseguire il codice oggetto generato dai passaggi precedenti.
Questa era la prassi all'epoca, se volevi lavorare in linguaggio macchina, e non solo con le macchine Commodore se ti vai rileggere le riviste dell'epoca (di cui trovi tante scansioni online, come quella che ho riportato).
Quando finalmente ho avuto a disposizione il Commodore Plus 4, che aveva un monitor integrato (programma che consentiva di disassemblare blocchi di memoria, assemblare istruzioni, eseguire il dump di blocchi di memoria, eseguire esecuzione passo-passo, ecc. ecc.), ho potuto assaggiare la differenza fra assembly e linguaggio macchina.
Ma il risultato finale, e la velocità d'esecuzione del codice oggetto/binario prodotto, era esattamente la stessa. A fronte di uno sforzo sovrumano col linguaggio macchina.
Per cui permettimi: ho potuto provare sulla mia pelle la differenza fra le due cose, e so benissimo come si lavorava con entrambi. Di slide, dunque, non ne ho proprio bisogno: al più te le posso produrre io, sulla scorta di anni di esperienza sul campo.

Qui stai dicendo quello che io ho detto dall'inizio,
la velocità di esecuzione del codice generato è la stessa, solo che con l'assembly anche se decisamente più conveniente da parte tua facevi o meglio l'assembler faceva un passaggio in più, non ho mai detto da nessuna parte che è più bello o più figo scrivere in linguaggio macchina altrimenti non ci sarebbe stato bisogno dell'assembly
sul Tanenbaum che forse è quello che descrive meglio e in modo più marcato i livelli dell'elaboratore trovi una slide simile a quella che avevo linkato dove l'assembly si trova a Livello 4, il linguaggio macchina al Livello 3 per favore però non iniziamo a discutere riguardo i livelli inferiori ti prego...

Spero di aver risposto a tutte le domande pendenti a questo punto anche se la maggior parte erano state ampiamente trattate in post precedenti, anzi alcune era doppie già nello stesso post.

[Lonherz]

Originariamente inviato da Vi7o

...

Secondo me il punto centrale di tutta la questione è questo:

da quello che scrivi (magari mi sbaglio) sembra che tu sia convinto che il codice assembly venga compilato prima di ogni esecuzione del programma.


Quello che normalmente succede è che il codice assembly viene compilato UNA VOLTA dal computer del programmatore, che poi distribuisce "la pappa pronta" a MILIONI di utenti. QUINDI L'UTENTE CHE AVVIA IL PROGRAMMA NON DEVE MAI COMPILARE NULLA, nemmeno al primo avvio, perché ha già il codice oggetto pronto per essere eseguito!

In questo l'esempio delle due ferrari era perfettamente calzante: quale delle due ferrari è più veloce? La ferrari già costruita o quella ancora da costruire?
La velocità delle due è la stessa, l'esempio che fai tu avrebbe senso solo se la ferrari la dovesse costruire l'utente finale OGNI VOLTA che gli serve.



Poi se consideriamo la quantità di riferimento giusta il tuo ragionamento non fa una piega, mi spiego meglio:

la quantità che ti interessa non è il tempo di esecuzione del singolo programma, ma "la somma di tutti i tempi di compilazione e di esecuzione passati, presenti e futuri di un determinato programma".

Considerando questa quantità, prendiamo ad esempio un programma che in tutto il suo ciclo di vita verrà utilizzato nel mondo per un totale di 1000000000 di ore (non è tanto se pensi che ci sono programmi che vengono utilizzati a livello mondiale per 1 miliardo di ore ogni giorno, e non per tutto il ciclo di vita del programma):

a questo punto avresti questa incredibile differenza prestazionale:

- codice binario: 1000000000 di ore

- codice assembly: 1000000000 di ore più 1 secondo di compilazione (a stare larghi)

Si, considerando questa quantità hai ragione tu, il codice binario è più ""veloce"" dello 0,000000000027%




Ora, consideriamo il caso all'estremo opposto: un programma che si fa un singolo programmatore per sè stesso, e che userà poco. Ipotizziamo che nell'intero ciclo vitale di questo programma, venga utilizzato solo per 1 ora:

qui la differenza prestazionale comincia ad essere rilevante:

- codice binario: 3600 secondi

- codice assembly: 3601 secondi (a stare larghi, ma molto... dubito che un programmino fatto per essere usato un'ora in tutta la sua vita richieda più di qualche millisecondo di compilazione DALL'ASSEMBLY* )

In questo caso, il codice binario è più ""veloce"" dello 0,027%




PS: Il ragionamento che fai tu non è che non abbia MAI senso, può avere senso nel caso di programmi che vengono compilati all'inizio di ogni esecuzione (ad esempio JAVA con compilatore JIT, in cui il bytecode viene compilato prima di ogni esecuzione del programma).
Ma non ha senso invece se si parla di un normale programma compilato una sola volta.


*PPS: ho pensato solo adesso che giustamente qualcuno mi potrebbe far notare che quello per l'assembly non è nemmeno un compilatore ma un assemblatore, infinitamente più semplice e veloce

[LordPBA]

IMHO:

sono sistemi molto piu' affidabili di quelli attuali

[LordPBA]

Originariamente inviato da s-y

ciao, una curiosita' che mi si e' rinfocolata leggendo il thread: ma i famigerati demo in assembly che qualche era geologica fa giravano su macchine di classe molto-pre-pentium (e che se non ricordo male nacquero sotto amiga) e facevano cascare la mascella, posto che fossero scritti in assembly... era una necessita' per motivi prettamente tecnici o anche ad esempio ancora non esistevano altri linguaggi utili ad ottenere lo stesso risultato?

era una necessita' dato che le memorie e la potenza erano molto inferiori di adesso e per aver quei risultati dovevi "spremere" l'hardware, ovvero, programmare a basso livello, quasi a livello di linguaggio macchina. L'assembler e' molto vicino al linguaggio macchina. Ancora oggi alcune routine dove la precisione e la performance sono primarie vengono programmate in assembler. Di solito queste routine sono poi all'interno di programmi piu' ad alto livello. Un esempio: i driver HW hanno un nocciolo di assembler, di solito.

[LordPBA]

Originariamente inviato da cdimauro

@Vi7o: l'81 è il mio.

Comunque di quello che hai scritto non ricordo di aver riscontrato qualcosa sul Tanenbaum, il Patterson, o qualche altro testo.

Per il resto, mi pare di capire che non hai avuto alcuna esperienza sull'argomento.

EDIT: Antonio m'ha fregato per 1 minuto.

Cazz..oo il Tanenbaum, lo ho ancora, che ricordi che mi hai tirato fuori, la programmazione del MIPS... ahaha che tempi!

[Vi7o]

Quanto detto Lonherz era grosso modo ciò che volevo dire.

Quello in cui sono stato spesso frainteso essendo pur sempre un ragionamento per lo più teorico che può benissimo distaccarsi dalla pragmantica praticità di tutti i giorni: è che una macchina a volte può essere semplice o semplice abbastanza da non giustificare l'utilizzo di un assemblatore che deve essere implemento ad hoc per quella macchina(e di conseguenza l'assembly)...forse è questo il punto dove non sono riuscito ad essere abbastanza chiaro(anche se ho fatto numerosi esempi in questo senso).
Non ho frainteso nulla, so bene di ciò che stiamo parlando altrimenti non mi sarei cimentato nella discussione, ho semplicemente estremizzato i concetti...e questo ha creato un pò di scompiglio...poi spesso sono state lette tra le righe di quello che scrivevo cose che non affermavo...essendo stata un discussione un pò lunga capisco anche che qualche post venisse perso per strada e non tutti avevano giustamente voglia/tempo di leggersi tutta la pappardella...
Con questo mi assumo le mie responsabilità, mi scuso e me ne tiro fuori

[cdimauro]

Originariamente inviato da s-y

ciao, una curiosita' che mi si e' rinfocolata leggendo il thread: ma i famigerati demo in assembly che qualche era geologica fa giravano su macchine di classe molto-pre-pentium (e che se non ricordo male nacquero sotto amiga) e facevano cascare la mascella, posto che fossero scritti in assembly... era una necessita' per motivi prettamente tecnici o anche ad esempio ancora non esistevano altri linguaggi utili ad ottenere lo stesso risultato?

Sostanzialmente la seconda che hai detto, perché con l'assembly potevi scrivere codice molto più compatto e veloce rispetto a qualunque altro linguaggio (C incluso).

E, cosa non meno importante, potevi sfruttare in maniera precisa ogni singola locazione di memoria del sistema.

Che poi è esattamente quello che ho fatto nei giochi a cui ho lavorato per Amiga (Fightin' Spirit, pubblicato, e USA Racing, mai pubblicato): senza l'assembly non sarebbero stati possibili, a meno di rinunciare a diverse cose.

Originariamente inviato da Vi7o

Premesso che mi ero già ritirato da questa discussione, per educazione quindi ti rispondo spero di essere il più esaustivo possibile:

Non mi sembra centri niente il caricamento in memoria con quanto abbiamo detto, che ovviamente avverrà per mezzo dello strumento di input previsto dalla macchina, non penso ci eravamo mai soffermati sull'IO sino ad ora.

Avevi affermato questo prima:

"Le macchine leggono solo il Linguaggio Macchina(binario), che poi "leggono" schede perforate(in binario) o listati(in binario) o cd(in binario) o pendisk(in binario) o nastri(in binario), dipende solo dall'interfaccia di lettura della suddetta macchina

Quindi in un ipotetica macchina che ha due ingressi di lettura:
1 - linguaggio macchina
2 - assembly

nel primo caso il codice sarà letto al volo, nel secondo sarà letto in assembly e tradotto in linguaggio macchina"

Nel momento in cui affermi che la macchina può leggere il linguaggio macchina, è ovvio che si pone il problema di come sarà stato generato.

In che modo pensi di generarlo?

Qui non ho capito la domanda

Parlavi di saper programmare allo stesso costo in assembly e linguaggio, il che è assolutamente impossibile: con l'assembly lavori di gran lunga più velocemente.

Ovviamente a parità di programma da realizzare.

Che io sappia il linguaggio macchina è binario o no??

No: può essere anche ottale o esadecimale, o con un'altra base, o con un mix di basi diverse. L'importante è che venga generato il codice oggetto che ci si aspetta.

anche se è un problema secondario piazzarlo in memoria visto che il risultato di LM e Assembly è lo stesso, lo faremo allo stesso modo

Non è un problema secondario. Se la macchina, come hai detto, è in grado di comprendere solo il linguaggio macchina, e questo deve stare in memoria, ci si pone il problema di come farglielo arrivare in quelle zone di memoria.

E, prima ancora, ci si pone il problema di come generare il codice binario.

è inutile gridare decontestualizzando la mia affermazione:

Non ho gridato: ho evidenziato, per mettere in risalto.

non continuate a dire che una volta compilato è la stessa cosa, perchè l'ho detto più volte che a prescindere dalla compilazione è la stessa cosa solo chè c'è un passaggio in più la compilazione attraverso l'assembler

Idem come sopra: se, a tuo dire, col linguaggio macchina ci sarebbe un passaggio in meno, ci spiegheresti in che modo verrebbe generato il codice oggetto/binario?

Esempio pratico: devi realizzare un programmino che dati due numeri interi a 8 bit senza segno ne faccia la somma, trascurando eventuali riporti, e la visualizzi.

Per semplicità si potrebbe prendere un PC col DOS in modalità 8086, visto che il problema si risolve con una manciata di istruzioni (e, dunque, in poco tempo), ma sei libero di scegliere la piattaforma che più ti aggrada.

Giusto per essere chiari, vorrei sapere in che modo scriveresti questo programma in linguaggio macchina evitando qualunque traduzione, e ovviamente in che modo lo faresti eseguire dalla macchina.

Quest'esempio taglierà la testa al toro.

qui sei tu che confondi assembler(può essere vista come una macchina astratta fisica o software) con assembly(linguaggio tradotto dall'assembler in linguaggio macchina), non mi sembra di aver confuso da nessuna parte questo punto...

Dove mi sarei confuso? Ho scritto chiaramente che l'assembler (da te citato) è un tool.

Poi ho specificato che l'assembly (dunque NON l'assembler) è un linguaggio (che ovviamente è quello che l'assembler riconosce per poi generare il codice oggetto).

la slide siccome è scritta con il comic sans non l'ho creata per forza io l'ho trovata in rete e sicuramente è di qualche corso universitario, la puoi riscontrare anche sui testi... e dovrebbe esplicare la suddivisione di un elaboratore in livelli con i rispettivi linguaggi, serviva semplicemente a far capire che i livelli in cui sono disposti non sono li tanto per e diceva soprattutto livello macchina sotto livello assembly, due livelli diversi,

E quindi solo per questo dovremmo essere d'accordo col contenuto?

Io non lo sono per le motivazioni che ho già ampiamente riportato.

qui però il tono che hai utilizzato mi è dispiaciuto mi dava tanto di "qualunque cosa dirai di qui in poi è una cavolata e non ti crederò nemmeno se mi dai prova che la Terra non è piatta..."

No, semmai dovresti porti il problema che non è che se una cosa la trovi su internet sia necessariamente vera. Questo anche nei corsi universitari, perché il docente potrebbe sbagliare. E magari uno studente potrebbe pure correggerlo...

Qui stai dicendo quello che io ho detto dall'inizio,
la velocità di esecuzione del codice generato è la stessa, solo che con l'assembly anche se decisamente più conveniente da parte tua facevi o meglio l'assembler faceva un passaggio in più, non ho mai detto da nessuna parte che è più bello o più figo scrivere in linguaggio macchina altrimenti non ci sarebbe stato bisogno dell'assembly

Il nocciolo della questione è che il passaggio serve anche col linguaggio macchina. Vedi sopra l'esempio.

sul Tanenbaum che forse è quello che descrive meglio e in modo più marcato i livelli dell'elaboratore trovi una slide simile a quella che avevo linkato dove l'assembly si trova a Livello 4, il linguaggio macchina al Livello 3 per favore però non iniziamo a discutere riguardo i livelli inferiori ti prego...

Non c'è bisogno, perché quei livelli riguarderanno sicuramente l'astrazione, che è un'altra cosa.

Che la macchina capisca e possa eseguire soltanto certe sfilze di uni e zeri è pacifico.

Il punto, però, è che col linguaggio macchina io posso scrivere codice ponendomi al suo stesso livello d'astrazione.

Solo che dovrà farglielo avere in qualche modo, e per questo motivo servirà sempre un "passaggio", come dici tu, esattamente come con tutti gli altri linguaggi (leggi: serve sempre un "traduttore" che generi l'apposito codice oggetto).

Spero di aver risposto a tutte le domande pendenti a questo punto anche se la maggior parte erano state ampiamente trattate in post precedenti, anzi alcune era doppie già nello stesso post.

Idem. E speriamo di aver chiarito tutto finalmente.

Originariamente inviato da Lonherz

*PPS: ho pensato solo adesso che giustamente qualcuno mi potrebbe far notare che quello per l'assembly non è nemmeno un compilatore ma un assemblatore, infinitamente più semplice e veloce

Si tratta di una sottigliezza: definizione alla mano, un assemblatore è comunque un compilatore.

Originariamente inviato da LordPBA

Cazz..oo il Tanenbaum, lo ho ancora, che ricordi che mi hai tirato fuori, la programmazione del MIPS... ahaha che tempi!

Meglio il 68000: i MIPS sono troppo semplici.