¿Por qué no tener un sistema operativo basado en lenguaje de alto nivel? ¿Los idiomas de bajo nivel son más eficientes?


44

Sin ser presuntuoso, me gustaría que consideraras la posibilidad de esto. La mayoría de los sistemas operativos actuales se basan en lenguajes de nivel bastante bajo (principalmente C / C ++) Incluso los nuevos, como Android, usan JNI y la implementación subyacente está en C

De hecho, (esto es una observación personal) muchos programas escritos en C se ejecutan mucho más rápido que sus contrapartes de alto nivel (por ejemplo: la transmisión (un cliente bittorrent en Ubuntu) es mucho más rápido que Vuze (Java) o Deluge (Python) ) Incluso los compiladores de Python están escritos en C, aunque PyPy es una excepción.

Entonces, ¿hay una razón particular para esto? ¿Por qué es que todos nuestros llamados "lenguajes de alto nivel" con los grandes conceptos de "OOP" no se pueden utilizar para hacer un sistema operativo sólido?

Entonces tengo 2 preguntas básicamente.

  1. ¿Por qué las aplicaciones escritas en lenguajes de bajo nivel son más eficientes que sus contrapartes HLL? ¿Los lenguajes de bajo nivel funcionan mejor por la simple razón de que son de bajo nivel y se traducen más fácilmente al código de máquina?
  2. ¿Por qué no tenemos un sistema operativo completo basado completamente en un lenguaje de alto nivel?

36
Usted implica que solo los "lenguajes de alto nivel" están orientados a objetos, lo cual no es cierto.
Uooo

2
@rtindru "¿Lenguaje bastante bajo" (principalmente C / C ++)? ¿Cuál es su definición de lenguaje de alto nivel entonces? Debe ser claro acerca de su definición / interpretación del lenguaje de alto nivel. Python es en realidad un lenguaje de secuencias de comandos, ya que se ejecuta directamente en su motor (IDLE o terminal de línea de comando), si aún no se dio cuenta de eso. Hay una muy buena razón (filosófica y práctica) por la cual C / C ++ se usan como lenguajes de implementación para muchos sistemas operativos, pero estoy seguro de que los usuarios avanzados aquí probablemente no se meterán en eso para esta pregunta.
hagubear

10
Android no es un sistema operativo nuevo. Es solo otro sabor de Linux.
Den

3
@hagubear Hay una muy buena razón (filosófica y práctica) por la cual C / C ++ se utilizan como lenguajes de implementación para muchos sistemas operativos . ¿Cuál es esta muy buena razón?
rtindru

2
Si entiendo correctamente, el sistema operativo para máquinas LISP se escribió en LISP. ¿Aunque quizás podría argumentarse que el dialecto utilizado era un lenguaje de bajo nivel?
Robert Fisher

Respuestas:


38

Microsoft ha hecho una investigación muy interesante en esta dirección, si nos fijamos en Singularity:

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

Además, Mothy Roscoe et al. Han estado trabajando en Barrelfish, que utiliza el lenguaje de programación de restricciones Eclipse como un servicio de SO para resolver todo tipo de problemas de administración de SO y asignación de recursos:

http://www.barrelfish.org/


Wow, no puedo votar, necesito 15 repeticiones ... ¡acabo de unirme hoy! Muchas gracias.
rtindru

99
@rtindru: incluso con 1 punto de repetición puede aceptar una respuesta ¿Qué significa cuando una respuesta es "aceptada"?
Marjan Venema

66
Aceptar una respuesta tiende a reducir las nuevas respuestas / discusiones. Personalmente, recomendaría no aceptar (a esta pregunta específica) por al menos otro día.
Brian

1
Añadiría Cosmos al grupo: código abierto, tercero, no tan interesante como la singularidad, ¡pero tengo algunas buenas ideas! cosmos.codeplex.com
Lorenzo Dematté

38

