Perché non avere un sistema operativo basato su linguaggio di alto livello? Le lingue di basso livello sono più efficienti?

Senza essere presuntuoso, vorrei che tu considerassi la possibilità di questo. La maggior parte dei sistemi operativi oggi si basa su linguaggi di livello piuttosto basso (principalmente C / C ++) Anche quelli nuovi come Android usano JNI e l'implementazione sottostante è in C

In effetti, (questa è un'osservazione personale) molti programmi scritti in C funzionano molto più velocemente rispetto alle loro controparti di alto livello (ad esempio: Transmission (un client bittorrent su Ubuntu) è molto più veloce di Vuze (Java) o Deluge (Python) ). Anche i compilatori Python sono scritti in C, sebbene PyPy sia un'eccezione.

Quindi c'è un motivo particolare per questo? Perché tutti i nostri cosiddetti "linguaggi di alto livello" con i grandi concetti "OOP" non possono essere utilizzati per creare un sistema operativo solido?

Quindi ho sostanzialmente 2 domande.

1. Perché le applicazioni scritte in lingue di basso livello sono più efficienti delle loro controparti HLL? Le lingue di basso livello hanno prestazioni migliori per il semplice motivo che sono di basso livello e sono più facili da tradurre in codice macchina?
2. Perché non abbiamo un sistema operativo completo basato interamente su un linguaggio di alto livello?

Microsoft ha fatto alcune ricerche molto interessanti in questa direzione, se guardi a Singularity:

http://research.microsoft.com/en-us/projects/singularity/

Inoltre, Mothy Roscoe et al. Hanno lavorato su Barrelfish che utilizza il linguaggio di programmazione dei vincoli Eclipse come servizio OS per risolvere tutti i tipi di problemi di gestione del sistema operativo e di allocazione delle risorse:

http://www.barrelfish.org/

Molto dipende da dove metti la divisione tra le lingue di basso e alto livello. Ad esempio, persone diverse tendono a mettere un linguaggio come C ++ su lati diversi di quella divisione.

Per quanto riguarda le tue domande:

1. Non credo che ci sia una tale differenza tra le lingue di basso e alto livello, ma più una differenza tra le lingue interpretate e le lingue che si compilano in istruzioni native.

   Ma potrebbe esserci anche una differenza nella cultura tra i programmatori, in cui quelli che usano un linguaggio di basso livello si concentrano maggiormente sugli aspetti prestazionali delle scelte (progettuali) che fanno.

2. Se consideri C ++ di alto livello, allora c'è almeno un SO scritto interamente in un linguaggio di alto livello (Symbian OS è scritto in C ++). Ciò che ti impedisce di scrivere un sistema operativo nella maggior parte delle lingue di alto livello sono due cose:

   • Un sistema operativo richiede un accesso di basso livello alla memoria e all'hardware ed esegue trucchi sporchi su di essi. Questo tipo di accesso è generalmente considerato non sicuro per i programmi a livello di applicazione, quindi molte lingue di alto livello non lo consentono.
   • Un sistema operativo deve essere eseguito senza la presenza di software di supporto, come gli interpreti. Ciò rende estremamente difficile scrivere un sistema operativo in una lingua che non può essere facilmente compilata in istruzioni native.

Ci sono una serie di buone ragioni per questo.

La lingua di basso livello di oggi era la lingua di alto livello di ieri

Sì, che ci crediate o no, una volta persino C era visto come un linguaggio di alto livello. Anche ~ 20 anni fa era abbastanza comune vederlo descritto come un linguaggio "di medio livello". Questo era un tempo prima che OO fosse così popolare come lo è oggi, Java non esisteva, C # non esisteva, anche C ++ non era ancora correttamente standardizzato.

Inerzia storica

I sistemi operativi che usi oggi hanno radici profonde nella storia. Windows risale agli inizi / metà degli anni '80, Unix risale agli inizi / metà degli anni '70. C'è MOLTO vecchio codice funzionante nei sistemi operativi e generalmente non si desidera riscrivere il vecchio codice funzionante.

Ad un certo punto devi passare all'hardware

Questo succede nel kernel, succede nei driver, succede nei sottosistemi di gestione della memoria, succede nel filesystem. Sicuramente puoi sovrapporre una lingua di alto livello sopra di essa, ma hai ancora bisogno della possibilità di accedere più direttamente all'hardware che offre una lingua di livello inferiore.

portabilità

Non intendo la portabilità su hardware diverso o su un sistema operativo diverso come oggi è più comunemente compreso; questo è più sottile. C'è un grande vantaggio nel fornire un'interfaccia basata su C per qualcosa, ed è il fatto che praticamente ogni altra lingua esistente può collegarsi a C. Anche l'API di Windows è ancora un'API basata su C per questo motivo.

Preferenza personale

Alcune persone preferiscono semplicemente programmare in questo modo, e questo può essere un fattore importante. Ad esempio, Linus Torvalds ha un famoso rant contro C ++, il che rende abbastanza chiaro che, per quanto lo riguarda, C sarà sempre il suo strumento preferito per questo tipo di lavoro (il contenuto del rant e se sei d'accordo o meno con esso è irrilevante per questa discussione; il fatto che il rant esista è sufficiente).

Nel loro insieme, questi dovrebbero stabilire chiaramente perché un sistema operativo era originariamente scritto in qualcosa come C ai vecchi tempi, e perché pezzi molto significativi di esso - anche oggi - rimangono tali.

Un motivo principale per il dominio di C sui sistemi operativi risiede nella storia: gli attuali sistemi operativi tradizionali come Windows e tutte le forme di Unix (BSD, Solaris, HP-UX, MacOS X, ... così come i cloni come Linux) risalgono al passato molto tempo prima che OO e altri costrutti di "alto livello" diventassero mainstream.

Per il nucleo del sistema operativo oltre alle prestazioni ci sono esigenze molto specifiche sulle istruzioni hardware e uno ha il pieno controllo sulla memoria quali linguaggi come C fanno molto bene.

Per i sistemi embedded a volte ci sono sistemi operativi che usano linguaggi di livello superiore per parti maggiori del sistema. Un esempio notevole è JavaOS di Sun.

Per sistemi operativi diffusi un esempio notevole che non usa C è anche il classico MacOS prima di MacOS X - che era in gran parte scritto in un dialetto di Pascal che consentiva una qualche forma di orientamento agli oggetti.

Innanzitutto, ci sono alcuni problemi di bootstrap. La maggior parte delle funzionalità che semplificano le lingue di alto livello si basano su astrazioni che un kernel deve fornire da solo. Come si scrive un gestore della memoria in una lingua che richiede un gestore della memoria? Come si scrivono i driver I / O senza utilizzare le belle librerie standard I / O della propria lingua? Come si creano le primitive di threading e sincronizzazione senza utilizzare le librerie del linguaggio?

In secondo luogo, è estremamente utile e molto più leggibile durante la scrittura di sistemi operativi per poter assegnare una variabile a una posizione di memoria specifica. Questo è facile in C, e ogni singolo programmatore C sa come farlo. Se è possibile anche in lingue di livello superiore, è così raro che solo i guru sanno come farlo.

In altre parole, quando si considerano tutte le limitazioni e le modifiche che si dovrebbero accettare, C e C ++ iniziano a sembrare molto più facili.

Prima di tutto, il bootstrap richiede che almeno una piccola parte sia scritta in Assembly o equivalente.

In secondo luogo, non v'è stato un sistema operativo scritto in un indiscutibilmente HLL - Lisp Machine . (Il fatto che fallisse commercialmente aveva più a che fare con altri hardware che diventavano meno costosi più velocemente e il trionfo di Peggiore è migliore che con carenze della sua filosofia o del suo design).

Terzo, il C ++ è piuttosto orientato agli oggetti e di alto livello, quindi, come altri hanno sottolineato, il sistema operativo Symbian è un altro esempio.

In quarto luogo, al momento non sono necessari nuovi sistemi operativi. Abbiamo già un paio di versioni di Linux e BSD che funzionano praticamente su qualsiasi hardware e creare un nuovo sistema operativo da zero è piuttosto costoso.

Per meglio mettere in fase ciò che ho scritto in precedenza.

Le macchine Burroughs 5xxx - 6xxx non avevano un linguaggio di assemblaggio. La lingua più bassa disponibile era un'estensione dell'Algol. L'Algol è stato implementato in hardware. Il sistema operativo e tutte le lingue sono state scritte in Algol. Ha superato tutte le macchine della concorrenza del tempo. Richiedeva inoltre una quantità significativamente inferiore di codice che ne rendeva molto più semplice la manutenzione. Aveva hardware stack che supportava un linguaggio ricorsivo come un Algol.

Il sistema operativo Burroughs si è evoluto in una versione chiamata MCP. MCP attualmente funziona su sistemi Unisys.

La maggior parte delle lingue di livello superiore che menzioni hanno una funzionalità che non si adatta bene ai sistemi operativi: gestione automatica della memoria. Non puoi fare affidamento su un garbage collector durante la scrittura di un sistema in tempo reale, sia soft (che è un sistema operativo) o anche peggio. Per citare Tanenbaum [i]:

Alcune cose che C non ha includono stringhe, thread, pacchetti, classi, oggetti, sicurezza dei tipi e garbage collection integrati. L'ultimo è un punto fermo per i sistemi operativi. Tutta la memoria in C è statica o esplicitamente allocata e rilasciata dal programmatore, di solito con la funzione di libreria malloc e free . È quest'ultima proprietà - controllo totale del programmatore sulla memoria - insieme a puntatori espliciti che rende C attraente per la scrittura di sistemi operativi. I sistemi operativi sono fondamentalmente sistemi in tempo reale in una certa misura, anche quelli di uso generale. Quando si verifica un interruzione, il sistema operativo potrebbe avere solo pochi microsecondi per eseguire alcune azioni o perdere informazioni critiche. Avere la spazzatura avviata in un momento arbitrario è intollerabile.

Ora, potresti sostenere che anche C ++ è un buon candidato poiché offre la gestione manuale della memoria. Il C ++ è già stato utilizzato in alcuni sistemi operativi come Symbian (menzionato da Bart ) e BeOS. Ma IMHO C è ancora il linguaggio più veloce che può essere portato in molte architetture senza un grande sforzo (in contrasto con l'assemblaggio di un'architettura specifica).

_{[i]: Modern Operating Systems 3rd edition, pagina 73}

Come altri hanno sottolineato, diversi sistemi operativi sono stati scritti in lingue di alto livello. Forse quello che vuoi dire è che tutto il successo, mercato di massa, sistema operativo generico è stato scritto in una combinazione di assembly, C e C ++?

La maggior parte delle lingue di alto livello hanno tonnellate di funzioni utili che comportano un costo associato alle prestazioni. La gestione automatizzata della memoria è un esempio evidente, il controllo dei limiti degli array è un altro. Se si sta scrivendo un sistema operativo generico, è probabile che si verifichino situazioni in cui la penalità prestazionale di queste utili funzioni è maggiore di quella che si è disposti a pagare. A quel punto ti piacerebbe essere in grado di spegnerli. Lingue come Python, C # e Java variano in base alle funzioni che è possibile disattivare, ma nessuna di queste è versatile come C o C ++ in questo senso.

Sotto questo aspetto C e C ++ sono quasi versatili quanto il puro assemblaggio. Se decidi di aver bisogno di dieci diversi gestori di memoria che coprono dieci diversi scenari di allocazione della memoria, puoi implementarli tutti in C e C ++ e caricarli e scaricarli come ritieni opportuno. Diamine, non è nemmeno necessario collegarsi alle librerie di runtime C standard o al codice di avvio se non si desidera.

La vera risposta è denaro . Non c'è abbastanza beneficio percepito da un sistema operativo linguistico di alto livello da giustificare la spesa delle risorse per costruirne uno e poi spingerlo nel mainstream. Ad esempio, la creazione di un nuovo driver comporta costi enormi per ogni componente hardware che deve supportare.

Esistono vari sistemi operativi scritti in lingue di alto livello, con lo scopo principale della ricerca, come Oberon e Singularity .