Newsgroup: it.comp.os.dibattiti
Titolo: Costruzione di S.O.

Forse la mia è una domanda un pò strana...
..Esistono compilatori che permettono di costruire Sistemi operativi?
Grazie  a chi mi risponderà
saluti
-- 
Posted from 
ppp-123-22.29-151.libero.it
 [151.29.22.123] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

..Esistono compilatori che permettono di costruire Sistemi operativi?
Tanti, forse tutti, ma mi dici che intenzione avresti di fare,
dopo che lo sai?
-- 
(*metallikop*libero*it*)
{
http://web.tiscali.it/mbsoftware
}

 ..Esistono compilatori che permettono di costruire Sistemi operativi?
Hai le idee *molto* confuse, a riguardo.
Bye,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)               [ 
http://digilander.iol.it/ebassi
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

..Esistono compilatori che permettono di costruire Sistemi operativi?
Più o meno tutti.
-- 
ciao, | "You're one of those condescending Unix computer users!"
Marco | "Here's a nickel, kid. Get yourself a better computer"  -- Dilbert
      | (Ri)scoprire fidonet: 
http://bbs.bofh.it

Un sistema operativo non é niente di più di un programma (con delle
funzioni molto particolari) per utilizzare il mucchio di ferraglia che
costituisce il computer.
Un compilatore é necessario nella realizzazione di qualsiasi programma,
incluso un sistema operativo.
Di solito più ti avvicini alla macchina (nel senso di interazione con i
componenti) più hai bisogno di linuguaggi "adatti" a risolvere
determinati problemi; ecco perché di solito un sistema operativo non é
scritto in Pascal, Clipper o Basic ma piuttosto in Assembler, C, C++ e
Java (Java un pò meno).
In realtà vengono sfruttati linguaggi diversi per risolvere problemi
diversi perché in realtà un sistema operativo é un programma molto
grosso e difficile.
Mi sono sforzato di rispondere in modo comprensibile a chiunque, spero
che nessuno me ne vorrà.

 ..Esistono compilatori che permettono di costruire Sistemi operativi?
Boh certo.. puoi scriverli in C, C++ o altri linguaggi.
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

 ..Esistono compilatori che permettono di costruire Sistemi operativi?
Si', ed esistono anche sistemi operativi che permettono di costruire 
compilatori. Il che e' un po' ricorsivo :)
Cmq, Gcc ad esempio e' un compilatore col quale costruiscono Linux, e vari 
sistemi OS Embedded...
--
                Davide "gatto feroce" Inglima
   " gli Dei cessano di esistere quando nessuno li venera piu' "
      ( citando OmbreDiFantasmi su it.hobby.giochi.gdr.dnd )
 
http://digilander.iol.it/nekochan/

 saluti
Tutti i compilatori tirano fuori eseguibili, e un s.o e' una serie di
eseguibili, indi, la risposta e' affermativa

 Assembler, C, C++ e Java (Java un pò meno).
il prossimo AmigaOS (o comecavolosichiama) non sarà scritto proprio in 
Java?
-- 
Nato nel vizio, morto nel supplizio
Nato nel peccato, ad entrare sia invitato

 Grazie  a chi mi risponderą


 Java?
No.
Fabio Alemagna

Dalla domanda, si desume che la risposta č inutile.
Bah.... in realta` credo che la cosa andrebbe ridimensionata. Un formalismo
per la descrizione di un sistema operativo immagino che introdurrebbe delle
limitazioni sulla classe di sistemi rappresentabili, ma non e` di per se'
impossibile (e magari potrebbe essere meno limitativo di quello che sembra a
me). Certamente, nel campo della modellistica, e` possibile e forse anche di
una qualche utilita`, un simulatore di sistemi operativi. In generale,
insomma, se puo` non avere un gran senso chiedere di compilatori di sistemi
operativi, un CAOS[1] Design e` certo possibile e, dai risultati, pare anche
che diversi ne abbiano fatto uso.
Ciao.
[1] Computer Aided Operative Systems

 ..Esistono compilatori che permettono di costruire Sistemi operativi?
Il termine "costruire" e' improprio. Per compilare un sistema operativo 
si usano normali compilatori.
):E...

 saluti
