Sistemas operativos en C??

X.Cyclop · #1 (**permalink**) 10/01/2006, 17:01

Porqué si C++ es mejor que C los sistemas operativos (windows - linux) están hechos en C?
Es más fácil C, pero se supone que los programadores son expertos y pueden hacerlo en C++.
Porqué no lo hacen en C++?

Eternal Idol · #2 (**permalink**) 10/01/2006, 17:04

Tendrias que preguntarte en que es mejor C++ y tener muy en cuenta que actualmente se podria considerar a C como un subconjunto de C++.

cabeza_nispero · #3 (**permalink**) 11/01/2006, 10:57

Dicen que se hacen en C porque el código es más adecuado para ello, los castings son normales, la manipulación extraña de memoria es más permisiva, no hay tipado tan fuerte...

Aunque es cierto en C++ se puede hacer lo mismo que en C aunque sea más pesado el olbigarle al compilador. ¿Por qué están en C realmente? Porque en la época en que salieron (Linux, UNIX, Windows) tuvieron que programar su propio compilador de C. Por ejemplo, Richard Stallman estuvo solo haciendo la primera versión de C. Evidentemente es compliacado escribir un compilador, y más haciéndolo sólo, pero sería simplemente imposible tú solo escribir uno de C++, además de que es necesario hacerlo rápido para salir al mercado (Windows) y que Linus no tenía toda una vida...

X.Cyclop · #4 (**permalink**) 11/01/2006, 14:47

Ok, gracias a los 2.
Una duda más: Windows o algún otro sistema operativo tiene algo de Asm?

Eternal Idol · #5 (**permalink**) 11/01/2006, 15:48

Si, hay un par de cosas del Kernel hechas en assembly como el manejo de interrupciones o el cambio de contexto.

cabeza_nispero · #6 (**permalink**) 11/01/2006, 16:33

Como dice Eternal Idol, el Asm es fundamental en los sistemas operativos. Aunque la base esté escrita en C, muchas funciones se deben fabricar en Asm directo.

X.Cyclop · #7 (**permalink**) 11/01/2006, 18:34

Ok. Muchas gracias!

X.Cyclop · #8 (**permalink**) 23/01/2006, 20:24

Estaba leyendo en Wikipedia, encontré esto:

Cita:

C

Al igual que sus dos predecesores, es un lenguaje orientado a la implementación de Sistemas Operativos (los sistemas operativos Linux y UNIX están escritos mayormente en C), pero se ha convertido en un lenguaje de propósito general de los más usados

Cita:

Lenguaje de programación de propósito general
Los lenguajes de propósito general, son lenguajes que pueden ser usados para varios propósitos, acceso a bases de datos, comunicación entre computadoras, comunicación entre disopositivos, captura de datos, cálculos matemáticos, diseño de imágenes o páginas, crear sistemas operativos, manejadores de bases de datos, compiladores, entre muchas otras cosas.

Puede ser usado para cualquier cosa que te propongas, claro de ello dependerá la dificultad, pues, para ciertas tareas más comunes, existen librerías para facilitar el desarrollo (recuerda, no hay que evitar reinventar la rueda).

Cita:

C - lenguajes de medio nivel

Son precisos para ciertas aplicaciones como la creación de sistemas operativos, ya que permiten un manejo abstracto (independiente de la máquina, a diferencia del ensamblador), pero sin perder mucho del poder y eficiencia que tienen los lenguajes de bajo nivel.

Instru · #9 (**permalink**) 25/01/2006, 19:44

Pues en ciertos puntos tus citas estan bien.

La verdad es que C es el mejor lenguaje para programacion universal.
Aun asi, cuando descubres el verdadero poder de C++, no lo que aparenta, sino la verdad. C++ te puede hacer la vida facil, muy facil. Pero finalmente Para saber C++ tienes que saber C asi que no hay de otra, o aprendes C o no aprendes nada. jajajaja.

Saludos

Beakdan · #10 (**permalink**) 25/01/2006, 20:48

Depende también de la plataforma a la que esté destinado tu sistema operativo. Yo trabajo mucho con procesadores de 8 bits para los cuales por cierto se requieren también sistemas operativos (OSEK y µC/OS son muy conocidos), y usar C++ simplemente aniquilaría el rendimiento del procesador. Es más, el fabricante mismo del compilador lo advierte:

Cita:

Some features of the C++ language are not designed for embedded controllers. If they are used, they may produce a excess code and occupy a lot of runtime.

Seguido de esto viene una lista de lo que no debería usar... Que me dejaría básicamente con C. Con C casi todo esta permitido, y lo que no, con algunas cuantas líneas de Assembly queda solucionado.

Eternal Idol tiene mucha razón en cuanto al manejo de interrupciones. Muchas veces no sabría como realizarlas sin ensamblador. Pero también, para el acceso a flags del procesador u operaciones en BCD (muy comunes con estos procesadores) lo más eficiente se logra con Assembly.

Eternal Idol · #11 (**permalink**) 26/01/2006, 01:47

Tendria que ver el codigo generado para esos procesadores como para darme una idea (nunca trabaje con ellos por cierto) de si realmente es tan costoso su uso.

En cuanto a x86 y x64 (bajo Windows NT mas precisamente) es bastante parecido si usamos lo mas basico de C++: todo lo que se puede hacer en C mas clases simples y variables declaradas "on the fly". Por mi experiencia con drivers, donde Microsoft no recomienda usar C++ a la ligera, yo diria que mientras no usemos plantillas, sobrecarga dinamica, RTTI, excepciones de C++ y otras caracteristicas avanzadas mas la cosa va muy bien. Permite un codigo mucho mas claro y MUCHISIMO mas facil de reemplazar y reutilizar.

En cuanto a lo que comentas de assembly en estas plataformas se trabaja codo a codo con el S.O. y para logar portabilidad esta absolutamente descartado el uso de assembly, hay macros y funciones del HAL (Hardware Abstraction Layer) que permiten todo tipo de acceso a hardware.

Beakdan · #12 (**permalink**) 26/01/2006, 04:33

En ese aspecto tienes toda la razón. Yo mismo he tenido que trabajar con un grupo de programadores expertos en drivers para desarrollar los de varios de los dispositivos que hacemos. Pero, del lado de la PC, se tiene por supuesto mucha ventaja. Puedes hacerlo todo con un lenguaje de alto nivel si lo deseas, y cumplir con todo un conjunto de reglas para asegurar la portabilidad, y otros aspectos como el reuso de código.
Sin intención de desviar el tema, del lado del Hardware que se conecta al PC por supuesto, muy pocas veces tienes oportunidad de trabajar con un procesador lo suficientemente veloz o poderoso como para seguir todas las reglas. De hecho, he recibido muchas críticas de otros programadores acerca de la gran mayoría de mi código. Aspectos como utilizar demasiadas variables globales, usar con demasiada frecuencia Inline Assembly, o tener múltiples puntos de salida para una función. Yo mismo evito hacer tales cosas programando aplicaciones para PC. Pero en algunas plataformas, las reglas estorban, o algunas cualidades de un lenguaje se vuelven la encarnación del mal. O lo que en estos procesadores genera una enorme mejora de velocidad, en un PC es irrelevante ya que, por la enorme cantidad de intrucciones que pueden procesar por segundo, un usuario no nota la diferencia entre 100 ciclos o 10,000. Por eso alguna vez te decía que muchas veces me da lo mismo el lenguaje de alto nivel que se use. Muchas veces termino optimizando sectores críticos con Assembly. Sobre todo en el manejo de interrupciones. En este mismísimo momento estoy trabajando con un procesador de Freescale de 8 bits. Te dejo dos ejemplos que en cuanto a funcionalidad, hacen exactamente lo mismo (reciben 8 bits con el protocolo I2C con un MCU funcionando a 3.2Mhz). Pero evidentemente, una de las soluciones es inaceptable.

Este ejemplo es fácil de comprender y breve...

Código:

//La variable i está declarada dentro de la función
//Y se está incrementando (esto ralentiza el bucle algunos ciclos)
//Se utilizaron BitFields
    for(i=0; i<8; i++){
        DDRA.BIT4 = 0;
        if(PTA.BIT3) TxRxSHR |= (1<<i);
        PTA.BIT4 = 0;     
        DDRA.BIT4 = 1;    
    }

Pero genera esto:

Código:

TSX   
CLR   ,X
LDA   _DDRA
AND   #-17
STA   DDRA
LDA   _PTA
AND   #8
TSTA
BEQ   +12
LDA   #1
LDX   ,X
BEQ   +3

