-
Panoramica sull'ambiente di run-time Lino 3Scritto daaltgutente che non utieneil 2013-09-04 16:31:26.0 alle 2013-09-04 16:31:26.0Trollate totali: 11540

Ho appena finito di scrivere la "trap" della versione 3. E` una subroutine che di norma interrompe l'esecuzione e stampa il contenuto dei registri e un breve dump dello stack. Nella versione 3, ho aggiunto le unita` di stato correnti delle interfacce esposte dal modulo di run-time, e il contenuto attuale delle unita` di comando (PCMD = pending command). Il listatino imposta i 5 registri generici e quello di riserva a valori semplici da ritrovare nel dump, e pusha un paio di unita` sullo stack, poi visibili dopo l'indirizzo di ritorno della chiamata a "trap", ovviamente in ordine inverso perche` lo stack e` LIFO.
Allora, il bit meno significativo di ogni unita` di stato e` il flag di "presenza", significa che la corrispondente interfaccia e` implementata e connessa. Nel dump ci sono tutte meno "file" (perche` il flag di presenza e` condizionato dall'esistenza del file su cui sta lavorando, e non si e` ancora fatto nulla su nessun file) e le quattro "estensioni modulari", cioe` interfacce che possono essere incluse nell'eseguibile su opzione (Auxiliary Pointing Devices, audio, network sockets, printer) e di cui il listato di prova non richiede l'inclusione. Il bit a sinistra di quello e` il flag di errore (nessun'interfaccia lo riporta, nel dump), gli altri hanno significati specifici dell'interfaccia (c'e` il bit "active" del display che indica che la finestra ha il fuoco dell'user input, e nella pointer c'e` il bit che indica che il puntatore del mouse e` attualmente visibile).
Tra i registri, da A ad E sono i registri generici, di cui solo E e` designato callee-saved (vedere wikipedia?) e di solito viene usato come puntatore alla base del frame delle variabili locali. Il registro O e` l'origine dei dati, relativamente al quale tutti i puntatori a dati sono mappati (sia dati statici che blocchi di heap). Il registro $ e` lo stack pointer, il puntatore alla cima dello stack all'ingresso in "trap". Il registro % e` lo spare register, il registro "di riserva" usato per i trasferimenti da memoria a memoria e per appoggio in altre istruzioni, nonche` il contenitore designato per il valore di ritorno delle funzioni. Poi c'e` la superglobale "f", che e` una variabile sempre accessibile con lo stato dell'ultima chiamata (subroutines e funzioni possono usarlo per riportare al chiamante come sono andate le cose: f = 1 significa che la chiamata ha avuto successo, cioe` ha svolto quel che era richiesto, 0 significa che qualcosa e` andato storto, e di solito implica che se era previsto un valore di ritorno, questo dovrebbe essere ignorato perche` il suo valore attuale non ha senso, infatti "f" serve a riportare lo stato al di la` del valore di ritorno, in modo da non dover riservare codici d'errore particolari tra i possibili valori di ritorno). Poi c'e` "0", che e` il modo in cui si chiama convenzionalmente il puntatore all'origine del codice, relativamente al quale avviene la rilocazione dei salti ad indirizzi assoluti, e quindi relativamente al quale tutti gli indirizzi di codice sono espressi. Infine ci sono le prime tre unita` in cima allo stack.
L'ho spiegato bene?
Avro` dato fastidio a Lich?
-
Re: Panoramica sull'ambiente di run-time Lino 3Scritto daaltgutente che non utieneil 2013-09-04 16:32:57.0 alle 2013-09-04 16:32:57.0Trollate totali: 11540> L'ho spiegato bene?

> Avro` dato fastidio a Lich?
p.s. mi sono dimenticato di citare che "trap" puo` anche redirigere l'output a un file, e in quel caso ritorna al chiamante che cosi` puo` magari inviare via rete il dump risultante allo sviluppatore.
-
Re: Panoramica sull'ambiente di run-time Lino 3Scritto daNon Autenticatoil 2013-09-04 17:37:01.0 alle 2013-09-04 17:37:01.0>

>
> Ho appena finito di scrivere la "trap" della versione 3. E` una subroutine che di norma interrompe l'esecuzione e stampa il contenuto dei registri e un breve dump dello stack. Nella versione 3, ho aggiunto le unita` di stato correnti delle interfacce esposte dal modulo di run-time, e il contenuto attuale delle unita` di comando (PCMD = pending command). Il listatino imposta i 5 registri generici e quello di riserva a valori semplici da ritrovare nel dump, e pusha un paio di unita` sullo stack, poi visibili dopo l'indirizzo di ritorno della chiamata a "trap", ovviamente in ordine inverso perche` lo stack e` LIFO.
>
> Allora, il bit meno significativo di ogni unita` di stato e` il flag di "presenza", significa che la corrispondente interfaccia e` implementata e connessa. Nel dump ci sono tutte meno "file" (perche` il flag di presenza e` condizionato dall'esistenza del file su cui sta lavorando, e non si e` ancora fatto nulla su nessun file) e le quattro "estensioni modulari", cioe` interfacce che possono essere incluse nell'eseguibile su opzione (Auxiliary Pointing Devices, audio, network sockets, printer) e di cui il listato di prova non richiede l'inclusione. Il bit a sinistra di quello e` il flag di errore (nessun'interfaccia lo riporta, nel dump), gli altri hanno significati specifici dell'interfaccia (c'e` il bit "active" del display che indica che la finestra ha il fuoco dell'user input, e nella pointer c'e` il bit che indica che il puntatore del mouse e` attualmente visibile).
>
> Tra i registri, da A ad E sono i registri generici, di cui solo E e` designato callee-saved (vedere wikipedia?) e di solito viene usato come puntatore alla base del frame delle variabili locali. Il registro O e` l'origine dei dati, relativamente al quale tutti i puntatori a dati sono mappati (sia dati statici che blocchi di heap). Il registro $ e` lo stack pointer, il puntatore alla cima dello stack all'ingresso in "trap". Il registro % e` lo spare register, il registro "di riserva" usato per i trasferimenti da memoria a memoria e per appoggio in altre istruzioni, nonche` il contenitore designato per il valore di ritorno delle funzioni. Poi c'e` la superglobale "f", che e` una variabile sempre accessibile con lo stato dell'ultima chiamata (subroutines e funzioni possono usarlo per riportare al chiamante come sono andate le cose: f = 1 significa che la chiamata ha avuto successo, cioe` ha svolto quel che era richiesto, 0 significa che qualcosa e` andato storto, e di solito implica che se era previsto un valore di ritorno, questo dovrebbe essere ignorato perche` il suo valore attuale non ha senso, infatti "f" serve a riportare lo stato al di la` del valore di ritorno, in modo da non dover riservare codici d'errore particolari tra i possibili valori di ritorno). Poi c'e` "0", che e` il modo in cui si chiama convenzionalmente il puntatore all'origine del codice, relativamente al quale avviene la rilocazione dei salti ad indirizzi assoluti, e quindi relativamente al quale tutti gli indirizzi di codice sono espressi. Infine ci sono le prime tre unita` in cima allo stack.
>
> L'ho spiegato bene?
Per saperlo avrei bisogno di conoscere tutto un contesto che non conosco.
> Avro` dato fastidio a Lich?
-
Re: Panoramica sull'ambiente di run-time Lino 3Scritto daaltgutente che non utieneil 2013-09-04 17:59:41.0 alle 2013-09-04 17:59:41.0Trollate totali: 11540> >

> >
> > Ho appena finito di scrivere la "trap" della versione 3. E` una subroutine che di norma interrompe l'esecuzione e stampa il contenuto dei registri e un breve dump dello stack. Nella versione 3, ho aggiunto le unita` di stato correnti delle interfacce esposte dal modulo di run-time, e il contenuto attuale delle unita` di comando (PCMD = pending command). Il listatino imposta i 5 registri generici e quello di riserva a valori semplici da ritrovare nel dump, e pusha un paio di unita` sullo stack, poi visibili dopo l'indirizzo di ritorno della chiamata a "trap", ovviamente in ordine inverso perche` lo stack e` LIFO.
> >
> > Allora, il bit meno significativo di ogni unita` di stato e` il flag di "presenza", significa che la corrispondente interfaccia e` implementata e connessa. Nel dump ci sono tutte meno "file" (perche` il flag di presenza e` condizionato dall'esistenza del file su cui sta lavorando, e non si e` ancora fatto nulla su nessun file) e le quattro "estensioni modulari", cioe` interfacce che possono essere incluse nell'eseguibile su opzione (Auxiliary Pointing Devices, audio, network sockets, printer) e di cui il listato di prova non richiede l'inclusione. Il bit a sinistra di quello e` il flag di errore (nessun'interfaccia lo riporta, nel dump), gli altri hanno significati specifici dell'interfaccia (c'e` il bit "active" del display che indica che la finestra ha il fuoco dell'user input, e nella pointer c'e` il bit che indica che il puntatore del mouse e` attualmente visibile).
> >
> > Tra i registri, da A ad E sono i registri generici, di cui solo E e` designato callee-saved (vedere wikipedia?) e di solito viene usato come puntatore alla base del frame delle variabili locali. Il registro O e` l'origine dei dati, relativamente al quale tutti i puntatori a dati sono mappati (sia dati statici che blocchi di heap). Il registro $ e` lo stack pointer, il puntatore alla cima dello stack all'ingresso in "trap". Il registro % e` lo spare register, il registro "di riserva" usato per i trasferimenti da memoria a memoria e per appoggio in altre istruzioni, nonche` il contenitore designato per il valore di ritorno delle funzioni. Poi c'e` la superglobale "f", che e` una variabile sempre accessibile con lo stato dell'ultima chiamata (subroutines e funzioni possono usarlo per riportare al chiamante come sono andate le cose: f = 1 significa che la chiamata ha avuto successo, cioe` ha svolto quel che era richiesto, 0 significa che qualcosa e` andato storto, e di solito implica che se era previsto un valore di ritorno, questo dovrebbe essere ignorato perche` il suo valore attuale non ha senso, infatti "f" serve a riportare lo stato al di la` del valore di ritorno, in modo da non dover riservare codici d'errore particolari tra i possibili valori di ritorno). Poi c'e` "0", che e` il modo in cui si chiama convenzionalmente il puntatore all'origine del codice, relativamente al quale avviene la rilocazione dei salti ad indirizzi assoluti, e quindi relativamente al quale tutti gli indirizzi di codice sono espressi. Infine ci sono le prime tre unita` in cima allo stack.
> >
> > L'ho spiegato bene?
>
> Per saperlo avrei bisogno di conoscere tutto un contesto che non conosco.
Speravo qualcosina si riuscisse ad intuire; intanto, a forza di piccoli post sull'andamento dei lavori, uno magari si familiarizza con certe parole-chiave. La panoramica di cui sopra e` molto a basso livello, quindi poggia su pochi strati di concetti: credo che si possa cominciare a fare quei discorsi subito dopo un dizionarietto che introduca protagonisti e interpreti. Boh, poi vedro`...
-
-
Re: Panoramica sull'ambiente di run-time Lino 3Scritto daNon Autenticatoil 2013-09-04 20:12:31.0 alle 2013-09-04 20:12:31.0Scritto da: altg
>
>
> Ho appena finito di scrivere la "trap" della versione 3. E` una subroutine che di norma interrompe l'esecuzione e stampa il contenuto dei registri e un breve dump dello stack. Nella versione 3, ho aggiunto le unita` di stato correnti delle interfacce esposte dal modulo di run-time, e il contenuto attuale delle unita` di comando (PCMD = pending command). Il listatino imposta i 5 registri generici e quello di riserva a valori semplici da ritrovare nel dump, e pusha un paio di unita` sullo stack, poi visibili dopo l'indirizzo di ritorno della chiamata a "trap", ovviamente in ordine inverso perche` lo stack e` LIFO.
>
> Allora, il bit meno significativo di ogni unita` di stato e` il flag di "presenza", significa che la corrispondente interfaccia e` implementata e connessa. Nel dump ci sono tutte meno "file" (perche` il flag di presenza e` condizionato dall'esistenza del file su cui sta lavorando, e non si e` ancora fatto nulla su nessun file) e le quattro "estensioni modulari", cioe` interfacce che possono essere incluse nell'eseguibile su opzione (Auxiliary Pointing Devices, audio, network sockets, printer) e di cui il listato di prova non richiede l'inclusione. Il bit a sinistra di quello e` il flag di errore (nessun'interfaccia lo riporta, nel dump), gli altri hanno significati specifici dell'interfaccia (c'e` il bit "active" del display che indica che la finestra ha il fuoco dell'user input, e nella pointer c'e` il bit che indica che il puntatore del mouse e` attualmente visibile).
>
> Tra i registri, da A ad E sono i registri generici, di cui solo E e` designato callee-saved (vedere wikipedia?) e di solito viene usato come puntatore alla base del frame delle variabili locali. Il registro O e` l'origine dei dati, relativamente al quale tutti i puntatori a dati sono mappati (sia dati statici che blocchi di heap). Il registro $ e` lo stack pointer, il puntatore alla cima dello stack all'ingresso in "trap". Il registro % e` lo spare register, il registro "di riserva" usato per i trasferimenti da memoria a memoria e per appoggio in altre istruzioni, nonche` il contenitore designato per il valore di ritorno delle funzioni. Poi c'e` la superglobale "f", che e` una variabile sempre accessibile con lo stato dell'ultima chiamata (subroutines e funzioni possono usarlo per riportare al chiamante come sono andate le cose: f = 1 significa che la chiamata ha avuto successo, cioe` ha svolto quel che era richiesto, 0 significa che qualcosa e` andato storto, e di solito implica che se era previsto un valore di ritorno, questo dovrebbe essere ignorato perche` il suo valore attuale non ha senso, infatti "f" serve a riportare lo stato al di la` del valore di ritorno, in modo da non dover riservare codici d'errore particolari tra i possibili valori di ritorno). Poi c'e` "0", che e` il modo in cui si chiama convenzionalmente il puntatore all'origine del codice, relativamente al quale avviene la rilocazione dei salti ad indirizzi assoluti, e quindi relativamente al quale tutti gli indirizzi di codice sono espressi. Infine ci sono le prime tre unita` in cima allo stack.
>
> L'ho spiegato bene?
l'hai spiegato nel posto sbagliato
> Avro` dato fastidio a Lich?
sì
-
Re: Panoramica sull'ambiente di run-time Lino 3Scritto da: altg
>
>
> Ho appena finito di scrivere la "trap" della versione 3. E` una subroutine che di norma interrompe l'esecuzione e stampa il contenuto dei registri e un breve dump dello stack. Nella versione 3, ho aggiunto le unita` di stato correnti delle interfacce esposte dal modulo di run-time, e il contenuto attuale delle unita` di comando (PCMD = pending command). Il listatino imposta i 5 registri generici e quello di riserva a valori semplici da ritrovare nel dump, e pusha un paio di unita` sullo stack, poi visibili dopo l'indirizzo di ritorno della chiamata a "trap", ovviamente in ordine inverso perche` lo stack e` LIFO.
>
> Allora, il bit meno significativo di ogni unita` di stato e` il flag di "presenza", significa che la corrispondente interfaccia e` implementata e connessa. Nel dump ci sono tutte meno "file" (perche` il flag di presenza e` condizionato dall'esistenza del file su cui sta lavorando, e non si e` ancora fatto nulla su nessun file) e le quattro "estensioni modulari", cioe` interfacce che possono essere incluse nell'eseguibile su opzione (Auxiliary Pointing Devices, audio, network sockets, printer) e di cui il listato di prova non richiede l'inclusione. Il bit a sinistra di quello e` il flag di errore (nessun'interfaccia lo riporta, nel dump), gli altri hanno significati specifici dell'interfaccia (c'e` il bit "active" del display che indica che la finestra ha il fuoco dell'user input, e nella pointer c'e` il bit che indica che il puntatore del mouse e` attualmente visibile).
>
> Tra i registri, da A ad E sono i registri generici, di cui solo E e` designato callee-saved (vedere wikipedia?) e di solito viene usato come puntatore alla base del frame delle variabili locali. Il registro O e` l'origine dei dati, relativamente al quale tutti i puntatori a dati sono mappati (sia dati statici che blocchi di heap). Il registro $ e` lo stack pointer, il puntatore alla cima dello stack all'ingresso in "trap". Il registro % e` lo spare register, il registro "di riserva" usato per i trasferimenti da memoria a memoria e per appoggio in altre istruzioni, nonche` il contenitore designato per il valore di ritorno delle funzioni. Poi c'e` la superglobale "f", che e` una variabile sempre accessibile con lo stato dell'ultima chiamata (subroutines e funzioni possono usarlo per riportare al chiamante come sono andate le cose: f = 1 significa che la chiamata ha avuto successo, cioe` ha svolto quel che era richiesto, 0 significa che qualcosa e` andato storto, e di solito implica che se era previsto un valore di ritorno, questo dovrebbe essere ignorato perche` il suo valore attuale non ha senso, infatti "f" serve a riportare lo stato al di la` del valore di ritorno, in modo da non dover riservare codici d'errore particolari tra i possibili valori di ritorno). Poi c'e` "0", che e` il modo in cui si chiama convenzionalmente il puntatore all'origine del codice, relativamente al quale avviene la rilocazione dei salti ad indirizzi assoluti, e quindi relativamente al quale tutti gli indirizzi di codice sono espressi. Infine ci sono le prime tre unita` in cima allo stack.
>
> L'ho spiegato bene?
> Avro` dato fastidio a Lich?
i programme linoleum li metti in file txt? non hanno un estensione tutta loro? tipo .lino, .mlou…Young professional woman and busy mom.-
Re: Panoramica sull'ambiente di run-time Lino 3Scritto daaltgutente che non utieneil 2013-09-04 23:56:12.0 alle 2013-09-04 23:56:12.0Trollate totali: 11540> >

> >
> > Ho appena finito di scrivere la "trap" della versione 3. E` una subroutine che di norma interrompe l'esecuzione e stampa il contenuto dei registri e un breve dump dello stack. Nella versione 3, ho aggiunto le unita` di stato correnti delle interfacce esposte dal modulo di run-time, e il contenuto attuale delle unita` di comando (PCMD = pending command). Il listatino imposta i 5 registri generici e quello di riserva a valori semplici da ritrovare nel dump, e pusha un paio di unita` sullo stack, poi visibili dopo l'indirizzo di ritorno della chiamata a "trap", ovviamente in ordine inverso perche` lo stack e` LIFO.
> >
> > Allora, il bit meno significativo di ogni unita` di stato e` il flag di "presenza", significa che la corrispondente interfaccia e` implementata e connessa. Nel dump ci sono tutte meno "file" (perche` il flag di presenza e` condizionato dall'esistenza del file su cui sta lavorando, e non si e` ancora fatto nulla su nessun file) e le quattro "estensioni modulari", cioe` interfacce che possono essere incluse nell'eseguibile su opzione (Auxiliary Pointing Devices, audio, network sockets, printer) e di cui il listato di prova non richiede l'inclusione. Il bit a sinistra di quello e` il flag di errore (nessun'interfaccia lo riporta, nel dump), gli altri hanno significati specifici dell'interfaccia (c'e` il bit "active" del display che indica che la finestra ha il fuoco dell'user input, e nella pointer c'e` il bit che indica che il puntatore del mouse e` attualmente visibile).
> >
> > Tra i registri, da A ad E sono i registri generici, di cui solo E e` designato callee-saved (vedere wikipedia?) e di solito viene usato come puntatore alla base del frame delle variabili locali. Il registro O e` l'origine dei dati, relativamente al quale tutti i puntatori a dati sono mappati (sia dati statici che blocchi di heap). Il registro $ e` lo stack pointer, il puntatore alla cima dello stack all'ingresso in "trap". Il registro % e` lo spare register, il registro "di riserva" usato per i trasferimenti da memoria a memoria e per appoggio in altre istruzioni, nonche` il contenitore designato per il valore di ritorno delle funzioni. Poi c'e` la superglobale "f", che e` una variabile sempre accessibile con lo stato dell'ultima chiamata (subroutines e funzioni possono usarlo per riportare al chiamante come sono andate le cose: f = 1 significa che la chiamata ha avuto successo, cioe` ha svolto quel che era richiesto, 0 significa che qualcosa e` andato storto, e di solito implica che se era previsto un valore di ritorno, questo dovrebbe essere ignorato perche` il suo valore attuale non ha senso, infatti "f" serve a riportare lo stato al di la` del valore di ritorno, in modo da non dover riservare codici d'errore particolari tra i possibili valori di ritorno). Poi c'e` "0", che e` il modo in cui si chiama convenzionalmente il puntatore all'origine del codice, relativamente al quale avviene la rilocazione dei salti ad indirizzi assoluti, e quindi relativamente al quale tutti gli indirizzi di codice sono espressi. Infine ci sono le prime tre unita` in cima allo stack.
> >
> > L'ho spiegato bene?
> > Avro` dato fastidio a Lich?
>
> i programme linoleum li metti in file txt? non hanno un estensione tutta loro? tipo .lino, .mlou…
No, o almeno, personalmente non sento il bisogno di attribuirgli un'estensione tutta loro. Quel che immagino e` che se uno vuole aprili in un IDE a cui sia associata quella tot estensione, apre prima l'IDE e con esso tutto un progetto, raramente un file solo. Se invece gli vuol dare un'occhiata rapida, doppioclicca il file e mi sembra incoraggiante vederlo apparire direttamente in notepad o chi per lui. A proposito del notepad-o-chi-per-lui, nel definire lo stile dei sorgenti versione 3 sto andando molto incontro a uno stile che usa solo tabulazioni intere e che appaia il piu` possibile chiaro anche in assenza di:
- font monospace (sto appunto editando le librerie 3.00 in notepad con font proporzionali)
- syntax highlighting (usando il piu` possibile sintassi che fanno risaltare gli operandi)
Ah, ehm... il buffo "programme" e` in disuso dalla versione 1.
Nel 3 si scrive "forewords" per iniziare il codice di una libreria, e "beginning" per iniziare quello del sorgente principale. "programme" era una mia mania di avere tutti i nomi dei periodi di uguale lunghezza, e siccome tutti gli altri erano 9 caratteri, avevo pensato di allungare "program". Anni e anni dopo, m'e` venuto in mente d'un tratto che "beginning" era 9 caratteri e molto piu` ragionevole.
-
Re: Panoramica sull'ambiente di run-time Lino 3Scritto da: altg
> > >
> > >
> > > Ho appena finito di scrivere la "trap" della versione 3. E` una subroutine che di norma interrompe l'esecuzione e stampa il contenuto dei registri e un breve dump dello stack. Nella versione 3, ho aggiunto le unita` di stato correnti delle interfacce esposte dal modulo di run-time, e il contenuto attuale delle unita` di comando (PCMD = pending command). Il listatino imposta i 5 registri generici e quello di riserva a valori semplici da ritrovare nel dump, e pusha un paio di unita` sullo stack, poi visibili dopo l'indirizzo di ritorno della chiamata a "trap", ovviamente in ordine inverso perche` lo stack e` LIFO.
> > >
> > > Allora, il bit meno significativo di ogni unita` di stato e` il flag di "presenza", significa che la corrispondente interfaccia e` implementata e connessa. Nel dump ci sono tutte meno "file" (perche` il flag di presenza e` condizionato dall'esistenza del file su cui sta lavorando, e non si e` ancora fatto nulla su nessun file) e le quattro "estensioni modulari", cioe` interfacce che possono essere incluse nell'eseguibile su opzione (Auxiliary Pointing Devices, audio, network sockets, printer) e di cui il listato di prova non richiede l'inclusione. Il bit a sinistra di quello e` il flag di errore (nessun'interfaccia lo riporta, nel dump), gli altri hanno significati specifici dell'interfaccia (c'e` il bit "active" del display che indica che la finestra ha il fuoco dell'user input, e nella pointer c'e` il bit che indica che il puntatore del mouse e` attualmente visibile).
> > >
> > > Tra i registri, da A ad E sono i registri generici, di cui solo E e` designato callee-saved (vedere wikipedia?) e di solito viene usato come puntatore alla base del frame delle variabili locali. Il registro O e` l'origine dei dati, relativamente al quale tutti i puntatori a dati sono mappati (sia dati statici che blocchi di heap). Il registro $ e` lo stack pointer, il puntatore alla cima dello stack all'ingresso in "trap". Il registro % e` lo spare register, il registro "di riserva" usato per i trasferimenti da memoria a memoria e per appoggio in altre istruzioni, nonche` il contenitore designato per il valore di ritorno delle funzioni. Poi c'e` la superglobale "f", che e` una variabile sempre accessibile con lo stato dell'ultima chiamata (subroutines e funzioni possono usarlo per riportare al chiamante come sono andate le cose: f = 1 significa che la chiamata ha avuto successo, cioe` ha svolto quel che era richiesto, 0 significa che qualcosa e` andato storto, e di solito implica che se era previsto un valore di ritorno, questo dovrebbe essere ignorato perche` il suo valore attuale non ha senso, infatti "f" serve a riportare lo stato al di la` del valore di ritorno, in modo da non dover riservare codici d'errore particolari tra i possibili valori di ritorno). Poi c'e` "0", che e` il modo in cui si chiama convenzionalmente il puntatore all'origine del codice, relativamente al quale avviene la rilocazione dei salti ad indirizzi assoluti, e quindi relativamente al quale tutti gli indirizzi di codice sono espressi. Infine ci sono le prime tre unita` in cima allo stack.
> > >
> > > L'ho spiegato bene?
> > > Avro` dato fastidio a Lich?
> >
> > i programme linoleum li metti in file txt? non hanno un estensione tutta loro? tipo .lino, .mlou…
>
> No, o almeno, personalmente non sento il bisogno di attribuirgli un'estensione tutta loro. Quel che immagino e` che se uno vuole aprili in un IDE a cui sia associata quella tot estensione, apre prima l'IDE e con esso tutto un progetto, raramente un file solo. Se invece gli vuol dare un'occhiata rapida, doppioclicca il file e mi sembra incoraggiante vederlo apparire direttamente in notepad o chi per lui. A proposito del notepad-o-chi-per-lui, nel definire lo stile dei sorgenti versione 3 sto andando molto incontro a uno stile che usa solo tabulazioni intere e che appaia il piu` possibile chiaro anche in assenza di:
>
> - font monospace (sto appunto editando le librerie 3.00 in notepad con font proporzionali)
> - syntax highlighting (usando il piu` possibile sintassi che fanno risaltare gli operandi)
Non è una grossa limitazione questa?
Alla fine uno sviluppatore che si rispetti usa editor migliori di blocco note.
> Ah, ehm... il buffo "programme" e` in disuso dalla versione 1.
Me lo ricordo di quando mi sono fatto il tutorial di yayo per provare lino 1.
> Nel 3 si scrive "forewords" per iniziare il codice di una libreria, e "beginning" per iniziare quello del sorgente principale. "programme" era una mia mania di avere tutti i nomi dei periodi di uguale lunghezza, e siccome tutti gli altri erano 9 caratteri, avevo pensato di allungare "program". Anni e anni dopo, m'e` venuto in mente d'un tratto che "beginning" era 9 caratteri e molto piu` ragionevole.
Ok, sei malato.
Young professional woman and busy mom.-
Re: Panoramica sull'ambiente di run-time Lino 3Scritto daNon Autenticatoil 2013-09-05 00:57:48.0 alle 2013-09-05 00:57:48.0> Me lo ricordo di quando mi sono fatto il tutorial di yayo per provare lino 1.
Ma allora qui qualcuno ha provato Linoleum oltre l'autore! Quali opinioni e impressioni?-
Re: Panoramica sull'ambiente di run-time Lino 3Scritto da:
> > Me lo ricordo di quando mi sono fatto il tutorial di yayo per provare lino 1.
>
> Ma allora qui qualcuno ha provato Linoleum oltre l'autore! Quali opinioni e impressioni?
Da quel che mi ricordo era un assembly++, spero che in lino3 ci sia un module system o un meccanismo di namespacing altrimenti costruirci sopra qualcosa di non banale diventa molto faticoso (vedi c vs c++).Young professional woman and busy mom.-
Re: Panoramica sull'ambiente di run-time Lino 3Scritto daaltgutente che non utieneil 2013-09-05 14:21:18.0 alle 2013-09-05 14:21:18.0Trollate totali: 11540> > > Me lo ricordo di quando mi sono fatto il tutorial di yayo per provare lino 1.
> >
> > Ma allora qui qualcuno ha provato Linoleum oltre l'autore! Quali opinioni e impressioni?
>
> Da quel che mi ricordo era un assembly++, spero che in lino3 ci sia un module system o un meccanismo di namespacing altrimenti costruirci sopra qualcosa di non banale diventa molto faticoso (vedi c vs c++).
Be', non sara` mai qualcosa di piu` di un assembly++ perche` quello e` il suo obiettivo. Comunque, il namespacing nella versione 3 esiste su base file: i file dichiarano il proprio namespace. Esistono tre livelli:
- il superglobale, cioe` nomi visibili da tutto e tutti;
- il globale, cioe` la norma nei file che specificano il proprio namespace;
- il locale, cioe` quello dove vivono i simboli locali di una funzione o subroutine.
Lo shadowing si puo` risolvere prefissando i nomi, ad esempio se hai un simbolo locale chiamato "proot", un simbolo nel namespace del file chiamato anch'esso "proot" che e` in shadow dal locale, e un simbolo "proot" superglobale che e` doppiamente shadowato dai due di sotto, nell'ambito locale di una funzione puoi scrivere:
proot -- per riferirti al locale,
filed . proot -- per riferirti a quello globale nel namespace del file,
super . proot -- per riferirti a quello superglobale.
Curiosamente, mentre i namespace sono di solito specifici di un file, piu` file possono essere uniti sotto lo stesso namespace: cosi` si possono creare librerie "modulari", dove c'e` un file di "commons" che dichiara i simboli comuni, di solito quelli che definiscono lo stato persistente della libreria (impostazioni eccetera), e piu` file di funzioni e subroutines con di norma una funzione o una subroutine sola, che vengono inclusi individualmente per evitare di includere codice non usato.
A parte quello, rispetto alla prima versione, la versione 3 e` basata sull'uso di heap, e ha una sorta di meccanismo di garbage collection (anche se non tradizionale, piu` che altro e` un meccanismo che centralizza la deallocazione di blocchi di heap nella cornice di un "task", e lo fa in modo da frammentare l'heap il meno possibile, oltre che in modo molto rapido). Ma in soldoni si possono allocare blocchi di heap senza preoccuparsi di liberarli tutti, o manipolare blocchi di memoria nello stesso modo senza preoccuparsi che questi siano allocati staticamente o dinamicamente. Il discorso e` lungo. Inoltre, il compilatore della versione 3 aggiunge molti dettagli, e anche un po' di roba importante, tra cui:
- parecchie istruzioni che danno accesso controllato allo spare register,
- sintassi grammaticale per le chiamate, insieme a una precisa calling convention;
- jump threading di blocchi condizionali stile if...then...else, innestabili a piacere.
E le librerie, poi, costruendo su heap e calling conventions, impostano un sistema d'interfacce estensibili, che possono essere connesse, disconnesse o riconfigurate nel run-time insieme alle loro implementazioni. Quello pero` non e` un processo controllato dal compilatore, a parte le chiamate in closure.
Insomma e` un mondo un bel po' diverso.
-
-
-
Re: Panoramica sull'ambiente di run-time Lino 3Scritto daaltgutente che non utieneil 2013-09-05 02:44:29.0 alle 2013-09-05 02:44:29.0Trollate totali: 11540> > > i programme linoleum li metti in file txt? non hanno un estensione tutta loro? tipo .lino, .mlou…
> >
> > No, o almeno, personalmente non sento il bisogno di attribuirgli un'estensione tutta loro. Quel che immagino e` che se uno vuole aprili in un IDE a cui sia associata quella tot estensione, apre prima l'IDE e con esso tutto un progetto, raramente un file solo. Se invece gli vuol dare un'occhiata rapida, doppioclicca il file e mi sembra incoraggiante vederlo apparire direttamente in notepad o chi per lui. A proposito del notepad-o-chi-per-lui, nel definire lo stile dei sorgenti versione 3 sto andando molto incontro a uno stile che usa solo tabulazioni intere e che appaia il piu` possibile chiaro anche in assenza di:
> >
> > - font monospace (sto appunto editando le librerie 3.00 in notepad con font proporzionali)
> > - syntax highlighting (usando il piu` possibile sintassi che fanno risaltare gli operandi)
>
> Non è una grossa limitazione questa?
> Alla fine uno sviluppatore che si rispetti usa editor migliori di blocco note.
Mah... limitazione e` una parola grossa.
Gli IDE non caricano i txt? E parlavi dei fonts e compagnia bella?
> > Ah, ehm... il buffo "programme" e` in disuso dalla versione 1.
>
> Me lo ricordo di quando mi sono fatto il tutorial di yayo per provare lino 1.
Roba molto vecchia, e abbozzata.
> > Nel 3 si scrive "forewords" per iniziare il codice di una libreria, e "beginning" per iniziare quello del sorgente principale. "programme" era una mia mania di avere tutti i nomi dei periodi di uguale lunghezza, e siccome tutti gli altri erano 9 caratteri, avevo pensato di allungare "program". Anni e anni dopo, m'e` venuto in mente d'un tratto che "beginning" era 9 caratteri e molto piu` ragionevole.
>
> Ok, sei malato.
Lo so.
Buonanotte.
-
Re: Panoramica sull'ambiente di run-time Lino 3> > > - syntax highlighting (usando il piu` possibile sintassi che fanno risaltare gli operandi)
> >
> > Non è una grossa limitazione questa?
> > Alla fine uno sviluppatore che si rispetti usa editor migliori di blocco note.
>
> Mah... limitazione e` una parola grossa.
> Gli IDE non caricano i txt? E parlavi dei fonts e compagnia bella?
mi riferivo alla parte che ho quotato in questo postYoung professional woman and busy mom.
-
-
-
-
-