| Ambos lados, revisión anterior Revisión previa Próxima revisión | Revisión previa |
| cursos:ensamblador:codigo_maquina [19-01-2024 06:13] – [Sintaxis del lenguaje ASM en Pasmo] sromero | cursos:ensamblador:codigo_maquina [21-01-2024 20:25] (actual) – [Guía de estilo para escribir ASM] sromero |
|---|
| |
| ld a, (de) ; Leemos un dato de [DE] | ld a, (de) ; Leemos un dato de [DE] |
| ADD A, valor ; Le sumamos 1 al dato leído | add a, valor ; Le sumamos 1 al dato leído |
| ld (hl), a ; Lo grabamos en el destino [HL] | ld (hl), a ; Lo grabamos en el destino [HL] |
| inc de ; Apuntamos al siguiente dato | inc de ; Apuntamos al siguiente dato |
| * **Normas para las instrucciones:**\\ \\ | * **Normas para las instrucciones:**\\ \\ |
| * Pondremos una sóla instrucción de ensamblador por línea.\\ \\ | * Pondremos una sóla instrucción de ensamblador por línea.\\ \\ |
| * Dado que cada editor renderiza los tabuladores con diferentes tamaños, recomendamos utilizar espacios para indentar. Para eso, utiliza la indentación de "tabulador inteligente" de tu editor, es decir, que el propio editor inserte espacios cuando utilices el tabulador. Es la única forma de que un listado se vea igual en cualquier editor y sistema operativo, algo que no ocurre con los tabuladores reales. Una tabulación inteligente de 4 espacios suele ser lo más compacto y a la vez legible: 2 espacios es poca indentación y 8 espacios aunque también es aceptable hace las líneas más anchas si incluyen comentarios a su derecha.\\ \\ | * Dado que cada editor renderiza los tabuladores con diferentes tamaños, recomendamos utilizar espacios para indentar. Para eso, utiliza la indentación de "tabulador inteligente" de tu editor, es decir, que el propio editor inserte espacios cuando utilices el tabulador. Es la única forma de que un listado se vea igual en cualquier editor y sistema operativo, algo que no ocurre con los tabuladores reales. Una tabulación inteligente de 4 u 8 espacios (al gusto visual del programador) suele ser lo más compacto y a la vez legible. Por contra, 2 espacios es poca indentación para leer el código.\\ \\ |
| * Además de una instrucción, en una misma línea podremos añadir etiquetas (para referenciar a dicha línea, algo que veremos posteriormente) y también comentarios (prececidos de '';'').\\ \\ | * Además de una instrucción, en una misma línea podremos añadir etiquetas (para referenciar a dicha línea, algo que veremos posteriormente) y también comentarios (prececidos de '';'').\\ \\ |
| * Todo lo que va después de un carácter '';'' es un **comentario** y es ignorado por el ensamblador. Podemos poner comentarios en sus propias líneas (se recomienda que para las rutinas estén al principio de la misma, y para bloques de instrucciones estén al mismo nivel que el bloque, es decir, a 4 espacios), o a la derecha de una instrucción. Si los colocamos a la derecha de la instrucción, **se recomienda elegir una posición de inicio común para todos los comentarios del listado, como por ejemplo la columna 40, 35 ó 30**.\\ \\ | * Todo lo que va después de un carácter '';'' es un **comentario** y es ignorado por el ensamblador. Podemos poner comentarios en sus propias líneas (se recomienda que para las rutinas estén al principio de la misma, y para bloques de instrucciones estén al mismo nivel que el bloque, es decir, a 4 espacios), o a la derecha de una instrucción. Si los colocamos a la derecha de la instrucción, **se recomienda elegir una posición de inicio común para todos los comentarios del listado, como por ejemplo la columna 35 ó 40**.\\ \\ |
| * **Minúsculas** y **mayúsculas**: las instrucciones y los registros pueden estar tanto en mayúsculas como en minúsculas. Es igual de válido ''ld a, 10'' que ''LD A, 10''. Usar mayúsculas o minúsculas es una preferencia personal de cada programador, y podemos encontrar listados de las 2 formas. Hace varias décadas había una especie de consenso por el cual se usaban las mayúsculas (podemos verlo en webs, revistas, libros y listados de la época). Más que consenso, se podría decir que los ensambladores de la época para muchos microprocesadores obligaban a escribir el código en minúsculas. Pero en los últimos años se ha ido imponiendo el uso de minúsculas ya el código resultante resulta menos "impactante" a la vista y es mucho más cómodo escribir sin tener que utilizar regularmente Shift o Caps-Shift cuando alternas entre código y comentarios.\\ \\ | * **Minúsculas** y **mayúsculas**: las instrucciones y los registros pueden estar tanto en mayúsculas como en minúsculas. Es igual de válido ''ld a, 10'' que ''LD A, 10''. Usar mayúsculas o minúsculas es una preferencia personal de cada programador, y podemos encontrar listados de las 2 formas. Hace varias décadas había una especie de consenso por el cual se usaban las mayúsculas (podemos verlo en webs, revistas, libros y listados de la época). Más que consenso, se podría decir que los ensambladores de la época para muchos microprocesadores obligaban a escribir el código en minúsculas. Pero en los últimos años se ha ido imponiendo el uso de minúsculas ya el código resultante resulta menos "impactante" a la vista y es mucho más cómodo escribir sin tener que utilizar regularmente Shift o Caps-Shift cuando alternas entre código y comentarios.\\ \\ |
| * De la misma forma, se puede o no poner espacios tras las comas de los operandos. Es igual de válido ''ld a, 10'' que ''ld a,10''. De nuevo, es una cuestión de preferencia personal. De nuevo en la literatura de la época nos encontraremos que los libros y publicaciones, incluído el manual del Spectrum no ponía las comas, pero personalmente encuentro más legible el código sin ellas. | * De la misma forma, se puede o no poner espacios tras las comas de los operandos. Es igual de válido ''ld a, 10'' que ''ld a,10''. De nuevo, es una cuestión de preferencia personal. De nuevo en la literatura de la época nos encontraremos que los libros y publicaciones, incluído el manual del Spectrum no ponía las comas, pero personalmente encuentro más legible el código sin ellas.\\ \\ |
| * Otra costumbre en algunos programadores es usar un tab en el espacio entre el nmemónico (''ld'') y los operandos (''a, 10''), de forma que todos los operandos queden a la misma altura. La otra opción es usar un simple espacio (no quedan el código alineado).\\ \\ Personalmente, mi opción de preferencia es: **minúsculas, con espacio tras la coma, con un espacio como separador entre nmemónico y operandos, con 4 u 8 espacios de indentación y con los comentarios en 30, 35 ó 40 según el programa**.\\ \\ Veamos un resumen de las diferentes "escuelas":\\ \\ <code z80> | * Otra costumbre en algunos programadores es usar un tab en el espacio entre el nmemónico (''ld'') y los operandos (''a, 10''), de forma que todos los operandos queden a la misma altura. La otra opción es usar un simple espacio (no quedando los operandos alineados).\\ \\ Personalmente, mi preferencia es: **minúsculas, con espacio tras la coma, con un espacio como separador entre nmemónico y operandos, con 4 u 8 espacios de indentación y con los comentarios en 30, 35 ó 40 según el programa**.\\ \\ Veamos un resumen de las diferentes "escuelas":\\ \\ <code z80> |
| ; Todo mayúsculas, espacio tras la coma | ; Todo mayúsculas, espacio tras la coma |
| LD A, 10 | LD A, 10 |
| | bucle: |
| AND $F0 | AND $F0 |
| CALL rutina | CALL rutina |
| ; Con espacio tras la coma | ; Con espacio tras la coma |
| ld a, 10 | ld a, 10 |
| | bucle: |
| and $f0 | and $f0 |
| call rutina | call rutina |
| ; Sin espacio tras la coma | ; Sin espacio tras la coma |
| ld a,10 | ld a,10 |
| | bucle: |
| and $f0 | and $f0 |
| call rutina | call rutina |
| ; Todo mayúsculas, tab entre nmenónico y operandos | ; Todo mayúsculas, tab entre nmenónico y operandos |
| LD A, 10 | LD A, 10 |
| AND $F0 | bucle: |
| CALL rutina | AND $F0 |
| LD HL, $1234 ; Hacemos HL = $1234 | CALL rutina |
| CP $FF | LD HL, $1234 ; Hacemos HL = $1234 |
| | CP $FF |
| LDI | LDI |
| JR NZ, bucle | JR NZ, bucle |
| | |
| | ; Todo minúsculas (excepto comentarios) |
| | ; Tabulado a 8 espacios (muy visible) |
| | ld a, 10 |
| | bucle: |
| | and $f0 |
| | call rutina |
| | ld hl, $1234 ; Hacemos HL = $1234 |
| | cp $ff |
| | ldi |
| | jr nz, bucle |
| | |
| | ; Todo minúsculas (excepto comentarios) |
| | ; Tabulado a 8 espacios (muy visible) |
| | ; Tab nmenónico y operandos |
| | ld a, 10 |
| | bucle: |
| | and $f0 |
| | call rutina |
| | ld hl, $1234 ; Hacemos HL = $1234 |
| | cp $ff |
| | ldi |
| | jr nz, bucle |
| </code> | </code> |
| |
| * Los operadores sólo tienen aplicación en tiempo de ensamblado, es decir, no podemos multiplicar o dividir en tiempo real en nuestro programa usando ''*'' o ''/''. Estos operadores están pensados para que podamos poner expresiones como 32*10+12, en lugar del valor numérico del resultado, por ejemplo.\\ \\ | * Los operadores sólo tienen aplicación en tiempo de ensamblado, es decir, no podemos multiplicar o dividir en tiempo real en nuestro programa usando ''*'' o ''/''. Estos operadores están pensados para que podamos poner expresiones como 32*10+12, en lugar del valor numérico del resultado, por ejemplo.\\ \\ |
| * A la hora de utilizar el paréntesis para poner un cálculo inmediato en una expresión, como por ejemplo ((32*10)+12), tenemos que tener cuidado ya que paréntesis rodeando la expresión pueden ser interpretados por el ensamblador como el operador de acceso a memoria, y no como paréntesis matemáticos.\\ \\ | * A la hora de utilizar el paréntesis para poner un cálculo inmediato en una expresión, como por ejemplo ((32*10)+12), tenemos que tener cuidado ya que paréntesis rodeando la expresión pueden ser interpretados por el ensamblador como el operador de acceso a memoria, y no como paréntesis matemáticos.\\ \\ |
| | |
| | \\ |
| | ===== Guía de estilo para escribir ASM ===== |
| | |
| | Se recomienda adoptar una "guía de estilo" para escribir código en ensamblador. Por guía de estilo entendemos el elegir un estilo único para el código (indentación, mayúsculas/minúsculas, posición de los comentarios, formato de cabecera para las rutinas, etc) y mantenerlo durante todo nuestro programa, librerías incluídas. |
| | |
| | \\ |
| | **Para los listados y ejemplos del curso hemos utilizado el siguiente estilo para el código** (siempre y cuando las limitaciones de espacio y tamaño en los ejemplos lo han permitido, en otro caso se ha modificado algún aspecto del estilo en los ejemplos): |
| | |
| | \\ |
| | * Minúsculas para los nmemónicos, con espacio tras la coma de los operandos (''ld a, 10'') y sin separar el nmemónico de los operandos con un tabulador (se usará simplemente un espacio). |
| | |
| | * 4 espacios de indentación para las instrucciones. **8 espacios suele ser la mejor opción**, porque es muy legible y evita que se mezclen tanto las instrucciones con las etiqueta, **pero en el curso por limitaciones de espacio usaremos 4**. No se recomienda utilizar tabs ya que tienen diferentes tamaños según el editor. Entre 4 u 8 espacios (igual que entre mayúsculas y minúsculas), es una simple decisión personal a la hora de tratar con el código. |
| | |
| | * Comentarios en la columna 35. Aunque en realidad, a veces hay que elegir una "columna variable": no siempre podrán comenzar en la misma columna debido a etiquetas largas. En general, se intentarán ubicar a partir de la columna 35. |
| | |
| | * Algunas personas colocan dos caracteres '';'' para el inicio de los comentarios que van sólos en una línea (y no a la derecha de una instrucción). Esas líneas de comentario comienzan por '';;'' y empiezan a 4 (u 8) espacios del inicio de la línea, igual que una instrucción. En mi preferencia personal, no suelo usar esta recomendación ya que reservo este tipo de prácticas para las cabeceras de las rutinas. |
| | |
| | * Mayúsculas para las directivas del ensamblador, como ''ORG'', ''EQU'', ''DB''/''DEFB'', etc. |
| | |
| | * Mayúsculas también para las constantes definidas por ''EQU'', tanto direcciones de salto como valores (colores, valores numéricos, etc), como por ejemplo ''COLOR_BLACK EQU 0''. |
| | |
| | * Minúsculas para las variables, como ''vidas_jugador DB 3''. |
| | |
| | * Si alguna variable es temporal ("local"), la precederemos por ''_'', como ''_valor_temporal DEFB 0''. |
| | |
| | * Una práctica que sigue gente que viene del mundo C es preceder los nombres de variables que referencian a direcciones de memoria con una ''p'' de "pointer", como ''p_atributo'', para indicar que no contiene un valor de atributo sino la dirección en memoria de un atributo. |
| | |
| | * Siempre que sea posible, etiquetas de puntos de salto (bucles, bifurcaciones) en "snakecase" (''bucle'' o ''fin_rutina'') excepto los puntos de entrada de las rutinas (los que se llamarían con un ''CALL''), que se escribirán en "PascalCase" o "UpperCamelCase" (como ''MenuPrincipal'' o ''LeerTeclado''. Es aceptable también el subrayado (''_'') para separar palabras en las rutinas si lo preferimos así: ''Leer_Teclado'', en una especie de mezcla de "snake_case" y "PascalCase". |
| | |
| | * Rutinas documentadas con una cabecera explicando qué hacen, qué parámetros de entrada tienen, qué salida producen, y qué registros/variables cambian. |
| | |
| | * Utilizar prefijos para los valores numéricos (''$'' para hexadecimal, ''%'' para binario) en lugar de sufijos (como ''h'' y ''b''). Los valores en hexadecimal, en minúsculas. |
| | |
| | * Utilizar números en binario (''%00000000'') en las operaciones lógicas relacionadas con bits (como ''AND'', ''OR'' o ''XOR'') en lugar de valores decimales o hexadecimales, ya que ayuda a entender sobre qué bits queremos actuar. |
| | |
| | * Añadir comentarios para explicar el objetivo de un bloque de código, y no para explicar instrucciones. No tiene sentido para ''AND %00000001'' decir ''; Chequeamos bit 0 de A'' cuando en ese caso concreto lo más apropiado pueda ser ''; Comprobamos si A es par o impar''. |
| | |
| | \\ |
| | Lo importante es que el lector encuentre su propio "código de estilo" y que lo siga en todos los programas que realice, tanto en el código principal como en las librerías que se desarrolle. |
| | |
| |
| \\ | \\ |