funcionamiento del reloj de una computadora

Iniciado por mikemizi, 4 Enero 2014, 22:08 PM

0 Miembros y 1 Visitante están viendo este tema.

mikemizi

Hola a todos.

Espero no repetirme, pero no he encontrado un tema similar, perdón si ya existe.

Necesito saber cómo funciona el reloj que controla la unidad de control de los procesadores intel de 16 o 32 bits.

Estoy programando un sistema operativo UNIX( en C y ensamblador con gcc y gas ) y para ello sólo tengo 2 duda:

Quiero saber el funcionamiento exacto de reloj del procesador:

Cada n nanosegundos el reloj emite un tic( no me refiero a la señal que gobierna el ciclo de ejecución de instrucciones ) que hace que si el procesador está en modo usuario( cómo cuando se está ejecutando un proceso ) pase a modo núcleo para evitar que el procesador esté siempre en modo usuario( debido a que no existe ninguna instrucción que permita en modo usuario poner el procesador en modo núcleo ) y pueda entrar a ejecutarse el kernel, lo que quiero saber es que ocurre exactamente cuando el tic hace pasar al procesador a modo núcleo, es decir, si hay algún registro en el cual el procesador lea la dirección de memoria que contiene y empiece a ejecutar el código a partir de ella cargándolo en el contador de programa o si almacena en algún registro( o pila ) la dirección de memoria de la instrucción que habría seguido ejecutándose si no se hubiera pasado a modo usuario( necesito saber esto para poder programar correctamente el kernel )
También necesito saber sobre la tabla de tratamiento de interrupciones:
Cuando las interrupciones están activadas el procesador ejecuta el código de la dirección del vector de tratamiento de interrupciones que contiene la rutina adecuada, lo que quiero saber es cómo se le dice al procesador en donde está el vector de interrupciones.

Gracias de antemano( he buscado en google, ixquick ) y lo único que encuentro son manuales de ensambalador( pero ya se ensamblador, lo que no se es el funcionamiento de esto en procesadores x86, es fundamental, porque es la base para programar el kernel, y sin kernel nada funciona con gran facilidad de uso ) pero ningún documento que me diga el funcionamienrto de esto para procesadores x86 de 16 y 32 bits.

Khronos14

#1
Para procesadores x86 en modo real (16 bits) no se si existe algo como eso...

En cambio en modo protegido o en modo largo (32 o 64 bits), dispones del PIT (Programmable Interval Timer). Puedes configurar la frecuencia en la que se va a producir una interrupción del PIT y que ejecute una función tuya, pero esto no es nada fácil y requiere hacer muchas cosas antes.

http://wiki.osdev.org/Programmable_Interval_Timer

1. Entrar en modo protegido y configurar la GDT (Global Descriptor Table). En esta tabla, se separan los rangos de memoria con los niveles de privilegio, básicamente sirve para dividir la memoria en partes para poner los programas en modo kernel o en modo usuario.

http://wiki.osdev.org/Global_Descriptor_Table

2. Configurar la IDT (Interruption Descriptor Table). Es una tabla en la que puedes registrar las interrupciones que deseas capturar, entre ellas están las excepciones del sistema (Page Fault, Double Fault, Tripe Fault, Division by Zero, etc..) y las interrupciones hardware, también conocidas como IRQs (FD, IDE, ATA, PIT, etc..). Esta tabla es de tamaño fijo y se carga en la memoria del procesador con la instrucción de ensamblador LIDT.

http://wiki.osdev.org/Interrupt_Descriptor_Table
http://wiki.osdev.org/Interrupts

y etcétera...

Programar un Kernel es una locura y tienes que tener mucho tiempo libre, saber mucho ensamblador, C e inglés.

La mejor página para buscar información es esta:
http://wiki.osdev.org/Main_Page

Y si te lo quieres tomar más en serio, en google puedes encontrar los manuales de Intel (3000 páginas) y AMD.

Saludos.

mikemizi

#2
Muchas gracias, almenos ya teno algo para empezar.

El kernel será monolítico( cómo es de esperar en un sistema UNIX verdadero ).

El motivo de escribirlo es por diversión y para sustituir al kernel linux y a las aplicaciones GNU hasta tener un sistema operativo comleto y no una mezcla de linux y GNU, así se evitará todo tipo de controversias de si es GNU/Linux o nó.

Escribiré también init, sh, una shell que sustituya a bash( con sintaxis bourne shell ), los comandos básicos, awk y el resto de aplicaciones necesarias para tener un UNIX completo que cumpla absolutamente con el estándar POSIX o el UNIX03+.

Aunque será muy básico, al menos funcionará, lo liberaré cómo software libre copyleft( GPLv3+ ).

Ya tengo algo, así que espero que pronto esté terminado, eso sí, no será tan grande cómo GNU/Linux o FreeBSD.

Si no te importa, sabes dónde está el manual de los procesadores intel que dices que tiene 3000 páginas, es que he buscado en la página de intel y sólo me salen catálogos de procesadores.

Gracias de antemano y saludos a todos.

Khronos14

Que el Kernel sea monolítico es una mala elección, hacer un cambio ahora mismo en Linux es una locura y los desarrolladores están criticando mucho la elección monolítica de Torvalds.

Tienes sistemas operativos con certificación UNIX como Mac OS X (kernel híbrido) y Minix (Micronúcleo).

Aquí tienes el manual de Intel:

http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf

Saludos.

mikemizi

Gracias por el manual, ahora ya tengo por fin la posibilidad de terminar el kernel.

El kernel debe ser monolítico por los siguientes motivos:

UNIX es un sistema operativo monolítico( así lo diseñaron Dennins M. Ritchie y Ken Thompson ).
No escribirlo monolítico sería no seguir la filosofía de UNIX.
Traicionaría el sentido histórico.
No me gustan los kernels no monolítcos.
Aunque esos sistemas estén aprobados por The Open Group, al fin y al cabo no son sistemas UNIX, puesto que no siguen la filosofía UNIX.
Evitar la congestión de mensajes de los kernels no monolíticos debido a que los servidores usan mucha memoria para ello.
Evitar depurar muchos programas cuando puedes depurar uno solo divido en módulos compilables y depurables por separado que son enlazados en un único fichero posteriormente.
Fácil de escribir.
Espacio único de direcciones para el kernel y otro para los procesos de usuario.
Más seguro.
Modularidad que permite elegir si recompilar o cargar un módulo.

Saludos a todos.