¿Cuánto de un sistema operativo podría estar escrito en, por ejemplo, Python?

Question

Esta es una cuestión teórica bastante-mucho, pero ..

¿Qué parte de un sistema operativo podría ser escrito en un lenguaje como Python, Ruby, Perl, o Lisp, Haskell, etc?

Parece que muchas cosas como init.d podrían hacerse trivialmente en un lenguaje de scripting. Uno de los firewall-device-OS (m0n0wall) usa PHP para su configuración del sistema (incluso en el arranque). Y uno podría argumentar que "emacs es un sistema operativo, escrito principalmente en Lisp" ..

Por supuesto, hay bits que deberían ser ensamblados/C, pero ¿cuánto podría ser regular ?py/rb/.pl/.el/.hk archivos ...? Puede que no tenga el mejor rendimiento, pero sería, de lejos, el sistema operativo más fácil de modificar ...

Answer 1

Técnicamente, cualquiera de ellos podría ser, si escribe un compilador para hacerlo. Los sistemas operativos se han hecho en Java (JNode), .NET (MOSA, Singularity, SharpOS, Cosmos), Haskell (HOUSE), Python (Unununium), etc.

Editar: Veo a mucha gente hablando sobre el mismo el nivel más bajo es un área donde esto no podría hacerse; esto no es verdad

No hay ninguna razón para que el compilador del lenguaje X no se pueda extender para manejar cualquier operación de bajo nivel y exponerlo al idioma. Toda la funcionalidad se puede lograr desde cualquier idioma, es simplemente una cuestión de elegir la herramienta adecuada para el trabajo. A veces esto es Python, a veces esto es C, a veces esto es ensamblaje.

mirada a proyectos como Cosmos y sharpos para ver un sistema operativo de alto nivel pura Done Right (TM).

Answer 2

House - Haskell User's Operating System and Environment. Incluso es arrancable dentro de VM y puedes jugar con él.

Las fuentes son muy legibles, IMO.

Answer 3

Python no proporciona construcciones para hablar directamente con el hardware, como punteros crudos para E/S mapeadas en memoria y muchas otras construcciones proporcionadas por C/ASM. Sin embargo, hay pruebas de que la mayoría de todo en un SO se puede escribir en un lenguaje más abstracto; el Singularity OS de Microsoft está escrito casi exclusivamente en variantes de C#. Hay una cantidad extremadamente pequeña de C/ASM para hacer interruptores y demás, pero todo lo demás, incluido lo que la mayoría de nosotros consideramos "kernel", se puede hacer en prácticamente cualquier lenguaje de Turing completo.

Cabe señalar que la elección de singularidad para poner en práctica estas construcciones de bajo nivel en C/ASM no debe interpretarse como una limitación fundamental de la sintaxis u otros aspectos de lenguajes de alto nivel. Uno ciertamente podría hacer una variante de Python que emitiera y tratara apropiadamente con el código ensamblador necesario.

Answer 4

Más allá del núcleo (y con esto, quiero decir kernel, estilo microkernel), y algo para compilar los tiempos de ejecución de cada uno de dichos lenguajes dinámicos, casi cualquier cosa y todo lo PODRÍAN ser si estuviera construyendo su propio sistema operativo . Simplemente no es práctico. Diablos, init.d está escrito principalmente en sh por lo que yo sé. Pero sh, aunque no es potente, es MUY ligero y, hasta donde yo sé, eficiente en lo que hace. lenguajes de alto nivel como Python, Perl, etc, podría manejarlo bien, pero sería mucho más lento, y tomarían mucho más memoria para casos de intérpretes.

Es posible, simplemente no es práctico.

Answer 5

Es difícil imaginar núcleos/controladores de dispositivo, etc. escritos en (por ejemplo, Python) - la gestión de la memoria sería un poco un dolor de cabeza.

Por otro lado, casi todo el código de espacio de usuario podría ser. En Linux, no hay ningún requisito de que "init" sea un código binario de máquina-código nativo, puede ser un script de Python o algo así, no hay problema.

