Como en mi convivencia con los compiladores de C retro he visto muchas cosas raras he hecho unas pruebas para ver que tipo de peculiaridades tiene el gbdk...
Estas pruebas que no tienen por que ser concluyentes, pero si ayudan a alguien más pues aquí quedan
Pruebas de tamaño:
if(level == 0)
{
....
}
else if(level == 1)
{
....
}a esta estructura: switch(level)
{
case 0:
....
break;
case 1:
....
break;
}El código generado es 7 bytes menor.
Curioso lo de los bucles, este for ocupa ~19bytes...
for( x = 0; x != 18; x++ )
{
....
}Igual que este while...
x = 0;
while( x != 18)
{
....
x++;
}Pero un do, while ocupa 2 bytes más :?x = 0;
do
{
....
x++;
}while( x != 18);... curioso, no?
Sin embargo, si os valiera empezar desde el valor final...
x = 18;
do
{
....
} while(--x);El código generado es 4 bytes menorLuego hay que tener cuidado por que no vale para todas las situaciones pero...
if( ScrollXCnt == 8 )if( ScrollXCnt & 8 )El código generado es 2 bytes menor.
Esto es un clásico pero si el módulo es potencia de dos...
temp = dx % 32;temp = dx & (32 - 1);El código generado es 10 bytes menor.
#define ANCHO 64
...
dx = dy + dz + 21 + (ANCHO * 18);Podría parecer lo mismo que...
#define ANCHO 64
...
dx = dy + dz + (21 + (ANCHO * 18));¡Pues no! este es 8 bytes menor. Asi que intentad agrupar las constantes.
if(dx == 0)if(!dx)El código generado es 5 bytes menor.
Luego sin diferencias en tamaño, pero quizás pudieran necesitar unas más ciclos que otras son:
dx = dy = 0;
dz++;
...
if ((dx == 1)&&(dy == 2))
...
if (dz < 1)
...
respecto a:
dx = 0;
dy = 0;
dz = dz + 1;
...
if (dx == 1) {
if (dy == 2) {
...
if(dz != 1) //según la doc esto seria más rápido aunque ocupe lo mismo
...
Estas son las pruebas suyas las conclusiones
