AVISO: contenido matemático

Aún podemos afinar más el análisis. Si realmente cada instrucción lleva asociado un ciclo extra por refresco de memoria tendríamos:

La solución con suma de 16 bits = 25 ciclos (22 + 3 instrucciones)

La solución con el salto =

21 ciclos (18 ciclos + 3 instrucciones) en el caso mejor.
26 ciclos (22 ciclos + 4 instrucciones) en el caso peor.

  En este caso el caso peor supondría un ciclo extra con respecto a la solución con suma de 16 bits, pero sólo sucedería si A+L activa el flag de acarreo. Para ello habría que calcular cual es la probabilidad de que A+L active el flag de acarreo, hagámoslo:

  Supongamos que la probabilidad de que un registro tome un valor cualquiera entre 0 y 255 es uniforme, de tal forma que la probabilidad de que A = V sea 1/256 (de igual manera la probabilidad de que L = W es 1/256). Supongamos, además, que los valores que tomen A y L son totalmente independientes, por lo que la probabilidad de que A = V y L = W es 1/65536 (el producto de ambas probabilidades).

  Ahora viene lo farragoso: calcular la probabilidad de que A+L active el flag de acarreo, es decir: conocer todos los valores V y W que sumados sean 256 o más. Vayamos paso a paso:

-Si A = 0, la suma será como mucho 255, luego la probabilidad de activación del flag (en adelante PAF) es 0.
-Si A = 1, para L = 255 la suma será 256, luego PAF = 1/65536 (sólo un par de valores activan el flag).
-Si A = 2, para L = 254 ó L = 255 la suma será superior a 255, luego PAF = 2/65536 (así que ya tenemos 3 pares de valores)
...

  Si continuamos para todos los valores de A (0..255) podremos sacar como conclusión que la probabilidad de que un par de valores concretos sumen más que 256 es

Sumatorio en A perteneciente a {0..255}. ( A / 65536 )

que es igual a

( Sumatorio en A perteneciente a {0..255}. ( A )  ) / 65536

  Ahora recordemos las clases de matemáticas cuando nos enseñaban a sumar una serie de números consecutivos (nota histórica: al parecer la idea se le ocurrió a Gauss cuando tenía 5 añitos): el primero más el último multiplicado por el número de términos y dividido por dos. Por lo tanto:

( Sumatorio en A perteneciente a {0..255}. ( A )  ) = ( ( 0 + 255 ) * 256 ) / 2 = 32640

  Así pues la probabilidad de que la suma de dos bytes cualesquiera active el flag de acarreo es

32640/65536 = 0'4980...

  Algo menos de la mitad. Y la probabilidad de que la suma no active el flag de acarreo (con lo que nos saltaríamos la instrucción INC H) es:

32896/65536 = 0'5019...

  Un poquito más de la mitad. Así que es más probable (por poco) que la suma de dos bytes cualesquiera no active el flag de acarreo. Por lo tanto el coste en media de la rutina con el salto es:

21 * ( 32896 / 65536 ) + 26 * ( 32640 / 65536 ) = 23'49 ciclos

un ciclo y medio menor que los 25 ciclos que cuesta siempre la otra rutina.

  Si es una rutina crítica que se vaya a usar a menudo un ciclo y medio siempre es importante

Saludos
--
SapphiRe

  Aún más...  esto se me ha ocurrido en el coche mientras venía hacia casa, ¡¡para que luego digan que los atascos en la M30 por culpa de las obras son inútiles!!

  Esta rutina está limitada a valores de A entre 0 y 8, por lo que la probabilidad de activar el flag de acarreo es

( Sumatorio en A perteneciente a {0..8} ( A ) ) / 65536 = 36/65536 = 0'0005491...

  Es decir, en este caso concreto la probabilidad de que la tabla se coloque en una posición que haga que la rutina con el salto sea menos eficiente es inferior al 0'1%, por lo que la velocidad en media de la rutina será mucho más cercana a los 21 ciclos del caso mejor que a los 26 del caso peor, ganando aproximadamente 4 ciclos de reloj.


Eso digo yo Encima a un matemático que se dedica a la enseñanza del análisis de algoritmos...


Exagerado... si en el fondo te has leído entera la discusión matemática y estás de acuerdo conmigo

Pues ya veo que mejor me callo...

Siento el comentario, Sap: me has convencido de la bondad de los saltos frente a las sumas de 16 bits, que son las que vengo usando desde hace bastante. Por cierto, que ya tengo un asMSX con PHASE/DEPHASE y alguna que otra sorpresita. Ahora me falta implementar lo que más ilusión me hace:

.MEGAROM konamiSCC

.BANK 1 AT 4000h

...

.SELECT 2 AT 6000h

Me parece que la sintaxis es bastante clara. Es decir, se define que el formato de salida será un megaROM con un determinado mapeador, se define el programa contenido siempre en bancos (de 8 o 16 KB según el mapeador) y se tiene una rutina de selección de banco. Es la solución más sencilla a la que he llegado. Ya que aquí tenemos abundancia de mentes capaces, ¿se os ocurre otra forma mejor de hacerlo? ¿Alguna sintaxis más conveniente?

Eso es exactamente lo que hace la BIOS (por lo menos la que yo miré).


Pues aunque solo sea por curiosidad, ahí va una chapucilla que prueba el joystick en el puerto 1. Si funciona en todas las máquinas se puede decir que GTSTCK a la salida entrega E así:
siendo 0-pulsado  1-no pulsado.

(p.d. me he desvirgado,este es el primer programa que hago en ensamblador... )

 Joder Saphire ahora que viene la Declaración de la Renta que no se metan contigo, si los de Hacienda te estafan aunque sólo sea un céntimo de Euro... les vas a hacer papilla.
 Invertiste algo en sellos??

Solo las direcciones. En el Philips VG-8020 también va. En la primera generación no creo que haya problema, me preocupa un poco más el resto, aunque pienso que tiene que funcionar.

un saludo.