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 :)
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
Curioso el bug, no me lo esperaba :P
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.
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.
Quote from: Drumpi on August 04, 2010, 05:35:45 PM
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.
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í?.
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.
Ok, gracias. Si encuentro la solución, te aviso.