Mostra notizie nelle discussioni
  • Avatar
    ☺
    Scritto da
    altg
    utente che non utiene
    il 2013-09-04 16:31:26.0 alle 2013-09-04 16:31:26.0
    Trollate totali: 11540
    Panoramica sull'ambiente di run-time Lino 3
    Immagine postata dall'utente

    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? Newbie, inesperto
    Avro` dato fastidio a Lich? Imbarazzato
    • Avatar
      Scritto da
      Non Autenticato
      il 2013-09-04 17:37:01.0 alle 2013-09-04 17:37:01.0
      Re: Panoramica sull'ambiente di run-time Lino 3
      > Immagine postata dall'utente
      >
      > 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? Newbie, inesperto

      Per saperlo avrei bisogno di conoscere tutto un contesto che non conosco.

      > Avro` dato fastidio a Lich? Imbarazzato
      • Avatar
        ☺
        Scritto da
        altg
        utente che non utiene
        il 2013-09-04 17:59:41.0 alle 2013-09-04 17:59:41.0
        Trollate totali: 11540
        Re: Panoramica sull'ambiente di run-time Lino 3
        > > Immagine postata dall'utente
        > >
        > > 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? Newbie, inesperto
        >
        > 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`...
    • Avatar
      Scritto da
      Non Autenticato
      il 2013-09-04 20:12:31.0 alle 2013-09-04 20:12:31.0
      Re: Panoramica sull'ambiente di run-time Lino 3
      Scritto da: altg
      > Immagine postata dall'utente
      >
      > 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? Newbie, inesperto

      l'hai spiegato nel posto sbagliato

      > Avro` dato fastidio a Lich? Imbarazzato

      sì

      Cylon
    • Avatar
      ☺
      Scritto da
      ::1
      il 2013-09-04 20:19:26.0 alle 2013-09-04 20:19:26.0
      Trollate totali: 12321
      Re: Panoramica sull'ambiente di run-time Lino 3
      Scritto da: altg
      > Immagine postata dall'utente
      >
      > 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? Newbie, inesperto
      > Avro` dato fastidio a Lich? Imbarazzato

      i programme linoleum li metti in file txt? non hanno un estensione tutta loro? tipo .lino, .mlou…
      Young professional woman and busy mom.
      • Avatar
        ☺
        Scritto da
        altg
        utente che non utiene
        il 2013-09-04 23:56:12.0 alle 2013-09-04 23:56:12.0
        Trollate totali: 11540
        Re: Panoramica sull'ambiente di run-time Lino 3
        > > Immagine postata dall'utente
        > >
        > > 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? Newbie, inesperto
        > > Avro` dato fastidio a Lich? Imbarazzato
        >
        > 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. Imbarazzato

        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. A bocca aperta
        • Avatar
          ☺
          Scritto da
          ::1
          il 2013-09-05 00:46:03.0 alle 2013-09-05 00:46:03.0
          Trollate totali: 12321
          Re: Panoramica sull'ambiente di run-time Lino 3
          Scritto da: altg
          > > > Immagine postata dall'utente
          > > >
          > > > 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? Newbie, inesperto
          > > > Avro` dato fastidio a Lich? Imbarazzato
          > >
          > > 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. Imbarazzato

          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. A bocca aperta

          Ok, sei malato. A bocca storta
          Young professional woman and busy mom.
          • Avatar
            Scritto da
            Non Autenticato
            il 2013-09-05 00:57:48.0 alle 2013-09-05 00:57:48.0
            Re: Panoramica sull'ambiente di run-time Lino 3
            > 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?
            • Avatar
              ☺
              Scritto da
              ::1
              il 2013-09-05 08:39:27.0 alle 2013-09-05 08:39:27.0
              Trollate totali: 12321
              Re: Panoramica sull'ambiente di run-time Lino 3
              Scritto 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.
              • Avatar
                ☺
                Scritto da
                altg
                utente che non utiene
                il 2013-09-05 14:21:18.0 alle 2013-09-05 14:21:18.0
                Trollate totali: 11540
                Re: Panoramica sull'ambiente di run-time Lino 3
                > > > 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.
          • Avatar
            ☺
            Scritto da
            altg
            utente che non utiene
            il 2013-09-05 02:44:29.0 alle 2013-09-05 02:44:29.0
            Trollate totali: 11540
            Re: Panoramica sull'ambiente di run-time Lino 3
            > > > 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? Newbie, inesperto

            > > Ah, ehm... il buffo "programme" e` in disuso dalla versione 1. Imbarazzato
            >
            > Me lo ricordo di quando mi sono fatto il tutorial di yayo per provare lino 1.

            Roba molto vecchia, e abbozzata. Imbarazzato

            > > 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. A bocca aperta
            >
            > Ok, sei malato. A bocca storta

            Lo so. In lacrime
            Buonanotte. Fantasma
            • Avatar
              ☺
              Scritto da
              ::1
              il 2013-09-05 08:36:30.0 alle 2013-09-05 08:36:30.0
              Trollate totali: 12321
              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? Newbie, inesperto

              mi riferivo alla parte che ho quotato in questo post
              Young professional woman and busy mom.
<softv>

Pagina generata in 244 millisecondi

Utenti attivi: 14 nell'ultimo minuto, 29 negli ultimi cinque minuti, 56 negli ultimi 15 minuti