Mucho depende de dónde coloque la división entre los idiomas de bajo y alto nivel. Por ejemplo, diferentes personas tienden a poner un lenguaje como C ++ en diferentes lados de esa división.

Con respecto a sus preguntas:

  1. No creo que haya tanta diferencia entre los idiomas de bajo y alto nivel, pero sí una diferencia entre los idiomas interpretados y los idiomas que compilan las instrucciones nativas.

    Pero también puede haber una diferencia en la cultura entre los programadores, donde una vez que usan un lenguaje de bajo nivel se centran más en los aspectos de rendimiento de las elecciones (de diseño) que hacen.

  2. Si considera que C ++ es de alto nivel, entonces hay al menos un sistema operativo escrito completamente en un lenguaje de alto nivel (Symbian OS está escrito en C ++). Lo que le impide escribir un sistema operativo en la mayoría de los idiomas de alto nivel son dos cosas:

    • Un sistema operativo necesita acceso de bajo nivel a la memoria y al hardware y realizar trucos sucios en ellos. Este tipo de acceso generalmente se considera inseguro para los programas de nivel de aplicación, por lo que muchos lenguajes de alto nivel no lo permiten.
    • Un sistema operativo debe ejecutarse sin software de soporte, como intérpretes. Esto hace que sea extremadamente difícil escribir un sistema operativo en un idioma que no se pueda compilar fácilmente en instrucciones nativas.

35
No existe un lenguaje interpretado o un lenguaje que compile las instrucciones nativas. Un lenguaje es un conjunto de reglas matemáticas, no se interpreta ni se compila, simplemente lo es . Interp. y Comp. son rasgos de, bueno, el intérprete o el compilador, no el lenguaje. Cada idioma puede implementarse utilizando un compilador o un intérprete. La mayoría de los idiomas actuales tienen implementaciones tanto interpretadas como compiladas. Hay intérpretes para C y todas las principales implementaciones de JavaScript compilan en código nativo. ¿Y qué es el código nativo de todos modos? Si compilo Java a JVM bytecode y ejecuto
Jörg W Mittag

11
eso en una CPU Java, y compilo C en código de máquina ARM y lo ejecuto en un intérprete ARM porque mi PC no tiene una CPU ARM, entonces, ¿qué hace que ARM sea nativo y JVML no?
Jörg W Mittag

55
@ JörgWMittag: si tiene una CPU que puede ejecutar directamente el bytecode de Java (sin utilizar un JVM adicional), entonces el bytecode de Java es el código nativo para esa CPU. Además, no descarto la posibilidad de escribir un sistema operativo en un lenguaje que generalmente se interpreta o ejecuta en una máquina virtual, pero las hace opciones menos obvias.
Bart van Ingen Schenau

15
@ JörgWMittag: estoy de acuerdo en que cualquier lenguaje se puede compilar o interpretar (compilar un script bash; usar C ++ interpretado (CINT / Cling)), pero muchas decisiones en el diseño del lenguaje se basan en si esto se interpretará, compilará o ambos. Un lenguaje que lo haga declarar / inicializar manualmente variables estáticamente tipadas, asignar / liberar memoria manualmente, hacer aritmética de puntero, recuerde verificar los límites de la matriz será menos conveniente en un intérprete (en comparación con un lenguaje que recolecta basura basura, infiere tipo dinámico, comprueba los límites de la matriz). ¿Es esta línea 100% clara? No, pero la diferencia existe en la práctica.
dr jimbob

15

Hay una serie de buenas razones para esto.

El lenguaje de bajo nivel de hoy era el lenguaje de alto nivel de ayer

Sí, lo creas o no, alguna vez incluso C fue visto como un lenguaje de alto nivel. Incluso hace ~ 20 años era lo suficientemente común como para verlo descrito como un lenguaje de "nivel medio". Este fue un momento antes de que OO fuera tan popular como lo es hoy, Java no existía, C # no existía, incluso C ++ aún no estaba correctamente estandarizado.

