Emulador de tlcs900h escrito en ensamblador

Bueno, realmente es para darte la enhorabuena !

Un compilador como GCC o Microsoft C, está hecho por gente mucho más inteligente que yo, y por lo tanto, genera un código mucho, mucho, mucho más eficiente, de lo que yo jamás podría conseguir mediante código ensamblador.

Enhorabuena!!! No borres el hilo hombre, es un gran trabajo.

Bueno, los resultados "mundo real" del emulador del 900h


60 hermosos fps

Trabis escribió:Un compilador como GCC o Microsoft C, está hecho por gente mucho más inteligente que yo, y por lo tanto, genera un código mucho, mucho, mucho más eficiente, de lo que yo jamás podría conseguir mediante código ensamblador.

Bueno, gcc va a generar en funcion a lo que escribas, asi que a menos que la pifies muy mal en ensamblador, siempre va a ser mejor tu codigo en asm, que el generado basado en uno que escribieras en C

theelf escribió:
Bueno, gcc va a generar en funcion a lo que escribas, asi que a menos que la pifies muy mal en ensamblador, siempre va a ser mejor tu codigo en asm, que el generado basado en uno que escribieras en C

Un ejemplo sencillo para que nos entienda la gente:

Si yo por ejemplo en un código de C/C++ divido o multiplico por una potencia de 2 como por ejemplo 8, entonces un compilador como GCC que es muy inteligente y genera código muy optimizado, se dará cuenta que en vez de utilizar las caras dividir o multiplicar, puede utilizar en cambio un desplazamiento de bits que es mucho más rápido o eficiente. Si por ejemplo declaras una variable y no la utilizas, pues el compilador se da cuenta. Quien dice eso dice utilizar los registros cuando se pueda, o utilizar las funciones SIMD cuando trabajas con 4 floats juntos o miles de cosas más.

Como actives la opción optimizar al máximo en esos compiladores ,estos te generan unas optimizaciones absolutamente locas.

Trabis escribió:

theelf escribió:
Bueno, gcc va a generar en funcion a lo que escribas, asi que a menos que la pifies muy mal en ensamblador, siempre va a ser mejor tu codigo en asm, que el generado basado en uno que escribieras en C

Un ejemplo sencillo para que nos entienda la gente:

Si yo por ejemplo en un código de C/C++ divido o multiplico por una potencia de 2 como por ejemplo 8, entonces un compilador como GCC que es muy inteligente y genera código muy optimizado, se dará cuenta que en vez de utilizar las caras dividir o multiplicar, puede utilizar en cambio un desplazamiento de bits que es mucho más rápido o eficiente. Si por ejemplo declaras una variable y no la utilizas, pues el compilador se da cuenta. Quien dice eso dice utilizar los registros cuando se pueda, o utilizar las funciones SIMD cuando trabajas con 4 floats juntos o miles de cosas más.

Como actives la opción optimizar al máximo en esos compiladores ,estos te generan unas optimizaciones absolutamente locas.

Esto es un debate bastante curioso. Lo que dices tiene razon, en el sentido bruto de la palabra, y es asi a un nivel muy concreto. El compilador puede asumir muchisimas cosas y verificar tantas otras para optimizar valores, pero no tiene un dato muy valioso: el contexto. El programador, si sabe lo que hace, es siempre consciente del contexto de lo que hace. En que momento esta, como distribuye sus datos, como optimiza ciertas rutinas. El compilador hace lo que puede, y lo hace muy bien, pero cuando tu defines dos estructuras de datos el compilador no tiene una referencia concreta de como vas a acceder a ellas, a veces si a veces no. Tu, como programador, si que puedes saberlo y organizar la estructura para optimizar lecturas de cache, por ejemplo. Memoria principal puede ser 100 o 200 veces mas lenta que una cache y el flujo de ejecucion de un programa, sobre todo cuando tiene punteros, es altamente complicado para optimizaciones buenas.

Con esto quiero decir que hacer algo en ensamblador mejor que un compilador es posible, muy posible. Hacer un navegador web mejor que un compilador no, pero ciertas tareas localizadas en las que el programador aplica contexto y estructura lo que hace en base a rendimiento si. Los compiladores mejoraran con el tiempo, pero aun no tienen la capacidad humana de conocer y extrapolar situaciones en base a informacion independiente del contexto.

Un saludo gente!

PS Perdon por la falta de tildes!

alkaitz escribió:
Esto es un debate bastante curioso. Lo que dices tiene razon, en el sentido bruto de la palabra, y es asi a un nivel muy concreto. El compilador puede asumir muchisimas cosas y verificar tantas otras para optimizar valores, pero no tiene un dato muy valioso: el contexto. El programador, si sabe lo que hace, es siempre consciente del contexto de lo que hace. En que momento esta, como distribuye sus datos, como optimiza ciertas rutinas. El compilador hace lo que puede, y lo hace muy bien, pero cuando tu defines dos estructuras de datos el compilador no tiene una referencia concreta de como vas a acceder a ellas, a veces si a veces no. Tu, como programador, si que puedes saberlo y organizar la estructura para optimizar lecturas de cache, por ejemplo. Memoria principal puede ser 100 o 200 veces mas lenta que una cache y el flujo de ejecucion de un programa, sobre todo cuando tiene punteros, es altamente complicado para optimizaciones buenas.

Con esto quiero decir que hacer algo en ensamblador mejor que un compilador es posible, muy posible. Hacer un navegador web mejor que un compilador no, pero ciertas tareas localizadas en las que el programador aplica contexto y estructura lo que hace en base a rendimiento si. Los compiladores mejoraran con el tiempo, pero aun no tienen la capacidad humana de conocer y extrapolar situaciones en base a informacion independiente del contexto.

Un saludo gente!

PS Perdon por la falta de tildes!

Buen post.

Me doy cuenta que estás al tanto de la magnífica charla de Mike Acton de Insomniac."Data-Oriented Design and C++".
(Esa charla ha marcado un antes y un después en el desarrollo de videojuegos).

Seguramente está otra no la has visto, porque es reciente. También habla de DOD y es en la lengua de Cervantes: Mind the cache.

Pues la verdad que no habia visto ninguna de las dos charlas, pero otras similares si. No te voy a enganhar.A ver si en el 2006 me dejan ir a la CppCon que la tengo aqui al ladito! Jejeje

En el fondo el gran problema ya no es el flujo y optimizar su orden, que es en lo que es dificil o casi imposible ganar al compilador, sino el modelo de memoria que usa el programa. La mayor parte de los lenguajes tienen un modelo estructurado que asume que variables relacionadas con una entidad (clase y sus atributos, por ejemplo) han de ser compactadas y guardadas de forma unitaria en el mismo bloque de memoria. Casi todos los lenguajes hacen esto porque es cierto que en muchos, quizas la mayoria, de los casos la probabilidad de uso cercano es alta.
Tengo entendido que ya hay modelos de compilacion que son capaces de aceptar resultados de profiling para ver en que partes la cosa no funciona como deberia y poder restructurar el modelo de memoria de una manera mas optima. Esto obviamente ralentiza bastante el proceso de compilacion y lo hace dependiente de ejecuciones concretas en el profiling, pero es un avance muy muy notable.

Pero en lo general si que coincido contigo, generalmente no es recomendable escribir ensamblador. Limita la portabilidad y potencia la aparicion de errores. Eso tampoco quita decir que el emulador escrito en ASM de este hilo sea un gran trabajo y merezca muy mucho la pena! De hecho, la mayor parte de los emuladores de arquitecturas "recientes" requiren de ciertos niveles de ensamblador para poder estar a la altura.

Un saludo a todos!