Answer 6

El único resultado interesante de Singularity es que ya no necesita una MMU (unidad de gestión de memoria) en la CPU, ya que todos los códigos de usuario se "administran". Pude ver esto beneficioso en escenarios integrados, usando Linux no MMU y además de las aplicaciones con guiones.

Answer 7

Vea Genera/OpenGenera para ver un ejemplo de un sistema operativo escrito en Lisp que en realidad se usó durante bastante tiempo en LispMachines.
Haskell tiene House.

Answer 8

Siempre que el lenguaje de programación tenga la capacidad de manipular archivos binarios, puede escribir un sistema operativo completo en el idioma en particular. Esto no quiere decir que sea fácil o práctico. Simplemente tiene sentido que, si su idioma elegido puede manipular binarios, puede ir tan bajo como lo necesite.

Answer 9

Yo diría que esto no es posible. Las respuestas a esta pregunta siguen refiriéndose a los cambios en el idioma o al uso del lenguaje para generar código de bajo nivel (kernel). Esto es solo usar un idioma para escribir otro idioma. Si bien estoy de acuerdo en que ambos le permitirán escribir un sistema operativo, entonces argumentaría que ahora no es el mismo idioma. Por lo tanto, un sistema operativo podría estar escrito en muchos idiomas diferentes, pero no todos los idiomas (sin cambio o idioma por pase) se pueden usar para escribir un sistema operativo.

La respuesta final a la pregunta original es casi todo, pero no todos. La única aceptación son los idiomas que pueden acceder a las instrucciones de nivel de CPU.

Answer 10

"cleese" - un sistema operativo escrito casi en su totalidad en Python

Answer 11

me sorprende que nadie ha mencionado el hardware de Java. Debería ser una inspiración para nosotros fomentar la evolución del hardware mediante la creación de un procesador de nivel aún más alto.

Hay otro proyecto que acabo de encontrar llamado "Pycorn".

Si hubiera un procesador de bytecode de Python, sería factible hacer un sistema operativo rápido en 100% Python. El procesador podría implementar todo el bytecode CPython, o cualquier cosa que sea compatible con el lenguaje Python (¡pero no con los módulos C!). El procesador tendría que manejar conteo de referencias, clases y objetos. El hashing nativo para dicts sería muy útil, todas las manipulaciones complejas de estructura de datos que Python actualmente necesita en el software deberían hacerse exclusivamente en hardware. No habría ningún concepto de punteros, que veo como una motivación principal para construir tal procesador, ya que sería imposible destruir la pila.

¡Todo sería objeto! El kernel mismo llamaría métodos al objeto de memoria, aunque no necesitaría tocarlo mucho ya que el hardware manejará la asignación y la recolección de basura de todos modos. Los manejadores de interrupciones simplemente pueden establecerse en métodos de pitón. MSR, cachés, registros de depuración y puertos de E/S son objetos.

Hay una discusión interesante sobre la implementación de Python en un FPGA here.

En otra nota, (perteneciente a un Python O/S en un procesador que no es Python) a las personas que afirman que no se puede hacer ensamblado en línea Pythonic, es bastante simple simplemente emitir ensamblaje desde una abstracción, ej:

asm = MetaASM() 
asm.r1 = 1234 
asm.r2 = r1 + 5 
asm.io.out(r1) 

usted podría cambiar de reunión específica para las necesidades de rendimiento de la arquitectura o arquitectura específica operaciones/registros cuando sea necesario:

asm = ASM("IA-32") 
asm.xor(asm.eax, asm.eax) 
asm.cr0 = asm.eax 
asm.invtlb 
asm.fs.0x0= asm.eax 
asm.al = 123 
asm.dword.ptr.eax = 1234 # mov dword ptr [eax], 1234 
asm.push(asm.eax) 

CorePy llega a los intereses sobre este tema.