Inercia Histórica

Los sistemas operativos que usa hoy tienen raíces profundas en la historia. Windows se remonta a principios / mediados de los 80, Unix se remonta a principios / mediados de los 70. Hay MUCHOS códigos antiguos que funcionan en los sistemas operativos y, por lo general, no desea volver a escribir el código antiguo que funciona.

En algún momento tienes que bajar al hardware

Esto sucede en el kernel, sucede en los controladores, sucede en los subsistemas de administración de memoria, sucede en el sistema de archivos. Claro que puede superponer un lenguaje de alto nivel, pero aún necesita la capacidad de acceder más directamente al hardware que ofrece un lenguaje de nivel inferior.

Portabilidad

No me refiero a la portabilidad a un hardware diferente o un sistema operativo diferente, ya que hoy se entiende más comúnmente; Esto es más sutil. Hay una gran ventaja de proporcionar una interfaz basada en C para algo, y es el hecho de que prácticamente todos los demás idiomas que existen pueden vincularse a C. Incluso la API de Windows sigue siendo una API basada en C en estos días por esa razón.

Preferencia personal

Algunas personas simplemente prefieren programar de esta manera, y eso puede ser un factor importante. Por ejemplo, Linus Torvalds tiene un famoso discurso contra C ++ que deja bastante claro que, en lo que a él respecta, C siempre será su herramienta de elección para este tipo de trabajo (el contenido del discurso y si está o no de acuerdo con él) es irrelevante para esta discusión; el hecho de que exista la diatriba es suficiente).

Tomados en conjunto, estos deberían establecer claramente por qué un sistema operativo se escribió originalmente en algo como C en los viejos tiempos, y por qué partes muy importantes de él, incluso hoy, siguen siéndolo.


13

Una razón principal del dominio de C para los sistemas operativos radica en la historia: los sistemas operativos principales actuales como Windows y todas las formas de Unix (BSD, Solaris, HP-UX, MacOS X, ... así como clones como Linux) se remontan mucho tiempo antes de que OO y otras construcciones de "alto nivel" se convirtieran en la corriente principal.

Para el núcleo del sistema operativo además del rendimiento, es necesario ser muy específico acerca de las instrucciones de hardware y uno necesita un control total sobre la memoria, que lenguajes como C funcionan muy bien.

Para los sistemas integrados, a veces hay sistemas operativos que utilizan lenguajes de nivel superior para partes más grandes del sistema. Un ejemplo notable es JavaOS de Sun.

Para los sistemas operativos generalizados, un ejemplo notable que no usa C también es el MacOS clásico antes que MacOS X, que estaba escrito en gran parte en un dialecto de Pascal que permitía alguna forma de orientación a objetos.


12

Primero, hay algunos problemas de arranque. La mayoría de las características que facilitan los lenguajes de alto nivel se basan en abstracciones que un núcleo debe proporcionarse. ¿Cómo se escribe un administrador de memoria en un idioma que requiere un administrador de memoria? ¿Cómo se escriben los controladores de E / S sin utilizar las agradables bibliotecas estándar de E / S de su idioma? ¿Cómo se crean primitivas de subprocesamiento y sincronización sin utilizar las bibliotecas del lenguaje?

En segundo lugar, es extremadamente útil y mucho más legible al escribir sistemas operativos para poder asignar una variable a una ubicación de memoria específica. Esto es fácil en C, y cada programador de C sabe cómo hacerlo. Si incluso es posible en idiomas de nivel superior, es tan raro que solo los gurús saben cómo hacerlo.

En otras palabras, cuando tiene en cuenta todas las limitaciones y modificaciones que tendría que aceptar, C y C ++ comienzan a verse mucho más fáciles.


