Newsgroup: it.comp.programmare
Titolo: Sistemi Operativi, Sogni ed incubi....

Uno dei miei sogni e' fare un piccolo seistema operativo, mentre il
mio peggiore incubo e' fare un compilatore.
Ma per fare un SO devo fare il compilatore? o esiste roba precotta...?
volevo fare un SO a 32 bit se possibile, in caso qualcuno mi potesse
dare una dritta a riguardo mi farebbe un piacere.
Spero di non essere OT
Grazie
Kirys
--------------------------------------------------
Brayan Fix Kirys Solfory
E-Mail: 
Ki...@technologist.com
 
For Free Software go to: 
http://Kiryssoft.cjb.net

 Ma per fare un SO devo fare il compilatore? o esiste roba precotta...?
Esistono tantissimi compilatori.  Se il tuo "piccolo SO" e` in
grado di leggere i formati di file eseguibili prodotti da uno
o piu` compilatori che girino su sistemi esistenti, hai risolto
(se non ti interessa potere *compilare* sul tuo SO ma solo
usarlo per farci girare prodotti scritti apposta; se no dovrai
anche saper *eseguire* gli eseguibili dei compilatori stessi
oltre a quelli che essi producono).
Il formato "portable executable" della Intel e` accuratamente
documentato (anche sulla MSDN), quindi se i chip di tuo
interesse sono Intel o compatibili sei praticamente a posto.
Alex

 dare una dritta a riguardo mi farebbe un piacere.
Prima dritta: studia l'assembler.
Se sei già un esperto di asm, (non sembrerebbe vista la domanda) allora puoi
continuare con i tuoi sogni e incubi
:-)))))
Un SO deve avere accesso diretto all'hardware, e la vedo dura con il solo C,
C++, e per quanto riguarda il compilatore, devi obbligatoriamente conoscere
l'asm alla perfezione.
--
(*****      MBSoftware       *****)
http://web.tiscalinet.it/mbsoftware

l'asm alla perfezione.
Lo conosco, lo devo ripassare un po ma lo conosco
Ciao


 dare una dritta a riguardo mi farebbe un piacere.
Suggerirei di dare uno sguardo a quello che gia' c'e'. A parte Linux, che
ormai e' diventato un mastodonte, esiste Minix, un piccolo SO realizzato
per uso didattico e liberamente disponibile per scopi commerciali. Se vuoi
ti posso dare l'indirizzo da dove scaricarlo, al momento non lo ricordo.
Fra l'altro, minix e' allegato al libro "sistemi operativi" di a.s.
tanenbaum, un libro che parla dei SO dal punto di vista della loro
implementazione (quindi poca teoria e tanto codice). Il libro e'
fantastico e vale senz'altro la spesa, anche se la traduzione italiana non
e' perfetta. In particolare, sono spiegate le fasi iniziali di avvio di un
sistema (quelle che mettono in crisi il programmatore tradizionale)
Ciao
Mauro

Scusate, nel post precedente mi ero sbagliato. Minix e' libero per scopi
NON commerciali
Ciao a tutti


cia
kirys


interesse sono Intel o compatibili sei praticamente a posto.
Beh ma dove lo trovo un compilatore c? gia' fatto?


 wrote:
Non e' che conoscete anche qualche sito a riguardo?
:D


 Non e' che conoscete anche qualche sito a riguardo?
www.minix.org
rimanendo, naturalmente, nella filosofia del post precedente.
Ciao
Mauro

l'asm alla perfezione.
E perche' mai ?
Attualmente i compilatori C sono cosi' efficienti da produrre codice
migliore di quello che farebbe un bravo programmatore direttamente in
ASM.
Il C sta tra l'altro lentamente sostituendo l'ASM sia nel settore SO
che nel controllo hardware.
Molti driver e controlli di periferiche complesse sono realizzate in
C.
Interi sistemi operativi (ad esempio UNIX di Berkley) sono stati
realizzati in C (anche se c'e' da dire che per la storia di unix asm e
C si intreccinao poiche' prima unix venne scritto in asm...poi venne
fatto il compilatore C e poi unix venne riscritto in C).
Per quanto riguardal'accesso diretto all'hardware ti torno a dire che
il C dispone di efficienti librerie dedicate... inoltre...se non erro
uno dei primi kernel di Linux (se ti interessa posso postarti il
codice) era proprio scritto in C.
Per quanto riguarda i compilatori...bhe il nostro amico puo' sempre
riferirsi all'ultimo capitolo di "Algoritmi + strutture dati =
programmi" in cui il buon vecchio Wirth segue il lettore passo passo
nellos viluppo di un compilatore per PL/1 (se non erro) di
pseudo-pascal
Augusto Pucci
Webmaster di Prospektiva On-line
http://www.prospektiva.it

 wrote:

Grazie
 ma ho bisogno di qualcosa di + descrittvo per iniziare, la parte
"divertente" e' la progettazione non l'implementazione in se.
:D
devo cercare qualche testo di base che spieghi i concetti di progetto
di so multitasking ecc....
:D
Pssibilmente scaricabile


 Beh ma dove lo trovo un compilatore c? gia' fatto?
Vedi ad esempio il mio tutorial Win32, 
http://aleax.supereva.it/
;
do` le URL di vari compilatori C gratuiti e disponibili in forma
di sorgenti.  Personalmente te ne consiglierei uno semplice e
leggero, come LCC, piu` che uno ricco e grosso come GCC.
Alex

 E perche' mai ?
[cut]
Per quanto riguarda i SO hai perfettamente ragione, visto che possono essere
scritti completamente in C.
Ma anche il C ha bisogno del compilatore ed essere tradotto in asm per
essere eseguito dalla cpu.
Certo, Unix e Windows sono scritti in C, ma poi devono essere compilati per
funzionare.
Per quanto riguarda i compilatori:
cos'č un compilatore se non un programma che traduce un linguaggio di alto
livello in linguaggio macchina, cioč asm?
Oppure cosa intendi per compilatore? Anche il compilatore run-time VB
(vbrunXXX.dll) traduce lo pseudo-eseguibile basic in asm.
Io per compilatore intendo un programma che traduce in asm, cioč linguaggio
comprensibile dalla cpu, e se vuoi costruirne uno serio, dovrai pur
conoscere l'asm per ottenere il file eseguibile, o no?
Ciao.



Ehi spero tu stia scherzando , da quando in qua la cpu capisce il linguaggio
assembler??
La cpu può solo interpretare il significato di una sequenza di 1 e di 0
mentre il compilatore è  un programma che legge un programma scritto il in
un linguaggio (sorgente C o assembler o cos'altro) e lo traduce in un
programma equivalente in un altro linguaggio (oggetto .obj ) che poi sarebbe
l 'unico capace di essere "capito" dalla cpu.
Ai fini del programmazione si può dire che un programma è pronto anche
quando esso è stato messo sotto forma di .obj ; in realtà però, essendoci
sempre un sistema operativo in mezzo si ha che il .obj deve essere
ri-tradotto in un altro formato  affinchè il SO passi il progamma alla cpu e
lo esegua ( in UNIX di default è .out mentre in windows è .exe); a tal fine
si usa un linker per risolvere i riferimenti  all'interno del codice
oggetto.
Per essere + preciso corroboro la mia asserzione con un esempio:
codice macchina       assembler equivalente
00011110                  PUSH    DS
00101011                  SUB      AX,AX
10111000                  MOV    AX, DATI
10001110                  MOV    DS,AX


Hai solo scritto le stesse istruzioni asm in due modi diversi. I byte a
sinistra, per la cpu, significano le istruzioni a destra. L'assembler
trasforma la sfilza di caratteri a destra ('P', 'U', 'S', 'H', ecc...) nei
bit a sinistra.
Lo stesso fanno i compilatori  Pascal o  C: trasformano le istruzioni di
quei linguaggi in sfilze di byte, corrispondenti alle istruzioni asm
interpretabili dalla cpu.
Quindi quando dico che la cpu capisce solo il linguaggio asm, lo capisce,
anche se lo legge in forma di gruppi di otto uni e zeri.


 wrote:

Sto scaricando LCC (Gia uso LCC_WIN32 con molta soddisfazione), credo
che dovro' rifare gli include files e le libs, appena avro' definito
il mio SO :D.
Sto LCC qua e' a 32 bit (almeno in asm)?
PS Conosci anche qualche sito generico che spieghi le basi del SO,
qualche idea la ho ma vorrei vedere qualcosa di Canonico, inoltre ho
bisogno di alcune info basilari quali.
Struttura fisica del floppy e metodi di controllo, VOrrei elaborare
una mi fat personale e inizierei dal floppy per evitare di
danneggiarmi l'HD.
Come si swappa tra I processi in sistemi multitasking.
Sto cercando su altavista ma ottengo solo siti che elogiano qualche so
commerciale.
Grazie 1024 per l'aiuto che mi hai dato fin'ora :D
Ciao
Kirys


conoscere l'asm per ottenere il file eseguibile, o no?
Si certo, infatti quel che intendevo dire e' che la parte difficile
non sarebbe tanto quella di fare un SO (visto che cio' non implica
come anche tu sottolinei conoscenze di ASM) quanto quella di creare un
compilatore..che lla fine dovra' appunto compilare in ASM..del resto
un SO senza compilatore che in esso funzioni resterebbe molto
monco..io comunque consiglierei al nostro amico di fare uan cosa
diversa...
Dal punto di vista didattico potrebbe essere molto interessante creare
una virtual machine..magari semplice basata sul modello a registri di
Von Neumann dotata di un suo psudo asm semplificato.
A questo punto potrebbe beniussimo scrivere un so funzionante su
questa virtual machine e un compilatore che appunto compili per la VM.
Il che se ci pensi bene potrebbe anche avere una sua utilita' pratica
in certi ambiti. Senza contare il fatto che questo tipo di esperienza
gli permetterebbe di imparare un sacco di cose senza doversi perdere
nell'asm di una singola macchina (che su calcolatori moderni diventa
un odissea) Questo e' quello che consiglierei al nostro amico..per
l'estate secondo me sarebbe un progetto molto istruttivo e
divertente..e privo di complicazioni "aggiunte" te che ne pensi ?


10001110                  MOV    DS,AX
Bhe non e' che sia particolarmente difficle la traduzione dall'oggetto
in asm al linguaggio amcchina a dire il vero... di solito il rapporto
delle istruzioni fra assemblatore e lm e' di 1:1 non mi sembra certo
questa al difficolta' del progetto


> 10001110                  MOV    DS,AX
##Hai solo scritto le stesse istruzioni asm in due modi diversi. I byte a
##sinistra, per la cpu, significano le istruzioni a destra. L'assembler
##trasforma la sfilza di caratteri a destra ('P', 'U', 'S', 'H', ecc...) nei
##bit a sinistra.
##Lo stesso fanno i compilatori  Pascal o  C: trasformano le istruzioni di
##quei linguaggi in sfilze di byte, corrispondenti alle istruzioni asm
##interpretabili dalla cpu.
Qui ribadisci il concetto che un compilatore di un qualsiasi linguaggio
trasforma
le istruzioni direttamente in una serie di 1 e 0.
##Quindi quando dico che la cpu capisce solo il linguaggio asm, lo capisce,
##anche se lo legge in forma di gruppi di otto uni e zeri.
-------------------Fine Commenti---------------------------------
In conclusione:
dovresti studiarti  di + la struttura e componenti dei compilatori
ed anche quelle dei processori ....
scusa ma non ti sei mai chiesto come fa un bios a funzionare???
Stando al tuo discorso tutti i programmi quando li compili diventano
eseguibili,
quindi anche un bios avrà estensione .exe ???
Non sai che puoi ottenere un programma unendo moduli di diverso linguaggio??
Stando al tuo discorso questo è impossibile perchè quando compili e quindi
crei il tuo
eseguibile, usi il compilatore di quel determinato linguaggio.
Non mi dirai che esistono compilatori come dire" multi-linguaggio" perchè
allora
sarebbe veramente il top.
In realtà tutto si spiegherebbe se tu conoscessi questi benedetti file
oggetto
(.obj) e l'uso del linker.
Lascia che ti erudisca a riguardo:
 _______                  ___________               ______
_____                ________
| sorgente |--------->| Compilatore  |-------->| oggetto |--------->| linker
|-------->| eseguibile |
 ----------                 --------------                ---------         
        -------                -----------
   ^                                    |
    |                                    |
    |                             --------
    |-------------------| errori |
                                  --------
Spero tu abbia le idde un pò + chiare.

| volevo fare un SO a 32 bit se possibile, in caso qualcuno mi potesse
| dare una dritta a riguardo mi farebbe un piacere.
Più che una dritta posso darti un augurio.
Durante il corso di S.O. 2 anni fa abbiamo visto, per vedere i vari moduli
necessari, le funzioni di un SO generico etc, i sorgenti del kernel della
versione 2.xx slackware di Linux. Come tesina in gruppi alcuni dovevano
MODIFICARE il kernel (un incubo la sola ricompilazione di durata di c.a.
mezz'ora sperando che tutto vada bene... per chi doveva modificare il
file-system c'era il rischio di dover reinstallare linux dopo ogni
compilazione mal riuscita o con qualche errore).
Al mio gruppo è toccato analizzare lo START del S.O. , cioè dal momento in
cui il kernel viene caricato in memoria al momento che parte il primo
processo (INIT il quale dovrà configurare poi tutto il sistema).
Questa è la parte più rognosa perchè da INIT in poi puoi "personalizzarti"
il sistema come vuoi ma prima è necessario inizializzare la memoria con
tutte le tabelle e le liste dei processi, i formati dei processi, ma
soprattutto, a monte, è necessario fare il passaggio da 16 a 32 bit il che
significa conoscere bene non solo l'asm o assembler o quello che sia, bensì
la struttura interna della CPU 386, come vuole allocata la memoria (tutti i
sistemi a 32 bit hanno uno spazio + o - identico e allo stesso indirizzo per
la paginazione e la segmentazione), conoscenza di tutte le interrupt e
relativa gestione. Si devono conoscere anche le interrupt basi del bios
perchè fino al momento che viene non viene eseguita l'istruzione che switcha
da 16 a 32 bit quelle vanno utilizzate per la gestione del sistema,
dopodichè devi crearti il "sostituto" del bios. Ultimo passo (ne ho saltati
molti che più non ricordo) va inizializzato il modulo di "task switcer" per
il passaggio da un task all'altro il quale deve essere veloce a "congelare"
il task in corso, piazzarlo in coda alla lista e "scongelare" quello in
coda. In linux questo avviene (avveniva) con 6/7 istruzioni assembler e una
lunga riga in C....
Quell'analisi è stata un incubo! In tutto il kernel, insieme a tutta la
classe, sono stati trovati un paio di bug tra l'altro... immagina come può
complicare le cose.
Un'occhiatina a linux versioni vecchie (p.e. la gloriosa 1.01 anche se io
non l'ho mai vista) piccole, si potrebbe dare. I file sono suddivisi
abbastanza bene per categoria e sufficentemente commentati. Penso che su
ftp.uniroma2.it
 (la mia università) dovresti trovarceli (una volta c'erano).
Comunque devo dire che anche a me piacerebbe molto fare un SO ma non ho le
competenze giuste per farlo... semmai un 16 bit che è molto più semplice da
realizzare (si possono addirittura sfruttare le risorse del bios)
Non posso consigliarti alcun libro, noi abbiamo fatto tutto con gli appunti
del professore (in quel corso, di ufficialmente 3 mesi ma che ha rubato
anche tutta la sessione [esami il 20 luglio... un caldo....] con anche 6-8
ore al dì di laboratorio, abbiamo imparato da 0 l'assembler spinto, il C
abbastanza avanzato [compresi i "trucchi anti-ottimizzazioni" in alcuni casi
necessari], la struttura del 8086,286,386,486,pentium (per fortuna non c'era
ancora il P II) con relativa segmentazione&paginazione della memoria, i
comandi linux, la teoria dei S.O. , la concretizzazione di ogni singolo
modulo di teoria.... insomma un abisso. Posso dire che quel solo corso mi da
ora la possibilità di lavorare come sistemista unix... [ogni tanto vado a
rivedere gli appunti che mantengo come fossero oro perchè forse lo sono di
più]).
Ciao, Matteo

 Spero tu abbia le idde un pò + chiare.
Si, non offenderti se te lo dico, ma ho chiarito il punto che tu usi un
metodo di programmazione preistorico. :-)
E questo spiega anche la mia incomprensione alla tua differenziazione tra
compilatore e linker.
Ok.
Ciao.

 non 
esiste


 


Qui secondo me stai travisando deliberatamente cio' 
che ho detto sopra. Non
ho detto che non esistono, più precisamente ho detto 
che in windows e dos
non esistono, o se esistono non vengono usati dai SO. 
Dimostrami il
contrario.
Esistono e vengono usati solo all'interno di 
alcuni ambienti di
programmazione, come il C e l' Object Pascal, dove, in 
quest'ultimo,  hanno
estensione .dcu, i quali non sono certo pronti da 
essere interpretati dalla
cpu, come tu invece sostieni.


 


Hai mai provato a scrivere una funzione 
equivalente a printf()??


Nel caso in cui lo farai ti renderai conto 
che il C non basta e dovrai 


linkare il tuo codice C insieme ad un file 
.obj che contiene (scritto 


naturalmente in assembler ) quello che 
manca nel tuo cod. C

Più che chip è una eprom , modificabile 
volendo basta mettere il bios


in un programmatore di eprom e scaricare al 
suo interno il file..


indovina un pò???? OGGETTO .obj capito 
ora?? in realtà le eprom hanno 


estensione .rom ma è totalmente 
uguale.  


 


 Se tu pensi che gli unici eseguibili che 
esistono sono solo quelli dentro i
file dell'harddisk con estensione exe o 
out, sbagli di grosso. Vediamo un
pò: mai sentito parlare di .dll ? Secondo 
te, sono eseguibili, o no?


 


.dll?? come corri veloce.Tra progettare un 
SO ed una dll ce n'è di strada,


le dll o 
similari
  

esistono in qualsiasi SO (con x-window e non) che sia 
stato 


progettato; essenzialmete esse 
permettono la programmazione all'interno 


del SO stesso.


In windows all'interno delle 
dll si possono 
trovare 
tutte le funzioni (
messe 



a disposizione dalla microsoft)con cui 
puoi progettare le tue interfacce od 


anche aprire una connessione remota ect 
ect... esse sono anche dette API.


La grande novità delle dll è che esse 
vengono caricate in memoria solo 


quando viene chiamata quella determinata 
API al contrario quindi di una 


programmazione usuale che prevede la 
compilazione di tutto il codice usato
,


da cui il nome dynamic linked list, in caso 
contrario usi una Static linked list;


queste le + usuali, poi volendo uno si può 
anche invetare tipi diversi.



Programmazione preistorica?? 



Diciamo pure  che il tuo modo di 
programmare è abbastanza diverso dal mio, 


sai qual'è il linguaggio di + basso livello 
??(<--guarda che non è l'assembler).


In realtà ho postato il mio intervento in 
questo punto poichè si parlava di sistemi operativi in quanto essi sono il 
classico esempio di realizzazione di un software dove neanche il C basta e tocca 
scendere ancora di livello arrivando all' assembler; essenzialmente lo 
si fà  perchè può andare + che bene per richiamare tutti gli interrupts 
presenti su una macchina media.


 


In finale non volevo farne una discussione ma visto che ho scritto 
un 


interprete in C e per il C, e tutto quello di cui ho parlato finora 
l'ho dovuto


tenere in considerazione, 
ho voluto dire la mia a 
riguardo.


 


Una nota a riguardo 
dell'interprete:


Il parser  php  altro non è che 
un interprete cui token di lettura e quindi sintassi del linguaggio 
stesso,  sono stati stabiliti a priori, ed il quale sfruttando una API di 
apache interagisce con esso al fine di processare le pagine "al volo"  là dove 
esse hanno estensione .phpx (x=numero versione).Lerdorf ebbe una grande idea 
nell' invetarlo anche perchè: te saluto CGI.


 


ciao





ops mi correggo volevo dire : 
dynamic-link library



più]).
umm che professore era magari trovo gli appunti su university.it....
Salutoni


| Dal punto di vista didattico potrebbe essere molto interessante creare
| una virtual machine..magari semplice basata sul modello a registri di
| Von Neumann dotata di un suo psudo asm semplificato.
| A questo punto potrebbe beniussimo scrivere un so funzionante su
| questa virtual machine e un compilatore che appunto compili per la VM.
Interessante come proposta... poi magari si potrebbe costruire un SO basato
su questa "piattaforma" per dare ancor più didatticità... cosa ne pensi come
proposta?
Nell'esame di reti logiche abbiamo utilizzato una VM, un processore virtuale
con, se non erro, 16 o 32 istruzioni, di cui ognuna occupava un byte (altro
che l'x86, che al mio ultimo, vecchio, aggiornamento occupavano da 1 a 4
byte...), e con quel linguaggio programmavamo.
Ciao, Matteo

| a dire la verita' neanche io da solo avrei competenze sufficenti per
| farlo ma conto di coinvolgere un paio di amici con i quali
| condividiamo le stesse passioni ma deviate in sottoargomenti
| diversi... insieme credo che dovremmo essere in grado di farcela...
allora rinnovo gli auguri a te e ai tuoi amici... poi fammi sapere se e come
procede... chissà che gli amici non diventano 3 (con me) in rete come ha
fatto Linux Torvalds.
| >Non posso consigliarti alcun libro, noi abbiamo fatto tutto con gli
appunti
| >del professore (in quel corso, di ufficialmente 3 mesi ma che ha rubato
| >anche tutta la sessione [esami il 20 luglio... un caldo....] con anche
6-8
| >ore al dì di laboratorio, abbiamo imparato da 0 l'assembler spinto, il C
| >abbastanza avanzato [compresi i "trucchi anti-ottimizzazioni" in alcuni
casi
| >necessari], la struttura del 8086,286,386,486,pentium (per fortuna non
c'era
| >ancora il P II) con relativa segmentazione&paginazione della memoria, i
| >comandi linux, la teoria dei S.O. , la concretizzazione di ogni singolo
| >modulo di teoria.... insomma un abisso. Posso dire che quel solo corso mi
da
| >ora la possibilità di lavorare come sistemista unix... [ogni tanto vado a
| >rivedere gli appunti che mantengo come fossero oro perchè forse lo sono
di
| >più]).
|
| umm che professore era magari trovo gli appunti su university.it....
non sapevo manco che esistesse questo sito, comunque mi riferivo agli
appunti scritti da noi stessi di nostro pugno con penna mentre spiegava alla
lavagna rinforzati dalla conferma/correzione che trovavamo al laboratorio.
Anche perchè in tre mesi con 5 ore a settimana (se non erro) tutto quello
che è scritto sopra non lo puoi esaurire (sai quanto ci vuole a imparare
contemporaneamente il pentium, il C, la teoria dei S.O.? penso che lo sai
visto che li usi se ho ben capito). Sono servite piuttosto le 6-8 ore (per
imparare ad utilizzare BENE anche internet che a quel tempo pochi avevamo
perchè ancora non c'era internet gratis) di laboratorio con i sorgenti sotto
gli occhi tramite i quali rubavamo qualche trucchetto/sintassi di C e ASM.
Comunque è buono che hai una equipé perchè io da solo non sarei riuscito
(penso) ad analizzare QUEL kernel... immagina scriverlo!!!
Ciao, Matteo

 La cpu puň solo interpretare il significato di una sequenza di 1 e di 0
Se vogliamo essere cosě pignoli la cpu "capisce" solo dei segnali elettrici
su dei semiconduttori!


Giusto! (che poi noi li interpretiamo e gli diamo nomi e li chiamiamo asm,
assembly, assembler, obj e chi piů ne ha piů ne metta questo non importa)
Ciao, Matteo


Ciao


| su quel sito appunto ci si scambia gli appuntid egli studenti (proprio
| quelli a mano :D)
| Dai solo il nome del professore che magari trovo anche qualche sua
| dispensa (magari dopo ne ha fatte :D)
dubito, conoscendo il professore e data la natura del corso (ovvero, al 99,9
% non puoi dare l'esame senza aver seguito il corso, di massimo 30-40
persone... come alle superiori, in cui ci sono esercizi assegnati durante il
corso e corso che si impara senza nessuno scritto come ti dicevo ma con
molti scritti... [ frammenti di commenti sul codice... i cui frammenti te li
devi trovare da solo, .pdf , altro ])
La nostra č stata la classe "pioniere" (se si scrive cosě). prima S.O. si
teneva su minix (e altri riguardo al funzionamento teorico ma non al codice)
da un'altro professore; poi č venuto lui (completamente, devo dirlo,
incompetente riguardo linux&comandi... l'anno successivo si č rimesso in
linea, si č messo sotto a studiare, pare, e l'assistente
ex-sistemista&installatore unix). Ora non so come č il corso...
[scusami se ti racconto cose che non centrano niente ma sono fatto cosě, se
non allungo non sono contento]
Ciao, Matteo

 :D
