Ver la versión completa : ¿Aprovechamiento del 2º micro en el compilador?
Comentándole a alguien que entiende del tema el problema del aprovechamiento del segundo micro, al no tener MMU. Me comentaba que una buena opción sería modificar el compilador para que sea él el que haga dicho aprovechamiento.
Esta opción sería transparente o semi-transparente al programador (se podría especificar qué cosas ejecutar en el segundo micro o dejar que lo decida el compilador) y sería independiente de ejecutar el código sobre linux o sobre un firmware distinto.
La idea es buena, pero creo que sería algo horrorosamente complicado ponerse a modificar el GCC para conseguir esto...
¿Alguno habeis trasteado alguna vez con el código del GCC y podríais decir hasta que punto esto sería viable?
Por este tipo de cosas se crearon los sitemas operativos... [wei4]
Yo no lo veo factible en un futuro cercano ni lejano.
Se pueden hacer cosillas pero no sacarian ni una decima de partido al 2 procesador.
Tenemos un problema y es que casi todos los emuladores por no decir todos de los que se portan son programados en un unico flujo de ejecución cuando la mayoria de las formas de aprovechar el segundo procesador se basan en "un hilo paralelo" e ideas semejantes.
Esta idea del hilo paralelo es algo clave para unas librerias 3D para un hipotetico emulador de PSX con el 2º procesador en _asm del arm. Pero en el resto de emulaciones resulta un engorro su aprovechamiento por la idea de cambiar el codigo para aprovechar un "hilo paralelo" lo que resulta harto complicado para todos.
He aqui el dilema thread o no thread, esa es la cuestion.
Por cierto java le esta declarando la guerra a la clase Thread. [wei4] una anecdota.
El saber no ocupa lugar, sus metodos stop();, resume(); y otro... han pasado a deprecated.
La noticia no es nueva pero a mi me ha dejado anodadado, que dejo, los threads parados?? :shock:
Una pregunta ¿En que afecta el no tener unidad de manejo de memoria al 2 procesador?
¿Podemos hacer 1 Thread paralelo, no?
¿No podemos acceder a ninguna parte de la RAM?
¿no podemos meter opcodes de manejo de memoria???
Es algo que me confunde.
Explicarlo un poco please.
He aqui el dilema thread o no thread, esa es la cuestion.
Por cierto java le esta declarando la guerra a la clase Thread. [wei4] una anecdota.
El saber no ocupa lugar, sus metodos stop();, resume(); y otro... han pasado a deprecated.
La noticia no es nueva pero a mi me ha dejado anodadado, que dejo, los threads parados?? :shock:
Hace tiempo ya de eso. No es declararle la guerra a los hilos, sino a los semáforos, que pueden producir interbloqueo y cosas de esas si no están bien programados...
La solución que plantean los de Sun, y la que uso yo viene a ser algo como esto:
private boolean bloqueado = true; //estado del hilo
// Bloquea el hilo. Se ha preferido no utilizar el método suspend() por
// problemas de interbloqueo (ver documentacion JDK1.3)
public synchronized void bloquear() {
bloqueado = true;
}
// Reanuda el hilo. se ha preferido no utilizar el método resume() por
// problemas de interbloqueo (ver documentacion JDK1.3). Si el hilo ha
// muerto o no ha comenzado su ejecución la inicia.
public synchronized void desbloquear() {
bloqueado = false;
if (!isAlive())
start();
else
notify(); // Pertenece a la clase Object. Continua un wait()
}
// Codigo de ejecucion de la tarea
public void run()
{
while (true)
{
// controla el estado de bloqueo
synchronized (this)
{
while (bloqueado)
{
System.out.println("El hilo ha sido bloqueado");
try { wait(); } catch (InterruptedException e) {};
System.out.println("El hilo continúa.");
}
}
}
Pero volviendo al tema. La verdad es que lo del compilador sería un engorro, pero si se hiciera sería la solución a nuestros problemas. Yo optaría por la opción semi-transparece, mediante la cual al programador pudiera especificar mediante directivas del compilador qué partes del código se deberían ejecutar en el segundo micro, como una rutina gráfica o de sonido (directiva de inicio y fin). Habría limitaciones respecto a la visibilidad de variables dentro de dichas regiones.
Bueno, quiza también se pueda currar algo en plan librería sin modificar el compilador...
Una pregunta ¿En que afecta el no tener unidad de manejo de memoria al 2 procesador?
¿Podemos hacer 1 Thread paralelo, no?
¿No podemos acceder a ninguna parte de la RAM?
¿no podemos meter opcodes de manejo de memoria???
Te explico un poco por encima.
El segundo micro, al no tener MMU no puede resolver las direcciones de memoria virtuales a físicas, al menos no como lo hace el primer micro. El segundo micro sólo trabaja con direcciones físicas puras. Aunque el primer micro puede especificarle al segundo los bits de mayor peso de las direcciones a utilizar por el segundo micro, lo que viene a ser como dividir la memoria (física) en páginas en las que el primer micro le dice al segundo qué pagina coger y el segundo trabaja sobre esa página.
Según he visto en el kernel de MagicEyes, se reserva 1MB de ram para que trabaje el segundo micro sobre él. Un ejemplo práctico sería el siguiente (los datos no son reales, para facilitar la comprensión):
El segundo micro tiene reservados 1MB de RAM dividido en 100 páginas de 10KB. Supongamos que tenemos una rutina para el segundo micro que aplica un efecto sobre una imagen contenida en una de estas páginas (una interpolación, por ejemplo).
El primer micro entonces accede a las páginas 1, 3 y 4; y le indica al segundo que ejecute la rutina sobre cada una de estas páginas.
Al terminar la ejecución de cada una le lanzaría una interrupción al procesador principal, para informarle de la finalización, y éste le ordenaría comenzar con la siguiente...
Lo suyo sería tener 2 o más hilos corriendo sobre el primer micro, y en uno de ellos ir dándo ordenes al segundo.
Bueno de todas formas hasta que los de GPH no le pegen un cambio del chupinazo
al kernel y a la forma de manejar los codecs y demas, este tema va a quedar en el aire.
Ya veremos cuando me llegue la consola mirare que cosas se pueden intentar con _asm.
Puff me voy a dormir, ciao!
¿Pero como se hara para q el compilador entienda que ciertas cosas las ha de hacer el segundo micro?
¿Se creara un thread y se le dira que este trabajo es para el segundo micro?
¿O quizas en ciertas funciones de las SDL el compilador se encargara de que las realice el segundo microprocesador para aprovechar la aceleracion grafica de este?
Yo no se mucho del tema... :shock:
Yo creo que lo más sencillo sería a través de directivas del compilador. Algo así como
int main() {
//Codigo que se ejecuta en el micro principal
int parametro1 = 1, parametro2 = 2;
int dato = suma_segundo_micro(parametro1, parametro2)
return 0
}
#cpu940
int suma_segundo_micro(int p1, int p2) {
//Codigo que se ejecuta en el segundo micro
return p1 + p2;
}
#endcpu940
con las directivas #cpu940 y #endcpu940 le especificariamos al compilado que la función debe ejecutarse en el segundo micro. Sería el compilador el encargado de gestionar el paso de parámetros, así como el valor devuelto.
La llamada en el main() quedaría bloqueada hasta la vuelta del parámetro, por lo que se deberían ejecutar 2 hilos sobre el micro principal: uno que hace el programa principal, y otro que realiza las llamadas al segundo micro y espera las respuestas.
Cómo veis, modificar el compilador para que haga estas cosas es un carajal, pero si se consiguiese hacer, sería muy facil utilizar el segundo micro.
Se podría hacer lo mismo sin modificar el compilador, por supuesto, pero tendríamos que meter ensamblador al código...
No creo q se ganase nada no?
Incluso con dos hilos el hilo del Procesador principal tendría que esparar a que el otro procesador terminara por lo que mientras el principal trabajara el secundario esperaría y a la inversa.
Es una buena idea pero no creo q mejorara el rendimiento, la programación multihilo la debería de hacer el programador dividiendo tareas y seguro que nunca estarían los dos micros trabajando al 100% (o eso creo yo)
Es una buena idea pero no creo q mejorara el rendimiento, la programación multihilo la debería de hacer el programador dividiendo tareas y seguro que nunca estarían los dos micros trabajando al 100% (o eso creo yo)
De eso se trata. Tendrías 2 hilos en el micro principal. Por ejemplo uno destinado al sonido y otro al resto del programa. El de sonido haría llamadas al segundo procesador y, mientras espera a que este termine, pasaría a ejecución el primer hilo con el resto del programa.
El funcionamiento es el mismo que con un sólo micro, solo que en este caso tendríamos los 2 hilos ejecutandose a la vez (aunque el hilo de sonido quedase bloqueado en el micro principal, el hilo principal seguiría ejecutándose).
No se si me explico :rolleyes:
De todas formas, como ya digo, esto se puede conseguir de diversas formas sin modificar el compilador (metiendo ensamblador para manejar el segundo micro, llamándo a librerías ya creadas para ese fin, modificando en kernel del SO...). A mí me parece que ésta sería un punto medio entre la transparencia que daría tirar de librerías, y la flexibilidad de hacerlo en ensamblador.
WinterN tío te ignoran [wei4]. A ver si atendemos un poco mas :rolleyes:.
Bueno las directivas no separan competencias así que por ahí no es viable, 100% seguro de que no sirve. Pueden haber tras alternativas, quizás... nop.
WinterN ya te digo que no es viable.
Tengo que ir a clase te lo digo rápido.
Un programa se carga en memoria, al compilar se calculan las direcciones al compilar... bueno, mas rápido aun, que no co.ño que no. Lo mas viable que veo es la programación de aplicaciones en dos programas (2 ejecutalbes) uno el del micro principal y otro el del secunadario que se comunicasen a traves de interrupciones de software o un espacio de variables en una segmentación de memoria. Por supuesto habria un Thread secundario en el programa del arm principal. El primero lanzaría al segundo.
Esa es mi idea. La otra ya te digo de que no vale.
No se puede hacer nada mas simple.
Ciao!
Bueno, quizá la idea del compilador no era viable, por eso preguntaba.
La idea de tener 2 ejecutables tampoco me gusta, creo que tendría que poder hacerse todo en uno sólo. El segundo micro tiene reservado 1MB de ram, lo que no quiere decir que el primero no pueda escribir sobre ella y usarla como memoria compartida. Claro que entonces tenemos el problema del espacio de direcciones lógicas...
A ver si nos llega ya la consola y podemos experimentar con estas cosas. A ver también si GPH saca los fuentes y vemos como hace uso del segundo micro el mplayer...
hectorblanco
16/11/2005, 03:47
Bueno, quizá la idea del compilador no era viable, por eso preguntaba.
La idea de tener 2 ejecutables tampoco me gusta, creo que tendría que poder hacerse todo en uno sólo. El segundo micro tiene reservado 1MB de ram, lo que no quiere decir que el primero no pueda escribir sobre ella y usarla como memoria compartida. Claro que entonces tenemos el problema del espacio de direcciones lógicas...
A ver si nos llega ya la consola y podemos experimentar con estas cosas. A ver también si GPH saca los fuentes y vemos como hace uso del segundo micro el mplayer...
Tambien podria ser que a nivel de hardware el primer CPU estuviera programado para enviar todas las instrucciones de tipo multimedia al segundo core.
Aunque sólo saldremos de dudas cuando GPH saque el SDK con todas las herramientas, y sobre todo tutoriales y documentación.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.