2
Tu primer párrafo no tiene sentido. Un controlador de E / S en C tampoco usa stdio.h. Una implementación de mutex personalizada no usa pthreads. ¡Eso es precisamente lo que significa implementarlo usted mismo! Y eso es independiente del lenguaje que está utilizando. Esto no quiere decir que los lenguajes de alto nivel sean una buena opción para tareas de bajo nivel (por lo general, no están en mi experiencia).

Estoy al tanto. Solo estoy señalando que mucho de lo que diferencia un lenguaje de alto nivel de un lenguaje de bajo nivel está en aquellas partes del lenguaje que no están disponibles en el desarrollo del kernel. Cuando compara los lenguajes núcleo a núcleo, C ya no parece tan espartano.
Karl Bielefeldt

No del todo cierto. Si bien necesitará algún código que no use X para implementar X, todo el código restante puede depender de ese código y usar X.

Ese es un buen punto.
Karl Bielefeldt

6

En primer lugar, el bootstrapping requiere que al menos una pequeña parte se escriba en ensamblador o equivalente.

En segundo lugar, era un sistema operativo escrito en un indiscutiblemente HLL - Máquina Lisp . (El hecho de que falló comercialmente tuvo más que ver con que otro hardware se volviera más barato y el triunfo de Peor es mejor que con las deficiencias de su filosofía o diseño).

En tercer lugar, C ++ es bastante orientado a objetos y de alto nivel, por lo que, como otros señalaron, Symbian OS es otro ejemplo.

Cuarto, hay poca necesidad de nuevos sistemas operativos en este momento. Ya tenemos bastantes sabores de Linux y BSD que se ejecutan en casi cualquier hardware, y crear un nuevo sistema operativo desde cero es bastante costoso.


Te perdiste los mainframes Burroughs B5000. Su sistema operativo fue escrito en Burroughs Extended ALGOL.
John R. Strohm

1
there is little need for new OSes at this timeTodavía no he decidido si esto es cierto o no. Sí, los sistemas operativos modernos (ventanas modernas (NT) / Unix moderno) son todo lo que necesitamos, funcionalidad y rendimiento. Pero apenas: nacen en otra área donde "la red" era corporativa / universitaria y los usuarios confiaban, y multiproc era procesadores 2/4. Están "plagados", hasta cierto punto, por el exceso de confianza (rootkits, malware, virus ...). Estoy empezando a pensar que hay espacio para un sistema operativo moderno, seguro y aislado ... con un mejor soporte para el paralelismo también (mejor que los hilos)
Lorenzo Dematté

¡Lisp es de bajo nivel, CARy CDRson macros de ensamblador IBM 704 ! Incluso C segrega el ensamblaje en línea , en lugar de tratarlo como cualquier otra función. Teniendo en cuenta Lisp CARy el CDRtrabajo en x86, ARM y una gran cantidad de ISA, es un ensamblaje impresionantemente portátil. (Nota al margen a cualquiera que pueda haber confundido: Sí, Lisp es un lenguaje de alto nivel. CARY CDRser macros ensambladores fue solo un detalle de implementación, no una característica clave.;))
8bittree

4

Para mejorar la fase de lo que escribí anteriormente.

Las máquinas Burroughs 5xxx - 6xxx no tenían un lenguaje ensamblador. El idioma más bajo disponible era una extensión de Algol. El Algol se implementó en hardware. El sistema operativo y todos los idiomas fueron escritos en Algol. Superó a todas las máquinas de la competencia de la época. También requería una cantidad significativamente menor de código, lo que facilitaba mucho el mantenimiento. Tenía hardware de pila que soportaba un lenguaje recursivo como Algol.

El sistema operativo Burroughs evolucionó a una versión llamada MCP. MCP actualmente se ejecuta en sistemas Unisys.


3

La mayoría de los idiomas de nivel superior que mencionas tienen una característica que no encaja bien con los sistemas operativos: administración automática de memoria. No puede confiar en un recolector de basura cuando escribe un sistema en tiempo real, ya sea suave (que es lo que es un sistema operativo) o incluso peor. Para citar a Tanenbaum [i]:

