ZONA DE PRUEBAS

¡Jarl, torpedos!

Resulta que llevo unos días pogramando, y en una parte hay algo que me fallaba siempre, y la verdad es que no daba con la causa del fallo, hasta que me he puesto a debugar paso a paso y ya he visto lo que pasaba...
El fallo era que estaba usando una instrucción tal que así:



Pues bien, PASMO (el ensamblador) se lo traga perfestamente, pero a la hora de ejecutar sólo coge los primeros 8 bits de NN, con lo que en memoria está metiendo un número de 8 bits en lugar del número de 16 bits que yo quería.
Pues bien, consultando el set de instrucciones del Z80 veo que esa instrucción ¡no existe!

Oño, ¿y por qué PASMO se la traga? Me hi quedao pasmao...

Así que a partir de ahora, para meter un número de 16 bits en memoria ya sé que la única manera es hacerlo alrevés:



Qué cosas...

Bubu escribió:Pues bien, consultando el set de instrucciones del Z80 veo que esa instrucción ¡no existe!

Oño, ¿y por qué PASMO se la traga? Me hi quedao pasmao...

El manual de Pasmo dice que los literales numéricos son siempre de 16 bits y se truncarán cuando sea necesario.

Es que la orden ficticia LD (HL), NN significaría que en la dirección apuntada por HL metes un valor NN de 16 bits. Lo cual en un micro como el Motorola 68000 que trabaja con "words" de 2 bytes y "long words" de 4 bytes, podría tener sentido... pero no en un equipo de 8 bits. En Z80 una dirección de memoria tiene 1 byte y la consecutiva es otra dirección de memoria.

La orden correcta LD (NN), HL efectivamente mete el registro L en la dirección NN y mete el registro H en la dirección NN+1. Recordemos que esto es así porque el Z80 es un micro little-endian. La familia Motorola tanto el 6800, 6809 de 8 bits y el 68000 de 16 bits, entre otros, son big-endian y el byte más significativo estaría primero.

Sí, todo correcto, lo único que digo es que el ensamblador creo que debería avisar cuando trunque, ya que genera un resultado que no es el esperado. Debería dar un error, o al menos un warning con el truncamiento, digo yo.

Bubu escribió:... creo que debería avisar cuando trunque, ya que genera un resultado que no es el esperado

Es que sí es el resultado esperado.
Estás poniendo un operando de 16 donde va uno de 8, y el ensamblador lo trunca por ti, como ya te avisó en las instrucciones.

Lo que pasa, entonces, es que ld (HL), nn "debería" hacer esto:

ld (HL), LOW nn
inc HL
ld (HL), HIGH nn
dec HL

pero solo existe la opción comentada, la de meter un byte y por eso lo trunca (ejecutaría la primera instrucción indicada antes).

¡Pero puedes crear una macro para que lo imite!

MACRO ld_@HL, nn
ld (HL), LOW nn
inc HL
ld (HL), HIGH nn
dec HL
ENDM

Sería una instrucción muy útil para guardar un puntero en una zona de memoria apuntada por HL.

Edito: añadir dec HL por indicación de @PabloMarmol

pero pon un dec hl después en ese macro....

Pero vamos, que estoy de acuerdo con Bubu, debería al menos devolver un warning.

El sjASM devuelve ni más ni menos lo que está pasando, un error como un castillo: "Value out of range".

Es que por eso, el PASMO que me parece un muy buen ensamblador, portable, megacuántico y todo lo demás, pero en cambio una cosa tan simple como es detectar números que se salgan del rango en instrucciones simples, pos se las traga.
Sólo quería avisar por si alguien más lo usa, pos pa que lo sepa.

De hecho acabo de poner:



y va el tío ¡y se lo traga como si nada!

Es normal que uno que va poniendo líneas y líneas de código, ponga sin querer un número fuera de rango, y al tragárselo el PASMO pos luego da resultados inesperados, y ya sabéis lo complicado y laborioso que es depurar el código para descubrir el error. En fins... para mí es una carencia importante del PASMO, pero por lo demás fetén.

Yo que tú, aprovechaba y escribía al autor para comentarle el problema.

Si le añade aunque sea un warning, te haces la vida más fácil a ti y probablemente a más gente.