LSLA            ;Aquí está el principal problema
DBNZX -3        ;Se retrasa (5*i) + (5*2i) + ... + (5*7i)
                ;es decir 140 ciclos
ORA   TxRxSHR
STA   TxRxSHR
LDA   _PTA
AND   #-17
STA   _PTA
LDA   _DDRA
ORA   #16
STA   _DDRA
TSX   
INC   ,X
LDA   ,X
CMP   #8
BCS   -39

Este otro código, ya no es portable definitivamente, si quiero volver a usarlo en otro procesador, tendré que reescribirlo...

Código:

//bitCount es una variable global declarada como "byte __near bitCount"
//En lugar de incrementarla, se decrementa, por lo tanto
//se compara contra cero, que es el modo más eficiente en
// un procesador. 
for(bitCount=8; bitCount>0; bitCount--){
    DDRA &= ~0x10;
    _asm{
        LDA    PTA
        AND    #0x08
        ADD    #0xF8
        ROL    TxRxSHR
    }
    PTA &= ~0x10;     
    DDRA |= 0x10;    
}

Sim embargo, genera este código que se ejecuta en ~32 ciclos:

Código:

MOV   #8,bitCount
BCLR  4,_DDRA
LDA   _PTA
AND   #8
ADD   #-8
ROL   TxRxSHR
BCLR  4,_PTA
BSET  4,_DDRA
DEC   bitCount
TST   bitCount
BNE   -20

El primer código podría ser usado, y sería portable, aún considerando que es lento, pero para esta aplicación en particular, agotaría la batería con que debe operar el procesador mucho más rápido que con el segundo código. Podría aumentar la velocidad del circuito, pero esto también acabaría con la batería. Como puedes ver, el asunto de la portabilidad ya no resulta importante. Y sigue siendo lenguaje C.

Disculpándome por desviar tanto el tema, y volviendo al rubro de los OS, alguna vez hice uno, por supuesto no un Windows, no un Linux. Simplemente se trataba de poder ejecutar varias "aplicaciones" en un MCU de 8 bits, con limitadísima memoria RAM (2K), y en lugar de disco duro, una memoria flash de 2M. Encontré un libro llamado "μC/OS, The Real-Time Kernel" de Jean J. Labrosse. Los conceptos que expone son válidos para para OS "mayores", y te guía paso a paso para que hagas uno que funcionará en un X86, ya que probablemente será el procesador que tendrás a mano. Este μC/OS ha sido portado a muchas plataformas, como los 8052, 8051, Motorola 68K, Philips 80C166... en fin, una lista interminable.

Y como ultima nota y abuso, con el incremento de aplicaciones embebidas, hay un vacío enorme de programadores que desarrollen OS o aplicaciones para estas plataformas. Desde 4 bits hasta 64 bits.

Eternal Idol · #13 (**permalink**) 26/01/2006, 05:24

Evidentemente el objetivo es diferente y en tu caso el uso de assembly es fundamental a comparacion de las plataformas en las que trabajo donde la portabilidad es mas importante que el rendimiento.

Supongo que ese vacio se debera a varios factores como la masificacion de las PCs y su amplisima capacidad a comparacion.

Beakdan · #14 (**permalink**) 26/01/2006, 08:47

Tienes muchísima razón en lo de la capacidad. Sin embargo, no en cuanto a la masificación. Si le preguntamos a un individuo común, que nos diga que es una computadora, facilmente pensará en teclado, cpu, mouse y pantalla.
Sin embargo, los sistemas de cómputo más extendidos son los embebidos. Y estos ni siquiera tienen por que tener una interfaz humana. Como el chico que preguntaba hace poco si era factible hacer su propio servidor web. Por unos $50 USD puede construirse uno y el código no pasará de los 30Kb probablemente. No va a pesar más de 150 gramos. Pero no será nada como lo que decías de ¿"SetAndForget"?.
Hace algún tiempo hice una investigación sobre los procesadores, y me sorprendí mucho al encontrar que 55% del total de procesadores que se venden en el mundo son de 8 bits. Luego, los procesadores de 32 bits eran el 8% del total de los procesadores fabricados. Y el 2% de los procesadores de 32 Bits, se dedicaban a las PC's y servidores. No recuerdo exactamente la página pero estaba en el sitio de http://www.embedded.com.
Pero la importancia de los procesadores para PC no está en las cantidades vendidas, sino en las ganancias obtenidas. Resulta que acaparan aprox. el 30% del total de las ganancias por ventas de semiconductores.
Sin embargo, resulta que aún cuando los procesadores embebidos son unas baratijas (desde unos $2 USD), se gana decentemente programando para ellos: de $25 a $100 USD por línea de código (fuente: Jack G. Ganssle en “The art of designing Embeded Systems”)...
Me gustaría ver que aquí en México me pagaran eso...