Algunas cosas que C no tiene incluyen cadenas integradas, hilos, paquetes, clases, objetos, seguridad de tipos y recolección de basura. El último es un show stopper para sistemas operativos. Todo el almacenamiento en C es estático o está explícitamente asignado y liberado por el programador, generalmente con la función de biblioteca malloc y gratuita . Es la última propiedad, el control total del programador sobre la memoria, junto con los punteros explícitos lo que hace que C sea atractivo para escribir sistemas operativos. Los sistemas operativos son básicamente sistemas en tiempo real, hasta cierto punto, incluso de uso general. Cuando ocurre una interrupción, el sistema operativo puede tener solo unos pocos microsegundos para realizar alguna acción o perder información crítica. Hacer que la recolección de basura se inicie en un momento arbitrario es intolerable.

Ahora, podría argumentar que C ++ también es un buen candidato, ya que ofrece administración manual de memoria. C ++ ya se ha utilizado en algunos sistemas operativos como Symbian (mencionado por Bart ) y BeOS. Pero IMHO C sigue siendo el lenguaje más rápido que se puede portar en muchas arquitecturas sin un gran esfuerzo (en contraste con el ensamblaje de una arquitectura específica).

[i]: Modern Operating Systems 3rd edition, página 73


3
Las máquinas simbólicas tenían gestión automática de memoria. Smalltalk lo hizo en un Alto. Eso fue en los años 80. Un sistema de tipo lineal elimina completamente la necesidad de GC. ¡Estos son problemas resueltos, si tan solo pudiéramos recordar eso!
Frank Shearar

Sería posible que un lenguaje incluya la administración automática de memoria, pero incluya un tipo especial de referencia "profundamente anclada" y permita que los métodos declaren explícitamente que no accederán a ninguna referencia no anclada ni invocarán ningún método que pueda hacerlo. No sería necesario que un recolector de basura de todo el mundo interfiera con el código que se ejecuta en un método que no accedería a ningún objeto que pudiera ser modificado por el GC.
supercat

2

Como otros han señalado, varios sistemas operativos han sido escritos en lenguajes de alto nivel. ¿Quizás lo que quieres decir es que todo el sistema operativo exitoso, de mercado masivo y de uso general se ha escrito en alguna combinación de ensamblaje, C y C ++?

La mayoría de los idiomas de alto nivel tienen toneladas de características útiles que conllevan un costo de rendimiento asociado. La gestión de memoria automatizada es un ejemplo obvio, la comprobación de límites de matrices es otra. Si está escribiendo un sistema operativo de propósito general, es probable que se encuentre con situaciones en las que la penalización de rendimiento de estas útiles funciones es mayor de lo que está dispuesto a pagar. En ese punto, le gustaría poder desactivarlos. Los lenguajes como Python, C # y Java varían en las características que puede desactivar, pero ninguno de ellos es tan versátil como C o C ++ a este respecto.

En este aspecto, C y C ++ son casi tan versátiles como el ensamblaje puro. Si decide que necesita diez administradores de memoria diferentes que cubren diez escenarios diferentes de asignación de memoria, puede implementarlos todos en C y C ++, y cargarlos y descargarlos como mejor le parezca. Diablos, ni siquiera tiene que vincular a las bibliotecas de tiempo de ejecución estándar de C o al código de inicio si no lo desea.


0

La verdadera respuesta es el dinero . No se perciben suficientes beneficios de un sistema operativo de lenguaje de alto nivel para justificar gastar los recursos para construir uno y luego llevarlo a la corriente principal. Hay un costo enorme involucrado en la construcción de un nuevo controlador para cada pieza de hardware que necesita soportar, por ejemplo.

Hay varios sistemas operativos escritos en lenguajes de alto nivel, con el objetivo principal de la investigación, como Oberon y Singularity .

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.