View Full Version : Compilatore e programmi, chi?
In questi giorni, veniva rispiegato il funzionamento di un compilatore.
Vi riporto una frase del professore: "Il compilatore non è altro che un programma che 'trasforma' il linguaggio di alto livello in linguaggio macchina, dando vita ( dopo una serie di altri passaggi - file *.obj e linker ) ad un programma, l'eseguibile"
Ora... Se il compilatore è parte di ciò che da vita ad un programma... E il compilatore è un programma... Chi/cosa ( quale entità??? :confused: ) ha compilato il codice che dava vita al compilatore?
Se è un mistero della fede ( informatica ), avvertitemi :Prrr:
In questi giorni, veniva rispiegato il funzionamento di un compilatore.
Vi riporto una frase del professore: "Il compilatore non è altro che un programma che 'trasforma' il linguaggio di alto livello in linguaggio macchina, dando vita ( dopo una serie di altri passaggi - file *.obj e linker ) ad un programma, l'eseguibile"
Ora... Se il compilatore è parte di ciò che da vita ad un programma... E il compilatore è un programma... Chi/cosa ( quale entità??? :confused: ) ha compilato il codice che dava vita al compilatore?
Se è un mistero della fede ( informatica ), avvertitemi :Prrr:
Jobs :D
Jobs :D
Però vero che ho ragione? Cioè... C'è qualcosa di losco... O comunque manca un pezzo di storia in tutto questo... :stordita:
Avanti, a nessun ( a cui sia stato spiegato il funzionamento di un compilatore ) è mai venuto in mente questo ragionamento?
Ha mai trovato risposte scientifiche?
Però vero che ho ragione? Cioè... C'è qualcosa di losco... O comunque manca un pezzo di storia in tutto questo... :stordita:
Avanti, a nessun ( a cui sia stato spiegato il funzionamento di un compilatore ) è mai venuto in mente questo ragionamento?
Ha mai trovato risposte scientifiche?
Per la serie: "è nato prima l 'uovo o la gallina?".
Quando facevo l'UNI mi ero posto questo quesito: coma diavolo sono nati i programmi? E i compilatori? E . e. e. ?
Beh la risposta sta in una dolcissima fanciulla che a manina scrisse il primo compilatore direttamente dal linguaggio binario (re-implementando il lavoro che fece Ada Lovelace qualche decennio prima... anzi, nel secolo prima :P).
Ahhh chi se la ricorda? :D Grace Hopper (http://it.wikipedia.org/wiki/Grace_Hopper)! Era lei, ne? ;)
Io ho terribili vuoti di memoria! :|
Ma ha scritto un compilatore a suon di 1 e 0 oppure in Assembly?
Ma ha scritto un compilatore a suon di 1 e 0 oppure in Assembly?
Da quel che ricordo io la prima versione a suon di bit.
Poi il primo vero compilatore in ASM fu per Lisp, però magari ricordo male.
Sono passati tanti anni (e io manco c'ero :D)
Da quel che ricordo io la prima versione a suon di bit.
Poi il primo vero compilatore in ASM fu per Lisp, però magari ricordo male.
Sono passati tanti anni (e io manco c'ero :D)
Tutto ciò è, passatemi il termine, fottutamente nerd...
Cioè ma come cacchio fai a fare un programma scrivendo 1 e 0 , cioè diventi scemo!!
Ma seriamente è stata la signora da te linkata?
banryu79
12-10-2010, 10:52
[OT]
Ma soprattutto notate come sia appannaggio esclusivo del mondo femminile il vero potere delle creazione. :D
Altro che sesso debole. :D
tomminno
12-10-2010, 10:52
Un nuovo compilatore per il linguaggio X lo puoi scrivere tramite le tecniche di bootstrapping, ovvero nei seguenti modi:
1)Nel linguaggio Y già esistente per la piattaforma
2)Tramite l'interprete del linguaggio X già scritto per la piattaforma (Lisp '62)
3)Cross compilando, ovvero utilizzando il compilatore X già esistente su un'altra piattaforma (esempio gcc puoi scrivere software per ARM da una macchina X86)
Ci sono linguaggi self-hosted ovvero che possono compilare se stessi
Tutto ciò è, passatemi il termine, fottutamente nerd...
Cioè ma come cacchio fai a fare un programma scrivendo 1 e 0 , cioè diventi scemo!!
Ma seriamente è stata la signora da te linkata?
Da quel che ricordo degli studi universitari si.
Ovviamente non ha fatto tutto da sola povera crista :D
[OT]
Ma soprattutto notate come sia appannaggio esclusivo del mondo femminile il vero potere delle creazione. :D
Altro che sesso debole. :D
Si... Alla fine si rimane sempre gabbati... Mannaggia :muro:
Un nuovo compilatore per il linguaggio X lo puoi scrivere tramite le tecniche di bootstrapping, ovvero nei seguenti modi:
1)Nel linguaggio Y già esistente per la piattaforma
2)Tramite l'interprete del linguaggio X già scritto per la piattaforma (Lisp '62)
3)Cross compilando, ovvero utilizzando il compilatore X già esistente su un'altra piattaforma (esempio gcc puoi scrivere software per ARM da una macchina X86)
Ci sono linguaggi self-hosted ovvero che possono compilare se stessi
Si questo è un discorso più tecnico, che credo, ai tempi dei primi ammassi hardware, non si applicassero perchè non c'erano tutti i linguaggi di programmazione di ora.
Quindi la prima va esclusa, perchè linguaggi immagino non c'è ne fossero...
La due uguale...
La tre pure!! Il compilatore non esiste!!
Quindi... Che dire... Mi sa che dojolab c'ha azzeccato... Certo però che è una cosa da fuoriditesta. È chiaro però che senza questi personaggi probabilmente non saremmo qui a scrivere, magari tutto ciò non esisterebbe nemmeno.
Quindi... Che dire... Mi sa che dojolab c'ha azzeccato... Certo però che è una cosa da fuoriditesta. È chiaro però che senza questi personaggi probabilmente non saremmo qui a scrivere, magari tutto ciò non esisterebbe nemmeno.
Cosa ho vinto? :D
Aspetto magari chi si ricorda meglio di me, in pausa mi vado a rileggere gli appunti/libro di storia dell'informatica del primo anno in uni :)
tomminno
12-10-2010, 11:16
Quindi... Che dire... Mi sa che dojolab c'ha azzeccato... Certo però che è una cosa da fuoriditesta. È chiaro però che senza questi personaggi probabilmente non saremmo qui a scrivere, magari tutto ciò non esisterebbe nemmeno.
Scusa ma non penserai mica che un compilatore degli anni 50 fosse complesso come uno di oggi?
All'epoca esistevano ancora le schede perforate figurati il poter modificare un programma senza dover andare di saldatore o di incisione di stampati era sicuramente una conquista straordinaria, anche se dovevi scrivere tutto in linguaggio macchina.
E comunque la domanda la potresti girare anche per il sistema operativo, che non è altro che un (IL) programma anche lui. Ma un compilatore senza sistema operativo non può funzionare. Quindi il sistema operativo necessita di essere compilato, ma il compilatore necessita di sistema operativo. Come risolvi?
Scusa ma non penserai mica che un compilatore degli anni 50 fosse complesso come uno di oggi?
All'epoca esistevano ancora le schede perforate figurati il poter modificare un programma senza dover andare di saldatore o di incisione di stampati era sicuramente una conquista straordinaria, anche se dovevi scrivere tutto in linguaggio macchina.
Vero, infatti alcune delle principali conoscenze Informatiche/Matematiche, in merito anche ad algoritmi, hanno qualche migliaio di anno.
Già nel '600 (Pascal) e successivamente nel 700/800 comparivano le prime macchine 'automatiche' che 'elaboravano' informazioni; ovviamente NON in digitale.
E comunque la domanda la potresti girare anche per il sistema operativo, che non è altro che un (IL) programma anche lui. Ma un compilatore senza sistema operativo non può funzionare. Quindi il sistema operativo necessita di essere compilato, ma il compilatore necessita di sistema operativo. Come risolvi?
No. Non necessariamente.
Un programma consiste in un INPUT dato ad un calcolatore e un OUTPUT ottenuto da esso. Fine.
Un compilatore può generare qualsiasi eseguibile senza dipendere da un sistema operativo; poi ci sono sistemi operativi non compilati. :)
tomminno
12-10-2010, 11:41
Un compilatore può generare qualsiasi eseguibile senza dipendere da un sistema operativo;
Certo quindi il compilatore deve essere in grado di avviare la macchina durante il boot, gestire la memoria virtuale e i dispositivi di archiviazione, quale compilatore non fa tutto questo? ;)
poi ci sono sistemi operativi non compilati. :)
Tutti quelli che conosco io di una qualche utilità pratica sono almeno scritti in C ;) (oppure sono talmente minimali da non essere considerabili dei sistemi operativi con l'accezione del termine odierno) e comunque è la stessa cosa che pensare ad un compilatore non compilato non ti pare?
Oggi comunque non è più un problema, non si riparte mai da 0, al massimo si cross compila in C :D
goldorak
12-10-2010, 12:04
Scusa ma non penserai mica che un compilatore degli anni 50 fosse complesso come uno di oggi?
All'epoca esistevano ancora le schede perforate figurati il poter modificare un programma senza dover andare di saldatore o di incisione di stampati era sicuramente una conquista straordinaria, anche se dovevi scrivere tutto in linguaggio macchina.
E comunque la domanda la potresti girare anche per il sistema operativo, che non è altro che un (IL) programma anche lui. Ma un compilatore senza sistema operativo non può funzionare. Quindi il sistema operativo necessita di essere compilato, ma il compilatore necessita di sistema operativo. Come risolvi?
Beh fermiamoci un momento. Non confondere il meccanismo di input (schede perforate) con il linguaggio. Il Fortran e' stato il primo linguaggio di alto livello, ed il primo ad avere un compilatore. Il lavoro per produrre quel compilatore, costo' un rene (anzi quasi 2) alla IBM che ne finanzio' lo sviluppo.
Fu un impresa a dir poco titanica. Anni 50 eh anni 50.
Oggi a confronto far un compilatore e' molto piu' semplice pur mantenendo tutti i distinguo del caso.
Certo quindi il compilatore deve essere in grado di avviare la macchina durante il boot, gestire la memoria virtuale e i dispositivi di archiviazione, quale compilatore non fa tutto questo? ;)
Stai parlando di compilatori moderni. Un compilatore di per sé può essere un qualsiasi programma che trasforma un codice sorgente in codice macchina.
Il concetto di sistema operativo è separato. Gli antichi computer anni '50 avevano l'input chessò, a schede perforate, e lo stesso output, nisba per tutto il resto.
In generale, i compilatore e i programmi per computer si sono evoluti nel tempo, e da un compilatore banale si è andati man mano verso compilatori più evoluti.
Il primo compilatore sarà stato scritto in codice macchina; a un certo punto, non appena un compilatore è diventato self-hosting, magari le versioni successive saranno diventate dipendenti da una versione precedente per compilarlo.
Ti faccio un esempio con GCC: immagino che GCC 4.5, che è un programma anch'esso, richieda GCC 4.4 per essere compilato, e GCC 4.6 richiederà GCC 4.5.
Ma in passato probabilmente la prima versione di GCC sarà stata a sua volta compilata con un'altro dei compilatori esistenti.
Prendi anche l'esempio di Go!, www.golang.org . Essendo la prima versione la toolchain è scritta in C per questioni di bootstrap, ma non è da escludere che il compilatore Go! 2.0 possa richiedere un compilatore 1.0 per essere compilata a sua volta.
Prendi anche l'esempio di Go!, www.golang.org . Essendo la prima versione la toolchain è scritta in C per questioni di bootstrap, ma non è da escludere che il compilatore Go! 2.0 possa richiedere un compilatore 1.0 per essere compilata a sua volta.
Mmh... mi sa che per Go è una questione differente, perchè non è nativo e la sua VM non potrà mai essere scritta in Go, o mi sbaglio?
Al massimo puoi scrivere una VM Go che gira Go, ma quella girerà sempre su una VM C, tipo PyPy (di cui continua a sfuggirmi lo scopo :D ).
Cmq quella del topic è una domanda che mi ha sempre confuso, ringrazio il prof di Calcolatori per avere indirettamente risposto :asd:
Certo quindi il compilatore deve essere in grado di avviare la macchina durante il boot, gestire la memoria virtuale e i dispositivi di archiviazione, quale compilatore non fa tutto questo? ;)
No perché non è compito del compilatore.
Rileggi bene ciò che ho scritto.
Tutti quelli che conosco io di una qualche utilità pratica sono almeno scritti in C ;) (oppure sono talmente minimali da non essere considerabili dei sistemi operativi con l'accezione del termine odierno) e comunque è la stessa cosa che pensare ad un compilatore non compilato non ti pare?
Non si parla dell'utilità pratica; esistono e sono esistiti.
Poi che sono utili o inutili è un altro paio di maniche :D
tomminno
12-10-2010, 12:23
Stai parlando di compilatori moderni. Un compilatore di per sé può essere un qualsiasi programma che trasforma un codice sorgente in codice macchina.
La mia era in risposta all'affermazione che un compilatore può essere indipendente dal sistema operativo.
Se ne è indipendente significa che deve svolgerne le funzioni altrimenti non utilizzi la macchina e quindi il compilatore stesso.
Puoi si può anche filosofeggiare su programmi astratti che girano su macchine di Turing.
Ti faccio un esempio con GCC: immagino che GCC 4.5, che è un programma anch'esso, richieda GCC 4.4 per essere compilato, e GCC 4.6 richiederà GCC 4.5.
gcc si autocompila: gcc 4.5 compila i sorgenti di se stesso :D
tomminno
12-10-2010, 12:25
No perché non è compito del compilatore.
Rileggi bene ciò che ho scritto.
Devo aver interpretato male la tua affermazione:
Un compilatore può generare qualsiasi eseguibile senza dipendere da un sistema operativo;
Io l'ho intesa come il compilatore ha vita propria anche senza un sistema operativo. Cosa intendevi esattamente con "senza dipendere"?
La mia era in risposta all'affermazione che un compilatore può essere indipendente dal sistema operativo.
Se ne è indipendente significa che deve svolgerne le funzioni altrimenti non utilizzi la macchina e quindi il compilatore stesso.
Sempre se supponi che ci sia un sistema operativo nel senso moderno del termine. Non sarei sicuro che la macchina su cui è stato creato il primo compilatore, quello di Grace Hopper di cui si parla sopra, ce l'avesse. Se devi gestire soltanto uno stream di input e uno di output non hai bisogno di un OS
gcc si autocompila: gcc 4.5 compila i sorgenti di se stesso :D
gcc 4.5.x probabilmente può autocompilarsi. Ma indubbiamente la prima release (4.5.alpha1?) sarà stata compilata con gcc 4.4, perché non esisteva prima alcuna build del 4.5.
E immagino pure che finché non è arrivato a stabilizzarsi almeno con il 4.5.0 non siano state rilasciate versioni autocompilate, per il rischio di inserire dei bug "ciclici".
Devo aver interpretato male la tua affermazione:
Io l'ho intesa come il compilatore ha vita propria anche senza un sistema operativo. Cosa intendevi esattamente con "senza dipendere"?
Tranquillo, forse non mi sono espresso benissimo io.
Intendevo dire che un compilatore deve poter produrre codice eseguibile indipendentemente dal Sistema Operativo, ovvero non deve dipendere dal Sistema Operativo che lo 'esegue'/ospita.
banryu79
12-10-2010, 13:04
Tranquillo, forse non mi sono espresso benissimo io.
Intendevo dire che un compilatore deve poter produrre codice eseguibile indipendentemente dal Sistema Operativo, ovvero non deve dipendere dal Sistema Operativo che lo 'esegue'/ospita.
Suppongo che tu voglia dire che un compilatore deve essere "agnostico" rispetto ad uno specifico Sistema Operativo, è corretto?
Suppongo che tu voglia dire che un compilatore deve essere "agnostico" rispetto ad uno specifico Sistema Operativo, è corretto?
Non proprio. Quello è scontato (almeno, penso lo sia); quello che intendevo dire è che un compilatore deve essere 'indipendente' dal Sistema Operativo. Giustamente come dici tu deve non interessare la struttura ai suoi piedi (OS) ma deve poter produrre codice eseguibile su qualsiasi OS.
Concetto astratto, se non mi sono espresso bene ci riprovo :P
Perdonatemi :D :D
banryu79
12-10-2010, 13:15
Boh, passo, non ho capito cosa stai dicendo, ma è molto probabile che ciò sia dovuto alla mia ignoranza circa l'argomento "compilatore", non ne so molto infatti, ma cercavo lo stesso di seguire il thread.
tomminno
12-10-2010, 13:48
Non proprio. Quello è scontato (almeno, penso lo sia); quello che intendevo dire è che un compilatore deve essere 'indipendente' dal Sistema Operativo. Giustamente come dici tu deve non interessare la struttura ai suoi piedi (OS) ma deve poter produrre codice eseguibile su qualsiasi OS.
Beh è un pò difficile visto che se un codice è eseguibile lo decide il sistema operativo.
Altrimenti potresti prendere quanto ottenuto da gcc su linux cercare di eseguirlo su Windows e aspettarti che questo funzioni.
Beh è un pò difficile visto che se un codice è eseguibile lo decide il sistema operativo.
Quello che intendo dire è che un compilatore deve fare il suo lavoro, semplice e pulito (lettura sorgente -> ecc... -> eseguibile) indipendentemente dalla piattaforma e dall'OS (librerie di sistema, ecc.).
Altrimenti potresti prendere quanto ottenuto da gcc su linux cercare di eseguirlo su Windows e aspettarti che questo funzioni.
Teoricamente con la cross-compilazione questo è possibile. :P
Certo quindi il compilatore deve essere in grado di avviare la macchina durante il boot, gestire la memoria virtuale e i dispositivi di archiviazione, quale compilatore non fa tutto questo? ;)
Non capisco il problema. La parte piu' rognosa e' il boot, dove magari ti serve un po' di assembler. Il resto lo scrivi come codice aggiuntivo nel linguaggio stesso. E' l'approccio di molti sistemi forth che con una manciata di assembler riescono avviare il compilatore/interprete e poi a caricare tutto il resto nel linguaggio stesso.
Cosa ho vinto? :D
Aspetto magari chi si ricorda meglio di me, in pausa mi vado a rileggere gli appunti/libro di storia dell'informatica del primo anno in uni :)
Vinto niente... Però se complimenti perchè è un problema che mi assaliva da più di un anno!
Scusa ma non penserai mica che un compilatore degli anni 50 fosse complesso come uno di oggi?
No, ovviamente no. Però se con due valori ( 1 e 0 ) devo scrivere qualcosa è più difficile ( e lungo ) da fare rispetto a farlo avendo un alfabeto intero ( 21 lettere ) e numeri in base dieci ( 0 - 9 ).
E comunque la domanda la potresti girare anche per il sistema operativo, che non è altro che un (IL) programma anche lui. Ma un compilatore senza sistema operativo non può funzionare. Quindi il sistema operativo necessita di essere compilato, ma il compilatore necessita di sistema operativo. Come risolvi? Giusto, giusto, non ci avevo pensato...
Però forse, come avete detto, agli inizi non esistendo il concetto di sistema operativo, i programmi giravano e basta no? Nel senso, il sistema operativo è stato poi un modo per 'standardizzare' gli eseguibili...
pabloski
12-10-2010, 18:32
ragassuoli state sempre ragionando con la mentalità tipica del ventunesimo secolo
dojolab ha ragione perchè i compilatori sono nati su schede perforate e lì i sistemi operativi non esistevano, ma non esistevano nemmeno tutte le diavolerie dell'hardware moderno
diamine, ai tempi del dos ( quindi non parlo di 100 anni fa ) avevamo wordprocessor pieni zeppi di driver per le stampanti
i primi compilatori erano ovviamente programmi che pilotavano direttamente l'hardware e quindi un sistema operativo non gli serviva
chiaramente oggi è impossibile perchè un compilatore non può ( e nemmeno è affar suo ) gestire periferiche, bootstrap della macchina, memoria virtuale, ecc...
rеpne scasb
13-10-2010, 16:37
■
Interrovativo gia' affrontato in questo stesso forum:
http://www.hwupgrade.it/forum/showthread.php?t=1403623
Si però questo thread puntava più a scovare chi ha inventanto tutto ciò!
In questi giorni, veniva rispiegato il funzionamento di un compilatore.
Vi riporto una frase del professore: "Il compilatore non è altro che un programma che 'trasforma' il linguaggio di alto livello in linguaggio macchina, dando vita ( dopo una serie di altri passaggi - file *.obj e linker ) ad un programma, l'eseguibile"
Ora... Se il compilatore è parte di ciò che da vita ad un programma... E il compilatore è un programma... Chi/cosa ( quale entità??? :confused: ) ha compilato il codice che dava vita al compilatore?
Se è un mistero della fede ( informatica ), avvertitemi :Prrr:
Quando scrivi un compilatore a tutti gli effetti crei un linguaggio di programmazione. Tale compilatore viene scritto ovviamente con un'altro linguaggio, in quanto quello che vuoi creare ancora non esiste. Poi, una volta creato il compilatore partendo da un'altro linguaggio, si può riscrivere il compilatore con il nuovo linguaggio appena creato. Questa seconda fase non è strettamente necessaria e comunque il poterlo fare o meno dipende dalla "potenza" del linguaggio.
Ad esempio, puoi scriverti un compilatore C con codice C. Oppure un compilatore per un linguaggio pippo partendo dal linguaggio C. Poi riscrivi il compilatore con il linguaggio pippo, che a questo punto hai a disposizione.
Beh si, però qua la storia si fa molto complicata perchè:
1. Chi stabilisce e come quanto un linguaggio è ( o sarà se lo stiamo creando ) potente?
2. Siccome presuppongo che all'inizio degli inizi non ci fosse niente, immagino che il primo compilatore ( e quindi il primo linguaggio ) sia stato scritto in linguaggio macchina...
rеpne scasb
13-10-2010, 19:28
■
Bene, però il link di wikipedia, in cui si parla del problema uovo/gallina propone delle soluzioni che, se ho ben capito, fanno uso di qualcosa già esistente.
A me ora pare di capire che l'unico modo per fare un compilatore partendo da zero sia di scriverlo in linguaggio macchina. Riscriverlo nel linguaggio per cui lo si è scritto, e ricompilarlo. Andando avanti finchè non si ottiene un codice abbastanza ottimizzato.
Ci siamo?
banryu79
13-10-2010, 22:41
A me ora pare di capire che l'unico modo per fare un compilatore partendo da zero sia di scriverlo in linguaggio macchina. Riscriverlo nel linguaggio per cui lo si è scritto, e ricompilarlo. Andando avanti finchè non si ottiene un codice abbastanza ottimizzato.
Ci siamo?
No, non ci siamo.
Non è strettamente neccessario implementare il primo compilatore per un nuovo linguaggio con il linguaggio macchina; è sufficiente scegliere un linguaggio preesistente adatto allo scopo.
Vuoi creare il nuovo linguaggio X
Se, ad esempio, sei in un era-informatica in cui esiste solo linguaggio macchina e linguaggio assembly, userai uno di questi due, probabilmente l'assembly.
1) Scrivi il compilatore per X in linguaggio assembly, lo compili con l'assembler, e hai l'eseguibile del primo compilatore per il linguaggio X.
2) A questo punto, in teoria potresti riscrivere il compilatore per X in linguaggio X, lo compili con il compilatore che hai ottenuto al punto 1) e hai l'eseguibile del compilatore per X scritto con X stesso.
Vuoi creare il nuovo linguaggio Y
Sei in un era-informatica in cui esiste linguaggio macchina, linguaggio assembly, e linguaggio C? Probabilmente scegliere il C per scrivere il primo compilatore per il nuovo linguaggio è una buona scelta.
Vuoi creare il nuovo linguaggio Z
Sei in un era-informatica in cui esiste solo il linguaggio macchina.
Indovina che fai?
Beh si, però qua la storia si fa molto complicata perchè:
1. Chi stabilisce e come quanto un linguaggio è ( o sarà se lo stiamo creando ) potente?
Dipende dalla grammatica del linguaggio, ed in particolare dalla classe a cui questa appartiene.
Se per potente intendiamo (come dovrebbe essere) la classe di problemi che puoi risolvere con esso.
2. Siccome presuppongo che all'inizio degli inizi non ci fosse niente, immagino che il primo compilatore ( e quindi il primo linguaggio ) sia stato scritto in linguaggio macchina...
L'assembly è stato inventato appositamente per semplificare la vita a chi all'epoca ragionava con 0 e 1 (a livello teorico la corrispondenza è 1:1, ma con la complessità raggiunta dai moderni processori non lo è di sicuro).
Di lì poi sicuramente il primo compilatore sarà stato scritto in assembly e così via...
goldorak
14-10-2010, 00:44
Beh si, però qua la storia si fa molto complicata perchè:
1. Chi stabilisce e come quanto un linguaggio è ( o sarà se lo stiamo creando ) potente?
Esistono grosso modo due classi di linguaggi (ai fini pratici), quelli cosidetti Turing completi e quelli che non lo sono. I linguaggi di programmazione normali ricadono nella prima categoria. Linguaggi come quelli per esprimere per esempio espressioni regolari sono linguaggi che stanno nella seconda categoria. E questi linguaggi non hanno la potenza espressiva di quelli Turing completi.
Un linguaggio Turing completo non dev'essere necessariamente complicato, basta guardare a Brain Fuck (http://en.wikipedia.org/wiki/Brainfuck).
E un linguaggio che e' tanto potente quanto il C o il C++ o Java etc... ma dal punto di vista semantico e' quasi a livello assembler per non dire peggio.
2. Siccome presuppongo che all'inizio degli inizi non ci fosse niente, immagino che il primo compilatore ( e quindi il primo linguaggio ) sia stato scritto in linguaggio macchina...
Beh si. I linguaggi non sono altro che astrazioni. Si costruiscono su astrazioni di livello inferiore e cosi' via. Ma non e' un ciclo infinito visto che alla fine raggiungi comunque l'hardware. Storicamente pero' l'evoluzione dei linguaggi e' andata in senso contrario, si e' partiti dal hardware per poi costruire a poco a poco astrazioni verso l'alto. Una volta che hai costruito un linguaggio ad esempio il Fortran, ci puoi costruire sopra altri linguaggi, e poi passare da un linguaggio all'altro senza dover andare a toccare l'hardware.
cdimauro
14-10-2010, 05:55
L'assembly è stato inventato appositamente per semplificare la vita a chi all'epoca ragionava con 0 e 1 (a livello teorico la corrispondenza è 1:1, ma con la complessità raggiunta dai moderni processori non lo è di sicuro).
Di lì poi sicuramente il primo compilatore sarà stato scritto in assembly e così via...
Anche l'assembly richiedeva un compilatore, che... sarà stato scritto in linguaggio macchina. :fagiano:
Un linguaggio Turing completo non dev'essere necessariamente complicato, basta guardare a Brain Fuck (http://en.wikipedia.org/wiki/Brainfuck).
E un linguaggio che e' tanto potente quanto il C o il C++ o Java etc... ma dal punto di vista semantico e' quasi a livello assembler per non dire peggio.
Preferisco di gran lunga l'assembly a BrainFuck.
Di recente ho rispolverato l'assembly 68000+ andando a ripescare i miei vecchi progetti per Amiga e... amore, amore, amore. Non lo si può dimenticare, ma soprattutto non apprezzare. :p
Beh si. I linguaggi non sono altro che astrazioni. Si costruiscono su astrazioni di livello inferiore e cosi' via. Ma non e' un ciclo infinito visto che alla fine raggiungi comunque l'hardware. Storicamente pero' l'evoluzione dei linguaggi e' andata in senso contrario, si e' partiti dal hardware per poi costruire a poco a poco astrazioni verso l'alto. Una volta che hai costruito un linguaggio ad esempio il Fortran, ci puoi costruire sopra altri linguaggi, e poi passare da un linguaggio all'altro senza dover andare a toccare l'hardware.
Esattamente. Ed è normale avere un problema di "bootstrap", per un dato linguaggio. Fatta eccezione per il primo della catena, che è quello macchina (da qualcosa si dovrà pur partire).
Anche l'assembly richiedeva un compilatore, che... sarà stato scritto in linguaggio macchina. :fagiano: È questo che sto cercando di dire che solo tu hai afferrato. Cioè noi siamo partiti dal non avere niente, ne linguaggi di programmazione, ne compilatori, e in linguaggio macchina abbiamo creato un compilatore per qualcosa...
Preferisco di gran lunga l'assembly a BrainFuck. :asd: Certo che a girare nella sezione linguaggi di wikipedia se ne trovano alcuni che fan ridere...
Immagino che questo, come molti altri, sia stato inventato per 'divertimento'
tomminno
14-10-2010, 08:22
È questo che sto cercando di dire che solo tu hai afferrato. Cioè noi siamo partiti dal non avere niente, ne linguaggi di programmazione, ne compilatori, e in linguaggio macchina abbiamo creato un compilatore per qualcosa...
Appunto non mi sembra ci sia nessun "mistero della fede" come ironicamente ipotizzavi nel post di apertura. ;)
La tua domanda originale:
Chi/cosa ( quale entità??? ) ha compilato il codice che dava vita al compilatore?
ha avuto ampie ed esaurienti risposte.
rеpne scasb
14-10-2010, 08:57
■
Vincenzo1968
15-10-2010, 08:46
edit
Appunto non mi sembra ci sia nessun "mistero della fede" come ironicamente ipotizzavi nel post di apertura. ;)
La tua domanda originale:
ha avuto ampie ed esaurienti risposte.
Si ma all'inizio del post che ne sapevo che qualcuno s'era messo a scrivere in binario un compilatore... :p
Ma ha scritto un compilatore a suon di 1 e 0 oppure in Assembly?
non è che cambi più di tanto tra scrivere in assembly o direttamente in binario c'è una corrispondenza biunivoca :D
cmq mettila così in compilatori sono programmi che dato un insieme di istruzioni (in forma testuale o grafica) trasformano tale insieme di istruzioni (in un linguaggio facilmente comprensibile dall'uomo) in una sequenza bit comprensibili dalla macchina
i compilatori sono nati dopo l'informatica, i primi progranmmi venivano scritti direttamente in linguaggio macchina (1/0) dopo di questo si è pensto di dare un nome e una struttura alle istruzioni di linguaggio macchina (assembly) e a seguire sono nati i linguaggi di programmazione ad alto livello che permettono di semplificare il lavoro aumentando il numero di istruzioni (es i primi processori non avevano neanche la moltiplicazione e la divisione in hardware e quindi andavano programmate in assembly mediante cicli di somme / sottrazioni.
tomminno
15-10-2010, 14:44
non è che cambi più di tanto tra scrivere in assembly o direttamente in binario c'è una corrispondenza biunivoca :D
Eh insomma MOV in Assembly rimane sempre MOV, ma in binario ha codici differenti a seconda del contesto in cui viene utilizzato.
Non è certamente biunivoca la relazione.
Eh insomma MOV in Assembly rimane sempre MOV, ma in binario ha codici differenti a seconda del contesto in cui viene utilizzato.
Non è certamente biunivoca la relazione.
Penso intenda dire che ad un'istruzione assembly corrisponda un'istruzione binaria. Se è pur vero che il mov d'assembly può essere diverso in binario, sempre però di spostamento di indirizzo ( perchè questo è ciò che penso faccia ) stiamo parlando...
cmq mettila così in compilatori sono programmi che dato un insieme di istruzioni (in forma testuale o grafica) trasformano tale insieme di istruzioni (in un linguaggio facilmente comprensibile dall'uomo) in una sequenza bit comprensibili dalla macchina SI quello che fanno i compilatori lo so, mi è stato spiegato. Era appunto dopo questa spiegazione che mi è nato il dubbio, e penso che generalmente nasca a tutti...
Eh insomma MOV in Assembly rimane sempre MOV, ma in binario ha codici differenti a seconda del contesto in cui viene utilizzato.
Non è certamente biunivoca la relazione.
un mov ha sempre lo stesso opcode qualunque siano i parametri
e l'istruzione parametrizzata in un dato modo ha sempre lo stesso binario
forse non mi sono spiegato bene ma intendevo proprio questo
cdimauro
15-10-2010, 16:58
Ha ragione tomminno. La corrispondenza fra mnemonico assembly e opcode in linguaggio macchina non è biunivoca, ma dipende dall'architettura.
Esempio: XCHG EAX,EBX in x86 la posso scrivere in almeno due modi (senza contare l'uso di prefissi) in linguaggio macchina (sono proprio due opcode diversi). ;)
rеpne scasb
15-10-2010, 18:43
■
Salve.
Ho trovato oggi questo thread, mi permetto di fare un po' di riassunto basato sulle mie esperienze di retrocomputing :)
- Come sapete, all'inizio c'era il caos: per modificare il programma si modificava la struttura hardware (ENIAC), quindi la descrizione del programma era uno schema elettrico (più o meno);
- Poi si è passati all'architettura di Von Neumann, e quindi si è passati dallo schema elettrico all'assembly: paradossalmente, l'assembly è nato prima degli assemblatori: i programmatori scrivevano in assembly, poi traducevano a mano i listati in codice binario e lo inserivano nella macchina tramite toggle-switches o schede perforate;
- Ad un certo punto, qualcuno scrisse il primo assemblatore: un programma che prendeva direttamente l'assembly e lo trasformava in codice eseguibile;
- Quindi si passò a scrivere compilatori per linguaggi più "alti", sicuramente usando i precedenti assemblatori;
- E usando i compilatori, come già detto, si crearono compilatori migliori ecc...
è d'obbligo dire che, come già emerso in altri post, molte volte il compilatore/assemblatore veniva avviato senza un OS sotto, ma controllando direttamente tutta la macchina: quando aveva finito la compilazione e scritto su schede perforate, il compilatore veniva scaricato e il nuovo prog veniva caricato ed eseguito.
Segnalo questo video che mostro perfettamente come si lavorava (in questo caso, su un computer Honeywell):
http://www.youtube.com/watch?v=hxVbRz6udmI
Segnalo questo video che mostro perfettamente come si lavorava (in questo caso, su un computer Honeywell):
http://www.youtube.com/watch?v=hxVbRz6udmI
Questo video mi fa ridere... Ma in senso buono... Cioè... se ho ben capito dal video, il compilatore non è altro che del nastro "speciale" bucherellato con una logica dietro... Tutto ciò mi lascia basito... :eek:
Veramente... Non posso immaginarmi che un programma sia un pezzo di carta ( se ho ben inteso il video )...
goldorak
18-10-2010, 21:20
Questo video mi fa ridere... Ma in senso buono... Cioè... se ho ben capito dal video, il compilatore non è altro che del nastro "speciale" bucherellato con una logica dietro... Tutto ciò mi lascia basito... :eek:
Veramente... Non posso immaginarmi che un programma sia un pezzo di carta ( se ho ben inteso il video )...
Un programma e' una codifica formale di un algoritmo. Gli algoritmi esistono indipendentemente dai calcolatori elettronici. Quando impari a fare la somma di due numeri o la moltiplicazione di due interi impari procedure algoritmiche. Nessuno conosce a memoria tutte le possibile somme di due numeri etc...
La macchina di Turing universale e' un dispositivo che accetta programmi scritti su un nastro !!! :asd:
banryu79
18-10-2010, 21:21
Veramente... Non posso immaginarmi che un programma sia un pezzo di carta ( se ho ben inteso il video )...
Perchè no?
Fai finta che quel pezzo di carta contentete tutta una serie di puntini "pieni" e "vuoti" sia una sorta di sequenza di bit, di zeri e uno. Et voilà.
EDIT:
Segnalo questo video che mostro perfettamente come si lavorava (in questo caso, su un computer Honeywell):
http://www.youtube.com/watch?v=hxVbRz6udmI
Grazie, affascinante ;)
Un programma e' una codifica formale di un algoritmo. Gli algoritmi esistono indipendentemente dai calcolatori elettronici. Quando impari a fare la somma di due numeri o la moltiplicazione di due interi impari procedure algoritmiche. Nessuno conosce a memoria tutte le possibile somme di due numeri etc...
La macchina di Turing universale e' un dispositivo che accetta programmi scritti su un nastro !!! :asd:
Perchè no?
Fai finta che quel pezzo di carta contentete tutta una serie di puntini "pieni" e "vuoti" sia una sorta di sequenza di bit, di zeri e uno. Et voilà.
EDIT:
Grazie, affascinante ;)
So che è così... Però per l'"era" in cui sono nato io, mi risulta inconcepibile....
È come far capire ad un anziano nato nel '20 che le foto ora non sono altro che bit, digitali...
goldorak
19-10-2010, 12:32
So che è così... Però per l'"era" in cui sono nato io, mi risulta inconcepibile....
È come far capire ad un anziano nato nel '20 che le foto ora non sono altro che bit, digitali...
E molto ironico visto e considerato che questi "vecchietti" hanno creato la rivoluzione informatica come la conosciamo noi. ;)
Ok forse non i vecchietti degli anni 20, ma quelli nati negli anni 40-50 si.
I giovani cosa lasceranno in eredita', facebook e simili ? :sbonk:
So che è così... Però per l'"era" in cui sono nato io, mi risulta inconcepibile....
È come far capire ad un anziano nato nel '20 che le foto ora non sono altro che bit, digitali...
Visto che avrebbe 90 anni suonati è difficile si, se non è morto :asd:
I giovani cosa lasceranno in eredita', facebook e simili ? :sbonk:
Perchè no? :Perfido:
Visto che avrebbe 90 anni suonati è difficile si, se non è morto :asd: Beh ci siam capiti... Intendo gente comunque non proprio "al passo coi tempi"
So che è così... Però per l'"era" in cui sono nato io, mi risulta inconcepibile....
È come far capire ad un anziano nato nel '20 che le foto ora non sono altro che bit, digitali...
Direi che questo sarebbe molto più complicato.
Che si tratti di carta bucata o di una superficie magnetizzata in un modo particolare, cosa cambia ? È sempre una sequenza di 0 e 1, una volta che hai lo strumento per leggerli è assolutamente indifferente il medium (tanto che con opportuno interfacciamente potrei far leggere i nastri perforati al mio cellulare).
La differenza tra una pellicola analogica e un nastro è molto più radicale. Non e' solo la natura del mezzo a cambiare, ma pure l'informazione contenuta
Direi che questo sarebbe molto più complicato.
Che si tratti di carta bucata o di una superficie magnetizzata in un modo particolare, cosa cambia ? È sempre una sequenza di 0 e 1, una volta che hai lo strumento per leggerli è assolutamente indifferente il medium (tanto che con opportuno interfacciamente potrei far leggere i nastri perforati al mio cellulare).
La differenza tra una pellicola analogica e un nastro è molto più radicale. Non e' solo la natura del mezzo a cambiare, ma pure l'informazione contenuta
Si, indubbiamente... Ma era per rendere il salto tecnologico... Io personalmente i bit li ho sempre immaginati come numerini che fluttuano nel nulla... Guardando un disco mi immaginavo tutti gli 1 e 0 sopra e robe del genere.... Poi vabbè, ognuno ha la sua astrazione :D
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.