Bug en endianess con las locales de tipo BYTE

[josebita]

Anoche por fin pude encontrar el fallo por el cual el eek sólo mostraba una pantalla en la Wii, a pesar de que el mismo código de la versión monolítica mostraba todas las pantallas en el ordenador.

Parece que hay un bug relacionado con la endianess (imagino; dado que el mismo código C funciona bien en Linux y falla en la Wii) que hace que cuando se pasa como parámetro a una función el valor de una variable local de tipo BYTE definida previamente, ese valor no se tome y se asigne siempre 0.

Pongo un ejemplo:
[code language="bennu"]import "mod_mouse"
import "mod_say"
import "mod_map"
import "mod_rand"

Local
byte var;
End;

Process robot(var)
Begin
   say("VAR: "+var);
End;

Process main()
Begin
   robot(rand(0, 10));
   robot(rand(0, 10));
   robot(rand(0, 10));
   robot(rand(0, 10));
End;[/code]
En la Wii la salida es:
[code language="bash"]VAR: 0
VAR: 0
VAR: 0
VAR: 0[/code]
Mientras que en el ordenador, la salida es:
[code language="bash"]VAR: 6
VAR: 10
VAR: 6
VAR: 2[/code]

Si el tipo de la variable local no se define (o se define como INT), el invento funciona sin problemas:
[code language="bennu"]import "mod_mouse"
import "mod_say"
import "mod_map"
import "mod_rand"

Local
var;
End;

Process robot(var)
Begin
   say("VAR: "+var);
End;

Process main()
Begin
   robot(rand(0, 10));
   robot(rand(0, 10));
   robot(rand(0, 10));
   robot(rand(0, 10));
End;[/code]
No he probado con otros tipos de datos como WORD o similares, eso sí.

Pues eso; no me he puesto a buscar el origen en el código C, pero me imagino que tendrá la misma raíz que todos los bugs de endianess que tocamos hace tiempo.

PD: Haciendo el cambio en las locales, el mono ya corretea libremente por sus 8 niveles en la Wii y promete dar caña pronto :)

[SplinterGU]

si, ya me imagino que es, me lo esperaba, pero hay que tocar mucho en el bgdrtm.

supongo que pasara en todo lo que no sea 32bits

[Windgate]

Curioso el bug, no me lo esperaba :P

[Drumpi]

Por cierto ¿se llegó a arreglar el "bug" del alineamiento en memoria de los datos tipo byte y word? me refiero a que antes, estos tipos de datos, siempre ocupaban 4 bytes, aunque sólo se leyesen 1 o 2 bytes respectivamente.
Yo por eso siempre uso INT mientras no use un registro o un vector, sé que no es correcto hacerlo, pero te quitas de bugs y problemas, como en este caso.

[SplinterGU]

wind, es un tema para los procesadores con diferentes endian, no es realmente un bug, es una funcionalidad incompleta.

el port para la plataformas bigendian no esta completo aun, y no lo estara hasta que yo disponga de algun aparatejo bigendian y tenga tiempo para terminarlo y probarlo como se merece.

a menos que otro lo haga, claro esta.

pero los cambios en esto son una pavada, pero llevan tiempo porque hay que tocar muchas lineas y posiblemente todos los modulos para estar seguros que todo lo soporte.

[SplinterGU]

Por cierto ¿se llegó a arreglar el "bug" del alineamiento en memoria de los datos tipo byte y word? me refiero a que antes, estos tipos de datos, siempre ocupaban 4 bytes, aunque sólo se leyesen 1 o 2 bytes respectivamente.
Yo por eso siempre uso INT mientras no use un registro o un vector, sé que no es correcto hacerlo, pero te quitas de bugs y problemas, como en este caso.

creo que estas mezclando todo y/o confundiendote con varias cosas.

pero si, una solucion provisoria para esto es usar int en todo, aunque hay cosas que es necesario usar un dato mas chico, por ejemplo, paletas.

[josebita]

Entonces, ¿lo dejo como bug conocido a la espera de que le puedas echar un ojo? O ¿espero a que lo puedas mirar?

En cualquier caso, una pregunta desde la ignorancia: ¿el procesador de la Wiz no funciona tanto en bigendian como en little-endian?. ¿No es posible hacer pruebas ahí?.

[SplinterGU]

no podre mirarlo ahora, pasa todo a int a ver si funciona.

wiz esta en little, no creo se pueda pasar a big, ya que las librerias son little.

[josebita]

Ok, gracias. Si encuentro la solución, te aviso.