Como sea, programar para PC tiene ventajas. Por ejemplo, yo sé que tú detestas VB entre otras cosas por su gran capacidad para generar BloatWare. Pero ni al programador común de VB ni al usuario del programa le importa cuán grande es el ejecutable sino cuando no les cabe en un disco. En C++ o C un programador novato podría escribir código ineficiente pero funcional, pero tampoco importará, porque a la velocidad de una PC esos ciclos inútiles extras, son imperceptibles. De hecho esa ha sido la filosofía para crear programas desde hace mucho tiempo. Agregar más y más "funcionalidad", opciones, etc. aún cuando el usuario promedio no la necesite o ni se dé por enterado. Si el programa se vuelve pesado, no importa, confían en que el nuevo hardware que compre el usuario compensará el problema con mayor velocidad, mayor memoria o mayor bus de datos. Por eso me sorprendo y disfruto mucho de encontrar programadores-optimizadores obsesivos aún cuando ya no parece ser necesario generar el código más breve y rápido posible.

De este lado, cada Khz que aumente a la frecuencia del CPU cuesta energía, cada ciclo malgastado consume energía, que las baterías no duren lo suficiente, o que se produzca interferencia electromagnética, un mayor cristal, un mayor costo... Tratas siempre de apegarte a un estándar, pero cuando este estorba, Assembly. Lo malo, es que aprender los opcodes de varios procesadores de distintos fabricantes es... Misión imposible.

X.Cyclop · #15 (**permalink**) 26/01/2006, 09:55

Lei todo pero no entendi casi nada.

Sistemas operativos de 8 bits

Para dispositivos móviles cuál sería bueno? Digamos Palms. Java? C? C++? Se podría en Vb?
Y cómo sabría mi compilador que esa aplicación es para Palm y no para un SO, código especial, se necesita otro compilador??

; Indica comentario en Asm o qué lenguaje es ese?

Eternal Idol · #16 (**permalink**) 26/01/2006, 10:34

Cita:

Iniciado por Beakdan

Tienes muchísima razón en lo de la capacidad. Sin embargo, no en cuanto a la masificación.

Menos mal que dije supongo

Cita:

Iniciado por Beakdan

Pero no será nada como lo que decías de ¿"SetAndForget"?.

No, el de RunAndForget sera para PC (y bajo .NET).

Beakdan · #17 (**permalink**) 26/01/2006, 11:34

Eternal Idol:
J@ es cierto "RunAndForget". Cuando leí eso me desternille de risa.

X.Cyclop:
Las Palm que yo conozco (no sé ultimos modelos) usaban procesadores como el DragonBall o el ColdFire de Motorola, que aunque son de 32 bits, tienen un bus de datos de 16. En mi experiencia, todo lo que uno gana con la portabilidad de Java es un dolor entre el hígado y el páncreas. El problema es el que todos conocen: Tu código tiene que ser interpretado por la máquina virtual. En un procesador de 32 o 64 bits, con más de 100Mhz de frecuencia en el bus... Realmente no importa cuanto le toma a la MV interpretar el programa. Pero en un procesador de 16 bits con una frecuencia de 30 o 60Mhz, pues, es demasiado lento salvo para hacer un "Hello World". Se que hay nuevas versiones de Java para sistemas embebidos, pero no las he probado siquiera. En sistemas de 8 bits con memoria limitada... Java no creo que pueda tener posibilidades de ser usado, salvo por la síntaxis, en cuyo caso, volvemos a hacer un programa básicamente en C.
Hay un VB para sistemas embebidos, pero, creo que sólo para WindowsCE y PocketPC. En todo caso, si encuentras qué procesador usa tu dispositivo, casi siempre podrás encontrar un buen compilador en C (o en C++ con un conjunto de instrucciones restringido)
Y sí, el punto y coma es un comentario en Assembly.