il grosso problema da gestire sono la mutua esclusione delle sezioni
critiche
per gestirle o usi direttamente a livello assembler i meccanismi che ti
offre l'archittetura
oppure il linguaggio contiene meccanismi per gestirlo (Monitor,
semafori,ecc)

 Java?
Il prossimo AmigaOS non credo che esisterà mai davvero.

critiche
Il DOS mica ce l'aveva :) eppure da molti è tranquillamente considerato 
un sistema operativo :) Alcuni lo definiscono un semplice ammasso di 
interrupt handler, potrebbero pure avere ragione loro


possono eseguire codice java.
Java è solo un linguaggio. Sotto Java c'è pur sempre dell'assembler, e 
la CPU è quello che esegue


> Bah.... in realta` credo che la cosa andrebbe ridimensionata.
In realtà credo che la cosa non abbia senso, con tutto il rispetto per il
tuo impegno di trovarne uno.
Alla suddetta domanda si risponde "si" salvo obiettare che in un certo
contesto è una domanda stupida (un po come chiedere: esistono organi
genitali capaci di riprodurre un uomo?)

 la CPU è quello che esegue
Per quanto ne so, Java e' un linguaggio macchina virtuale... anzi, direi
una... macchina virtuale.
Non e' escluso che qualcuno abbia fatto una cpu in grado di eseguire
direttamente Java: d'altronde, e mi sembra piu' difficile, in passato eì
esistito un processore in grado di eseguire... pascal sorgente.  *:-)
bye G.L.

 esistito un processore in grado di eseguire... pascal sorgente.  *:-)
È quello che fa Jazelle:
http://www.arm.com/armtech/jazelle?OpenDocument
I processori ARM con estensioni Jazelle eseguono direttamente in
hardware il 95% delle istruzioni in un binario Java, il restante 5%
viene emulato in software mediante codice ARM. La comodità principale
è che si può continuare ad usare senza grossi grattacapi un sistema
operativo nativo, che girerà usando istruzioni ARM o Thumb, passando
in modalità Java al momento opportuno mediante una apposita
istruzione - non è necessario riscrivere tanto codice o portarlo su
una nuova architettura.
-- 
 "Viva i cessi, sian benedetti Viva i bagni, le toilettes e i gabinetti"
 Rudi Chiarito         SGML/XML, user interface, i18n         Amiga Inc.
 
ru...@amiga.com
 
http://amiga.com/

 ha scritto:
[cut]
Mi scuso con il ng per l'intrusione... sono nuovo di queste parti....
volevo solo salutare una mia vecchia conoscenza! Ciao bit estroso!
Amiga rulez, Linux livez :-)))
-- 
Bye. Cisco.
// Registered Linux User #227472  (
http://counter.li.org
)
// -- Linux is the answer, now what was your question? --

 istruzione
Si suppone un notevole incremento della velocita', dal momento che il 95%
delle istruzioni non dovrebbero essere piu' interpretate ma eseguite
direttamente...   :-)   Dovrebbe essere anche decisamente piu' snella
l'implementazione del jre per queste architetture. Fa caso notare che c'e' chi
crede molto nel java non solo in... termini software.   :-)
bye G.L.

software. :-)
Io credo in Java ! Non tanto per il linguaggio (Per uno che proviene
da  Oberon,  M2, Pascal  e  C,  Java  e'  come l'Eldorado),  ma  per
l'immensa disponibilita' di classi liberamente utilizzabili.
-- 
 __
| _         "The Internet is slow, could you please reboot it ?"
|__|iambo   mailto:
gabr...@giambonini.com
 
www.giambonini.com

 l'immensa disponibilita' di classi liberamente utilizzabili.
Yessss...    :-)
bye G.L.
p.s. : devo provare ad installare su linux o solaris instant basic 4
(alcyonsoft), un clone del ms vb4 in java, per portare in java progetti vb4,
installer in java...

 Anch'io credo in java
Curiosità.
Quale l'utilizzo di Java? Per che tipo di progetti?
Ciao.

"H.P.L." wrote:

Nello specifico della ditta per la quale lavoro, od in generale?
In ogni caso, col java in teoria ci puoi fare tutto... (e' una
piattaforma realmente aperta, secondo le intenzioni di sun)
bye G.L.

 In ogni caso, col java in teoria ci puoi fare tutto...
Vedi sopra.
Ciao.

 degli errori.
Questo e' proprio curioso, visto che il GC si propone proprio di 
*evitare* quel tipo di problemi. E direi che ci riesce piuttosto bene...
Fabio Alemagna

 problemi. E direi che ci riesce piuttosto bene...
Assolutamente no.
Se noti infatti, in qualunque esempio di codice scritto per "decantare"
le meravigliose virtù del GC (in qualunque linguaggio ciò venga fatto)
viene tralasciata la gestione degli errori.
Non si tratta di una semplificazione, ma di un vero e proprio atto di
"falsificazione". E ciò è presto detto. Con il GC lo sviluppatore non
può sapere *quando* una risorsa da lui precedentemente acquisita verrà
rilasciata, perché è il GC a farlo e a decidere come e quando.
Quindi il GC semplifica la gestione della memoria, ma in cambio complica
la gestione delle risorse (rendendo necessario occuparsene a "mano"),
invalidando il fondamentale idioma "resource acquisition is
initialization", invalidamento che complica di conseguenza la gestione
degli errori.
Ciao.

 degli errori.
Ancora non ho capito in che modo... Un esempio pratico?
Fabio Alemagna

 pratico?
Un esempietto semplice e banale:
In C++:
if (...)
{
    ....
    std::ofstream of("pippo.txt");
    ....
}
....
if (...)
{
    ....
    std:.ofstream of1("pippo.txt")
    ....
}
In Java:
if (...)
{
    ...
    File of = new File("Pippo.txt");
    ...
}
...
if (...)
{
    ...
    File of1 = new File("Pippo.txt");
    ...
}
Vediamo se capisci da solo quale è il problema del codice scritto in
Java (dovuto al GC) e come porvi rimedio.
Ciao.

 Ancora una volta: OOP.
Ooooh...  ti si e' incantato il disco?

Hu? Io non vedo alcun problema, a parte il fatto che *dimentichi* di 
invocare il distruttore sul file, nelal versione java. Il GC non centra 
una mazza, dovresti invocare il distruttore anche in C++ se invece che 
allocare gli oggetti sullo stack li avessi allocati nello heap, tramite 
la keyword "new". Proprio come in java.
Ma in ogni caso... dove starebbero gli errori e le loro gestioni?
Fabio Alemagna

 invalidando il fondamentale idioma "resource acquisition is
Fondamentale per il C++...


 Java (dovuto al GC) e come porvi rimedio.
Hai dimenticato un "file.close()". Tralasciarlo è errato, così come è
errato bloccare un oggetto e non sbloccarlo più.
Lo stesso esempio in Eiffel, usando due approcci diversi:
local
  of: FILE
  of1: FILE
do
  ...
  if (...) then
    ...
    !!of.make_open_write("pippo.txt")
    ...
  end
  ...
  if (...) then
    ...
    !!of1                       -- crea l'oggetto
    of1.open_write("pippo.txt") -- associalo al file pippo.txt
    ...
    of1.close
    of1.open_read("topolino.txt")
    ...
  end
  ,,,
end
Come vedi, of1 può essere chiuso e "ricollegato" ad un file diverso,
adottando una strategia di "riciclaggio". Volendo fare l'avvocato del
diavolo, in tal modo se devi aprire N file non contemporaneamente,
puoi usare un solo oggetto per tutti, senza perdere tempo in N
allocazioni e deallocazioni. Tra l'altro, tralasciando "of1.close" e
compilando il programma con pre- e postcondizioni attive, ti verrebbe
segnalato che stai tentando di accedere ad un altro file senza aver
chiuso quello corrente.
Eiffel è ad oggetti tanto quanto il C++, se non di più, visto che a
differenza di C++ è impossibile non scrivere ad oggetti (se davvero
sei masochista, il peggio che tu possa fare è creare un solo oggetto
con un solo metodo che includa tutto il tuo codice). Non esiste
nemmeno il concetto di main().
Il principio che l'inizializzazione di una entità e l'acquisizione di
risorse ad essa associate siano inscindibili è totalmente indipendente
dalla programmazione ad oggetti. Si tratta soltanto di una particolare
decisione di chi progetta una classe. Come ho mostrato nell'esempio
sopra, se ne può fare anche a meno o addirittura usarlo solo quando
ritenuto opportuno.
Quanto alla sua effettiva utilità, si tratta del classico specchietto
per le allodole, o zuccherino che dir si voglia. L'apertura di un file
può fallire per molteplici motivi: mancanza di memoria per creare
l'oggetto "file", file inesistente, diritti di accesso insufficienti,
ecc. Inglobare creazione dell'oggetto e allocazione delle risorse
associate in una sola operazione, né impedisce a tali problemi di
insorgere né evita al programmatore di scrivere X spezzoni di codice
per gestire le X condizioni di errore significative (spero che tu non
fascia di tutta l'erba un fascio e semplicemente consideri tutti gli
errori equivalenti, gestendoli tutti allo stesso modo).


 significative
Ancora una volta, mi evita di gestire a mano le risorse utilizzate.
Vedi l'esempio che ho scritto nel post di risposta a Fabio.
Ciao.

 loro gestioni?
Riscriviamo il tutto con un'adeguata gestione degli errori:
try
{
    if (...)
    {
        std::ofstream of("Pippo.txt");
        if (!of)
            ...
        ...
    }
    if (...)
    {
        std::ofstream of1("Pippo.txt");
        if (!of1)
            ...
        ...
    }
}
catch(...)
{
     ...
}
In Java:
if (...)
{
    File of = null;
    try
    {
        of = new File("Pippo.txt" ) ;
         ...
    }
    catch( ... )
    {
         //gestisco l'errore
    }
    finally
    {
        if (of != null)
            of.close() ;
    }
}
if (...)
{
    File of1 = null;
    try
    {
        of1 = new File("Pippo.txt" ) ;
        ...
    }
    catch( ... )
    {
         //gestisco l'errore
    }
    finally
    {
        if (of1 != null)
            of1.close() ;
    }
}
Gli esempi sono perfettamente equivalenti, e mi pare ben ovvia la
complessità maggiore del codice Java dovuta alla presenza del GC. E
questo per 10 banali righe di codice. In un applicativo completo le
differenza può diventare molto grande.
Ciao.

 Fondamentale per il C++...
Fondamentale per semplificare la vita del programmatore.
Non fondamentale (perché non si può utilizzare) in Java. In questo
caso si utilizza l'altra fondamentale filosofia, quella della volpe e
l'uva.
Ciao.

 interrupt handler, potrebbero pure avere ragione loro
Oddio, le sue primitive per *un* (uno, 1) programma ce le ha... poi e'
tutto il resto che manca alla definizione di un vero os... il resto
naturalmente si poteva fare andando... "oltre" il sistema, oppure con
apposite estensioni...
Certo, coi parametri odierni, non e' un vero os.
bye G.L.

Quale l'utilizzo di Java? Per che tipo di progetti?
"Server-Side": Con  degli amici abbiamo sviluppato  nel tempo libero
un paio di  applicazioni. Una di queste,  "pinit", sara' disponibile
in  versione  demo  entro l'anno  prossimo.  
www.rcfmedia.ch
,  cosi'
potete vedere pure la mia facciaccia :)
Se tutto va' bene, fra qualche  mese potrete dire ai vostri amici di
aver avuto uno scambio di opinioni in ico.dibattiti con Giambo :)
Ah,  da  dopodomani  invece  potrete  ammirare  stupefatti  un'altra
applicazione  di   java,  per   la  ditta   per  la   quale  lavoro:
finfox.nzz.ch
Sempre che  quella porcheria  di Borland  Application Server  non ci
molli proprio sul piu' bello ...
Credo che il maggiore utilizzo di Java stia appunto nei WEB-Servers,
come applicazioni  "client-side" ho  visto ben  poco. Del  resto, se
dovessi sviluppare  un applicativo portabile, credo  che mi getterei
su wxwindows o su qt ...


genitali capaci di riprodurre un uomo?)
In realta', come ben sai, non sono gli organi genitali a riprodurre
alcunche'. Allo stesso modo, non e' il compilatore che costruisce sistemi
operativi. Quindi, la risposta ad entrambe le domande e' no.
Se invece si chiede (magari confusamente) se esistono sistemi in grado di
riprodursi (o di costruirne altri), se ne puo' parlare (magari non troppo a
lungo).
Ciao.