Diferencias

Muestra las diferencias entre dos versiones de la página.

--- cursos:ensamblador:codigo_maquina [19-01-2024 06:59] – [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
@@ Línea 685: / Línea 685: @@
     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]
     inc de                         ; Apuntamos al siguiente dato
@@ Línea 766: / Línea 766: @@
   * **Normas para las instrucciones:**\\ \\
     * 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 '';'').\\ \\
-    * 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.\\ \\
     * 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.\\ \\
@@ Línea 774: / Línea 774: @@
     ; Todo mayúsculas, espacio tras la coma
     LD A, 10
+bucle:
     AND $F0
     CALL rutina
@@ Línea 784: / Línea 785: @@
     ; Con espacio tras la coma
     ld a, 10
+bucle:
     and $f0
     call rutina
@@ Línea 794: / Línea 796: @@
     ; Sin espacio tras la coma
     ld a,10
+bucle:
     and $f0
     call rutina
@@ Línea 803: / Línea 806: @@
     ; Todo mayúsculas, tab entre nmenónico y operandos
     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
-    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>
@@ Línea 853: / Línea 880: @@
     * 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.\\ \\
-Para los listados y ejemplos del curso utilizaremos siempre que se pueda la siguiente configuración para el código:
+\\
+===== Guía de estilo para escribir ASM =====
-   * Minúsculas para los nmemónicos. con espacio tras la coma de los operandos (''ld a, 10'').
+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.
-   * 4 espacios de indentación (aunque 8 podría ser más legible en un editor de texto moderno, por limitaciones de espacio en el texto impreso, para tutoriales, cursos o libros suele ser más apropiado 4).
-   * Comentarios en una columna variable: no siempre (entre diferentes listados) comenzarán en la misma columna, sino que según el ejemplo y la longitud de las etiquetas podrán estar en columnas diferentes.
-   * Siempre que sea posible, etiquetas de puntos de salto (bucles, bifurcaciones) en "snakecase" (''fin_rutina'') excepto los puntos de entrada de las rutinas (los que se llamarían con un ''CALL''), que se escribirán en "CamelCase" como ''MenuPrincipal'' o ''LeerTeclado''.
-   * Rutinas documentadas con una cabecera explicando qué hacen, qué parámetros de entrada tienen, qué salida producen y en qué registros, y qué registros/variables cambian.
-   * Comentarios para explicar el objetivo de un bloque de código, y no para 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''.
+\\
+**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.