TAREA

Estudio de la arquitectura del Microprocesador ARM del RPI

Asignación:

Desde la página

[Link]

Realizar ya sea de manera física o virtual los tutoriales dispuestos en los capí[Link] 1 al 4

Esto se puede realizar usando una aplicación gráfica o la terminal del RPI.

Ensamblador ARM en Raspberry Pi

- Capítulo 1
9 de enero de 2013• Roger Ferrer Ibáñez • Raspberry Pi • brazo , ensamblador , pi , frambuesa

En mi opinión, es mucho más beneficioso aprender un lenguaje de alto nivel que un

ensamblador de arquitectura específico. Pero me apetecía aprender un ensamblador ARM
solo por diversión, ya que conozco un ensamblador 386. La idea no es convertirse en un
maestro, sino comprender algunos de los detalles de lo que sucede debajo.

Presentando ARM
Verás que mis explicaciones no pretenden ser muy minuciosas a la hora de describir la
arquitectura. Intentaré ser pragmático.

ARM es una arquitectura de 32 bits que tiene un objetivo simple en mente: flexibilidad. Si
bien esto es excelente para los integradores (ya que tienen mucha libertad al diseñar su
hardware), no es tan bueno para los desarrolladores de sistemas que tienen que lidiar con
las diferencias en el hardware ARM. Entonces, en este texto, asumiré que todo se hace en
una Raspberry Pi Modelo B que ejecuta Raspbian (la que tiene 2 puertos USB y 512
MB de RAM).

Algunas partes serán ARM-genéricas, pero otras serán específicas de Raspberry Pi. No haré
una distinción. El sitio web de ARM tiene mucha documentación. ¡Úsalo!
Ensamblador de escritura
El lenguaje ensamblador es solo una fina capa de sintaxis sobre el código binario.

El código binario es lo que puede ejecutar una computadora. Está compuesto por

instrucciones, que están codificadas en una representación binaria (tales codificaciones
están documentadas en los manuales de ARM). Podría escribir instrucciones de
codificación de código binario, pero eso sería laborioso (además de algunos otros aspectos
técnicos relacionados con el propio Linux que ahora podemos ignorar felizmente).

Entonces escribiremos ensamblador, ensamblador ARM. Dado que la computadora no

puede ejecutar el ensamblador, tenemos que obtener un código binario de él. Usamos una
herramienta llamada, bueno, ensamblador para ensamblar el código ensamblador en un
código binario que podemos ejecutar.

La herramienta para hacer esto se llama as. En particular GNU Assembler, que es la

herramienta ensambladora del proyecto GNU, a veces también se conoce como gaspor esta
razón. Esta es la herramienta que usaremos para ensamblar nuestros programas.

Simplemente abra un editor como vim, nanoo emacs. Nuestros archivos de lenguaje

ensamblador (llamados archivos fuente ) tendrán un sufijo .s. No tengo idea de por qué
es, .spero esta es la convención habitual.

Nuestro primer programa

Tenemos que comenzar con algo, así que comenzaremos con un programa ridículamente
simple que no hace más que devolver un código de error.
1/* -- first.s */
2/* This is a comment */
[Link] main /* 'main' is our entry point and must be global */
4
5main: /* This is main */
6 mov r0, #2 /* Put a 2 inside the register r0 */
7 bx lr /* Return from main */

Cree un archivo llamado [Link] escriba el contenido que se muestra arriba. Guárdalo.

Para ensamblar el archivo, escriba el siguiente comando (escriba lo que viene después $ ).

1$ as -o first.o first.s

Esto creará un first.o. Ahora vincule este archivo para obtener un ejecutable.

1$ gcc -o first first.o

Si todo sale como se esperaba, obtendrá un firstarchivo. Este es tu programa. Ejecutarlo.

 1$ ./first

No debería hacer nada. Sí, es un poco decepcionante, pero en realidad hace algo. Obtenga

su código de error esta vez.
1$ ./first ; echo $?
22

¡Excelente! Ese código de error de 2 no es casualidad, se debe a eso #2en el código

ensamblador.

Dado que ejecutar el ensamblador y el vinculador pronto se vuelve aburrido, le recomiendo

que use el siguiente Makefilearchivo o uno similar.
1# Makefile
2all: first
3
4first: first.o
5 gcc -o $@ $+
6
7first.o : first.s
8 as -o $@ $<
9
10clean:
11 rm -vf first *.o

Bueno, que paso?

Hicimos un poco de trampa solo para hacer las cosas un poco más fáciles. Escribimos
una mainfunción C en ensamblador que solo lo hace return 2;. De esta manera nuestro
programa es más fácil ya que el tiempo de ejecución de C manejó la inicialización y
terminación del programa por nosotros. Usaré este enfoque todo el tiempo.

Repasemos cada línea de nuestro archivo ensamblador mínimo.

1/* -- first.s */
2/* This is a comment */

Estos son comentarios. Los comentarios se incluyen en /*y */. Úselos para documentar su

ensamblador, ya que se ignoran. Como suele ser habitual, no anida /*y por */dentro /*porque
no funciona.
[Link] main /* 'main' is our entry point and must be global */

Esta es una directiva para GNU Assembler. Una directiva le dice a GNU Assembler que
haga algo especial. Comienzan con un punto ( .) seguido del nombre de la directiva y
algunos argumentos. En este caso estamos diciendo que maines un nombre global. Esto es
necesario porque el tiempo de ejecución de C llamará main. Si no es global, el tiempo de
ejecución de C no lo podrá llamar y la fase de vinculación fallará.
5main: /* This is main */

Cada línea en GNU Assembler que no sea una directiva siempre será como label:
instruction. Podemos omitir label:y instruction(las líneas vacías y en blanco se ignoran). Una
línea con solo label:, aplica esa etiqueta a la siguiente línea (puede tener más de una etiqueta
que se refiera a lo mismo de esta manera). La instructionparte es el propio lenguaje
ensamblador ARM. En este caso solo estamos definiendo mainya que no hay instrucción.
6 mov r0, #2 /* Put a 2 inside the register r0 */

Los espacios en blanco se ignoran al principio de la línea, pero la sangría sugiere

visualmente que esta instrucción pertenece a la mainfunción.

Esta es la movinstrucción que significa moverse . Movemos un valor 2al registro r0. En el

próximo capítulo veremos más sobre registros, no te preocupes ahora. Sí, la sintaxis es
incómoda porque el destino está en realidad a la izquierda. En la sintaxis ARM siempre está
a la izquierda, por lo que estamos diciendo algo como mover para registrar r0 el valor
inmediato 2 . Veremos qué significa valor inmediato en ARM en el próximo capítulo, no te
preocupes de nuevo.

En resumen, esta instrucción pone un 2dentro del registro r0(esto sobrescribe efectivamente

cualquier registro que r0pueda tener en ese punto).
7 bx lr /* Return from main */

Esta instrucción bxsignifica rama e intercambio . Realmente no nos importa en este

momento la parte del intercambio . Ramificar significa que cambiaremos el flujo de
ejecución de la instrucción. Un procesador ARM ejecuta instrucciones secuencialmente,
una tras otra, por lo que después de lo movanterior, esta bxse ejecutará (esta ejecución
secuencial no es específica de ARM, sino lo que sucede en casi todas las arquitecturas). Se
utiliza una instrucción de bifurcación para cambiar esta ejecución secuencial implícita. En
este caso nos bifurcamos a lo que lrdiga el registro. No nos importa ahora lo
que lrcontenga. Es suficiente entender que esta instrucción simplemente abandona
la mainfunción, terminando así nuestro programa de manera efectiva.

¿Y el código de error? Bueno, el resultado de main es el código de error del programa y al

salir de la función dicho resultado debe ser almacenado en el registro r0, por lo que
la movinstrucción que realiza nuestro main es en realidad establecer el código de error en 2.

Eso es todo por hoy

Ensamblador ARM en Raspberry Pi
- Capítulo 2
10 de enero de 2013• Roger Ferrer Ibáñez • Raspberry Pi • brazo , ensamblador , pi , frambuesa

Registros
En esencia, un procesador en una computadora no es más que una poderosa
calculadora. Los cálculos solo se pueden realizar utilizando valores almacenados en
memorias muy pequeñas llamadas registros . El procesador ARM en una Raspberry Pi
tiene 16 registros enteros y 32 registros de punto flotante. Un procesador utiliza estos
registros para realizar cálculos de números enteros y cálculos de coma flotante,
respectivamente. Dejaremos los registros flotantes a un lado por ahora y eventualmente los
volveremos a encontrar en una entrega futura. Centrémonos en los registros de números
enteros.

Esos 16 registros enteros en ARM tienen nombres de r0a r15. Pueden contener 32 bits. Por

supuesto, estos 32 bits pueden codificar lo que quieras. Dicho esto, es conveniente
representar números enteros en complemento a dos, ya que hay instrucciones que realizan
cálculos asumiendo esta codificación. Entonces, a partir de ahora, excepto lo indicado,
asumiremos que nuestros registros contienen valores enteros codificados en complemento a
dos.

No todos los registros desde r0hasta r15se utilizan por igual, pero esto no nos preocupará
por ahora. Simplemente asuma que lo que hacemos está "bien".

Aritmética básica
Casi todos los procesadores pueden realizar algunos cálculos aritméticos básicos utilizando
los registros de números enteros. También lo hacen los procesadores ARM. Puedes ADDdos
registros. Retomemos nuestro ejemplo del primer capítulo.
1/* -- sum01.s */
[Link] main
3
4main:
5 mov r1, #3 /* r1 ← 3 */
6 mov r2, #4 /* r2 ← 4 */
7 add r0, r1, r2 /* r0 ← r1 + r2 */
8 bx lr

Si compilamos y ejecutamos este programa, el código de error es, como se esperaba, 7.

$ ./sum01 ; echo $?
7
Nada nos impide reutilizar r0.
1/* -- sum02.s */
[Link] main
3
4main:
5 mov r0, #3 /* r0 ← 3 */
6 mov r1, #4 /* r1 ← 4 */
7 add r0, r0, r1 /* r0 ← r0 + r1 */
8 bx lr

Que se comporta como se esperaba.

$ ./sum02 ; echo $?
7

Ensamblador ARM en Raspberry Pi

- Capítulo 3
11 de enero de 2013• Roger Ferrer Ibáñez • Raspberry
Pi • brazo , ensamblador , carga , pi , frambuesa , tienda

Vimos en el capítulo 1 y en el capítulo 2 que podemos mover valores a registros

(usando movinstrucción) y agregar dos registros (usando addinstrucción). Si nuestro
procesador solo pudiera trabajar con registros, sería bastante limitado.

Memoria
Una computadora tiene una memoria donde se almacenan el código ( .texten el
ensamblador) y los datos, por lo que debe haber alguna forma de acceder a ellos desde el
procesador. Un poco de digresión aquí, en arquitecturas 386 y x86-64, las instrucciones
pueden acceder a registros o memoria, por lo que podríamos sumar dos números, uno de los
cuales está en la memoria. No puede hacer esto en ARM donde todos los operandos deben
ser registros. Podemos solucionar este problema (no es realmente un problema, sino un
diseño de decisión deliberado que va más allá del alcance de este texto) cargando datos en
un registro desde la memoria y almacenando datos desde un registro en una memoria.

Estas dos operaciones especiales, cargar y almacenar, son instrucciones por sí mismas
llamadas normalmente cargar y almacenar . Hay varias formas de cargar y almacenar datos
desde / hacia la memoria, pero hoy nos centraremos en las más simples: cargar para
registrar ldry almacenar desde el registro str.
Cargar datos desde la memoria es un poco complicado porque necesitamos hablar
de direcciones .

Direcciones
Para acceder a los datos necesitamos darle un nombre. De lo contrario, no podríamos
referirnos a qué datos queremos. Pero, por supuesto, una computadora no tiene un nombre
diferente para cada dato que puede guardar en la memoria. Bueno, de hecho, tiene un
nombre para cada dato. Es la direccion . La dirección es un número, en ARM un número de
32 bits que identifica cada byte (esto es 8 bits) de la memoria.

 La memoria es como una matriz de bytes donde cada byte tiene su
propia dirección.

Al cargar o almacenar datos desde / hacia la memoria, necesitamos calcular una

dirección. Esta dirección se puede calcular de muchas formas. Cada uno de estos modos se
denomina modo de direccionamiento . ARM tiene varios de estos modos de
direccionamiento y nos llevaría un tiempo explicarlos todos aquí, por lo que
consideraremos solo uno: direccionamiento a través de un registro.

No es casualidad que ARM tenga registros enteros de 32 bits y las direcciones de la

memoria sean números de 32 bits. Esto significa que podemos mantener una dirección
dentro de un registro. Una vez que tenemos una dirección dentro de un registro, podemos
usar ese registro para cargar o almacenar algún dato.

Datos
Vimos en el capítulo 1 que el ensamblador contiene tanto código (llamado texto ) como
datos. Estuve deliberadamente suelto al describir las etiquetas del ensamblador. Ahora
podemos revelar su significado profundo: las etiquetas en el ensamblador son solo nombres
simbólicos para direcciones en su programa. Estas direcciones pueden referirse tanto a
datos como a códigos. Hasta ahora hemos utilizado solo una etiqueta mainpara designar la
dirección de nuestra mainfunción. Una etiqueta solo denota una dirección, nunca su
contenido. Tener esto en cuenta.

Dije que el ensamblador es una capa delgada sobre el código binario. Bueno, esa capa
delgada ahora puede parecerle un poco más gruesa ya que la herramienta ensambladora
( as) es responsable de asignar valores a las direcciones de las etiquetas. De esta manera
podemos usar estas etiquetas y el ensamblador hará algo de magia para que funcione.

Entonces, podemos definir datos y adjuntar alguna etiqueta a su dirección. Depende de

nosotros, como programadores ensambladores, asegurarnos de que el almacenamiento al
que hace referencia la etiqueta tenga el tamaño y el valor adecuados.

Definamos una variable de 4 bytes e inicialicemos a 3. Le daremos una etiqueta myvar1.

.balign 4
myvar1:
.word 3
Hay dos nuevas directivas de ensamblador en el ejemplo
anterior: .baligny .word. Cuando asencuentra una .baligndirectiva, asegura que la siguiente
dirección iniciará un límite de 4 bytes. Es decir, la dirección del siguiente dato emitido (es
decir, una instrucción pero también podría ser un dato) será un múltiplo de 4 bytes. Esto es
importante porque ARM impone algunas restricciones sobre las direcciones de los datos
con los que puede trabajar. Esta directiva no hace nada si la dirección ya estaba alineada
con 4. De lo contrario, la herramienta ensambladora emitirá algo de [Link], que no
son utilizados en absoluto por el programa, por lo que se cumple la alineación solicitada. Es
posible que podamos omitir esta directiva si todas las entidades emitidas por el
ensamblador tienen 4 bytes de ancho (4 bytes son 32 bits), pero tan pronto como queramos
usar datos de diferente tamaño, esta directiva se volverá obligatoria.

Ahora definimos la dirección de myvar1. Gracias a la .baligndirectiva anterior , sabemos que

su dirección estará alineada en 4 bytes.

.wordLa directiva establece que la herramienta ensambladora debe emitir el valor del
argumento de la directiva como un entero de 4 bytes. En este caso emitirá 4 bytes que
contienen el valor 3. Tenga en cuenta que nos basamos en el hecho de que .wordemite 4
bytes para definir el tamaño de nuestros datos.

Secciones
Los datos viven en la memoria como el código, pero debido a algunos tecnicismos
prácticos, que ahora no nos importan mucho, generalmente se mantienen juntos en lo que se
llama una sección de datos . .dataLa directiva le dice al ensamblador que emita las entidades
en la sección de datos . Esa .textdirectiva que vimos en el primer capítulo, hace algo similar
para el código. Así que colocaremos los datos después de una .datadirectiva y el código
después de un .text.
Carga
Ok, recuperaremos nuestro ejemplo del Capítulo 2 y lo mejoraremos con algunos accesos a
la memoria. Definiremos dos variables de 4 bytes myvar1y myvar2, inicializadas a 3 y 4
respectivamente. Cargaremos sus valores usando ldr, y realizaremos una suma. El código de
error resultante debería ser 7, como el del capítulo 2.

1/* -- load01.s */
2
3/* -- Data section */
[Link]
5
6/* Ensure variable is 4-byte aligned */
[Link] 4
8/* Define storage for myvar1 */
9myvar1:
10 /* Contents of myvar1 is just 4 bytes containing value '3' */
11 .word 3
12
13/* Ensure variable is 4-byte aligned */
[Link] 4
15/* Define storage for myvar2 */
16myvar2:
17 /* Contents of myvar2 is just 4 bytes containing value '4' */
18 .word 4
19
20/* -- Code section */
[Link]
22
23/* Ensure code is 4 byte aligned */
[Link] 4
[Link] main
26main:
27 ldr r1, addr_of_myvar1 /* r1 ← &myvar1 */
28 ldr r1, [r1] /* r1 ← *r1 */
29 ldr r2, addr_of_myvar2 /* r2 ← &myvar2 */
30 ldr r2, [r2] /* r2 ← *r2 */
31 add r0, r1, r2 /* r0 ← r1 + r2 */
32 bx lr
33
34/* Labels needed to access data */
35addr_of_myvar1 : .word myvar1
36addr_of_myvar2 : .word myvar2
He hecho un poco de trampa en el ejemplo anterior debido a limitaciones en el
ensamblador. Como puede ver, hay cuatro ldrinstrucciones. Intentaré explicar su
significado. Primero, sin embargo, tenemos que discutir las siguientes dos etiquetas.

34/* Labels needed to access data */

35addr_of_myvar1 : .word myvar1
36addr_of_myvar2 : .word myvar2

Bueno, estas dos etiquetas contienen la dirección de myvar1y myvar2. Quizás se pregunte por

qué los necesitamos si ya tenemos la dirección de nuestros datos en las
etiquetas myvar1y myvar2. Bueno una explicación detallada es un poco larga, pero lo que
pasa aquí es que myvar1y myvar2están en una sección diferente: en la .datasección. Esa
sección existe para que el programa pueda modificarla, por eso las variables se guardan
allí. Por otro lado, el programa no suele modificar el código (por razones de eficiencia y
seguridad). Así que esta es una razón para tener dos secciones diferentes con diferentes
propiedades adjuntas. Pero no podemos acceder directamente a un símbolo de una sección a
otra. Por lo tanto, necesitamos una etiqueta especial en la .codeque se haga referencia a la
dirección de una entidad en la .datasección.

Bueno, cuando el ensamblador emita el código binario, .word myvar1no será la dirección

de myvar1sino que será una reubicación . Una reubicación es la forma en que el
ensamblador utiliza para emitir una dirección, cuyo valor exacto se desconoce, pero se
sabrá cuando el programa esté vinculado (es decir, cuando se genere el ejecutable final). Es
como decir , bueno, no tengo idea de dónde estará realmente esta variable, dejemos que el
enlazador parchee este valor más tarde . Entonces esto addr_of_myvar1se usará en su
lugar. La dirección de addr_of_myvar1está en la misma sección .text. Ese valor
será parcheadopor el enlazador durante la fase de enlace (cuando se crea el ejecutable final
y sabe dónde definitivamente se colocarán en memoria todas las entidades de nuestro
programa). Es por eso que se llama al enlazador (invocado internamente
por gcc) ld. Significa Link eDitor.

27 ldr r1, addr_of_myvar1 /* r1 ← &myvar1 */

28 ldr r1, [r1] /* r1 ← *r1 */

Ok, entonces dos cargas. El primero de la línea 27 carga realmente el valor de reubicación
de la dirección de myvar1. Es decir, hay algunos datos en la memoria, cuya dirección
es addr_of_myvar1, con un tamaño de 4 bytes que contiene la dirección real
de myvar1. Entonces, después del primero ldr, r1tenemos la dirección real de myvar1. Pero no
queremos la dirección en absoluto, sino el contenido de la memoria en esa dirección, así
que hacemos un segundo ldr.
  Suponiendo el contenido de memoria dado,
esto es lo que sucede con los registros después de que se ejecuta una instrucción de carga.

Probablemente se esté preguntando por qué las dos cargas tienen una sintaxis diferente. El
primero ldrusa la dirección simbólica de addr_of_myvar1etiqueta. El segundo ldrutiliza el
valor del registro como modo de direccionamiento . Entonces, en el segundo caso, estamos
usando el valor dentro r1como la dirección. En el primer caso, no sabemos realmente qué
usa el ensamblador como modo de direccionamiento, por lo que lo ignoraremos por ahora.

El programa carga dos valores de 32 bits desde myvar1y myvar2, que tenían los valores
iniciales 3 y 4, los suma y establece el resultado de la suma como el código de error del
programa en el r0registro justo antes de salir main.
$ ./load01 ; echo $?
7

Tienda
Ahora tome el ejemplo anterior, pero en lugar de establecer los valores iniciales
de myvar1y myvar2en 3 y 4 respectivamente, establezca ambos en 0. Reutilizaremos el
código existente pero antepondremos algún ensamblador para almacenar un 3 y un 4 en las
variables.

1/* -- store01.s */
2
3/* -- Data section */
[Link]
5
6/* Ensure variable is 4-byte aligned */
[Link] 4
8/* Define storage for myvar1 */
9myvar1:
 10 /* Contents of myvar1 is just '3' */
11 .word 0
12
13/* Ensure variable is 4-byte aligned */
[Link] 4
15/* Define storage for myvar2 */
16myvar2:
17 /* Contents of myvar2 is just '3' */
18 .word 0
19
20/* -- Code section */
[Link]
22
23/* Ensure function section starts 4 byte aligned */
[Link] 4
[Link] main
26main:
27 ldr r1, addr_of_myvar1 /* r1 ← &myvar1 */
28 mov r3, #3 /* r3 ← 3 */
29 str r3, [r1] /* *r1 ← r3 */
30 ldr r2, addr_of_myvar2 /* r2 ← &myvar2 */
31 mov r3, #4 /* r3 ← 4 */
32 str r3, [r2] /* *r2 ← r3 */
33
34 /* Same instructions as above */
35 ldr r1, addr_of_myvar1 /* r1 ← &myvar1 */
36 ldr r1, [r1] /* r1 ← *r1 */
37 ldr r2, addr_of_myvar2 /* r2 ← &myvar2 */
38 ldr r2, [r2] /* r2 ← *r2 */
39 add r0, r1, r2
40 bx lr
41
42/* Labels needed to access data */
43addr_of_myvar1 : .word myvar1
44addr_of_myvar2 : .word myvar2

Tenga en cuenta una rareza en la strinstrucción, el operando de destino de la

instrucción no es el primer operando . En cambio, el primer operando es el registro fuente
y el segundo operando es el modo de direccionamiento.
$ ./store01; echo $?
7
Ensamblador ARM en Raspberry Pi
- Capítulo 4
12 de enero de 2013• Roger Ferrer Ibáñez • Raspberry
Pi • brazo , ensamblador , depurador , gdb , pi , frambuesa

A medida que avancemos en el aprendizaje de los fundamentos del ensamblador ARM,

nuestros ejemplos se harán más largos. Dado que es fácil cometer errores, creo que vale la
pena aprender a usar GNU Debugger gdbpara depurar ensamblador. Si desarrollas C / C ++
en Linux y nunca lo usaste gdb, la culpa es tuya. Si conoce gdbeste pequeño capítulo, le
explicará cómo depurar ensamblador directamente.

gdb
Usaremos el ejemplo store01del capítulo 3. Comience gdbespecificando el programa que va a
depurar.
$ gdb --args ./store01
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
...
Reading symbols from /home/roger/asm/chapter03/store01...(no debugging symbols found)...done.
(gdb)
Ok, estamos en el modo interactivo de gdb. En este modo te comunicas gdbusando
comandos. Hay un comando de ayuda incorporado llamado help. O puede consultar
la documentación del depurador GNU . Un primer comando para aprender es
(gdb) quit
Ok, ahora empieza de gdbnuevo. El programa aún no se está ejecutando. De hecho gdbno
podrá contarte muchas cosas al respecto ya que no tiene información de depuración. Pero
esto está bien, estamos depurando ensamblador, por lo que no necesitamos mucha
información de depuración. Entonces, como primer paso, comencemos el programa.
(gdb) start
Temporary breakpoint 1 at 0x8390
Starting program: /home/roger/asm/chapter03/store01

Temporary breakpoint 1, 0x00008390 in main ()

Ok, gdbejecuté nuestro programa hasta main. Esto es genial, nos hemos saltado todos los
pasos de inicialización de la biblioteca C y estamos a punto de ejecutar la primera
instrucción de nuestra mainfunción. Veamos qué hay ahí.
(gdb) disassemble
Dump of assembler code for function main:
=> 0x00008390 : ldr r1, [pc, #40] ; 0x83c0
0x00008394 : mov r3, #3
0x00008398 : str r3, [r1]
0x0000839c : ldr r2, [pc, #32] ; 0x83c4
0x000083a0 : mov r3, #4
0x000083a4 : str r3, [r2]
0x000083a8 : ldr r1, [pc, #16] ; 0x83c0
0x000083ac : ldr r1, [r1]
0x000083b0 : ldr r2, [pc, #12] ; 0x83c4
0x000083b4 : ldr r2, [r2]
0x000083b8 : add r0, r1, r2
0x000083bc : bx lr
End of assembler dump.
¡UH oh! Las instrucciones que hacen referencia a la etiqueta addr_of_myvarXson
diferentes. Está bien. Ignore eso por ahora, aprenderemos en un capítulo futuro lo que ha
sucedido. Hay una flecha que =>señala la instrucción que vamos a ejecutar (aún no se ha
ejecutado). Antes de ejecutarlo, inspeccionemos algunos registros.
(gdb) info registers r0 r1 r2 r3
r0 0x1 1
r1 0xbefff744 3204446020
r2 0xbefff74c 3204446028
r3 0x8390 33680
Podemos modificar los registros usando pqué medios printpero también evaluamos los
efectos secundarios. Por ejemplo,
(gdb) p $r0 = 2
$1 = 2
(gdb) info registers r0 r1 r2 r3
r0 0x2 2
r1 0xbefff744 3204446020
r2 0xbefff74c 3204446028
r3 0x8390 33680
gdbha impreso $1, este es el identificador
del resultado y podemos usarlo cuando sea
necesario, por lo que podemos omitir algo de escritura. No es muy útil ahora pero lo será
cuando imprimamos una expresión complicada.
(gdb) p $1
$2 = 2
Ahora podríamos usar $2, y así sucesivamente. Ok, es hora de ejecutar la primera
instrucción.
(gdb) stepi
0x00008394 in main ()
Bueno, no pasó mucho, usemos disassemble, de nuevo.
(gdb) disassemble
Dump of assembler code for function main:
0x00008390 : ldr r1, [pc, #40] ; 0x83c0
=> 0x00008394 : mov r3, #3
0x00008398 : str r3, [r1]
0x0000839c : ldr r2, [pc, #32] ; 0x83c4
 0x000083a0 : mov r3, #4
0x000083a4 : str r3, [r2]
0x000083a8 : ldr r1, [pc, #16] ; 0x83c0
0x000083ac : ldr r1, [r1]
0x000083b0 : ldr r2, [pc, #12] ; 0x83c4
0x000083b4 : ldr r2, [r2]
0x000083b8 : add r0, r1, r2
0x000083bc : bx lr
End of assembler dump.
Ok, veamos qué pasó en r1.
(gdb) info register r1
r1 0x10564 66916
Genial, ha cambiado. De hecho, esta es la dirección de myvar1. Comprobemos esto usando
su nombre simbólico y sintaxis C.
(gdb) p &myvar1
$3 = ( *) 0x10564
¡Excelente! ¿Podemos ver qué hay en esta variable?
(gdb) p myvar1
$4 = 0
Perfecto. Esto fue lo esperado ya que en este ejemplo establecemos cero como el valor
inicial de myvar1y myvar2. Ok, paso siguiente.
(gdb) stepi
0x00008398 in main ()
(gdb) disas
Dump of assembler code for function main:
0x00008390 : ldr r1, [pc, #40] ; 0x83c0
0x00008394 : mov r3, #3
=> 0x00008398 : str r3, [r1]
0x0000839c : ldr r2, [pc, #32] ; 0x83c4
0x000083a0 : mov r3, #4
0x000083a4 : str r3, [r2]
0x000083a8 : ldr r1, [pc, #16] ; 0x83c0
0x000083ac : ldr r1, [r1]
0x000083b0 : ldr r2, [pc, #12] ; 0x83c4
0x000083b4 : ldr r2, [r2]
0x000083b8 : add r0, r1, r2
0x000083bc : bx lr
End of assembler dump.
Puede usar disas(¡pero no disa!) Como abreviatura de disassemble. Veamos qué pasó conr3
(gdb) info registers r3
r3 0x3 3
Hasta aquí todo bien. Otro paso más.
(gdb) stepi
0x0000839c in main ()
(gdb) disas
Dump of assembler code for function main:
0x00008390 : ldr r1, [pc, #40] ; 0x83c0
0x00008394 : mov r3, #3
 0x00008398 : str r3, [r1]
=> 0x0000839c : ldr r2, [pc, #32] ; 0x83c4
0x000083a0 : mov r3, #4
0x000083a4 : str r3, [r2]
0x000083a8 : ldr r1, [pc, #16] ; 0x83c0
0x000083ac : ldr r1, [r1]
0x000083b0 : ldr r2, [pc, #12] ; 0x83c4
0x000083b4 : ldr r2, [r2]
0x000083b8 : add r0, r1, r2
0x000083bc : bx lr
End of assembler dump.
Ok, veamos qué sucedió, almacenamos r3, que contenía un 3 en myvar1,
¿verdad? Revisemos esto.
(gdb) p myvar1
$5 = 3
Increíble, ¿no es así? Está bien. Ahora corre hasta el final.
(gdb) continue
Continuing.
[Inferior 1 (process 3080) exited with code 07]

Ensamblador ARM en Raspberry Pi

- Capítulo 5
19 de enero de 2013• Roger Ferrer Ibáñez • Raspberry Pi • brazo , ensamblador , ramas , pi , frambuesa

Derivación
Hasta ahora, nuestros pequeños programas ensambladores ejecutan una instrucción tras
otra. Si nuestro procesador ARM solo pudiera funcionar de esta manera, sería de uso
limitado. No pudo reaccionar a las condiciones existentes que pueden requerir diferentes
secuencias de instrucciones. Este es el propósito de las instrucciones de bifurcación .

Un registro especial
En el capítulo 2 aprendimos que nuestro procesador ARM Raspberry Pi tiene 16 registros
enteros de propósito general y también dijimos que algunos de ellos juegan roles especiales
en nuestro programa. Ignoré deliberadamente qué registros eran especiales, ya que no eran
relevantes en ese momento.

Pero ahora es relevante, al menos para el registro r15. Este registro es muy especial, tan
especial que también tiene otro nombre: pc. Es poco probable que lo veas usado r15ya que
es confuso (aunque correcto desde el punto de vista de la arquitectura ARM). A partir de
ahora solo usaremos pcpara nombrarlo.
¿Qué significa pc? pcsignifica contador de programa . Este nombre, cuyos orígenes se
encuentran en los albores de la informática, significa poco o nada hoy en día. En general,
el pcregistro (también llamado ip, puntero de instrucción , en otras arquitecturas como 386 o
x86_64) contiene la dirección de la siguiente instrucción que va a ser ejecutado.

Cuando el procesador ARM ejecuta una instrucción, pueden suceder dos cosas al final de
su ejecución. Si la instrucción no se modifica pc(y la mayoría de las instrucciones no lo
hacen), pcsimplemente se incrementa en 4 (como si lo hiciéramos add pc, pc, #4). ¿Por qué
4? Porque en ARM, las instrucciones tienen un ancho de 32 bits, por lo que hay 4 bytes
entre cada instrucción. Si la instrucción modifica pc, pcse utiliza el nuevo valor de .

Una vez que el procesador ha ejecutado completamente una instrucción, entonces usa el
valor en pccomo la dirección para que se ejecute la siguiente instrucción. De esta forma,
una instrucción que no modifique el pcserá seguida por la siguiente instrucción contigua en
memoria (ya que se ha incrementado automáticamente en 4). Esto se
denomina secuenciación implícita de instrucciones: después de que una se ha ejecutado,
normalmente se ejecuta la siguiente en la memoria. Pero si una instrucción modifica pc, por
ejemplo, a un valor distinto de pc + 4, entonces podemos estar ejecutando otra instrucción
del programa. Este proceso de cambiar el valor de pcse llama ramificación . En ARM, esto
se hace usando instrucciones de bifurcación .

Ramas incondicionales
Puede decirle al procesador que se bifurque incondicionalmente utilizando la
instrucción b(para la bifurcación ) y una etiqueta. Considere el siguiente programa.

1/* -- branch01.s */
[Link]
[Link] main
4main:
5 mov r0, #2 /* r0 ← 2 */
6 b end /* branch to 'end' */
7 mov r0, #3 /* r0 ← 3 */
8end:
9 bx lr

Si ejecuta este programa, verá que devuelve un código de error de 2.

$ ./branch01 ; echo $?
2
Lo que sucedió es que la instrucción se b end bifurcó (modificando pc) a la instrucción en la
etiqueta end, es decir bx lr, la instrucción que ejecutamos al final de nuestro programa. De
esta manera, la instrucción mov r0, #3no se ha ejecutado en absoluto (el procesador nunca
llegó a esa instrucción).
En este punto, la instrucción de bifurcación incondicional bpuede parecer un poco inútil. No
es el caso. De hecho, esta instrucción es esencial en algunos contextos, en particular cuando
se vincula con la ramificación condicional. Pero antes de que podamos hablar de
ramificación condicional, debemos hablar de condiciones.

Ramas condicionales
Si nuestro procesador solo pudiera bifurcarse porque sí, no sería muy útil. Es mucho más
útil bifurcar cuando se cumple alguna condición . Entonces, un procesador debería poder
evaluar algún tipo de condiciones.

Antes de continuar, necesitamos revelar otro registro llamado cpsr(para Registro de estado

del programa actual). Este registro es un poco especial y modificarlo directamente está
fuera del alcance de este capítulo. Dicho esto, mantiene algunos valores que se pueden leer
y actualizar al ejecutar una instrucción. Los valores de dicho registro incluyen
cuatro banderas de código de condición de llamadas N( n egative), Z( z ERO), C( c Arry)
y V(o v erflow). Estos cuatro indicadores de código de condición suelen leerse mediante
instrucciones de bifurcación. Las instrucciones aritméticas y las instrucciones especiales de
prueba y comparación también pueden actualizar estos códigos de condición si se solicita.

La semántica de estos cuatro códigos de condición en las instrucciones que actualizan

el cpsres aproximadamente la siguiente

 Nse habilitará si el resultado de la instrucción arroja un número

negativo. Deshabilitado de lo contrario.
 Zse habilitará si el resultado de la instrucción arroja un valor cero. Desactivado si es
distinto de cero.
 Cse habilitará si el resultado de la instrucción arroja un valor que requiere un bit 33
para estar completamente representado. Por ejemplo, una adición que desborda el
rango de enteros de 32 bits. Hay un caso especial para C y las restas donde una
resta sin préstamo lo habilita, deshabilitado de lo contrario: restar un número mayor a
uno menor habilita C, pero se deshabilitará si la resta se hace al revés.
 V se habilitará si el resultado de la instrucción arroja un valor que no se puede
representar en complemento a dos de 32 bits.

Así que tenemos todas las piezas necesarias para realizar ramificaciones de forma
condicional. Pero primero, comencemos a comparar dos valores. Usamos la
instrucción cmppara este propósito.
cmp r1, r2 /* updates cpsr doing "r1 - r2", but r1 and r2 are not modified */
Esta instrucción resta al valor del primer registro el valor del segundo registro. ¿Ejemplos
de lo que podría suceder en el fragmento anterior?

 Si r2tuviera un valor (estrictamente) mayor que r1entonces Nestaría habilitado

porque r1-r2daría un resultado negativo.
 Si r1y r2tuviera el mismo valor, entonces Zestaría habilitado porque r1-r2sería cero.
  Si r1fuera 1 y r2fuera 0 entonces r1-r2no pediría prestado, por lo que en este
caso Cestaría habilitado. Si los valores se intercambiaran ( r1era 0 y r2era 1), C se
deshabilitaría porque la resta toma prestada.
 Si r1fuera 2147483647 (el entero positivo más grande en el complemento a dos de 32
bits) y r2fuera -1, entonces r1-r2sería 2147483648 pero dicho número no se puede
representar en el complemento a dos de 32 bits, por Vlo que estaría habilitado para
señalar esto.

¿Cómo podemos usar estas banderas para representar condiciones útiles para nuestros
programas?

 EQ( eq ual) Cuando Z está habilitado (Z es 1)

 NE( N ot e Qual). Cuando Z está desactivado. (Z es 0)
 GE( G reater o e qual que, en complemento de dos). Cuando tanto V como N están
habilitados o deshabilitados (V es N)
 LT( L ower t han, en complemento de dos). Esto es lo opuesto a GE, por lo que
cuando V y N no están habilitados o deshabilitados (V no es N)
 GT( G reather t han, en complemento a dos). Cuando Z está deshabilitado y N y V
están habilitados o deshabilitados (Z es 0, N es V)
 LE( L ower o e qual que, en complemento de dos). Cuando Z está habilitado o si no, N
y V están habilitados o deshabilitados (Z es 1. Si Z no es 1, N es V)
 MI( mi nus / negativo) Cuando N está habilitado (N es 1)
 PL( pl us / positivo o cero) Cuando N está deshabilitado (N es 0)
 VS(o v erflow s et) Cuando V está activado (V es 1)
 VC(o v erflow c Lear) Cuando V está desactivado (V es 0)
 HI( Hi gher) Cuando C está habilitado y Z está desactivado (C es 1 y Z es 0)
 LS( L ower o s AME) Cuando C está deshabilitado o Z está activado (C es 0 o Z es 1)
 CS/ HS( C arry s et / h igher o s AME) Cuando C está activado (C es 1)
 CC/ LO( C arry c Lear / Mín wer) cuando c es desactivado (C es 0)

Estas condiciones se pueden combinar con nuestras binstrucciones para generar nuevas

instrucciones. De esta forma, beqse bifurcará solo si Zes 1. Si no se cumple la condición de
una bifurcación condicional, la bifurcación se ignorará y se ejecutará la siguiente
instrucción. Es tarea del programador asegurarse de que los códigos de condición estén
configurados correctamente antes de una bifurcación condicional.

1/* -- compare01.s */
[Link]
[Link] main
4main:
5 mov r1, #2 /* r1 ← 2 */
6 mov r2, #2 /* r2 ← 2 */
7 cmp r1, r2 /* update cpsr condition codes with the value of r1-r2 */
8 beq case_equal /* branch to case_equal only if Z = 1 */
9case_different :
10 mov r0, #2 /* r0 ← 2 */
11 b end /* branch to end */
12case_equal:
 13 mov r0, #1 /* r0 ← 1 */
14end:
15 bx lr

Si ejecuta este programa, devolverá un código de error de 1 porque ambos r1y r2tienen el

mismo valor. Ahora cambie mov r1, #2en la línea 5 para que sea mov r1, #3y el código de error
devuelto debería ser 2. Tenga en cuenta que case_differentno queremos ejecutar
las case_equalinstrucciones, por lo que tenemos que bifurcar end(de lo contrario, el código de
error siempre sería 1).

Ensamblador ARM en Raspberry Pi

- Capítulo 6
20 de enero de 2013• Roger Ferrer Ibáñez • Raspberry Pi • brazo , ensamblador , estructuras de
control , pi , frambuesa

Estructuras de Control
En el capítulo anterior aprendimos instrucciones de bifurcación. Son herramientas
realmente poderosas porque nos permiten expresar estructuras de control. La programación
estructurada es un hito importante en la mejora de la ingeniería informática (fundamental,
pero no obstante importante). Por lo tanto, ser capaz de mapear construcciones de
programación estructuradas habituales en ensamblador, en nuestro procesador, es algo
bueno ™.

Si, entonces, si no
Bueno, este es básico, y de hecho ya usamos esta estructura en el capítulo
anterior. Considere la siguiente estructura, donde Ees una expresión S1y S2son
declaraciones (pueden ser declaraciones compuestas como { SA; SB; SC; })
if (E) then
S1
else
S2
Una posible forma de expresar esto en el ensamblador ARM podría ser la siguiente
if_eval:
/* Assembler that evaluates E and updates the cpsr accordingly */
bXX else /* Here XX is the appropiate condition */
then_part:
/* assembler for S1, the "then" part */
b end_of_if
else:
 /* assembler for S2, the "else" part */
end_of_if:
Si no hay otra parte, podemos reemplazarla bXX elsecon bXX end_of_if.

Bucles
Este es otro habitual en la programación estructurada. Si bien hay varios tipos de bucles, en
realidad todos se reducen a la siguiente estructura.
while (E)
S
Supuestamente Shace que algo Efinalmente se vuelva falso y se deje el bucle. De lo
contrario, nos mantendríamos informados para siempre (a veces esto es lo que quieres, pero
no en nuestros ejemplos). Una forma de implementar estos bucles es la siguiente.
while_condition : /* assembler to evaluate E and update cpsr */
bXX end_of_loop /* If E is false, then leave the loop right now */
/* assembler of S */
b while_condition /* Unconditional branch to the beginning */
end_of_loop:
Un ciclo común implica iterar desde un solo rango de enteros, como en
for (i = L; i < N; i += K)
S
Pero esto no es más que
i = L;
while (i < N)
{
S;
i += K;
}
Por lo tanto, no tenemos que aprender una nueva forma de implementar el bucle en sí.

1 + 2 + 3 + 4 + ... + 22
Como primer ejemplo, sumemos todos los números del 1 al 22 (te diré más adelante por
qué elegí 22). El resultado de la suma es 253(compruébalo con una calculadora ). Sé que
tiene poco sentido calcular algo cuyo resultado ya conocemos, pero esto es solo un ejemplo.

1/* -- loop01.s */
[Link]
[Link] main
4main:
5 mov r1, #0 /* r1 ← 0 */
6 mov r2, #1 /* r2 ← 1 */
7loop:
8 cmp r2, #22 /* compare r2 and 22 */
 9 bgt end /* branch if r2 > 22 to end */
10 add r1, r1, r2 /* r1 ← r1 + r2 */
11 add r2, r2, #1 /* r2 ← r2 + 1 */
12 b loop
13end:
14 mov r0, r1 /* r0 ← r1 */
15 bx lr

Aquí estamos contando del 1 al 22. Usaremos el registro r2como contador. Como puede ver
en la línea 6 lo inicializamos a 1. La suma se acumulará en el registro r1, al final del
programa movemos el contenido de r1en r0para devolver el resultado de la suma como el
código de error del programa (nosotros Podría haber usado r0en todo el código y evitar este
final movpero creo que es más claro así).

En la línea 8 comparamos r2(recuerde, el contador que irá de 1 a 22) a 22. Esto actualizará

y, por lo cpsrtanto, en la línea 9 podemos verificar si la comparación fue tal que r2 fue
mayor que 22. Si este es el caso, terminamos el ciclo ramificándonos en end. De lo
contrario, sumamos el valor actual de r2al valor actual de r1(recuerde, en r1acumulamos la
suma de 1 a 22).

La línea 11 es importante. Aumentamos el valor de r2, porque estamos contando de 1 a 22 y

ya agregamos el valor actual del contador r2al resultado de la suma en r1. Luego, en la línea
12, volvemos a ramificarnos al comienzo del ciclo. Tenga en cuenta que si la línea 11 no
estuviera allí, colgaríamos ya que la comparación en la línea 8 siempre sería falsa y nunca
dejaríamos el bucle en la línea 9.
$ ./loop01; echo $?
253
Bueno, ahora puedes cambiar la línea 8 e intentar, digamos, # 100. El resultado debería ser
5050.
$ ./loop01; echo $?
186
¿Qué sucedió? Bueno, sucede que en Linux el código de error de un programa es un
número del 0 al 255 (8 bits). Si el resultado es 5050, solo se utilizan los 8 bits inferiores del
número. 5050 en binario es 1001110111010, sus 8 bits inferiores son 10111010exactamente
186. ¿Cómo podemos comprobar que el calculado r1es 5050 antes de finalizar el
programa? Usemos GDB.
$ gdb loop
...
(gdb) start
Temporary breakpoint 1 at 0x8390
Starting program: /home/roger/asm/chapter06/loop01

Temporary breakpoint 1, 0x00008390 in main ()

(gdb) disas main,+(9*4)
Dump of assembler code from 0x8390 to 0x83b4:
0x00008390 <main+0>: mov r1, #0
 0x00008394 <main+4>: mov r2, #1
0x00008398 <loop+0>: cmp r2, #100 ; 0x64
0x0000839c <loop+4>: bgt 0x83ac <end>
0x000083a0 <loop+8>: add r1, r1, r2
0x000083a4 <loop+12>: add r2, r2, #1
0x000083a8 <loop+16>: b 0x8398 <loop>
0x000083ac <end+0>: mov r0, r1
0x000083b0 <end+4>: bx lr
End of assembler dump.
Digamos a gdb que se detenga en 0x000083ac, justo antes de ejecutar mov r0, r1.
(gdb) break *0x000083ac
(gdb) cont
Continuing.

Breakpoint 2, 0x000083ac in end ()

(gdb) disas
Dump of assembler code for function end:
=> 0x000083ac <+0>: mov r0, r1
0x000083b0 <+4>: bx lr
End of assembler dump.
(gdb) info register r1
r1 0x13ba 5050
Genial, esto es lo que esperábamos pero no pudimos ver debido a los límites en el código
de error.

Tal vez haya notado que sucede algo extraño con nuestras etiquetas identificadas como
funciones. Abordaremos este problema en un capítulo futuro, aunque en su mayoría es
inofensivo.

3n + 1
Hagamos otro ejemplo un poco más complicado. Este es el famoso problema 3n +
1 también conocido como la conjetura de Collatz . Dado un número nlo dividiremos por 2 si
es par y lo multiplicaremos por 3 y sumaremos uno si es impar.
if (n % 2 == 0)
n = n / 2;
else
n = 3*n + 1;
Antes de continuar, nuestro procesador ARM es capaz de multiplicar dos números pero
deberíamos aprender una nueva instrucción mulque nos desviaría un poco. En su lugar,
usaremos la siguiente identidad 3 * n = 2*n + n. Realmente no sabemos cómo multiplicar o
dividir por dos todavía, estudiaremos esto en un capítulo futuro, así que por ahora solo
asuma que funciona como se muestra en el ensamblador a continuación.

La conjetura de Collatz establece que, para cualquier número n, la aplicación repetida de

este procedimiento eventualmente nos dará el número 1. Teóricamente podría suceder que
este no sea el caso. Hasta el momento, no se ha encontrado tal número, pero no se ha
demostrado lo contrario. Si queremos aplicar repetidamente el procedimiento anterior,
nuestro programa está haciendo algo como esto.
n = ...;
while (n != 1)
{
if (n % 2 == 0)
n = n / 2;
else
n = 3*n + 1;
}
Si la conjetura de Collatz fuera falsa, existirían algunos npara los que el código anterior se
colgaría, sin llegar nunca a 1. Pero como dije, no se ha encontrado tal número.

1/* -- collatz.s */
[Link]
[Link] main
4main:
5 mov r1, #123 /* r1 ← 123 */
6 mov r2, #0 /* r2 ← 0 */
7loop:
8 cmp r1, #1 /* compare r1 and 1 */
9 beq end /* branch to end if r1 == 1 */
10
11 and r3, r1, #1 /* r3 ← r1 & 1 */
12 cmp r3, #0 /* compare r3 and 0 */
13 bne odd /* branch to odd if r3 != 0 */
14even:
15 mov r1, r1, ASR #1 /* r1 ← (r1 >> 1) */
16 b end_loop
17odd:
18 add r1, r1, r1, LSL #1 /* r1 ← r1 + (r1 << 1) */
19 add r1, r1, #1 /* r1 ← r1 + 1 */
20
21end_loop:
22 add r2, r2, #1 /* r2 ← r2 + 1 */
23 b loop /* branch to loop */
24
25end:
26 mov r0, r2
27 bx lr

En r1guardaremos el número n. En este caso usaremos el número 123. 123 llega a 1 en 46

pasos: [123, 370, 185, 556, 278, 139, 418, 209, 628, 314, 157, 472, 236, 118, 59, 178, 89,
268, 134, 67, 202, 101, 304, 152, 76, 38, 19, 58, 29, 88, 44, 22, 11, 34, 17, 52, 26, 13, 40,
20, 10, 5, 16, 8, 4, 2, 1]. Contaremos el número de pasos en el registro r2. Así que
inicializamos r1con 123 y r2con 0 (todavía no se ha realizado ningún paso).
Al comienzo del ciclo, en las líneas 8 y 9, comprobamos si r1es 1. Entonces lo comparamos
con 1 y si es igual dejamos el ciclo ramificándose a end.

Ahora sabemos que r1no es 1, por lo que procedemos a comprobar si es par o impar. Para

hacer esto usamos una nueva instrucción andque realiza una operación bit a bit . Un número
par tendrá el bit menos significativo (LSB) a 0, mientras que un número impar tendrá el
LSB a 1. Por lo tanto, un bit a bit y el uso de 1 devolverán 0 o 1 en números pares o
impares, respectivamente. En la línea 11 mantenemos el resultado del bit a bit y
en r3registro y luego, en la línea 12, lo comparamos con 0. Si no es cero, entonces nos
bifurcamos a odd, de lo contrario continuamos con el evencaso.

Ahora ocurre algo de magia en la línea 15. Esta es una operación combinada que ARM nos
permite hacer. Esto es un, movpero no movemos el valor de r1directamente a r1(lo que no
haría nada), pero primero hacemos un desplazamiento aritmético a la derecha (ASR) al
valor de r1(al valor, no al registro en sí). Luego, este valor desplazado se traslada al
registro r1. Un desplazamiento aritmético a la derecha desplaza todos los bits de un registro
a la derecha: el bit más a la derecha se descarta efectivamente y el más a la izquierda se
establece en el mismo valor que el bit más a la izquierda antes del desplazamiento. Cambiar
un bit a la derecha a un número es lo mismo que dividir ese número por 2. Así que esto mov
r1, r1, ASR #1es lo que realmente sucede r1 ← r1 / 2.

Algo similar ocurre con el caso par en la línea 18. En este caso estamos haciendo un add. El
primer y segundo operandos deben ser registros (operando de destino y el primer operando
de origen). El tercero se combina con un desplazamiento lógico a la izquierda (LSL). El
valor del operando se desplaza 1 bit hacia la izquierda: el bit más a la izquierda se descarta
y el bit más a la derecha se establece en 0. Esto es efectivamente multiplicar el valor por 2.
Entonces estamos sumando r1(que mantiene el valor de n) a 2*r1. Esto
es 3*r1así 3*n. Mantenemos este valor r1nuevamente. En la línea 19 sumamos 1 a ese valor,
por lo que r1termina teniendo el valor 3*n+1que queríamos.

No te preocupes mucho ahora por estos LSL y ASR. Solo déjalos por sentado ahora. En un
capítulo futuro los veremos con más detalle.

Finalmente, al final del ciclo, en la línea 22 actualizamos r2(recuerde que mantiene el

contador de nuestros pasos) y luego nos bifurcamos de nuevo al principio del ciclo. Antes
de finalizar el programa movemos el contador a r0por lo que devolvemos el número de
pasos que hicimos para llegar a 1.
$ ./collatz; echo $?
46
Excelente.

Eso es todo por hoy.

Posdata
Kevin Millikin señaló correctamente (en un comentario a continuación) que, por lo general,
un bucle no se implementa de la forma que se muestra arriba. De hecho, Kevin dice que
una mejor manera de hacer el bucle [Link] la siguiente.

1/* -- loop02.s */
[Link]
[Link] main
4main:
5 mov r1, #0 /* r1 ← 0 */
6 mov r2, #1 /* r2 ← 1 */
7 b check_loop /* unconditionally jump at the end of the loop */
8loop:
9 add r1, r1, r2 /* r1 ← r1 + r2 */
10 add r2, r2, #1 /* r2 ← r2 + 1 */
11check_loop:
12 cmp r2, #22 /* compare r2 and 22 */
13 ble loop /* branch if r2 <= 22 to the beginning of the loop */
14end:
15 mov r0, r1 /* r0 ← r1 */
16 bx lr

Si cuenta el número de instrucciones en los dos códigos, hay 9 instrucciones en

ambos. Pero si observa detenidamente la propuesta de Kevin, verá que al ramificar
incondicionalmente hasta el final del ciclo e invertir la verificación de la condición,
podemos saltarnos una ramificación, reduciendo así el número de instrucciones del ciclo en
sí de 5 a 4.

Sin embargo, hay otra ventaja en esta segunda versión: solo hay una rama en el bucle
mismo, ya que recurrimos a la secuenciación implícita para alcanzar nuevamente las dos
instrucciones que realizan la verificación. Por razones más allá del alcance de esta
publicación, la ejecución de una instrucción de rama puede afectar negativamente el
desempeño de nuestros programas. Los procesadores tienen mecanismos para mitigar la
pérdida de rendimiento debido a las ramas (y de hecho, el procesador en la Raspberry Pi los
tiene). Pero evitar una instrucción de bifurcación evita por completo la posible penalización
del rendimiento de ejecutar una instrucción de bifurcación.

Si bien ahora no nos importa mucho el rendimiento de nuestro ensamblador. Sin embargo,

pensé que valía la pena desarrollar un poco más el comentario de Kevin.

Ensamblador ARM en Raspberry Pi

- Capítulo 7
26 de enero de 2013• Roger Ferrer Ibáñez • Raspberry Pi • brazo , ensamblador , modos de
indexación , pi , frambuesa

La arquitectura ARM ha estado dirigida durante mucho tiempo a los sistemas

integrados. Los sistemas empotrados suelen acabar utilizándose en productos de fabricación
masiva (lavavajillas, teléfonos móviles, televisores, etc.). En este contexto, los márgenes
son muy ajustados, por lo que un diseñador siempre intentará ahorrar tantos componentes
como sea posible (un centavo ahorrado en cientos de miles o incluso millones de
dispositivos puede dar sus frutos). Un componente relativamente caro es la memoria,
aunque cada día la memoria es cada vez menos cara. De todos modos, en entornos de
memoria restringida, poder ahorrar memoria es bueno y el conjunto de instrucciones ARM
se diseñó con este objetivo en mente. Nos llevará varios capítulos aprender todas estas
técnicas, hoy comenzaremos con una característica que generalmente se llama operando
desplazado .

Modos de indexación
Hemos visto que, a excepción de load ( ldr), store ( str) y branch ( by bXX), las instrucciones
ARM toman como operandos registros o valores inmediatos. También hemos visto que el
primer operando suele ser el registro de destino (siendo struna excepción notable ya que allí
desempeña el papel de origen porque el destino ahora es la memoria). La
instrucción movtiene otro operando, un registro o un valor inmediato. Las instrucciones
aritméticas como addy and(y muchas otras) tienen dos registros fuente más, el primero de los
cuales es siempre un registro y el segundo puede ser un registro o un valor inmediato.

Estos conjuntos de operandos permitidos en las instrucciones se denominan

colectivamente modos de indexación . Hoy este concepto se verá un poco fuera de lugar ya
que no indexaremos nada. La indexación de nombres tiene sentido en los operandos de
memoria, pero las instrucciones ARM, excepto la carga y el almacenamiento, no tienen
operandos de memoria. Esta es la nomenclatura que encontrará en la documentación de
ARM, por lo que parece sensato usar la suya.

Podemos resumir la sintaxis de la mayoría de las instrucciones ARM en el siguiente patrón

instruction Rdest, Rsource1, source2
Hay algunas excepciones, principalmente mover ( mov), sucursales, cargar y almacenar. De
hecho, moverse no es tan diferente en realidad.
mov Rdest, source2
Ambos Rdesty Rsource1deben ser registros. En la siguiente sección hablaremos source2.

Discutiremos los modos de indexación de carga y las instrucciones de almacenamiento en

un capítulo futuro. Las ramas, por otro lado, son sorprendentemente simples y su único
operando es solo una etiqueta de nuestro programa, por lo que hay poco que discutir sobre
los modos de indexación para las ramas.

Operando desplazado
¿Qué es este misterioso source2en los patrones de instrucción anteriores? Si recuerda los
capítulos anteriores, hemos utilizado registros o valores inmediatos. Así que al menos
eso source2es esto: registro o valor inmediato. Puede utilizar un registro inmediato o
donde source2se espera un. A continuación se muestran algunos ejemplos, pero ya los hemos
utilizado en los ejemplos de los capítulos anteriores.
mov r0, #1
mov r1, r0
add r2, r1, r0
add r2, r3, #4
Pero source2puede ser mucho más que un simple registro o un inmediato. De hecho, cuando
es un registro podemos combinarlo con una operación de desplazamiento . Ya vimos una
de estas operaciones de cambio en el capítulo 6. No es el momento de desvelarlas todas.

 LSL #n L gico S hift L eft. Cambia los ntiempos de bits a la izquierda. Los nbits

más a la izquierda se pierden y los nmás a la derecha se ponen a cero.
 LSL Rsource3 Como el anterior, pero en lugar de inmediato, el byte inferior de
un registro especifica la cantidad de desplazamiento.
 LSR #n L gico S hift R ight. Cambia los ntiempos de bits a la derecha. Los nbits
más a la derecha se pierden y los nbits más a la izquierda se ponen a cero,
 LSR Rsource3 Como el anterior, pero en lugar de inmediato, el byte inferior de
un registro especifica la cantidad de desplazamiento.
 ASR #n A rithmetic S hift R ight. Como LSR, pero el bit más a la izquierda
antes del cambio se usa en lugar de cero en los nmás a la izquierda.
 ASR Rsource3 Como el anterior pero usando el byte más bajo de un registro en
lugar de un inmediato.
 ROR #n Ro tate R ight. Como LSR, pero los nbits más a la derecha no se
pierden, sino que se colocan en los nbits más a la izquierda.
 ROR Rsource3 Como el anterior pero usando el byte más bajo de un registro en
lugar de un inmediato.

En el listado anterior, nes un inmediato de 1 a 31. Estas operaciones adicionales pueden

aplicarse al valor en el segundo registro fuente (al valor, no al registro en sí) para que
podamos realizar algunas operaciones más en una sola instrucción. Por ejemplo, ARM no
tiene ninguna instrucción de desplazamiento hacia la derecha o hacia la izquierda. Solo usa
las movinstrucciones.
mov r1, r2, LSL #1
Quizás se pregunte por qué querría uno desplazar hacia la izquierda o hacia la derecha el
valor de un registro. Si recuerdas el capítulo 6, vimos que desplazar LSLun valor a
la izquierda ( ) da un valor que equivale a multiplicarlo por 2. A la inversa, desplazarlo a la
derecha ( ASRsi usamos el complemento a dos, de lo LSRcontrario) es lo mismo que dividir
por 2. Dado que un el cambio de nes lo mismo que hacer ncambios de 1, los cambios en
realidad multiplican o dividen un valor por 2 n .
mov r1, r2, LSL #1 /* r1 ← (r2*2) */
mov r1, r2, LSL #2 /* r1 ← (r2*4) */
mov r1, r3, ASR #3 /* r1 ← (r3/8) */
mov r3, #4
mov r1, r2, LSL r3 /* r1 ← (r2*16) */
Podemos combinarlo con addpara conseguir algunos casos útiles.
add r1, r2, r2, LSL #1 /* r1 ← r2 + (r2*2) equivalent to r1 ← r2*3 */
add r1, r2, r2, LSL #2 /* r1 ← r2 + (r2*4) equivalent to r1 ← r2*5 */
Puedes hacer algo similar con sub.
sub r1, r2, r2, LSL #3 /* r1 ← r2 - (r2*8) equivalent to r1 ← r2*(-7)
ARM viene con un práctico rsb( R Everse S u b instrucción stract) que calcula Rdest ←
source2 - Rsource1(lo comparan con subel cual calcula Rdest ← Rsource1 - source2).

rsb r1, r2, r2, LSL #3 /* r1 ← (r2*8) - r2 equivalent to r1 ← r2*7 */

Otro ejemplo, un poco más elaborado.
/* Complicated way to multiply the initial value of r1 by 42 = 7*3*2 */
rsb r1, r1, r1, LSL #3 /* r1 ← (r1*8) - r1 equivalent to r1 ← 7*r1 */
add r1, r1, r1, LSL #1 /* r1 ← r1 + (2*r1) equivalent to r1 ← 3*r1 */
add r1, r1, r1 /* r1 ← r1 + r1 equivalent to r1 ← 2*r1 */
Probablemente se esté preguntando por qué querríamos usar turnos para realizar
multiplicaciones. Bueno, la instrucción de multiplicación genérica siempre funciona, pero
generalmente es mucho más difícil de calcular con nuestro procesador ARM, por lo que
puede llevar más tiempo. Hay momentos en los que no hay otra opción, pero para muchos
valores constantes pequeños, una sola instrucción puede ser más eficiente.

Las rotaciones son menos útiles que los turnos en el uso diario. Suelen utilizarse en
criptografía, para reordenar bits y "codificarlos". ARM no proporciona una forma de rotar a
la izquierda, pero podemos nrotar a la izquierda haciendo un 32-nrotar a la derecha.
/* Assume r1 is 0x12345678 */
mov r1, r1, ROR #1 /* r1 ← r1 ror 1. This is r1 ← 0x91a2b3c */
mov r1, r1, ROR #31 /* r1 ← r1 ror 31. This is r1 ← 0x12345678 */

Ensamblador ARM en Raspberry Pi

- Capítulo 8
27 de enero de 2013• Roger Ferrer Ibáñez • Raspberry Pi • direcciones , brazo , ensamblador , modos de
indexación , pi , postindex , preindex , frambuesa

En el capítulo anterior vimos que el segundo operando de la mayoría de las instrucciones

aritméticas puede usar un operador de desplazamiento que nos permite desplazar y rotar
bits. En este capítulo continuaremos aprendiendo los modos de indexación disponibles de
las instrucciones ARM. Esta vez nos centraremos en las instrucciones de carga y
almacenamiento.

Matrices y estructuras
Hasta ahora hemos podido mover 32 bits de la memoria a los registros (cargar) y volver a la
memoria (almacenar). Pero trabajar con elementos individuales de 32 bits (generalmente
llamados escalares) es un poco limitante. Pronto nos encontraríamos trabajando en matrices
y estructuras, incluso si no lo sabíamos.

Una matriz es una secuencia de elementos del mismo tipo en la memoria. Las matrices son
una estructura de datos fundamental en casi todos los lenguajes de bajo nivel. Cada matriz
tiene una dirección base, generalmente indicada por el nombre de la matriz, y contiene N
elementos. Cada uno de estos elementos tiene asociado un índice creciente, que va de 0 a
N-1 o de 1 a N. Usando la dirección base y el índice podemos acceder a un elemento del
arreglo. En el capítulo 3 mencionamos que la memoria podría verse como una matriz de
bytes. Una matriz en la memoria es la misma, pero un elemento puede ocupar más de un
byte.

Una estructura (o registro o tupla) es una secuencia de elementos de tipo posiblemente

diferente. Cada elemento de una estructura se suele denominar campo. Los campos no
tienen un índice asociado sino un desplazamiento con respecto al inicio de la
estructura. Las estructuras se establecen en la memoria para garantizar que se utilice la
alineación adecuada en todos los campos. La dirección base de una estructura es la
dirección de su primer campo. Si la dirección base está alineada, la estructura debe
disponerse de manera que todo el campo también esté alineado correctamente.

¿Qué tienen que ver las matrices y la estructura con los modos de indexación de carga y
almacenamiento? Bueno, estos modos de indexación están diseñados para facilitar el acceso
a matrices y estructuras.

Definición de matrices y estructuras

Para ilustrar cómo trabajar con matrices y referencias, usaremos las siguientes
declaraciones de C y las implementaremos en ensamblador.
int a[100];
struct my_struct
{
char f0;
int f1;
} b;
Primero definamos en nuestro ensamblador el arreglo 'a'. Son solo 100 enteros. Un entero
en ARM tiene un ancho de 32 bits, por lo que en nuestro código ensamblador tenemos que
dejar espacio para 400 bytes (4 * 100).

1/* -- array01.s */
[Link]
3
[Link] 4
5a: .skip 400
En la línea 5 definimos el símbolo ay luego dejamos espacio para 400 bytes. La directiva
.skip le dice al ensamblador que avance un número dado de bytes antes de emitir el
siguiente dato. Aquí estamos saltando 400 bytes porque nuestra matriz de enteros toma 400
bytes (4 bytes por cada uno de los 100 enteros). Declarar una estructura no es muy
diferente.

[Link] 4
8b: .skip 8

En este momento, debería preguntarse por qué omitimos 8 bytes cuando la estructura en sí
solo ocupa 5 bytes. Bueno, necesita 5 bytes para almacenar información útil. El primer
campo f0es a char. A charocupa 1 byte de almacenamiento. El siguiente campo f1es un
número entero. Un número entero toma 4 bytes y también debe estar alineado en 4 bytes,
por lo que tenemos que dejar 3 bytes sin usar entre el campo f0y el campo f1. Este
almacenamiento no utilizado puesto solo para cumplir con la alineación se
llama relleno . Su programa nunca debe utilizar el relleno.

Enfoque ingenuo sin modos de indexación

Ok, escribamos un código para inicializar cada elemento de la matriz a[i]. Haremos algo
equivalente al siguiente código C.
for (i = 0; i < 100; i++)
a[i] = i;
[Link]
11
[Link] main
13main:
14 ldr r1, addr_of_a /* r1 ← &a */
15 mov r2, #0 /* r2 ← 0 */
16loop:
17 cmp r2, #100 /* Have we reached 100 yet? */
18 beq end /* If so, leave the loop, otherwise continue */
19 add r3, r1, r2, LSL #2 /* r3 ← r1 + (r2*4) */
20 str r2, [r3] /* *r3 ← r2 */
21 add r2, r2, #1 /* r2 ← r2 + 1 */
22 b loop /* Go to the beginning of the loop */
23end:
24 bx lr
25addr_of_a: .word a

¡Uf! Estamos usando muchas cosas que hemos aprendido de los capítulos anteriores. En la
línea 14 cargamos la dirección base de la matriz en r1. La dirección de la matriz no
cambiará, así que la cargamos una vez. En registro r2mantendremos el índice que estará en
el rango de 0 a 99. En la línea 17 lo comparamos con 100 para ver si hemos llegado al final
del ciclo.

La línea 19 es importante. Aquí calculamos la dirección del artículo. Tenemos en r1la

dirección base y sabemos que cada elemento tiene 4 bytes de ancho. También sabemos
que r2mantiene el índice del bucle que usaremos para acceder al elemento de la
matriz. Dado un elemento con índice, isu dirección debe ser &a + 4*i, ya que hay 4 bytes
entre cada elemento de esta matriz. También lo r3tiene la dirección del elemento actual en
este paso del ciclo. En la línea 20 almacenamos r2, esto es i, en la memoria apuntada por r3,
el i-ésimo elemento de la matriz, esto es a[i].

Luego procedemos a aumentar r2y retroceder para el siguiente paso del bucle.

Como puede ver, acceder a una matriz implica calcular la dirección del elemento
accedido. ¿El conjunto de instrucciones ARM proporciona una forma más compacta de
hacer esto? La respuesta es sí. De hecho, proporciona varios modos de indexación .

Modos de indexación
En el capítulo anterior, el modo de indexación de conceptos estaba un poco apagado porque
no estábamos indexando nada. Ahora tiene mucho más sentido ya que estamos indexando
un elemento de matriz. ARM proporciona nueve de estos modos de indexación. Distinguiré
dos tipos de modos de indexación: no actualizar y actualizar dependiendo de si presentan
un efecto secundario que discutiremos más adelante, cuando se trata de actualizar los
modos de indexación.

Modos de indexación sin actualización

1. [Rsource1, +#immediate]o
[Rsource1, -#immediate]

Simplemente suma (o resta) el valor inmediato para formar la dirección. Esto

es muy útil para ordenar elementos cuyo índice es una constante en el código o
campos de una estructura, ya que su desplazamiento es siempre
constante. En Rsource1ponemos la dirección base y en immediateel offset que
queremos en bytes. El inmediato no puede tener más de 12 bits
(0..4096). Cuando lo inmediato es #0, es como lo habitual que hemos estado
usando [Rsource1].

Por ejemplo, podemos establecerlo a[3]en 3 de esta manera (asumimos que r1

ya contiene la dirección base de a). Tenga en cuenta que el desplazamiento está
en bytes, por lo que necesitamos un desplazamiento de 12 (4 bytes * 3
elementos omitidos).
mov r2, #3 /* r2 ← 3 */
str r2, [r1, #+12] /* *(r1 + 12) ← r2 */
 2. [Rsource1, +Rsource2]o
[Rsource1, -Rsource2]

Esto es como el anterior, pero el desplazamiento agregado (o restado) es el

valor en un registro. Esto es útil cuando el desplazamiento es demasiado grande
para el inmediato. Tenga en cuenta que para el +Rsource2caso, los dos registros
se pueden intercambiar (ya que esto no afectaría la dirección calculada).

Ejemplo. Lo mismo que el anterior pero usando un registro esta vez.

mov r2, #3 /* r2 ← 3 */
mov r3, #12 /* r3 ← 12 */
str r2, [r1,+r3] /* *(r1 + r3) ← r2 */

3. [Rsource1, +Rsource2, shift_operation #immediate]o

[Rsource1, -Rsource2, shift_operation #immediate]

Esta es similar a la operación de turno habitual que podemos hacer con otras
instrucciones. Una operación de desplazamiento
(recuerda: LSL, LSR, ASRo ROR) se aplica a Rsource2, Rsource1se añade a
continuación (o se resta) al resultado de la operación de desplazamiento
aplicada a Rsource2. Esto es útil cuando necesitamos multiplicar la dirección por
una cantidad fija. Al acceder a los elementos de la matriz de enteros a, tuvimos
que multiplicar el resultado por 4 para obtener una dirección significativa.

Para este ejemplo, recordemos primero cómo calculamos por encima de la

dirección en la matriz del elemento en posición r2.

19add r3, r1, r2, LSL #2 /* r3 ← r1 + r2*4 */

20str r2, [r3] /* *r3 ← r2 */

Podemos expresar esto de una manera mucho más compacta (sin la necesidad
del registro r3).
str r2, [r1, +r2, LSL #2] /* *(r1 + r2*4) ← r2 */

Actualizar modos de indexación

En estos modos de indexación, el Rsource1registro se actualiza con la dirección sintetizada
por la instrucción de carga o almacenamiento. Quizás se pregunte por qué querría hacer
esto. Primero un pequeño desvío. Vuelva a verificar el código de la carga de la matriz. ¿Por
qué tenemos que mantenernos alrededor de la dirección base de la matriz si siempre
estamos alejándonos efectivamente 4 bytes de ella? ¿No tendría mucho más sentido
mantener la dirección de la entidad actual? Entonces en lugar de

19add r3, r1, r2, LSL #2 /* r3 ← r1 + r2*4 */

20str r2, [r3] /* *r3 ← r2 */
podríamos querer hacer algo como
str r2, [r1] /* *r1 ← r2 */
add r1, r1, #4 /* r1 ← r1 + 4 */
porque no hay necesidad de calcular cada vez desde el principio la dirección del siguiente
elemento (ya que estamos accediendo a ellos secuencialmente). Incluso si esto se ve un
poco mejor, aún se puede mejorar un poco más. ¿Qué pasaría si nuestra instrucción pudiera
actualizarse r1por nosotros? Algo como esto (obviamente, la sintaxis exacta no es la que se
muestra)
/* Wrong syntax */
str r2, [r1] "and then" add r1, r1, #4
Existen tales modos de indexación. Hay dos tipos de modos de indexación de actualización
según el momento en que Rsource1se actualice. Si Rsource1se actualiza después de la carga o
el almacenamiento en sí (lo que significa que la dirección para cargar o almacenar es
el Rsource1valor inicial ), este es un modo de acceso posterior a la indexación . Si Rsource1se
actualiza antes de la carga real o tienda (lo que significa que la dirección de la carga o la
tienda es el valor final de Rsource1) este es un pre-indexación modo de acceder. En todos los
casos, al final de la instrucción Rsource1tendrá el valor del cómputo del modo de
indexación. Ahora, esto suena un poco complicado, solo mira el ejemplo anterior: primero
cargamos usando r1y luego lo hacemos r1 ← r1 + 4. Esto es post-indexación: primero usamos
el valor der1como la dirección donde almacenamos el valor de r2. Luego r1se actualiza
con r1 + 4. Ahora considere otra sintaxis hipotética.
/* Wrong syntax */
str r2, [add r1, r1, #4]
Esto es preindexación: primero lo calculamos r1 + 4y lo usamos como la dirección donde
almacenamos el valor de r2. Al final de la instrucción también r1se ha actualizado
efectivamente, pero el valor actualizado ya se ha utilizado como la dirección de la carga o
la tienda.

Modos de post-indexación
4. [Rsource1], #+immediateo
[Rsource1], #-immediate

El valor de Rsource1se utiliza como dirección para la carga o

tienda. Luego Rsource1se actualiza con el valor de immediatedespués de sumarlo
(o restarlo) a Rsource1. Usando este modo de indexación podemos reescribir el
ciclo de nuestro primer ejemplo de la siguiente manera:

16loop:
17 cmp r2, #100 /* Have we reached 100 yet? */
18 beq end /* If so, leave the loop, otherwise continue */
19 str r2, [r1], #4 /* *r1 ← r2 then r1 ← r1 + 4 */
20 add r2, r2, #1 /* r2 ← r2 + 1 */
21 b loop /* Go to the beginning of the loop */
22end:
 5. [Rsource1], +Rsource2o
[Rsource1], -Rsource2

Como el anterior pero en lugar de inmediato, Rsource2se usa el valor de . Como

de costumbre, esto se puede utilizar como una solución cuando el
desplazamiento es demasiado grande para el valor inmediato.

6. [Rsource1], +Rsource2, shift_operation #immediateo

[Rsource1], -Rsource2, shift_operation #immediate

El valor de Rsource1se utiliza como dirección para la carga o

tienda. Luego Rsource2se aplica una operación de desplazamiento
( LSL, LSR, ASRo ROL). El valor resultante de ese cambio se suma (o
resta) Rsource1. Rsource1finalmente se actualiza con este último valor.

Modos de preindexación
Los modos de preindexación pueden parecer un poco extraños al principio, pero son útiles
cuando la dirección calculada se reutilizará pronto. En lugar de volver a calcularlo,
podemos reutilizar el archivo actualizado Rsource1. Tenga !en cuenta el símbolo en estos
modos de indexación que los distingue de los modos de indexación que no se actualizan.

7. [Rsource1, #+immediate]!o
[Rsource1, #-immediate]!

Se comporta como el modo de indexación sin actualización similar,

pero Rsource1se actualiza con la dirección calculada. Imagina que queremos
calcular a[3] = a[3] + a[3]. Podríamos hacer esto (asumimos que r1ya tiene la
dirección base de la matriz).
ldr r2, [r1, #+12]! /* r1 ← r1 + 12 then r2 ← *r1 */
add r2, r2, r2 /* r2 ← r2 + r2 */
str r2, [r1] /* *r1 ← r2 */

8. [Rsource1, +Rsource2]!o
[Rsource1, +Rsource2]!

Similar al anterior pero utilizando un registro en Rsource2lugar de uno

inmediato.

9. [Rsource1, +Rsource2, shift_operation #immediate]!o

[Rsource1, -Rsource2, shift_operation #immediate]!

Al igual que el equivalente sin indexación, pero Rsource1 se actualizará con la

dirección utilizada para la instrucción de carga o almacenamiento.
Volver a estructuras
Todos los ejemplos de este capítulo han utilizado una matriz. Las estructuras son un poco
más simples: el desplazamiento a los campos es siempre constante: una vez que tenemos la
dirección base de la estructura (la dirección del primer campo), acceder a un campo es solo
un modo de indexación con un desplazamiento (normalmente, inmediato). Nuestra
estructura actual presenta, a propósito, a charcomo su primer campo f0. Actualmente no
podemos trabajar con escalares en memoria de diferente tamaño de 4 bytes. De modo que
pospondremos el trabajo en ese primer campo para un capítulo futuro.

Por ejemplo, imagine que quisiéramos incrementar el campo f1 de esta manera.

b.f1 = b.f1 + 7;
Si r1contienela dirección base de nuestra estructura, acceder al campo f1es bastante fácil
ahora que conocemos todos los modos de indexación disponibles.

1ldr r2, [r1, #+4]! /* r1 ← r1 + 4 then r2 ← *r1 */

2add r2, r2, #7 /* r2 ← r2 + 7 */
3str r2, [r1] /* *r1 ← r2 */

Tenga en cuenta que usamos un modo de preindexación para mantener r1la dirección del
campo f1. De esta forma, la segunda tienda no necesita volver a calcular esa dirección.

Ensamblador ARM en Raspberry Pi

- Capítulo 9
2 de febrero de 2013• Roger Ferrer Ibáñez • Frambuesa Pi • brazo , ensamblador , función , llamada de
función , funciones , pi , frambuesa

En capítulos anteriores aprendimos los fundamentos del ensamblador ARM: registros,

algunas operaciones aritméticas, cargas y almacenes y sucursales. Ahora es el momento de
juntar todo y agregar otro nivel de abstracción a nuestras habilidades de ensamblador:
funciones.

¿Por qué funciones?

Las funciones son una forma de reutilizar el código. Si tenemos algún código que será
necesario más de una vez, poder reutilizarlo es algo bueno ™. De esta forma, solo tenemos
que asegurarnos de que el código que se está reutilizando sea correcto. Si repetimos el
código deberíamos verificar que sea correcto en todos los puntos. Esto claramente no
escala. Las funciones también pueden obtener parámetros. De esta forma no solo
reutilizamos el código sino que podemos usarlo de varias formas, pasando diferentes
parámetros. Sin embargo, toda esta magia tiene un precio. Una función debe ser
un ciudadano de buen comportamiento .

Lo que se debe y no se debe hacer en una

función
Ensamblador nos da mucho poder. Pero con mucho poder también viene mucha
responsabilidad. Podemos romper muchas cosas en ensamblador, porque estamos en un
nivel muy bajo. Puede suceder un error y cosas desagradables. Para que todas las funciones
se comporten de la misma manera, existen convenciones en cada entorno que dictan cómo
debe comportarse una función. Como estamos en una Raspberry Pi con Linux usaremos
el AAPCS (lo más probable es que lo sigan otros sistemas operativos ARM como RISCOS
o Windows RT). Puede encontrar este documento en el sitio web de documentación de
ARM, pero intentaré resumirlo en este capítulo.

Nuevos registros especiales con nombre

Cuando hablamos de las ramas, aprendimos que r15también se llamaba, pcpero
nunca r15más. Bueno, cambiemos el nombre a partir de
ahora r14como lry r13como sp. lrsignifica l ink r egister y es la dirección de la instrucción
que sigue a la instrucción que nos llamó (veremos más adelante qué es esto). spson las
siglas de s tack  p ointer . La pila es un área de memoria que pertenece solo a la función
actual, el spregistro almacena la dirección superior de esa pila. Por ahora, dejemos la pila a
un lado. Lo recuperaremos en el próximo capítulo.

Pasando parámetros
Las funciones pueden recibir parámetros. Los primeros 4 parámetros deben ser
almacenados, de forma secuencial, en los registros r0, r1, r2y r3. Quizás se esté preguntando
cómo pasar más de 4 parámetros. Podemos, por supuesto, pero necesitamos usar la pila,
pero lo discutiremos en el próximo capítulo. Hasta entonces, solo pasaremos hasta 4
parámetros.

Funciones de buen comportamiento

Una función debe adherirse, al menos, a las siguientes reglas si queremos que sea
compatible con AAPCS.

 Una función no debe hacer ninguna suposición sobre el contenido de cpsr. Entonces, al

ingresar una función, los códigos de condición N, Z, C y V son desconocidos.
 Una función puede modificar libremente registros r0, r1, r2y r3.
 Una función no puede asumir nada sobre el contenido de r0, r1, r2y r3, a menos que
están jugando el papel de un parámetro.
  Una función se puede modificar libremente, lrpero el valor al ingresar a la función será
necesario al salir de la función (por lo que dicho valor debe mantenerse en algún
lugar).
 Una función puede modificar todos los registros restantes siempre que se restauren sus
valores al salir de la función. Esto incluye spy se registra r4en r11.

Esto significa que, después de llamar a una función, tenemos que asumir que (sólo)
registros r0, r1, r2, r3y lrhan sido sobrescritos. </ Li>
Llamar a una función
Hay dos formas de llamar a una función. Si la función se conoce estáticamente (lo que
significa que sabemos exactamente a qué función se debe llamar) la usaremos bl label. Esa
etiqueta debe ser una etiqueta definida en la .textsección. A esto se le llama llamada directa
(o inmediata). Podemos hacer llamadas indirectas almacenando primero la dirección de la
función en un registro y luego usando blx Rsource1.

En ambos casos el comportamiento es el siguiente: la dirección de la función (codificada

inmediatamente en blo usando el valor del registro en blx) se almacena en pc. La dirección
de la instrucción que sigue a la instrucción blo blxse mantiene en lr.

Dejando una función

Una función que se comporta bien, como se indicó anteriormente, tendrá que mantener el
valor inicial de lralgún lugar. Al salir de la función, recuperaremos ese valor y lo
pondremos en algún registro (puede ser de lrnuevo pero esto no es obligatorio). Entonces lo
haremos bx Rsource1(podríamos usar blxtambién, pero este último se actualizaría, lo lrcual es
inútil aquí).

Devolver datos de funciones

Las funciones deben usarse r0para datos que quepan en 32 bits (o menos). Esto es, los tipos
C char, short, int, long(y floataunque no hemos visto todavía en coma flotante) será devuelto
en r0. Para los tipos básicos de 64 bits, como los tipos C long longy double, se devolverán
en r1y r0. Cualquier otro dato se devuelve a través de la pila a menos que sea de 32 bits o
menos, donde se devolverá r0.

En los ejemplos de los capítulos anteriores, devolvimos el código de error del programa en
formato r0. Esto ahora tiene sentido. C's maindevuelve an int, que se usa como el valor del
código de error de nuestro programa.

Hola Mundo
Por lo general, este es el primer programa que escribe en cualquier lenguaje de
programación de alto nivel. En nuestro caso, primero tuvimos que aprender muchas
cosas. De todos modos, aquí está. Un "Hola mundo" en ensamblador ARM.
(Nota para los expertos: dado que no discutiremos la pila hasta el próximo capítulo, este
código puede parecerle muy tonto)

1/* -- hello01.s */
[Link]
3
4greeting:
5 .asciz "Hello world"
6
[Link] 4
8return: .word 0
9
[Link]
11
[Link] main
13main:
14 ldr r1, address_of_return /* r1 ← &address_of_return */
15 str lr, [r1] /* *r1 ← lr */
16
17 ldr r0, address_of_greeting /* r0 ← &address_of_greeting */
18 /* First parameter of puts */
19
20 bl puts /* Call to puts */
21 /* lr ← address of next instruction */
22
23 ldr r1, address_of_return /* r1 ← &address_of_return */
24 ldr lr, [r1] /* lr ← *r1 */
25 bx lr /* return from main */
26address_of_greeting: .word greeting
27address_of_return: .word return
28
29/* External */
[Link] puts

Vamos a llamar a la putsfunción. Esta función está definida en la biblioteca C y tiene el

siguiente prototipo int puts(const char*). Recibe, como primer parámetro, la dirección de una
cadena C (es decir, una secuencia de bytes donde no hay ningún byte pero el último es
cero). Cuando se ejecuta, envía esa cadena a stdout(por lo que debería aparecer de forma
predeterminada en nuestra terminal). Finalmente devuelve el número de bytes escritos.

Comenzamos definiendo en la .dataetiqueta greetingen las líneas 4 y 5. Esta etiqueta

contendrá la dirección de nuestro mensaje de saludo. GNU as proporciona
una .ascizdirectiva conveniente para ese propósito. Esta directiva emite como bytes según
sea necesario para representar la cadena más el byte cero final. Podríamos haber usado otra
directiva .asciisiempre que agreguemos explícitamente el byte cero final.

Después de los bytes del mensaje de saludo, nos aseguramos de que la siguiente etiqueta
tenga 4 bytes alineados y definimos una returnetiqueta en la línea 8. En esa etiqueta
mantendremos el valor de la lrque tenemos main. Como se indicó anteriormente, este es un
requisito para una función de buen comportamiento: poder obtener el valor original de lral
ingresar. Así que le hacemos espacio.

Las dos primeras instrucciones, líneas 14 y 15, de nuestra función principal mantienen el
valor de lren esa returnvariable definida anteriormente. Luego, en la línea 17 preparamos los
argumentos para la llamada a puts. Cargamos la dirección del mensaje de saludo en
el r0registro. Este registro contendrá el primer parámetro (el único en realidad)
de puts. Luego, en la línea 20 llamamos a la función. Recuerde que blse establecerá en lrla
dirección de la instrucción que le sigue (esta es la instrucción en la línea 23). Esta es la
razón por la que copiamos el valor de lren una variable al comienzo de la mainfunción,
porque iba a ser sobrescrito por bl.

Ok, se putsejecuta y el mensaje se imprime en el stdout. Es hora de obtener el valor inicial

de lrpara poder regresar correctamente desde main. Luego volvemos.

¿Nuestra mainfunción se comporta bien? Sí, se mantiene y vuelve lra salir. Solo

modifica r0y r1. Podemos suponer que putstambién se porta bien, por lo que todo debería
funcionar bien. Más la ventaja de ver cuántos bytes se han escrito en la salida.
$ ./hello01
Hello world
$ echo $?
12
Tenga en cuenta que "Hola mundo" tiene solo 11 bytes (el cero final no se cuenta ya que
solo desempeña el papel de un byte de finalización) pero el programa devuelve 12. Esto se
debe a que putssiempre agrega un byte de nueva línea, que representa ese byte extra.

Interacción real!
Ahora que tenemos el poder de llamar a funciones, podemos unirlas. Llamemos a printf y
scanf para leer un número y luego imprimirlo en la salida estándar.

1/* -- printf01.s */
[Link]
3
4/* First message */
[Link] 4
6message1: .asciz "Hey, type a number: "
7
8/* Second message */
[Link] 4
10message2: .asciz "I read the number %d\n"
11
12/* Format pattern for scanf */
[Link] 4
14scan_pattern : .asciz "%d"
15
16/* Where scanf will store the number read */
[Link] 4
18number_read: .word 0
19
[Link] 4
21return: .word 0
22
[Link]
24
[Link] main
26main:
27 ldr r1, address_of_return /* r1 ← &address_of_return */
28 str lr, [r1] /* *r1 ← lr */
29
30 ldr r0, address_of_message1 /* r0 ← &message1 */
31 bl printf /* call to printf */
32
33 ldr r0, address_of_scan_pattern /* r0 ← &scan_pattern */
34 ldr r1, address_of_number_read /* r1 ← &number_read */
35 bl scanf /* call to scanf */
36
37 ldr r0, address_of_message2 /* r0 ← &message2 */
38 ldr r1, address_of_number_read /* r1 ← &number_read */
39 ldr r1, [r1] /* r1 ← *r1 */
40 bl printf /* call to printf */
41
42 ldr r0, address_of_number_read /* r0 ← &number_read */
43 ldr r0, [r0] /* r0 ← *r0 */
44
45 ldr lr, address_of_return /* lr ← &address_of_return */
46 ldr lr, [lr] /* lr ← *lr */
47 bx lr /* return from main using lr */
48address_of_message1 : .word message1
49address_of_message2 : .word message2
50address_of_scan_pattern : .word scan_pattern
51address_of_number_read : .word number_read
52address_of_return : .word return
 53
54/* External */
[Link] printf
[Link] scanf

En este ejemplo, le pediremos al usuario que escriba un número y luego lo

imprimiremos. También devolvemos el número en el código de error, por lo que podemos
verificar dos veces si todo sale como se esperaba. Para la verificación del código de error,
asegúrese de que su número sea inferior a 255 (de lo contrario, el código de error mostrará
solo sus 8 bits inferiores).
$ ./printf01
Hey, type a number: 123↴
I read the number 123
$ ./printf01 ; echo $?
Hey, type a number: 124↴
I read the number 124
124

Nuestra primera función

Definamos nuestra primera función. Extendamos el ejemplo anterior pero multipliquemos
el número por 5.

[Link] 4
24return2: .word 0
25
[Link]
27
28/*
29mult_by_5 function
30*/
31mult_by_5:
32 ldr r1, address_of_return2 /* r1 ← &address_of_return */
33 str lr, [r1] /* *r1 ← lr */
34
35 add r0, r0, r0, LSL #2 /* r0 ← r0 + 4*r0 */
36
37 ldr lr, address_of_return2 /* lr ← &address_of_return */
38 ldr lr, [lr] /* lr ← *lr */
39 bx lr /* return from main using lr */
40address_of_return2 : .word return2

Esta función necesitará otra " return" variable como la que mainusa. Pero esto es por el bien
del ejemplo. En realidad, esta función no llama a otra función. Cuando esto sucede, no es
necesario que se mantenga, lrya que no blo la blxinstrucción lo va a modificar. Si la función
quisiera usar lrcomo r14registro de propósito general, el proceso de mantener el valor aún
sería obligatorio.

Como puede ver, una vez que la función ha calculado el valor, es suficiente
mantenerlo r0. En este caso fue bastante fácil y una sola instrucción fue suficiente.

El ejemplo completo sigue.

1/* -- printf02.s */
[Link]
3
4/* First message */
[Link] 4
6message1: .asciz "Hey, type a number: "
7
8/* Second message */
[Link] 4
10message2: .asciz "%d times 5 is %d\n"
11
12/* Format pattern for scanf */
[Link] 4
14scan_pattern : .asciz "%d"
15
16/* Where scanf will store the number read */
[Link] 4
18number_read: .word 0
19
[Link] 4
21return: .word 0
22
[Link] 4
24return2: .word 0
25
[Link]
27
28/*
29mult_by_5 function
30*/
31mult_by_5:
32 ldr r1, address_of_return2 /* r1 ← &address_of_return */
33 str lr, [r1] /* *r1 ← lr */
34
35 add r0, r0, r0, LSL #2 /* r0 ← r0 + 4*r0 */
 36
37 ldr lr, address_of_return2 /* lr ← &address_of_return */
38 ldr lr, [lr] /* lr ← *lr */
39 bx lr /* return from main using lr */
40address_of_return2 : .word return2
41
[Link] main
43main:
44 ldr r1, address_of_return /* r1 ← &address_of_return */
45 str lr, [r1] /* *r1 ← lr */
46
47 ldr r0, address_of_message1 /* r0 ← &message1 */
48 bl printf /* call to printf */
49
50 ldr r0, address_of_scan_pattern /* r0 ← &scan_pattern */
51 ldr r1, address_of_number_read /* r1 ← &number_read */
52 bl scanf /* call to scanf */
53
54 ldr r0, address_of_number_read /* r0 ← &number_read */
55 ldr r0, [r0] /* r0 ← *r0 */
56 bl mult_by_5
57
58 mov r2, r0 /* r2 ← r0 */
59 ldr r1, address_of_number_read /* r1 ← &number_read */
60 ldr r1, [r1] /* r1 ← *r1 */
61 ldr r0, address_of_message2 /* r0 ← &message2 */
62 bl printf /* call to printf */
63
64 ldr lr, address_of_return /* lr ← &address_of_return */
65 ldr lr, [lr] /* lr ← *lr */
66 bx lr /* return from main using lr */
67address_of_message1 : .word message1
68address_of_message2 : .word message2
69address_of_scan_pattern : .word scan_pattern
70address_of_number_read : .word number_read
71address_of_return : .word return
72
73/* External */
[Link] printf
[Link] scanf

Quiero que se fijen en las líneas 58 a 62. Allí preparamos la llamada a la printfque recibe
tres parámetros: el formato y los dos enteros referenciados en el formato. Queremos que el
primer entero sea el número ingresado por el usuario. El segundo será ese mismo número
multiplicado por 5. Luego de la llamada a mult_by_5, r0contiene el número ingresado por el
usuario multiplicado por 5. Queremos que sea el tercer parámetro así que lo movemos
a r2. Luego cargamos el valor del número ingresado por el usuario en r1. Finalmente
cargamos en r0la dirección al formato de mensaje de printf. Tenga en cuenta que aquí el
orden de preparación de los argumentos de una llamada no es relevante siempre que los
valores sean correctos en el momento de la llamada. Usamos el hecho de que tendremos
que sobrescribirr0, por lo que, para mayor comodidad, primero copiamos r0en r2.
$ ./printf02
Hey, type a number: 1234↴
1234 times 5 is 6170

Ensamblador ARM en Raspberry Pi

- Capítulo 10
7 de febrero de 2013• Roger Ferrer Ibáñez • Frambuesa Pi • brazo , ensamblador , función , llamada de
función , funciones , pi , frambuesa , pila

En el capítulo 9 nos presentaron las funciones y vimos que tienen que seguir una serie de
convenciones para funcionar bien con otras funciones. También mencionamos brevemente
la pila, como un área de memoria que pertenece únicamente a la función. En este capítulo
profundizaremos en la pila y por qué es importante para las funciones.

Activación dinámica
Uno de los beneficios de las funciones es poder llamarlas más de una vez. Pero eso más de
una vez esconde una pequeña trampa. No estamos restringiendo quién podrá llamar a la
función, por lo que puede suceder que sea la misma función la que se llame a sí
misma. Esto sucede cuando usamos la recursividad.

Un ejemplo típico de recursividad es el factorial de un número n , generalmente escrito

como n!  . Un factorial en C se puede escribir de la siguiente manera.
int factorial(int n)
{
if (n == 0)
return 1;
else
return n * factorial(n-1);
}
Tenga en cuenta que solo hay una función factorial, pero se puede llamar varias veces. Por
ejemplo: factorial (3) → factorial (2) → factorial (1) → factorial (0) , donde → significa
un «llama». Por tanto, una función se activa dinámicamente cada vez que se llama. El lapso
de una activación dinámica va desde el punto donde se llama a la función hasta que
regresa. En un momento dado, más de una función se activa dinámicamente. Todo el
conjunto de funciones de activación dinámica incluye la función actual y el conjunto de
activación dinámica de la función que la llamó (la función actual).

Está bien. Tenemos una función que se llama a sí misma. No es gran cosa, ¿verdad? Bueno,
esto no sería un problema si no fuera por las reglas que debe cumplir una función. Vamos a
recordarlos rápidamente.

 Sólo r0, r1, r2y r3se pueden modificar libremente.

 lr El valor en la entrada de la función debe mantenerse en algún lugar porque lo
necesitaremos para salir de la función (para volver a la persona que llama).
 Todos los otros registros r4a r11, y spse pueden modificar, pero que deben ser
restaurados a sus valores originales a la salida de la función.

En el capítulo 9 usamos una variable global para mantener lr. Pero si intentáramos usar una
variable global en nuestro ejemplo factorial (3) , se sobrescribirá en la siguiente activación
dinámica de factorial. Solo podríamos volver de factorial (0) a factorial (1) . Después de
eso nos quedaríamos atrapados en factorial (1) , ya lrque siempre tendríamos el mismo
valor.

Entonces, parece que necesitamos alguna forma de mantener al menos el valor de lr por
cada activación dinámica . Y no solo lr, si quisiéramos usar registros de r4a r11también
necesitamos mantener de alguna manera por cada activación dinámica, una variable global
tampoco sería suficiente. Aquí es donde entra en juego la pila.

La pila
En informática, una pila es una estructura de datos (una forma de organizar los datos que
proporciona algunas propiedades interesantes). Una pila normalmente tiene tres
operaciones: acceder a la parte superior de la pila, empujar hacia la parte superior, saltar
desde la parte superior. Dependiendo del contexto, solo puede acceder a la parte superior de
la pila, en nuestro caso podremos acceder a más elementos que solo la parte superior.

Pero, ¿qué es la pila? Ya dije en el capítulo 9 que la pila es una región de memoria que
pertenece únicamente a la función. Ahora podemos reformular esto un poco mejor: la pila
es una región de memoria que pertenece únicamente a la activación dinámica actual. ¿Y
cómo controlamos la pila? Bueno, en el capítulo 9 dijimos que el
registro spsignifica s tack p ointer . Este registro contendrá la parte superior de la pila. La
región de memoria propiedad de la activación dinámica es la extensión de bytes contenidos
entre el valor actual de spy el valor inicial que sptenía al comienzo de la
función. Llamaremos a esa región la memoria [Link] una función (más precisamente, de
una activación dinámica de la misma). Pondremos allí todo lo que haya que guardar al
comienzo de una función y restaurarlo antes de salir. También guardaremos allí
las variables locales de una función (activación dinámica).

Nuestra función también tiene que adherirse a algunas reglas al manejar la pila.
  El puntero de la pila ( sp) siempre está alineado con 4 bytes. Esto es
absolutamente obligatorio. Sin embargo, debido al estándar de llamada a
procedimiento para la arquitectura ARM (AAPCS), el puntero de la pila tendrá
que estar alineado en 8 bytes; de lo contrario, pueden suceder cosas divertidas
cuando llamamos a lo que AAPCS llama interfaces públicas (es decir, código
escrito por otros gente).
 El valor de spal salir de la función debe ser el mismo valor que tenía al ingresar
a la función.

La primera regla es consistente con las restricciones de alineación de ARM, donde la

mayoría de las veces las direcciones deben estar alineadas en 4 bytes. Debido a AAPCS,
nos ceñiremos a la restricción de alineación de 8 bytes adicionales. La segunda regla
establece que, no importa cuán grande sea nuestra memoria local, siempre desaparecerá al
final de la función. Esto es importante, porque las variables locales de una activación
dinámica no necesitan tener ningún almacenamiento después de que finaliza la activación
dinámica.

Es una convención cómo la pila, y por lo tanto la memoria local, tiene definido su
tamaño. La pila puede crecer hacia arriba o hacia abajo. Si crece hacia arriba significa que
tenemos que incrementar el valor del spregistro para poder ampliar la memoria local. Si
crece hacia abajo tenemos que hacer lo contrario, el valor del spregistro debe restarse tantos
bytes como el tamaño del almacenamiento local. En Linux ARM, la pila crece hacia abajo,
hacia cero (aunque nunca debería llegar a cero). Las direcciones de las variables locales
tienen valores muy grandes en el rango de 32 bits. Suelen estar cerca de 2 32 .

Otra convención al usar la pila se refiere a si el spregistro contiene la dirección de la parte

superior de la pila o algunos bytes arriba. En Linux ARM, el spregistro apunta directamente
a la parte superior de la pila: en la memoria a la que se dirige sphay información útil.

Bien, sabemos que la pila crece hacia abajo y la parte superior de la pila siempre debe estar
adentro sp. Entonces, para ampliar la memoria local debería ser suficiente
disminuyendo sp. La memoria local se define entonces por el rango de memoria desde
el spvalor actual hasta el valor original que sptenía al comienzo de la función. Un registro
que casi siempre debemos mantener es lr. Veamos cómo podemos mantenernos en la pila.
sub sp, sp, #8 /* sp ← sp - 8. This enlarges the stack by 8 bytes */
str lr, [sp] /* *sp ← lr */
... // Code of the function
ldr lr, [sp] /* lr ← *sp */
add sp, sp, #8 /* sp ← sp + 8. /* This reduces the stack by 8 bytes
effectively restoring the stack
pointer to its original value */
bx lr
Una función con buen comportamiento puede modificar sp pero debe asegurarse de que al
final tenga el mismo valor que tenía cuando ingresamos a la función. Esto es lo que
hacemos aquí. Primero restamos 8 bytes a sp y al final volvemos a agregar 8 bytes.
Esta secuencia de instrucciones sería suficiente. Pero tal vez recuerde el capítulo 8 y los
modos de indexación que podría usar para cargar y almacenar. Tenga en cuenta que las dos
primeras instrucciones se comportan exactamente como una preindexación. Primero
actualizamos spy luego usamos spcomo dirección donde almacenamos lr. ¡Esto es
exactamente un preíndice! Lo mismo ocurre con las dos últimas instrucciones. Primero
cargamos lrusando la dirección actual de spy luego disminuimos sp. ¡Esto es exactamente un
posíndice!
str lr, [sp, #-8]! /* preindex: sp ← sp - 8; *sp ← lr */
... // Code of the function
ldr lr, [sp], #+8 /* postindex; lr ← *sp; sp ← sp + 8 */
bx lr
Sí, estos modos de direccionamiento se inventaron para admitir este tipo de cosas. Usar una
sola instrucción es mejor en términos de tamaño de código. Esto puede no parecer
relevante, ¡pero es cuando nos damos cuenta de que la contabilidad de la pila es necesaria
en casi todas las funciones que escribimos!

Primer enfoque
Implementemos la función factorial anterior.

En primer lugar tenemos que aprender una nueva instrucción para multiplicar dos
números: mul Rdest, Rsource1, Rsource2. Tenga en cuenta que la multiplicación de dos valores
de 32 bits puede requerir hasta 64 bits para el resultado. Esta instrucción solo calcula los 32
bits inferiores. Debido a que no vamos a utilizar valores de 64 bits en este ejemplo, ¡el
factorial máximo que podremos calcular es 12! (13! Es mayor que 2 32 ). No verificaremos
que el número ingresado sea menor que 13 para simplificar el ejemplo (aunque le animo a
agregar esta verificación al ejemplo). En versiones de la arquitectura ARM anteriores a
ARMv6, esta instrucción no podía tener Rdestlo mismo que Rsource1. El ensamblador GNU
puede imprimir una advertencia si no aprueba -march=armv6.
1/* -- factorial01.s */
[Link]
3
4message1: .asciz "Type a number: "
5format: .asciz "%d"
6message2: .asciz "The factorial of %d is %d\n"
7
[Link]
9
10factorial:
11 str lr, [sp,#-4]! /* Push lr onto the top of the stack */
12 str r0, [sp,#-4]! /* Push r0 onto the top of the stack */
13 /* Note that after that, sp is 8 byte aligned */
14 cmp r0, #0 /* compare r0 and 0 */
15 bne is_nonzero /* if r0 != 0 then branch */
16 mov r0, #1 /* r0 ← 1. This is the return */
17 b end
18is_nonzero:
19 /* Prepare the call to factorial(n-1) */
20 sub r0, r0, #1 /* r0 ← r0 - 1 */
21 bl factorial
22 /* After the call r0 contains factorial(n-1) */
23 /* Load r0 (that we kept in th stack) into r1 */
24 ldr r1, [sp] /* r1 ← *sp */
25 mul r0, r0, r1 /* r0 ← r0 * r1 */
26
27end:
28 add sp, sp, #+4 /* Discard the r0 we kept in the stack */
29 ldr lr, [sp], #+4 /* Pop the top of the stack and put it in lr */
30 bx lr /* Leave factorial */
31
[Link] main
33main:
34 str lr, [sp,#-4]! /* Push lr onto the top of the stack */
35 sub sp, sp, #4 /* Make room for one 4 byte integer in the stack */
36 /* In these 4 bytes we will keep the number */
37 /* entered by the user */
38 /* Note that after that the stack is 8-byte aligned */
39 ldr r0, address_of_message1 /* Set &message1 as the first parameter of printf */
40 bl printf /* Call printf */
41
42 ldr r0, address_of_format /* Set &format as the first parameter of scanf */
43 mov r1, sp /* Set the top of the stack as the second parameter */
44 /* of scanf */
45 bl scanf /* Call scanf */
46
47 ldr r0, [sp] /* Load the integer read by scanf into r0 */
48 /* So we set it as the first parameter of factorial */
49 bl factorial /* Call factorial */
50
51 mov r2, r0 /* Get the result of factorial and move it to r2 */
52 /* So we set it as the third parameter of printf */
53 ldr r1, [sp] /* Load the integer read by scanf into r1 */
54 /* So we set it as the second parameter of printf */
55 ldr r0, address_of_message2 /* Set &message2 as the first parameter of printf */
56 bl printf /* Call printf */
57
58
 59 add sp, sp, #+4 /* Discard the integer read by scanf */
60 ldr lr, [sp], #+4 /* Pop the top of the stack and put it in lr */
61 bx lr /* Leave main */
62
63address_of_message1: .word message1
64address_of_message2: .word message2
65address_of_format: .word format

La mayor parte del código es bastante sencillo. En ambas funciones, mainy factorial,

asignamos 4 bytes adicionales en la parte superior de la pila. En factorial, para mantener el
valor de r0, porque se sobrescribirá durante la llamada recursiva (dos veces, como primer
parámetro y como resultado de la llamada a la función recursiva). En main, para mantener el
valor ingresado por el usuario (si recuerda el capítulo 9, usamos una variable global aquí).

Es importante tener en cuenta que la pila, como una pila real, el último elemento apilado
(empujado hacia arriba) será el primero en ser sacado de la pila (salido desde
arriba). Almacenamos lry dejamos espacio para un número entero de 4 bytes. Dado que se
trata de una pila, se debe utilizar el orden opuesto para devolver la pila a su estado
original. Primero descartamos el entero y luego restauramos el lr. Tenga en cuenta que esto
también sucede cuando reservamos el almacenamiento de la pila para el entero usando
a suby luego descartamos dicho almacenamiento haciendo la operación opuesta add.

¿Podemos hacerlo mejor?

Tenga en cuenta que la cantidad de instrucciones que necesitamos para enviar y extraer
datos desde y hacia la pila crece linealmente con respecto a la cantidad de elementos de
datos. Dado que ARM fue diseñado para sistemas embebidos, los diseñadores de ARM
idearon una forma de reducir la cantidad de instrucciones que necesitamos para la
"contabilidad" de la pila. Estas instrucciones son múltiples carga, ldmy almacenar
múltiples, stm.

Estas dos instrucciones son bastante poderosas y permiten en una sola instrucción realizar
muchas cosas. Su sintaxis se muestra a continuación. Elementos encerrados entre
llaves {y }pueden omitirse de la sintaxis (aunque el efecto de la instrucción variará).
ldm addressing-mode Rbase{!}, register-set
stm addressing-mode Rbase{!}, register-set
Lo consideraremos addressing-modemás adelante. Rbasees la dirección base utilizada para
cargar o almacenar desde el register-set. Los 16 registros ARM se pueden especificar
en register-set(excepto pcen stm). Se genera un conjunto de direcciones al ejecutar estas
instrucciones. Una dirección por registro en el conjunto de registros. Luego, cada registro,
en orden ascendente, se empareja con cada una de estas direcciones, también en orden
ascendente. De esta manera, el registro con el número más bajo obtiene la dirección de
memoria más baja y el registro con el número más alto obtiene la dirección de memoria
más alta. Cada par de direcciones de registro se utiliza para realizar la operación de
memoria: cargar o almacenar. Especificar los !medios que Rbasese actualizarán. El valor
actualizado depende de addressing-mode.

Tenga en cuenta que, si los registros están emparejados con direcciones en función de su
número de registro, parece que siempre se cargarán y almacenarán de la misma manera. Por
ejemplo, un register-setcontenedor r4, r5y r6siempre se almacenará r4en la dirección más baja
generada por la instrucción y r6en la más alta. Sin embargo, podemos especificar cuál se
considera la dirección más baja o la más alta. Entonces, ¿es Rbaserealmente la dirección más
alta o la más baja de la carga / tienda múltiple? Este es uno de los dos aspectos que
controla addressing-mode. El segundo aspecto se refiere a cuándo cambia la dirección de la
operación de memoria entre cada operación de memoria.

Si el valor en Rbasese considera la dirección más alta, significa que primero debemos
disminuir Rbasetantos bytes como requiera el número de registros en register-set(esto es 4
veces el número de registros) para formar la dirección más baja. Luego podemos cargar o
almacenar cada registro de forma consecutiva comenzando desde esa dirección más baja,
siempre en orden ascendente del número de registro. Este modo de direccionamiento se
denomina decreciente y se especifica mediante a d. Por el contrario, si Rbasese considera la
dirección más baja, entonces esto es un poco más fácil, ya que podemos usar su valor como
la dirección más baja. Procedemos como de costumbre, cargando o almacenando cada
registro en orden ascendente de su número de registro. Este modo de direccionamiento se
llama aumentoy se especifica mediante un i.

En cada carga o almacenamiento, la dirección generada para la operación de memoria

puede actualizarse antes o después de la operación de memoria en sí. Podemos especificar
esto usando o , respectivamente. ab

Si especificamos !, después de la instrucción, Rbasetendrá la dirección más alta generada en

el modo creciente y la dirección más baja generada en el modo decreciente. El valor final
de Rbaseincluirá la suma o resta final si usamos un modo que se actualiza después
(un amodo).

Así que tenemos cuatro modos de direccionamiento, a saber: ia, ib, day db. Estos modos de

direccionamiento se especifican como sufijos de las instrucciones stmy ldm. Por lo que el
conjunto completo de nombres es stmia, stmib, stmda, stmdb, ldmia, ldmib, ldmda, ldmdb. Ahora
puede pensar que esto es demasiado complicado, pero no necesitamos usar los ocho
modos. Solo dos de ellos nos interesan ahora.

Cuando empujamos algo a la pila, en realidad disminuimos el puntero de la pila (porque en

Linux la pila crece hacia abajo). Más precisamente, primero disminuimos el puntero de pila
tantos bytes como sea necesario antes de realizar el almacenamiento real en ese puntero de
pila recién calculado. Entonces lo apropiado addressing-modeal empujar sobre la pila
es stmdb. A la inversa, cuando salgamos de la pila usaremos ldmia: incrementamos el puntero
de la pila después de haber realizado la carga.

Factorial de nuevo
Antes de ilustrar estas dos instrucciones, primero reescribiremos ligeramente nuestro
factorial.

Si vuelve al código de nuestro factorial, hay un momento, al calcular n * factorial(n-1),

donde r0se requiere el valor inicial de . El valor de nestaba en r0al comienzo de la función,
pero r0se puede modificar libremente mediante funciones llamadas. Elegimos, en el
ejemplo anterior, mantener una copia de r0en la pila en la línea 12. Más tarde, en la línea
24, lo cargamos de la pila r1, justo antes de calcular la multiplicación.

En nuestra segunda versión de factorial, guardaremos una copia del valor inicial
de r0into r4. Pero r4es un registro cuyo valor debe restaurarse al salir de una función. Así
que mantendremos el valor de r4en la entrada de la función en la pila. Al final, lo
restauraremos de la pila. De esta forma podemos usar r4sin romper las reglas de las
funciones que se comportan bien .
10factorial:
11 str lr, [sp,#-4]! /* Push lr onto the top of the stack */
12 str r4, [sp,#-4]! /* Push r4 onto the top of the stack */
13 /* The stack is now 8 byte aligned */
14 mov r4, r0 /* Keep a copy of the initial value of r0 in r4 */
15
16
17 cmp r0, #0 /* compare r0 and 0 */
18 bne is_nonzero /* if r0 != 0 then branch */
19 mov r0, #1 /* r0 ← 1. This is the return */
20 b end
21is_nonzero:
22 /* Prepare the call to factorial(n-1) */
23 sub r0, r0, #1 /* r0 ← r0 - 1 */
24 bl factorial
25 /* After the call r0 contains factorial(n-1) */
26 /* Load initial value of r0 (that we kept in r4) into r1 */
27 mov r1, r4 /* r1 ← r4 */
28 mul r0, r0, r1 /* r0 ← r0 * r1 */
29
30end:
31 ldr r4, [sp], #+4 /* Pop the top of the stack and put it in r4 */
32 ldr lr, [sp], #+4 /* Pop the top of the stack and put it in lr */
33 bx lr /* Leave factorial */

Tenga en cuenta que el resto del programa no tiene que cambiar. Esto es lo genial de las
funciones :)

Bien, ahora preste atención a estas dos secuencias en nuestra nueva versión factorial
anterior.
 11 str lr, [sp,#-4]! /* Push lr onto the top of the stack */
12 str r4, [sp,#-4]! /* Push r4 onto the top of the stack */

30 ldr r4, [sp], #+4 /* Pop the top of the stack and put it in r4 */
31 ldr lr, [sp], #+4 /* Pop the top of the stack and put it in lr */

Ahora, reemplácelos con stmdby ldmiacomo se explicó hace unos párrafos.

11 stmdb sp!, {r4, lr} /* Push r4 and lr onto the stack */

30 ldmia sp!, {r4, lr} /* Pop lr and r4 from the stack */

Tenga en cuenta que el orden de los registros en el conjunto de registros no es relevante,

pero el procesador los manejará en orden ascendente, por lo que debemos escribirlos en
orden ascendente. El ensamblador GNU emitirá una advertencia de lo contrario. Dado lrque
en realidad r14debe ir después r4. Esto significa que nuestro código es 100% equivalente al
anterior ya r4que terminará en una dirección más baja que lr: recuerde que nuestra pila crece
hacia direcciones más bajas, por r4lo tanto, el que está en la parte superior de la
pila factorialtiene la dirección más baja.

Recordar stmdb sp!y ldmia sp!puede ser un poco difícil. Además, dado que estas dos
instrucciones serán relativamente comunes al ingresar y salir de funciones, el ensamblador
GNU proporciona dos mnemónicos push y poppara stmdb sp!y ldmia sp!,
respectivamente. Tenga en cuenta que estas no son instrucciones ARM en realidad, solo
nombres de conveniencia que son más fáciles de recordar.
11 push {r4, lr}

30
pop {r4, lr}

Ensamblador ARM en Raspberry Pi

- Capítulo 11
16 de marzo de 2013• Roger Ferrer Ibáñez • Frambuesa
Pi • brazo , ensamblador , ramas , función , llamada de función , funciones , pi , la predicación , la
frambuesa

Varias veces, en capítulos anteriores, dije que la arquitectura ARM se diseñó teniendo en
cuenta el mundo integrado. Aunque el costo de la memoria es cada día más bajo, aún puede
representar una parte importante del presupuesto de un sistema integrado. El conjunto de
instrucciones ARM tiene varias características destinadas a reducir el impacto del tamaño
del código. Una de las características que ayuda en tal enfoque es la predicación .

Predicación
Vimos en los capítulos 6 y 7 cómo usar ramas en nuestro programa para modificar el flujo
de ejecución de instrucciones e implementar estructuras de control útiles. Las ramas pueden
ser incondicionales, por ejemplo, cuando llamamos a una función como hicimos en los
capítulos 9 y 10, o condicionales cuando queremos saltar a alguna parte del código solo
cuando se cumple una condición previamente probada.

La predicación está relacionada con las ramas condicionales. ¿Qué pasaría si, en lugar de
ramificación a alguna parte del código destinado a ser ejecutado sólo cuando una
condición Cse mantiene, hemos sido capaces de convertir algunas
instrucciones apagado cuando esa Ccondición no se cumple ?. Considere un caso como
este.
if (C)
T();
else
E();
Usando la predicación (y con alguna sintaxis inventada para expresarla) podríamos escribir
lo anterior de la siguiente manera.
P = C;
[P] T();
[!P] E();
De esta forma evitamos las ramas. Pero, ¿por qué querría evitar las ramas? Bueno, ejecutar
una rama condicional implica un poco de incertidumbre. Pero esto merece un poco de
explicación.

La línea de montaje de instrucciones

Imagina una línea de montaje. En esa línea de montaje hay 5 trabajadores, cada uno
totalmente especializado en una sola tarea. Esa línea de montaje ejecuta instrucciones. Cada
instrucción entra en la línea de montaje por la izquierda y la deja por la derecha. Cada
trabajador realiza alguna tarea en la instrucción y pasa al siguiente trabajador a la
derecha. Además, imagina que todos los trabajadores están más o menos sincronizados,
cada uno termina la tarea en la misma cantidad de 6segundos. Esto significa que cada 6
segundos hay una instrucción que sale de la línea de montaje, una instrucción
completamente ejecutada. También significa que en un momento dado puede haber hasta 5
instrucciones en proceso (aunque no completamente ejecutadas, solo tenemos una
instrucción completamente ejecutada cada 6 segundos).

El primer trabajador busca las instrucciones y las coloca en la línea de montaje. Obtiene la

instrucción en la dirección especificada por el registro pc. De forma predeterminada, a
menos que se le indique, este trabajador recupera la instrucción físicamente siguiendo la
que obtuvo anteriormente (esto es una secuencia implícita ).

En esta línea de montaje, el trabajador que comprueba el estado de una rama condicional no
es el primero sino el tercero. Ahora considere lo que sucede cuando el primer trabajador
obtiene una rama condicional y la coloca en la línea de ensamblaje. El segundo trabajador
lo procesará y lo pasará al tercero. El tercero lo procesará verificando la condición de la
rama condicional. Si no se mantiene, no pasa nada, la rama no tiene ningún efecto. Pero si
la condición se cumple, el tercer trabajador debe notificar al primero que la siguiente
instrucción obtenida debe ser la instrucción en la dirección de la sucursal.

Pero ahora hay dos instrucciones en la línea de ensamblaje que no deberían ejecutarse por
completo (las que estaban físicamente después de la rama condicional). Aquí hay varias
opciones. El tercer trabajador puede elegir dos pegatinas etiquetadas como NO HACER
NADA y pegarlas en las dos siguientes instrucciones. Otro enfoque sería que el tercer
trabajador le diga al primero y al segundo trabajador "Hola chicos, NO HAGAN NADA a su
instrucción actual". Trabajadores posteriores, cuando vean que estas pegatinas NO HACEN
NADA , no harán nada. De esta manera, cada instrucción de NO HACER NADA nunca se
ejecutará por completo.
Pero al hacer esto, esa bonita propiedad de nuestra línea de ensamblaje desaparece: ahora
no tenemos una instrucción completamente ejecutada cada 6 segundos. De hecho, después
de la rama condicional hay dos instrucciones de NO HACER NADA . Un programa que se
ramifica constantemente puede reducir el rendimiento de nuestra línea de montaje de una
instrucción (útil) cada 6 segundos a una instrucción cada 18 segundos. ¡Esto es tres veces
más lento!

La verdad es que los procesadores modernos, incluido el de Raspberry Pi,

tienen predictores de ramaque son capaces de mitigar estos problemas: intentan predecir si
la condición se mantendrá, por lo que la rama se toma o no. Los predictores de sucursales,
sin embargo, predicen el futuro como los corredores de bolsa, utilizando el pasado y,
cuando no hay información pasada, utilizando algunas suposiciones sensatas. Por lo tanto,
los predictores de rama pueden funcionar muy bien con códigos relativamente predecibles,
pero es posible que no funcionen tan bien si el código tiene un comportamiento
impredecible. Este comportamiento, por ejemplo, se observa cuando se ejecutan
descompresores. Un compresor reduce el tamaño de sus archivos eliminando la
redundancia. Las cosas redundantes son predecibles y se pueden omitir (por ejemplo, en "él
está usando su abrigo", puede omitir "él" o reemplazar "su" por "su", independientemente
de si hacerlo es de mala educación, porque sabe que está hablando Un macho).

Volviendo al ejemplo de la línea de montaje, sería el primer trabajador que intenta predecir
dónde se llevará o no la sucursal. Es el tercer trabajador quien verifica si el primer
trabajador hizo la predicción correcta. Si el primer trabajador predijo mal la sucursal,
entonces tenemos que volver a aplicar dos pegatinas y notificar al primer trabajador cuál es
la dirección correcta de la siguiente instrucción. Si el primer trabajador predijo
correctamente la rama, no se tiene que hacer nada especial, lo cual es genial.

Si evitamos las ramas, evitamos la incertidumbre de si la rama está tomada o no. Entonces

parece que esa predicación es el camino a seguir. No tan rapido. Procesar un montón de
instrucciones que en realidad están desactivadas no es un uso eficiente de un procesador.

De regreso a nuestra línea de ensamblaje, el tercer trabajador verificará el predicado. Si no

se mantiene, la instrucción actual recibirá una etiqueta de NO HACER NADA, pero a
diferencia de una rama, no notifica al primer trabajador.

Así que termina, como de costumbre, que ningún enfoque es perfecto por sí solo.

Predicación en ARM
En ARM, la predicación es muy simple de usar: casi todas las instrucciones se pueden
predicar. El predicado se especifica como sufijo del nombre de la instrucción. El sufijo es
exactamente el mismo que los utilizados en las ramas en el capítulo
5: eq, neq, le, lt, gey gt. Instrucciones que no se predican se supone que tienen un sufijo alde
pie para AL maneras . Ese predicado siempre es válido y no lo escribimos por economía
(aunque es válido). Puede entender las ramas condicionales como ramas predicadas si lo
desea.

Conjetura de Collatz revisada

En el capítulo 6 implementamos un algoritmo que calculó la longitud de la secuencia de
granizo de un número dado. Aunque aún no se ha probado, no se ha encontrado ningún
número que tenga una secuencia infinita de granizo. Dado nuestro conocimiento de las
funciones que aprendimos en los capítulos 9 y 10, encapsulé el código que calcula la
longitud de la secuencia de Hailstone en una función.

1/* -- collatz02.s */
[Link]
3
4message: .asciz "Type a number: "
5scan_format : .asciz "%d"
6message2: .asciz "Length of the Hailstone sequence for %d is %d\n"
7
 [Link]
9
10collatz:
11 /* r0 contains the first argument */
12 /* Only r0, r1 and r2 are modified,
13 so we do not need to keep anything
14 in the stack */
15 /* Since we do not do any call, we do
16 not have to keep lr either */
17 mov r1, r0 /* r1 ← r0 */
18 mov r0, #0 /* r0 ← 0 */
19 collatz_loop:
20 cmp r1, #1 /* compare r1 and 1 */
21 beq collatz_end /* if r1 == 1 branch to collatz_end */
22 and r2, r1, #1 /* r2 ← r1 & 1 */
23 cmp r2, #0 /* compare r2 and 0 */
24 bne collatz_odd /* if r2 != 0 (this is r1 % 2 != 0) branch to collatz_odd */
25 collatz_even:
26 mov r1, r1, ASR #1 /* r1 ← r1 >> 1. This is r1 ← r1/2 */
27 b collatz_end_loop /* branch to collatz_end_loop */
28 collatz_odd:
29 add r1, r1, r1, LSL #1 /* r1 ← r1 + (r1 << 1). This is r1 ← 3*r1 */
30 add r1, r1, #1 /* r1 ← r1 + 1. */
31 collatz_end_loop:
32 add r0, r0, #1 /* r0 ← r0 + 1 */
33 b collatz_loop /* branch back to collatz_loop */
34 collatz_end:
35 bx lr
36
[Link] main
38main:
39 push {lr} /* keep lr */
40 sub sp, sp, #4 /* make room for 4 bytes in the stack */
41 /* The stack is already 8 byte aligned */
42
43 ldr r0, address_of_message /* first parameter of printf: &message */
44 bl printf /* call printf */
45
46 ldr r0, address_of_scan_format /* first parameter of scanf: &scan_format */
47 mov r1, sp /* second parameter of scanf:
48 address of the top of the stack */
49 bl scanf /* call scanf */
50
 51 ldr r0, [sp] /* first parameter of collatz:
52 the value stored (by scanf) in the top of the stack */
53 bl collatz /* call collatz */
54
55 mov r2, r0 /* third parameter of printf:
56 the result of collatz */
57 ldr r1, [sp] /* second parameter of printf:
58 the value stored (by scanf) in the top of the stack */
59 ldr r0, address_of_message2 /* first parameter of printf: &address_of_message2 */
60 bl printf
61
62 add sp, sp, #4
63 pop {lr}
64 bx lr
65
66
67address_of_message: .word message
68address_of_scan_format: .word scan_format
69address_of_message2: .word message2

Agregar predicación
Ok, agreguemos un poco de predicación. Hay una construcción if-then-else en las líneas 22
a 31. Allí verificamos si el número es par o impar. Si incluso lo dividimos por 2, si incluso
lo multiplicamos por 3 y sumamos 1.

22 and r2, r1, #1 /* r2 ← r1 & 1 */

23 cmp r2, #0 /* compare r2 and 0 */
24 bne collatz_odd /* if r2 != 0 (this is r1 % 2 != 0) branch to collatz_odd */
25 collatz_even:
26 mov r1, r1, ASR #1 /* r1 ← r1 >> 1. This is r1 ← r1/2 */
27 b collatz_end_loop /* branch to collatz_end_loop */
28 collatz_odd:
29 add r1, r1, r1, LSL #1 /* r1 ← r1 + (r1 << 1). This is r1 ← 3*r1 */
30 add r1, r1, #1 /* r1 ← r1 + 1. */
31 collatz_end_loop:

Nota en la línea 24 que hay una bne( b rancho si n ot e Qual). Podemos usar esta condición

(y su opuesta eq) para predicar esta construcción if-then-else . Las instrucciones en
la parte then se predicarán usando eq, las instrucciones en la parte else se predicarán
usando ne. El código resultante se muestra a continuación.
cmp r2, #0 /* compare r2 and 0 */
 moveq r1, r1, ASR #1 /* if r2 == 0, r1 ← r1 >> 1. This is r1 ← r1/2 */
addne r1, r1, r1, LSL #1 /* if r2 != 0, r1 ← r1 + (r1 << 1). This is r1 ← 3*r1 */
addne r1, r1, #1 /* if r2 != 0, r1 ← r1 + 1. */
Como puede ver, no hay etiquetas en la versión predicada. No nos ramificamos ahora, por
lo que ya no son necesarios. Tenga en cuenta también que en realidad eliminamos dos
ramas: la que se ramifica desde el código de prueba de condición a la parte else y la que se
ramifica desde el final de la parte then hasta la instrucción después de todo el if-then-
else . Esto conduce a un código más compacto.

¿Hace alguna diferencia en el rendimiento?

Tomado como está, este programa es muy pequeño para ser responsable del tiempo, así que
lo modifiqué para ejecutar el mismo cálculo dentro de la función collatz 4194304 (esto es
2 22 ) veces. Elegí el número después de algunas pruebas, por lo que la ejecución no tardó
demasiado en ser un tedio.

Lamentablemente, aunque el procesador Raspberry Pi proporciona algunos contadores de

rendimiento de hardware, no he podido usar ninguno de ellos. perfLa herramienta (del
paquete linux-tools-3.2) se queja de que no se puede abrir el contador.
$ perf_3.2 stat -e cpu-cycles ./collatz02
Error: open_counter returned with 19 (No such device). /bin/dmesg may provide additional information.

Fatal: Not all events could be opened

dmesgno proporciona ninguna información adicional. Sin embargo, podemos ver que el
kernel cargó los contadores de rendimiento.
$ dmesg | grep perf
[ 0.061722] hw perfevents: enabled with v6 PMU driver, 3 counters available
Supuestamente debería poder medir hasta 3 eventos de hardware al mismo tiempo. Creo
que el procesador Raspberry Pi, incluido en el BCM2835 SoC, no proporciona una PMU
(unidad de supervisión del rendimiento) que se requiere para los contadores de
rendimiento. No obstante podemos utilizar cpu-clockpara medir el tiempo.

A continuación se muestran las versiones que utilicé para esta comparación. Primero está la
versión de las ramas, segundo la versión de la predicación.

1collatz:
2 /* r0 contains the first argument */
3 push {r4}
4 sub sp, sp, #4 /* Make sure the stack is 8 byte aligned */
5 mov r4, r0
6 mov r3, #4194304
7 collatz_repeat:
8 mov r1, r4 /* r1 ← r0 */
9 mov r0, #0 /* r0 ← 0 */
10 collatz_loop:
11 cmp r1, #1 /* compare r1 and 1 */
12 beq collatz_end /* if r1 == 1 branch to collatz_end */
13 and r2, r1, #1 /* r2 ← r1 & 1 */
14 cmp r2, #0 /* compare r2 and 0 */
15 bne collatz_odd /* if r2 != 0 (this is r1 % 2 != 0) branch to collatz_odd */
16 collatz_even:
17 mov r1, r1, ASR #1 /* r1 ← r1 >> 1. This is r1 ← r1/2 */
18 b collatz_end_loop /* branch to collatz_end_loop */
19 collatz_odd:
20 add r1, r1, r1, LSL #1 /* r1 ← r1 + (r1 << 1). This is r1 ← 3*r1 */
21 add r1, r1, #1 /* r1 ← r1 + 1. */
22 collatz_end_loop:
23 add r0, r0, #1 /* r0 ← r0 + 1 */
24 b collatz_loop /* branch back to collatz_loop */
25 collatz_end:
26 sub r3, r3, #1
27 cmp r3, #0
28 bne collatz_repeat
29 add sp, sp, #4 /* Make sure the stack is 8 byte aligned */
30 pop {r4}
31 bx lr

1collatz2:
2 /* r0 contains the first argument */
3 push {r4}
4 sub sp, sp, #4 /* Make sure the stack is 8 byte aligned */
5 mov r4, r0
6 mov r3, #4194304
7 collatz_repeat:
8 mov r1, r4 /* r1 ← r0 */
9 mov r0, #0 /* r0 ← 0 */
10 collatz2_loop:
11 cmp r1, #1 /* compare r1 and 1 */
12 beq collatz2_end /* if r1 == 1 branch to collatz2_end */
13 and r2, r1, #1 /* r2 ← r1 & 1 */
14 cmp r2, #0 /* compare r2 and 0 */
15 moveq r1, r1, ASR #1 /* if r2 == 0, r1 ← r1 >> 1. This is r1 ← r1/2 */
16 addne r1, r1, r1, LSL #1 /* if r2 != 0, r1 ← r1 + (r1 << 1). This is r1 ← 3*r1 */
17 addne r1, r1, #1 /* if r2 != 0, r1 ← r1 + 1. */
18 collatz2_end_loop:
19 add r0, r0, #1 /* r0 ← r0 + 1 */
20 b collatz2_loop /* branch back to collatz2_loop */
 21 collatz2_end:
22 sub r3, r3, #1
23 cmp r3, #0
24 bne collatz_repeat
25 add sp, sp, #4 /* Restore the stack */
26 pop {r4}
27 bx lr

La herramienta perfse puede utilizar para recopilar contadores de rendimiento. Ejecutaremos

5 veces cada versión. Usaremos el número 123. Redirigimos la salida de yes 123a la entrada
estándar de nuestro programa probado. De esta forma no tenemos que escribirlo (lo que
puede afectar el tiempo de la comparación).

La versión con ramas da los siguientes resultados:

$ yes 123 | perf_3.2 stat --log-fd=3 --repeat=5 -e cpu-clock ./collatz_branches 3>&1
Type a number: Length of the Hailstone sequence for 123 is 46
Type a number: Length of the Hailstone sequence for 123 is 46
Type a number: Length of the Hailstone sequence for 123 is 46
Type a number: Length of the Hailstone sequence for 123 is 46
Type a number: Length of the Hailstone sequence for 123 is 46

Performance counter stats for './collatz_branches' (5 runs):

3359,953200 cpu-clock ( +- 0,01% )

3,365263737 seconds time elapsed ( +- 0,01% )

(Al redirigir la entrada de perfuno debe especificar el descriptor de archivo para la salida
de perf statsí mismo. En este caso, hemos utilizado el descriptor de archivo número 3 y luego
le hemos dicho al shell que redirija el descriptor de archivo número 3 a la salida estándar,
que es el archivo. descriptor número 1).
$ yes 123 | perf_3.2 stat --log-fd=3 --repeat=5 -e cpu-clock ./collatz_predication 3>&1
Type a number: Length of the Hailstone sequence for 123 is 46
Type a number: Length of the Hailstone sequence for 123 is 46
Type a number: Length of the Hailstone sequence for 123 is 46
Type a number: Length of the Hailstone sequence for 123 is 46
Type a number: Length of the Hailstone sequence for 123 is 46

Performance counter stats for './collatz_predication' (5 runs):

2318,217200 cpu-clock ( +- 0,01% )

2,322732232 seconds time elapsed ( +- 0,01% )

Entonces la respuesta es sí. En este caso sí marca la diferencia. La versión predicada se
ejecuta 1,44 veces más rápido que la versión que usa ramas. Sin embargo, sería audaz
asumir que, en general, la predicación supera a las ramas. Mide siempre tu tiempo.
Ensamblador ARM en Raspberry Pi
- Capítulo 12
28 de marzo de 2013• Roger Ferrer Ibáñez • Raspberry Pi • brazo , ensamblador , pi , frambuesa

En el capítulo 6 vimos algunos esquemas simples para implementar construcciones de

programación estructuradas habituales como if-then-else y bucles. En este capítulo
revisaremos estas construcciones y aprovecharemos una característica del conjunto de
instrucciones ARM que aún no hemos aprendido.

Jugando con bucles

La forma más genérica de bucle es esta.
while (E)
S;
También hay dos formas especiales, que en realidad son encarnaciones particulares de la
que se muestra arriba, pero también son interesantes.
for (i = lower; i <= upper; i += step)
S;
do
S
while (E);
Algunos lenguajes, como Pascal, tienen construcciones como esta.
repeat
S
until E;
pero esto es como un do S while (!E).

Podemos manipular bucles para obtener una forma que sea más conveniente. Por ejemplo.
do
S
while (E);

/* Can be rewritten as */

S;
while (E)
S;
while (E)
S;

/* Can be rewritten as */

if (E)
 {
do
S
while (E);
}
La última manipulación es interesante, porque podemos evitar la if-thensi vamos
directamente a la whilepieza.
/* This is not valid C */
goto check;
do
S
check: while (E);
En C válido, la transformación anterior se escribiría de la siguiente manera.
goto check;
loop:
S;
check:
if (E) goto loop;
Lo que parece mucho más feo que abusar de un poco de sintaxis C.

El sufijo -s
Hasta ahora, al verificar la condición de un ifo while, hemos evaluado la condición y luego
usamos la cmpinstrucción para actualizar cpsr. La actualización de cpsres obligatoria para
nuestros códigos condicionales, sin importar si usamos ramificación o
predicación. Pero cmpno es la única forma de actualizar cpsr. De hecho, muchas
instrucciones pueden actualizarlo.

Por defecto, una instrucción no se actualiza a cpsrmenos que agreguemos el sufijo -

s. Entonces, en lugar de la instrucción addo subescribimos addso subs. El resultado de la
instrucción (lo que se almacenaría en el registro de destino) se usa para actualizar cpsr.

¿Cómo podemos usar esto? Bueno, considere este simple ciclo contando hacia atrás.
/* for (int i = 100 ; i >= 0; i--) */
mov r1, #100
loop:
/* do something */
sub r1, r1, #1 /* r1 ← r1 - 1 */
cmp r1, #0 /* update cpsr with r1 - 0 */
bge loop /* branch if r1 >= 100 */
Si reemplazamos subpor subsentonces cpsrse actualizará con el resultado de la
sustracción. Esto significa que las banderas N, Z, C y V se actualizarán, por lo que
podemos usar una rama inmediatamente después subs. En nuestro caso, queremos volver al
bucle solo si i >= 0, aquí es cuando el resultado no es negativo. Podemos utilizar bplpara
lograr esto.
/* for (int i = 100 ; i >= 0; i--) */
mov r1, #100
loop:
/* do something */
subs r1, r1, #1 /* r1 ← r1 - 1 and update cpsr with the final r1 */
bpl loop /* branch if the previous sub computed a positive number (N flag in cpsr is 0) */
Es un poco complicado hacer estas cosas bien (es por eso que usamos compiladores). Por
ejemplo, este bucle similar, pero no idéntico, usaría en bnelugar de bpl. Aquí la condición
es ne(no igual). Sería bueno tener un alias como nz(no cero) pero, desafortunadamente, esto
no existe en ARM.
/* for (int i = 100 ; i > 0; i--). Note here i > 0, not i >= 0 as in the example above */
mov r1, #100
loop:
/* do something */
subs r1, r1, #1 /* r1 ← r1 - 1 and update cpsr with the final r1 */
bne loop /* branch if the previous sub computed a number that is not zero (Z flag in cpsr is 0) */
Una regla general en la que es posible que deseemos aplicar el uso del sufijo -s es en los
códigos de la siguiente forma.
s = ...
if (s @ 0)
donde @significa cualquier comparación con respecto a 0 (igual, diferente, menor, etc.).

Operación de números de 64 bits

Como ejemplo del uso del sufijo -s, implementaremos tres operaciones enteras de 64 bits en
ARM: suma, resta y multiplicación. Recuerde que ARM es una arquitectura de 32 bits, por
lo que todo tiene una mentalidad de 32 bits. Si solo usamos números de 32 bits, esto no es
un problema, pero si por alguna razón necesitamos números de 64 bits, las cosas se
complican un poco más. Representaremos un número de 64 bits como dos números de 32
bits, la parte inferior y la superior. De esta manera, un número n de 64 bits representado
usando dos partes de 32 bits, n menor yn mayor , tendrá el valor n = 2 32 × n mayor + n menor

Obviamente, necesitaremos mantener los 32 bits en alguna parte. Al mantenerlos en

registros, usaremos dos registros consecutivos (por ejemplo, r1 y r2, como los
escribiremos {r1,r2}) y mantendremos la parte más alta en el registro numerado más alto. Al
mantener un número de 64 bits en memoria, almacenaremos en dos direcciones
consecutivas las dos partes, siendo la inferior en la dirección inferior. La dirección estará
alineada con 8 bytes.

Adición
Agregar dos números de 64 bits usando operandos de 32 bits significa agregar primero la
parte inferior y luego agregar las partes superiores, pero teniendo en cuenta un posible
arrastre desde la parte inferior. Con nuestro conocimiento actual, podríamos escribir algo
como esto (suponga que el primer número está adentro {r2,r3}, el segundo adentro {r4,r5}y el
resultado estará adentro {r0,r1}).
add r1, r3, r5 /* First we add the higher part */
 /* r1 ← r3 + r5 */
adds r0, r2, r4 /* Now we add the lower part and we update cpsr */
/* r0 ← r2 + r4 */
addcs r1, r1, #1 /* If adding the lower part caused carry, add 1 to the higher part */
/* if C = 1 then r1 ← r1 + 1 */
/* Note that here the suffix -s is not applied, -cs means carry set */
Esto funcionaría. Afortunadamente, ARM proporciona instrucciones adcque suman dos
números y la bandera de acarreo. Entonces podríamos reescribir el código anterior con solo
dos instrucciones.
adds r0, r2, r4 /* First add the lower part and update cpsr */
/* r0 ← r2 + r4 */
adc r1, r3, r5 /* Now add the higher part plus the carry from the lower one */
/* r1 ← r3 + r5 + C */

Sustracción
Restar dos números es similar a sumarlos. En ARM, al restar dos números usando subs, si
necesitamos pedir prestado (porque el segundo operando es más grande que el primero), C
se desactivará (C será 0). Si no necesitamos pedir prestado, se habilitará C (C será 1). Esto
es un poco sorprendente pero coherente con el resto de la arquitectura (consulte las
condiciones CS / HS y CC / LO del capítulo 5). Similar a adchay a sbcque realiza una resta
normal si C es 1. De lo contrario, resta un elemento más. Nuevamente, esto es coherente
con el funcionamiento de C en la subsinstrucción.
subs r0, r2, r4 /* First subtract the lower part and update cpsr */
/* r0 ← r2 - r4 */
sbc r1, r3, r5 /* Now subtract the higher part plus the NOT of the carry from the lower one */
/* r1 ← r3 - r5 - ~C */

Multiplicación
Multiplicar dos números de 64 bits es complicado. Cuando multiplicamos dos números de
N bits, el resultado puede necesitar hasta 2 * N bits. Entonces, al multiplicar dos números
de 64 bits, es posible que necesitemos un número de 128 bits. En aras de la simplicidad,
asumiremos que esto no sucede y que 64 bits serán suficientes. Nuestros números de 64 bits
son dos enteros de 32 bits, por lo que una x de 64 bits es en realidad x = 2 32 × x 1 + x 0 ,
donde x 1 y x 0 son dos números de 32 bits. De manera similar, otro número y de 64 bits
sería y = 2 32 × y 1 + y 0 . Al multiplicar xey se obtiene z donde z = 2 64 × x 1 × y 1 + 2 32×
(x 0 × y 1 + x 1 × y 0 ) + x 0 × y 0 . Bueno, ahora nuestro problema es multiplicar cada x i por
y i , pero nuevamente es posible que necesitemos 64 bits para representar el valor.

ARM proporciona un montón de instrucciones diferentes para la multiplicación. Hoy

veremos solo tres de ellos. Si estamos multiplicando 32 bits y no nos importa que el
resultado no encaje en un número de 32 bits, podemos usarlo mul Rd, Rsource1,
Rsource2. Desafortunadamente, no establece ningún indicador cpsrútil para detectar un
desbordamiento de la multiplicación (es decir, cuando el resultado no se ajusta al rango de
32 bits). Esta instrucción es la más rápida de las tres. Si queremos el resultado de la
multiplicación de 64 bits, tenemos otras dos instrucciones smully umull. El primero se usa
cuando multiplicamos a números en complemento a dos, el segundo cuando representamos
valores sin signo. Su sintaxis es {s,u}mull RdestLower, RdestHigher, Rsource1, Rsource2. La parte
inferior del resultado de 64 bits se mantiene en el registro RdestLowery la parte superior en el
registro RdestHigher.

En este ejemplo tenemos que usar, de lo umullcontrario, las partes inferiores de 32 bits
podrían terminar interpretándose como números negativos, dando valores intermedios
negativos. Dicho esto, ahora podemos multiplicar x 0 e y 0 . Recuerde que tenemos los dos
números de 64 bits r2,r3y r4,r5pares de registros. Así que primero multiplica r2y r4. Tenga en
cuenta el uso de r0ya que este será su valor final. Por el contrario, el registro r6se utilizará
más tarde.
umull r0, r6, r2, r4
Ahora multipliquemos x 0 por y 1 y x 1 por y 0 . Esto es r3por r4y r2por r5. Observe cómo
sobrescribimos r4y r5en la segunda multiplicación. Esto está bien, ya que ya no los
necesitaremos.
umull r7, r8, r3, r4
umull r4, r5, r2, r5
No es necesario multiplicar x 1 por y 1 porque si da un valor distinto de cero, siempre
desbordará un número de 64 bits. Esto significa que si ambos r3y r5fueran distintos de cero,
la multiplicación nunca se ajustará a 64 bits. Ésta es una condición suficiente, pero no
necesaria. El número puede desbordarse al agregar los valores intermedios que
resultarán r1.
adds r2, r7, r4
adc r1, r2, r6
Empaquetemos este código en una función agradable en un programa para ver si
funciona. Multiplicaremos los números 12345678901 (esto es 2 × 2 32 + 3755744309) y
12345678 e imprimiremos el resultado.

1/* -- mult64.s */
[Link]
3
[Link] 4
5message : .asciz "Multiplication of %lld by %lld is %lld\n"
6
[Link] 8
8number_a_low: .word 3755744309
9number_a_high: .word 2
10
[Link] 8
12number_b_low: .word 12345678
13number_b_high: .word 0
14
[Link]
16
17/* Note: This is not the most efficient way to doa 64-bit multiplication.
18 This is for illustration purposes */
19mult64:
20 /* The argument will be passed in r0, r1 and r2, r3 and returned in r0, r1 */
21 /* Keep the registers that we are going to write */
22 push {r4, r5, r6, r7, r8, lr}
23 /* For covenience, move {r0,r1} into {r4,r5} */
24 mov r4, r0 /* r0 ← r4 */
25 mov r5, r1 /* r5 ← r1 */
26
27 umull r0, r6, r2, r4 /* {r0,r6} ← r2 * r4 */
28 umull r7, r8, r3, r4 /* {r7,r8} ← r3 * r4 */
29 umull r4, r5, r2, r5 /* {r4,r5} ← r2 * r5 */
30 adds r2, r7, r4 /* r2 ← r7 + r4 and update cpsr */
31 adc r1, r2, r6 /* r1 ← r2 + r6 + C */
32
33 /* Restore registers */
34 pop {r4, r5, r6, r7, r8, lr}
35 bx lr /* Leave mult64 */
36
[Link] main
38main:
39 push {r4, r5, r6, r7, r8, lr} /* Keep the registers we are going to modify */
40 /* r8 is not actually used here, but this way
41 the stack is already 8-byte aligned */
42 /* Load the numbers from memory */
43 /* {r4,r5} ← a */
44 ldr r4, addr_number_a_low /* r4 ← &a_low */
45 ldr r4, [r4] /* r4 ← *r4 */
46 ldr r5, addr_number_a_high /* r5 ← &a_high */
47 ldr r5, [r5] /* r5 ← *r5 */
48
49 /* {r6,r7} ← b */
50 ldr r6, addr_number_b_low /* r6 ← &b_low */
51 ldr r6, [r6] /* r6 ← *r6 */
52 ldr r7, addr_number_b_high /* r7 ← &b_high */
53 ldr r7, [r7] /* r7 ← *r7 */
54
55 /* Now prepare the call to mult64
56 /*
57 The first number is passed in
58 registers {r0,r1} and the second one in {r2,r3}
59 */
60 mov r0, r4 /* r0 ← r4 */
 61 mov r1, r5 /* r1 ← r5 */
62
63 mov r2, r6 /* r2 ← r6 */
64 mov r3, r7 /* r3 ← r7 */
65
66 bl mult64 /* call mult64 function */
67 /* The result of the multiplication is in r0,r1 */
68
69 /* Now prepare the call to printf */
70 /* We have to pass &message, {r4,r5}, {r6,r7} and {r0,r1} */
71 push {r1} /* Push r1 onto the stack. 4th (higher) parameter */
72 push {r0} /* Push r0 onto the stack. 4th (lower) parameter */
73 push {r7} /* Push r7 onto the stack. 3rd (higher) parameter */
74 push {r6} /* Push r6 onto the stack. 3rd (lower) parameter */
75 mov r3, r5 /* r3 ← r5. 2rd (higher) parameter */
76 mov r2, r4 /* r2 ← r4. 2nd (lower) parameter */
77 ldr r0, addr_of_message /* r0 ← &message 1st parameter */
78 bl printf /* Call printf */
79 add sp, sp, #16 /* sp ← sp + 16 */
80 /* Pop the two registers we pushed above */
81
82 mov r0, #0 /* r0 ← 0 */
83 pop {r4, r5, r6, r7, r8, lr} /* Restore the registers we kept */
84 bx lr /* Leave main */
85
86addr_of_message : .word message
87addr_number_a_low: .word number_a_low
88addr_number_a_high: .word number_a_high
89addr_number_b_low: .word number_b_low
90addr_number_b_high: .word number_b_high

Observe primero que tenemos las direcciones de la parte inferior y superior de cada
número. En lugar de esto, podríamos cargarlos simplemente usando un desplazamiento,
como vimos en el capítulo 8. Entonces, en las líneas 41 a 44 podríamos haber hecho lo
siguiente.

40 /* {r4,r5} ← a */
41 ldr r4, addr_number_a_low /* r4 ← &a_low */
42 ldr r5, [r4, +#4] /* r5 ← *(r4 + 4) */
43 ldr r4, [r4] /* r4 ← *r4 */
En la función mult64pasamos el primer valor (x) como r0,r1y el segundo valor (y)
como r2,r3. El resultado se almacena en formato r0,r1. Movemos los valores a los registros
apropiados para el paso de parámetros en las líneas 57 a 61.

Imprimir el resultado es un poco complicado. Los 64 bits deben pasarse como pares de

registros consecutivos donde la parte inferior está en un registro de número par. Dado que
pasamos la dirección del mensaje, r0no podemos pasar el primer entero de 64 bits r1. Así
que saltamos r1y usamos r2y r3para el primer argumento. Pero ahora nos hemos quedado sin
registros para pasar parámetros. Cuando esto sucede, tenemos que usar la pila para pasar
parámetros.

Deben tenerse en cuenta dos reglas al pasar datos en la pila.

1. Debe asegurarse de que la pila esté alineada para los datos que va a pasar (ajustando la
pila primero). Entonces, para números de 64 bits, la pila debe estar alineada con 8
bytes. Si pasa un número de 32 bits y luego un número de 64 bits, tendrá que omitir 4
bytes antes de pasar el número de 64 bits. No olvide mantener la pila siempre alineada
en 8 bytes según el requisito del estándar de llamada a procedimiento para arquitectura
ARM (AAPCS).
2. Un argumento con un número de posición más bajo en la llamada debe tener una
dirección más baja en la pila. Entonces tenemos que pasar los argumentos en orden
opuesto.

La segunda regla es la que explica por qué presionamos primero r1y luego r0, cuando son
los registros que contienen el último número de 64 bits (el resultado de la multiplicación) al
que queremos pasar printf.

Tenga en cuenta que en el ejemplo anterior, no podemos pasar los parámetros en la pila
usando push {r0,r1,r6,r7}, que es equivalente a push {r0}, push {r1}, push {r6}y push {r7}, pero no
es equivalente a la orden requerido al pasar los argumentos en la pila.

Si ejecutamos el programa, deberíamos ver algo como.

$ ./mult64_2
Multiplication of 12345678901 by 12345678 is 152415776403139878

Ensamblador ARM en Raspberry Pi

- Capítulo 13
12 de mayo de 2013• Roger Ferrer Ibáñez • Raspberry Pi

Hasta ahora, todos los ejemplos se han ocupado de valores enteros. Pero los procesadores
serían bastante limitados si solo pudieran trabajar con valores enteros. Afortunadamente,
pueden trabajar con números de coma flotante. En este capítulo veremos cómo podemos
utilizar las instalaciones de punto flotante de nuestra Raspberry Pi.
Números de punto flotante
A continuación se muestra un resumen rápido de lo que es un número de punto flotante.

Un número de coma flotante binario es una representación aproximada de un número real

con tres partes: signo , mantisa y exponente . El signo puede ser solo 0 o 1, lo que significa
que 1 es un número negativo, de lo contrario positivo. La mantisa representa una magnitud
fraccionaria. De manera similar a 1.2345, podemos tener un binario 1.01110donde cada
dígito es solo un bit. El punto significa donde termina la parte entera y comienza la parte
fraccionaria. Tenga en cuenta que no hay nada especial en los números fraccionarios
binarios: 1.01110es sólo 2 0 + 2 -2 + 2 -3 + 2 -4 = 1,43750 (10. Por lo general, los números están
normalizados, esto significa que la mantisa se ajusta para que la parte entera sea siempre 1,
por lo que en lugar de 0.00110101 representaríamos 1.101101 (de hecho, un punto flotante
puede ser una desnormal si esta propiedad no se cumple, pero tales números se encuentran
en un rango muy específico para que podamos ignorarlos aquí). Si la mantisa se ajusta para
que siempre tenga un solo 1 como la parte entera dos, suceden cosas. Primero, no
representamos la parte entera (ya que siempre es 1 en números normalizados). En segundo
lugar, para que las cosas suenen necesitamos un exponenteque compensa la normalización
de la mantisa. Esto significa que el número -101.110111 (recuerda que es un número real
binario) estará representado por un signo = 1, mantisa = 1.01110111 y exponente = 2
(porque movimos el punto 2 dígitos a la izquierda). De manera similar, el número
0.0010110111 se representa con un signo = 0, mantisa = 1.0110111 y exponente = -3
(movimos el punto 3 dígitos a la derecha).

Para que diferentes computadoras puedan compartir números de punto flotante, IEEE 754
estandariza el formato de un número de punto flotante. VFPv2 admite dos de los números
IEEE 754: Binary32 y Binary64, generalmente conocidos por sus tipos C floaty double, o por
precisión simple y doble, respectivamente. En un punto flotante de precisión simple, la
mantisa es de 23 bits (+1 del entero para números normalizados) y el exponente es de 8 bits
(por lo que el exponente varía de -126 a 127). En un punto flotante de doble precisiónla
mantisa es de 52 bits (+1) y el exponente es de 11 bits (por lo que el exponente varía de
-1022 a 1023). Un número de coma flotante de precisión simple ocupa 32 bits y un número
de coma flotante de precisión doble ocupa 64 bits. La operación de números de doble
precisión es, en promedio, una y media o dos veces más lenta que la de precisión simple.

El famoso artículo de Goldberg es una referencia clásica que cualquier persona seria
debería leer cuando utilice números de coma flotante.

Coprocesadores
Como dije varias veces en capítulos anteriores, ARM fue diseñado para ser muy
flexible. Podemos ver esto en el hecho de que la arquitectura ARM proporciona una
interfaz de coprocesador genérica. Los fabricantes de sistemas en chips pueden agrupar
coprocesadores adicionales. Cada coprocesador se identifica con un número y proporciona
instrucciones específicas. Por ejemplo, el Raspberry Pi SoC es un BCM2835 que
proporciona un coprocesador multimedia (que no discutiremos aquí).
Dicho esto, hay dos coprocesadores estándar en la arquitectura ARMv6: 10 y 11. Estos dos
coprocesadores brindan soporte de punto flotante para precisión simple y doble,
respectivamente. Aunque las instrucciones de punto flotante tienen sus propios nombres
específicos, en realidad se asignan a instrucciones de coprocesador genéricas dirigidas al
coprocesador 10 y 11.

Vector de punto flotante v2

ARMv6 define una subarquitectura de punto flotante llamada Vector Floating-point v2
(VFPv2). Versión 2 porque las arquitecturas ARM anteriores admitían una forma más
simple llamada ahora v1. Como se indicó anteriormente, el VFP se implementa sobre dos
coprocesadores estandarizados 10 y 11. ARMv6 no requiere que VFPv2 se implemente en
hardware (siempre se puede recurrir a una implementación de software más
lenta). Afortunadamente, Raspberry Pi proporciona una implementación de hardware de
VFPv2.

Registros VFPv2
Ya sabemos que la arquitectura ARM proporciona 16 registros de propósito general, r0a r15,
donde algunos de ellos desempeñan papeles especiales: r13, r14y r15. A pesar de su nombre,
estos registros de propósito general no permiten operar números de punto flotante en ellos,
por lo que VFPv2 nos proporciona algunos registros específicos. Estos registros se
nombran s0para s31, para precisión simple y d0para d15para precisión doble. Estos no son 48
registros diferentes. En su lugar, cada se asigna a dos registros (consecutivos) y , donde 0
≤ ≤ 15. dns2ns2n+1n

Estos registros están estructurados en 4

bancos: s0- s7( d0- d3), s8- s15( d4- d7), s16- s23( d8- d11) y s24- s31( d12- d15). Al primer banco
(banco 0, s0- s7, d0- d3) lo llamaremos banco escalar , mientras que los tres restantes
son bancos vectoriales (a continuación veremos por qué).
VFPv2 proporciona tres registros de control, pero solo nos interesará uno
llamado fpscr. Este registro es similar a la cpsrya que mantiene las banderas de comparación
habituales N, Z, Cy V. También almacena dos campos que son muy útiles leny stride. Estos
dos campos controlan cómo se comportan las instrucciones de punto flotante. No nos
importa mucho la información restante en este registro: información de estado de las
excepciones de coma flotante, el modo de redondeo actual y si los números desnormales se
vacían a cero.

Operaciones aritmeticas
La mayoría de las instrucciones de VFPv2 tienen el formato o . Tienen tres modos de
funcionamiento. vname Rdest, Rsource1, Rsource2fname Rdest, Rsource1

 Escalar. Este modo se utiliza cuando el registro de destino está en el banco 0

( s0- s7o d0- d3). En este caso, la instrucción opera solo
con Rsource1y Rsource2. No hay otros registros involucrados.
 Vectorial. Este modo se usa cuando el registro de destino y Rsource2 (o
Rsource1 para instrucciones con un solo registro de fuente) no están en el
banco 0. En este caso, la instrucción operará tantos registros (comenzando
desde el registro dado en la instrucción y envolviendo el banco del registro)
como se define en el campo lendel fpscr(al menos 1). El siguiente registro
operado está definido por el stridecampo de fpscr(al menos 1). Si se produce un
reinicio, no se puede operar ninguna caja registradora dos veces.
  Escalar expandido (también llamado vector mixto / escalar ). Este modo se usa
si Rsource2 (o Rsource1 si la instrucción solo tiene un registro de fuente) está
en el banco0, pero el destino no. En este caso, Rsource2 (o Rsource1 para
instrucciones con una sola fuente) se deja fijo como fuente. Los registros
restantes se operan como en el caso vectorial (es decir,
usando leny stridedesde fpscr).

Ok, esto parece bastante complicado, así que veamos algunos ejemplos. La mayoría de las
instrucciones terminan en .f32si operan en precisión simple y en .f64si operan en precisión
doble. Podemos sumar dos números de precisión simple usando vadd.f32 Rdest, Rsource1,
Rsource2y doble precisión usando vadd.f64 Rdest, Rsource1, Rsource2. Tenga en cuenta también
que podemos usar la predicación en estas instrucciones (pero tenga en cuenta que, como de
costumbre, la predicación usa las banderas en cpsrno en fpscr). La predicación se
especificaría antes del sufijo como en vaddne.f32.
// For this example assume that len = 4, stride = 2
vadd.f32 s1, s2, s3 /* s1 ← s2 + s3. Scalar operation because Rdest = s1 in the bank 0 */
vadd.f32 s1, s8, s15 /* s1 ← s8 + s15. ditto */
vadd.f32 s8, s16, s24 /* s8 ← s16 + s24
s10 ← s18 + s26
s12 ← s20 + s28
s14 ← s22 + s30
or more compactly {s8,s10,s12,s14} ← {s16,s18,s20,s22} + {s24,s26,s28,s30}
Vectorial, since Rdest and Rsource2 are not in bank 0
*/
vadd.f32 s10, s16, s24 /* {s10,s12,s14,s8} ← {s16,s18,s20,s22} + {s24,s26,s28,s30}.
Vectorial, but note the wraparound inside the bank after s14.
*/
vadd.f32 s8, s16, s3 /* {s8,s10,s12,s14} ← {s16,s18,s20,s22} + {s3,s3,s3,s3}
Scalar expanded since Rsource2 is in the bank 0
*/

Cargar y almacenar
Una vez que tenemos una idea aproximada de cómo podemos operar puntos flotantes en
VFPv2, queda una pregunta: ¿cómo cargamos / almacenamos valores de punto flotante
desde / hacia la memoria? VFPv2 proporciona varias instrucciones específicas de carga /
almacenamiento.

Cargamos / almacenamos un punto flotante de precisión simple usando vldr/ vstr. La

dirección de la carga / almacenamiento ya debe estar en un registro de propósito general,
aunque podemos aplicar un desplazamiento en bytes que debe ser un múltiplo de 4 (esto
también se aplica a la precisión doble).
vldr s1, [r3] /* s1 ← *r3 */
vldr s2, [r3, #4] /* s2 ← *(r3 + 4) */
vldr s3, [r3, #8] /* s3 ← *(r3 + 8) */
vldr s4, [r3, #12] /* s4 ← *(r3 + 12) */

vstr s10, [r4] /* *r4 ← s10 */

vstr s11, [r4, #4] /* *(r4 + 4) ← s11 */
vstr s12, [r4, #8] /* *(r4 + 8) ← s12 */
vstr s13, [r4, #12] /* *(r4 + 12) ← s13 */
Podemos cargar / almacenar varios registros con una sola instrucción. A diferencia de la
carga / almacenamiento general, no podemos cargar un conjunto arbitrario de registros, sino
que deben ser un conjunto secuencial de registros.
// Here precision can be s or d for single-precision and double-precision
// floating-point-register-set is {sFirst-sLast} for single-precision
// and {dFirst-dLast} for double-precision
vldm indexing-mode precision Rbase{!}, floating-point-register-set
vstm indexing-mode precision Rbase{!}, floating-point-register-set
El comportamiento es similar a los modos de indexación que vimos en el capítulo 10. Hay
un registro Rbase usado como la dirección base de varios registros de carga /
almacenamiento hacia / desde registros de punto flotante. Solo hay dos modos de
indexación: incremento después y decremento antes. Cuando se usa incremento después, la
dirección utilizada para cargar / almacenar el registro de valor de punto flotante aumenta en
4 después de que se haya realizado la carga / almacenamiento. Cuando se usa decremento
antes, la dirección base primero se resta tantos bytes como valores de punto de inflado se
van a cargar / almacenar. Rbase siempre se actualiza en decremento antes, pero es opcional
actualizarlo en incrementos después.
vldmias r4, {s3-s8} /* s3 ← *r4
s4 ← *(r4 + 4)
s5 ← *(r4 + 8)
s6 ← *(r4 + 12)
s7 ← *(r4 + 16)
s8 ← *(r4 + 20)
*/
vldmias r4!, {s3-s8} /* Like the previous instruction
but at the end r4 ← r4 + 24
*/
vstmdbs r5!, {s12-s13} /* *(r5 - 4 * 2) ← s12
*(r5 - 4 * 1) ← s13
r5 ← r5 - 4*2
*/
Para las operaciones habituales de pila, cuando empujamos sobre la pila varios registros de
coma flotante usaremos vstmdbcon sp!como registro base. Para salir de la pila
usaremos vldmianuevamente con sp!como registro base. Dado que los nombres de estas
instrucciones son muy difíciles de recordar, podemos usar los mnemónicos vpushy vpop,
respectivamente.
vpush {s0-s5} /* Equivalent to vstmdb sp!, {s0-s5} */
vpop {s0-s5} /* Equivalent to vldmia sp!, {s0-s5} */

Movimientos entre registros

Otra operación que puede ser necesaria a veces es moverse entre registros. Similar a
la movinstrucción para registros de propósito general, existe la vmovinstrucción. Son
posibles varios movimientos.
Podemos mover valores de coma flotante entre dos registros de coma flotante de la misma
precisión
vmov s2, s3 /* s2 ← s3 */
Entre un registro de propósito general y un registro de precisión simple. Pero tenga en
cuenta que los datos no se convierten. Solo se copian bits, así que tenga cuidado de no
mezclar valores de punto flotante con instrucciones enteras o al revés.
vmov s2, r3 /* s2 ← r3 */
vmov r4, s5 /* r4 ← s5 */
Como el caso anterior pero entre dos registros de propósito general y dos registros
consecutivos de precisión simple.
vmov s2, s3, r4, r10 /* s2 ← r4
s3 ← r10 */
Entre dos registros de propósito general y un registro de doble precisión. Nuevamente,
tenga en cuenta que los datos no se convierten.
vmov d3, r4, r6 /* Lower32BitsOf(d3) ← r4
Higher32BitsOf(d3) ← r6
*/
vmov r5, r7, d4 /* r5 ← Lower32BitsOf(d4)
r7 ← Higher32BitsOf(d4)
*/

Conversiones
A veces necesitamos convertir de un número entero a un punto flotante y lo
contrario. Tenga en cuenta que algunas conversiones pueden perder precisión, en particular,
cuando un punto flotante se convierte en un número entero. Hay una sola
instrucción vcvtcon un sufijo .[Link] T(objetivo) y S(fuente) se
puede u32, s32, f32y f64( Sdeben ser diferentes a T). Ambos registros deben ser registros de
coma flotante, por lo que para convertir enteros a coma flotante o coma flotante a un valor
entero, un extravmovSe requerirá instrucción desde o hacia un registro entero antes o
después de la conversión. Debido a esto, por un momento (entre las dos instrucciones) un
registro de punto flotante contendrá un valor que no es un valor IEEE 754, téngalo en
cuenta.
vcvt.f64.f32 d0, s0 /* Converts s0 single-precision value
to a double-precision value and stores it in d0 */

vcvt.f32.f64 s0, d0 /* Converts d0 double-precision value

to a single-precision value and stores it in s0 */

vmov s0, r0 /* Bit copy from integer register r0 to s0 */

vcvt.f32.s32 s0, s0 /* Converts s0 signed integer value
to a single-precision value and stores it in s0 */

vmov s0, r0 /* Bit copy from integer register r0 to s0 */

vcvt.f32.u32 s0, s0 /* Converts s0 unsigned integer value
to a single-precision value and stores in s0 */
vmov s0, r0 /* Bit copy from integer register r0 to s0 */
vcvt.f64.s32 d0, s0 /* Converts r0 signed integer value
to a double-precision value and stores in d0 */

vmov s0, r0 /* Bit copy from integer register r0 to s0 */

vcvt.f64.u32 d0, s0 /* Converts s0 unsigned integer value
to a double-precision value and stores in d0 */

Modificar fpscr
El fpscr registro especial, donde leny stridese establecen, no se puede modificar
directamente. En su lugar, tenemos que cargar fpscr en un registro de propósito general
usando vmrsinstrucción. Luego operamos en el registro y lo volvemos a mover al fpscr,
usando la vmsrinstrucción.

El valor de lense almacena en los bits 16 a 18 de fpscr. El valor de lenno se almacena

directamente en estos bits. En cambio, tenemos que restar 1 antes de configurar los
bits. Esto se debe a lenque no puede ser 0 (no tiene sentido operar 0 puntos flotantes). De
esta manera, el valor 000en estos bits significa len= 1, 001significa len=
2, ..., 111significa len= 8. El siguiente es un código que se establece lenen 8.
/* Set the len field of fpscr to be 8 (bits: 111) */
mov r5, #7 /* r5 ← 7. 7 is 111 in binary */
mov r5, r5, LSL #16 /* r5 ← r5 << 16 */
vmrs r4, fpscr /* r4 ← fpscr */
orr r4, r4, r5 /* r4 ← r4 | r5. Bitwise OR */
vmsr fpscr, r4 /* fpscr ← r4 */
stridese almacena en los bits 20 a 21 de fpscr. Similar a len, un valor de 00en estos bits
significa stride= 1, 01significa stride= 2, 10significa stride= 3 y 11significa stride= 4.

Convención de llamada a función y registros

de punto flotante
Dado que hemos introducido nuevos registros, debemos indicar cómo usarlos al llamar a
funciones. Las siguientes reglas se aplican a los registros VFPv2.

 Los campos leny stridede fpscrtienen todos sus bits como cero a la entrada de una

función y esos bits deben ser cero al salir de ella.
 Podemos pasar parámetros de punto flotante usando
registros s0- s15y d0- d7. Tenga en cuenta que pasar una precisión doble después
de una precisión simple puede implicar descartar un registro de precisión
simple de número impar (por ejemplo, podemos usar s0, d1pero tenga en cuenta
que s1no se usará).
 Todos los demás registros de coma flotante ( s16- s31y d8- d15) deben conservar
sus valores al salir de la función. Instrucciones vpushy vpopse puede utilizar para
eso.
  Si una función devuelve un valor de punto flotante, el registro de retorno
será s0o d0.

Finalmente, una nota sobre funciones variadas como printf: no puede pasar un punto
flotante de precisión simple a una de estas funciones. Solo se pueden pasar dobles. Por lo
tanto, deberá convertir los valores de precisión simple en valores de precisión doble. Tenga
en cuenta también que se utilizan registros enteros habituales ( r0- r3), por lo que solo podrá
pasar hasta 2 valores de doble precisión, el resto debe pasarse a la pila. En particular
para printf, dado que r0contiene la dirección del formato de cadena, solo podrá pasar una
precisión doble en {r2,r3}.

Ensamblador
Asegúrese de pasar la bandera -mfpu=vfpv2a as, de lo contrario, no reconocerá las
instrucciones de VFPv2.

Colofón
Es posible que desee consultar esta tarjeta de referencia rápida oficial de VFP . Tenga en
cuenta que también incluye VFPv3 no disponible en el procesador Raspberry Pi. La mayor
parte de lo que hay allí ya se ha presentado aquí, aunque es posible que se hayan omitido
algunos detalles menores.

En el próximo capítulo usaremos estas instrucciones en un ejemplo completo.

Ensamblador ARM en Raspberry Pi

- Capítulo 14
12 de mayo de 2013• Roger Ferrer Ibáñez • Raspberry Pi

En el capítulo 13 vimos los elementos básicos de VFPv2, la subarquitectura de punto

flotante de ARMv6. En este capítulo implementaremos una multiplicación de matriz de
punto flotante usando VFPv2.

Descargo de responsabilidad : le desaconsejo el uso del código de este capítulo en

proyectos de grado comercial a menos que lo revise por completo para verificar su
exactitud y precisión.

Matriz multiplicar
Dados dos vectores v y w de rango r donde v = <v 0 , v 1 , ... v r-1 > y w = <w 0 , w 1 , ..., w r-
1 >, definimos el producto escalar de v por w como el escalar v · w = v 0 × w 0 + v 1 ×
w 1 + ... + v r-1 × w r-1 .
Podemos multiplicar una matriz Ade nfilas y mcolumnas ( nx m) por una matriz Bde mfilas
y pcolumnas ( mx p). El resultado es una matriz de nfilas y pcolumnas. La multiplicación de
matrices puede parecer complicada, pero en realidad no lo es. Cada elemento en la matriz
de resultados es solo el producto escalar (definido en el párrafo anterior) de la fila
correspondiente de la matriz Apor la columna correspondiente de la matriz B(es por eso que
debe haber tantas columnas Acomo filas B) .

Una implementación sencilla de la multiplicación de matrices en C es la siguiente.

1float A[N][M]; // N rows of M columns each row

2float B[M][P]; // M rows of P columns each row
3// Result
4float C[N][P];
5
6for (int i = 0; i < N; i++) // for each row of the result
7{
8 for (int j = 0; j < P; j++) // and for each column
9 {
 10 C[i][j] = 0; // Initialize to zero
11 // Now make the dot matrix of the row by the column
12 for (int k = 0; k < M; k++)
13 C[i][j] += A[i][k] * B[k][j];
14 }
15}

Para simplificar el ejemplo, asumiremos que ambas matrices A y B son matrices cuadradas
de tamaño n x n. Esto simplifica un poco el algoritmo.

1float A[N][N];
2float B[N][N];
3// Result
4float C[N][N];
5
6for (int i = 0; i < N; i++)
7{
8 for (int j = 0; j < N; j++)
9 {
10 C[i][j] = 0;
11 for (int k = 0; k < N; k++)
12 C[i][j] += A[i][k] * B[k][j];
13 }
14}

La multiplicación de matrices es una operación importante que se utiliza en muchas

áreas. Por ejemplo, en gráficos por computadora se suele realizar en matrices de 3x3 y 4x4
que representan geometría 3D. Así que intentaremos hacer una versión razonablemente
rápida (aunque no pretendemos hacer la mejor).

Una primera mejora que queremos hacer en este algoritmo es hacer que los bucles estén
perfectamente anidados. Hay algunas razones técnicas más allá del alcance de este código
para eso. Entonces nos desharemos de la inicialización de C[i][j]a 0, fuera del ciclo.

1float A[N][N];
2float B[M][N];
3// Result
4float C[N][N];
5
6for (int i = 0; i < N; i++)
7 for (int j = 0; j < N; j++)
8 C[i][j] = 0;
9
10for (int i = 0; i < N; i++)
 11 for (int j = 0; j < N; j++)
12 for (int k = 0; k < N; k++)
13 C[i][j] += A[i][k] * B[k][j];

Después de este cambio, la parte interesante de nuestro algoritmo, la línea 13, está dentro
de un nido perfecto de bucles de profundidad 3.

Accediendo a una matriz

Es relativamente sencillo acceder a una matriz de una sola dimensión, como
en a[i]. Simplemente obtenga i, multiplíquelo por el tamaño en bytes de cada elemento de la
matriz y luego agregue la dirección de a(la dirección base de la matriz). Entonces, la
dirección de a[i]es solo a + ELEMENTSIZE*i.

Las cosas se complican un poco más cuando nuestra matriz tiene más de una dimensión,
como una matriz o un cubo. Dado un acceso como a[i][j][k]tenemos que calcular qué
elemento se denota por [i][j][k]. Esto depende de si el idioma es un orden de fila principal o
de columna principal. Asumimos aquí el orden de las filas principales (como en el lenguaje
C). Por [i][j][k]lo tanto, debe indicar k + j * NK + i * NK * NJdónde NKy NJson el número de
elementos en cada dimensión. Por ejemplo, una matriz tridimensional de 3 x 4 x 5
elementos, el elemento [1] [2] [3] es 3 + 2 * 5 + 1 * 5 * 4 = 23 (aquí NK= 5 y NJ= 4. Tenga
en cuenta queNI= 3 pero no lo necesitamos en absoluto). Suponemos que nuestro lenguaje
indexa matrices a partir de 0 (como C). Si el idioma permite un límite inferior distinto de 0,
primero tenemos que restar el límite inferior para obtener la posición.

Podemos calcular la posición de una manera un poco mejor si la reordenamos. En lugar de

calcular k + j * NK + i * NK * NJlo haremos k + NK * (j + NJ * i). De esta manera, todo el cálculo
es solo un conjunto repetido de pasos que se calculan como en el ejemplo siguiente. x + Ni *
y

/* Calculating the address of C[i][j][k] declared as int C[3][4][5] */

/* &C[i][j][k] is, thus, C + ELEMENTSIZE * ( k + NK * (j + NJ * i) ) */
// Assume i is in r4, j in r5 and k in r6 and the base address of C in r3 */
mov r8, #4 /* r8 ← NJ (Recall that NJ = 4) */
mul r7, r8, r4 /* r7 ← NJ * i */
add r7, r5, r7 /* r7 ← j + NJ * i */
mov r8, #5 /* r8 ← NK (Recall that NK = 5) */
mul r7, r8, r7 /* r7 ← NK * (j + NJ * i) */
add r7, r6, r7 /* r7 ← k + NK * (j + NJ + i) */
mov r8, #4 /* r8 ← ELEMENTSIZE (Recall that size of an int is 4 bytes) */
mul r7, r8, r7 /* r7 ← ELEMENTSIZE * ( k + NK * (j + NJ * i) ) */
add r7, r3, r7 /* r7 ← C + ELEMENTSIZE * ( k + NK * (j + NJ * i) ) */

Multiplicación de matriz ingenua de precisión

simple 4x4
Como primer paso, implementemos una multiplicación matricial ingenua que siga el
algoritmo C anterior de acuerdo con la letra.

1/* -- matmul.s */
[Link]
3mat_A: .float 0.1, 0.2, 0.0, 0.1
4 .float 0.2, 0.1, 0.3, 0.0
5 .float 0.0, 0.3, 0.1, 0.5
6 .float 0.0, 0.6, 0.4, 0.1
7mat_B: .float 4.92, 2.54, -0.63, -1.75
8 .float 3.02, -1.51, -0.87, 1.35
9 .float -4.29, 2.14, 0.71, 0.71
10 .float -0.95, 0.48, 2.38, -0.95
11mat_C: .float 0.0, 0.0, 0.0, 0.0
12 .float 0.0, 0.0, 0.0, 0.0
13 .float 0.0, 0.0, 0.0, 0.0
14 .float 0.0, 0.0, 0.0, 0.0
15 .float 0.0, 0.0, 0.0, 0.0
16
17format_result : .asciz "Matrix result is:\n%5.2f %5.2f %5.2f %5.2f\n%5.2f %5.2f %5.2f %5.2f\n%5.2f %5.2f %5.2f %5.2f\n%
18
[Link]
20
21naive_matmul_4x4:
22 /* r0 address of A
23 r1 address of B
24 r2 address of C
25 */
26 push {r4, r5, r6, r7, r8, lr} /* Keep integer registers */
27 /* First zero 16 single floating point */
28 /* In IEEE 754, all bits cleared means 0 */
29 mov r4, r2
30 mov r5, #16
31 mov r6, #0
32 b .Lloop_init_test
33 .Lloop_init :
34 str r6, [r4], +#4 /* *r4 ← r6 then r4 ← r4 + 4 */
35 .Lloop_init_test:
36 subs r5, r5, #1
37 bge .Lloop_init
38
39 /* We will use
40 r4 as i
41 r5 as j
42 r6 as k
43 */
44 mov r4, #0 /* r4 ← 0 */
45 .Lloop_i: /* loop header of i */
46 cmp r4, #4 /* if r4 == 4 goto end of the loop i */
47 beq .Lend_loop_i
48 mov r5, #0 /* r5 ← 0 */
49 .Lloop_j: /* loop header of j */
50 cmp r5, #4 /* if r5 == 4 goto end of the loop j */
51 beq .Lend_loop_j
52 /* Compute the address of C[i][j] and load it into s0 */
53 /* Address of C[i][j] is C + 4*(4 * i + j) */
54 mov r7, r5 /* r7 ← r5. This is r7 ← j */
55 adds r7, r7, r4, LSL #2 /* r7 ← r7 + (r4 << 2).
56 This is r7 ← j + i * 4.
57 We multiply i by the row size (4 elements) */
58 adds r7, r2, r7, LSL #2 /* r7 ← r2 + (r7 << 2).
59 This is r7 ← C + 4*(j + i * 4)
60 We multiply (j + i * 4) by the size of the element.
61 A single-precision floating point takes 4 bytes.
62 */
63 vldr s0, [r7] /* s0 ← *r7 */
64
65 mov r6, #0 /* r6 ← 0 */
66 .Lloop_k : /* loop header of k */
67 cmp r6, #4 /* if r6 == 4 goto end of the loop k */
68 beq .Lend_loop_k
69
70 /* Compute the address of a[i][k] and load it into s1 */
71 /* Address of a[i][k] is a + 4*(4 * i + k) */
72 mov r8, r6 /* r8 ← r6. This is r8 ← k */
73 adds r8, r8, r4, LSL #2 /* r8 ← r8 + (r4 << 2). This is r8 ← k + i * 4 */
74 adds r8, r0, r8, LSL #2 /* r8 ← r0 + (r8 << 2). This is r8 ← a + 4*(k + i * 4) */
75 vldr s1, [r8] /* s1 ← *r8 */
76
77 /* Compute the address of b[k][j] and load it into s2 */
78 /* Address of b[k][j] is b + 4*(4 * k + j) */
79 mov r8, r5 /* r8 ← r5. This is r8 ← j */
80 adds r8, r8, r6, LSL #2 /* r8 ← r8 + (r6 << 2). This is r8 ← j + k * 4 */
81 adds r8, r1, r8, LSL #2 /* r8 ← r1 + (r8 << 2). This is r8 ← b + 4*(j + k * 4) */
82 vldr s2, [r8] /* s1 ← *r8 */
83
 84 vmul.f32 s3, s1, s2 /* s3 ← s1 * s2 */
85 vadd.f32 s0, s0, s3 /* s0 ← s0 + s3 */
86
87 add r6, r6, #1 /* r6 ← r6 + 1 */
88 b .Lloop_k /* next iteration of loop k */
89 .Lend_loop_k: /* Here ends loop k */
90 vstr s0, [r7] /* Store s0 back to C[i][j] */
91 add r5, r5, #1 /* r5 ← r5 + 1 */
92 b .Lloop_j /* next iteration of loop j */
93 .Lend_loop_j: /* Here ends loop j */
94 add r4, r4, #1 /* r4 ← r4 + 1 */
95 b .Lloop_i /* next iteration of loop i */
96 .Lend_loop_i: /* Here ends loop i */
97
98 pop {r4, r5, r6, r7, r8, lr} /* Restore integer registers */
99 bx lr /* Leave function */
100
101
[Link] main
103main:
104 push {r4, r5, r6, lr} /* Keep integer registers */
105 vpush {d0-d1} /* Keep floating point registers */
106
107 /* Prepare call to naive_matmul_4x4 */
108 ldr r0, addr_mat_A /* r0 ← a */
109 ldr r1, addr_mat_B /* r1 ← b */
110 ldr r2, addr_mat_C /* r2 ← c */
111 bl naive_matmul_4x4
112
113 /* Now print the result matrix */
114 ldr r4, addr_mat_C /* r4 ← c */
115
116 vldr s0, [r4] /* s0 ← *r4. This is s0 ← c[0][0] */
117 vcvt.f64.f32 d1, s0 /* Convert it into a double-precision
118 d1 ← s0
119 */
120 vmov r2, r3, d1 /* {r2,r3} ← d1 */
121
122 mov r6, sp /* Remember the stack pointer, we need it to restore it back later */
123 /* r6 ← sp */
124
125 mov r5, #1 /* We will iterate from 1 to 15 (because the 0th item has already been handled */
126 add r4, r4, #60 /* Go to the last item of the matrix c, this is c[3][3] */
 127 .Lloop:
128 vldr s0, [r4] /* s0 ← *r4. Load the current item */
129 vcvt.f64.f32 d1, s0 /* Convert it into a double-precision
130 d1 ← s0
131 */
132 sub sp, sp, #8 /* Make room in the stack for the double-precision */
133 vstr d1, [sp] /* Store the double precision in the top of the stack */
134 sub r4, r4, #4 /* Move to the previous element in the matrix */
135 add r5, r5, #1 /* One more item has been handled */
136 cmp r5, #16 /* if r5 != 16 go to next iteration of the loop */
137 bne .Lloop
138
139 ldr r0, addr_format_result /* r0 ← &format_result */
140 bl printf /* call printf */
141 mov sp, r6 /* Restore the stack after the call */
142
143 mov r0, #0
144 vpop {d0-d1}
145 pop {r4, r5, r6, lr}
146 bx lr
147
148addr_mat_A : .word mat_A
149addr_mat_B : .word mat_B
150addr_mat_C : .word mat_C
151addr_format_result : .word format_result

Eso es mucho código pero no es complicado. Desafortunadamente, calcular la dirección de

la matriz requiere una cantidad importante de instrucciones. En
nuestra naive_matmul_4x4tenemos los tres bucles i, jy kdel algoritmo C. Calculamos la
dirección de C[i][j]en el bucle j(no es necesario calcularlo cada vez que en el bucle k) en las
líneas 52 a 63. El valor contenido en C[i][j]se carga en s0. En cada iteración del
bucle kcargamos A[i][k]y B[k][j]en s1y s2respectivamente (líneas 70 a 82). Una vez
que kfinaliza el ciclo , podemos s0volver a almacenar en la posición de la matriz (mantenida
en la r7línea 90)

Para imprimir la matriz de resultados tenemos que pasar 16 puntos flotantes

a printf. Desafortunadamente, como se indicó en el capítulo 13, primero debemos
convertirlos en doble precisión antes de pasarlos. Tenga en cuenta también que la primera
precisión simple se puede pasar utilizando registros r2y r3. Todo el resto debe pasarse a la
pila y no olvide que los parámetros de la pila deben pasarse en orden opuesto. Es por esto
que una vez cargado el primer elemento de la matriz C {r2,r3}(líneas 117 a 120) avanzamos
60 bytes r4. Es decir C[3][3], el último elemento de la matriz C. Cargamos la precisión
simple, la convertimos en precisión doble, la empujamos en la pila y luego nos movemos
hacia atrás r4, al elemento anterior de la matriz (líneas 128 a 137). Observe que
usamosr6como marcador de la pila, ya que necesitamos restaurar la pila una vez
que printfregresa (línea 122 y línea 141). Por supuesto, podríamos evitar el uso r6y, en su
lugar, hacerlo, add sp, sp, #120ya que esta es exactamente la cantidad de bytes que enviamos a
la pila (15 valores de doble precisión, cada uno con 8 bytes).

No he elegido los valores de las dos matrices al azar. El segundo es (aproximadamente) el

inverso del primero. De esta forma obtendremos la matriz identidad (una matriz con todos
ceros pero una diagonal de unos). Debido a problemas de redondeo, la matriz de resultados
no será la identidad, pero estará bastante cerca. Ejecutemos el programa.
$ ./matmul
Matrix result is:
1.00 -0.00 0.00 0.00
-0.00 1.00 0.00 -0.00
0.00 0.00 1.00 0.00
0.00 -0.00 0.00 1.00

Enfoque vectorial
El algoritmo que estamos intentando implementar está bien, pero no es el más
optimizable. El problema radica en la forma en que el bucle kaccede a los elementos. El
acceso A[i][k]es elegible para una carga múltiple ya que A[i][k]y A[i][k+1]son elementos
contiguos en la memoria. De esta manera podríamos evitar por completo todo el bucle ky
realizar una carga de 4 elementos de A[i][0]a A[i][3]. El acceso B[k][j]no permite eso, ya que
los elementos B[k][j]y B[k+1][j]tienen una fila completa entre ellos. Este es un acceso
escalonado (el stride aquí es una fila completa de 4 elementos, esto es 16 bytes), VFPv2 no
permite una carga múltiple escalonada, por lo que tendremos que cargar uno por uno .. Una
vez que tengamos todos los elementos de el ciclo kcargado, podemos hacer una
multiplicación de vectores y una suma.

1naive_vectorial_matmul_4x4:
2 /* r0 address of A
3 r1 address of B
4 r2 address of C
5 */
6 push {r4, r5, r6, r7, r8, lr} /* Keep integer registers */
7 vpush {s16-s19} /* Floating point registers starting from s16 must be preserved */
8 vpush {s24-s27}
9 /* First zero 16 single floating point */
10 /* In IEEE 754, all bits cleared means 0 */
11 mov r4, r2
12 mov r5, #16
13 mov r6, #0
14 b .L1_loop_init_test
15 .L1_loop_init :
16 str r6, [r4], +#4 /* *r4 ← r6 then r4 ← r4 + 4 */
17 .L1_loop_init_test:
18 subs r5, r5, #1
19 bge .L1_loop_init
20
21 /* Set the LEN field of FPSCR to be 4 (value 3) */
22 mov r5, #0b011 /* r5 ← 3 */
23 mov r5, r5, LSL #16 /* r5 ← r5 << 16 */
24 fmrx r4, fpscr /* r4 ← fpscr */
25 orr r4, r4, r5 /* r4 ← r4 | r5 */
26 fmxr fpscr, r4 /* fpscr ← r4 */
27
28 /* We will use
29 r4 as i
30 r5 as j
31 r6 as k
32 */
33 mov r4, #0 /* r4 ← 0 */
34 .L1_loop_i: /* loop header of i */
35 cmp r4, #4 /* if r4 == 4 goto end of the loop i */
36 beq .L1_end_loop_i
37 mov r5, #0 /* r5 ← 0 */
38 .L1_loop_j: /* loop header of j */
39 cmp r5, #4 /* if r5 == 4 goto end of the loop j */
40 beq .L1_end_loop_j
41 /* Compute the address of C[i][j] and load it into s0 */
42 /* Address of C[i][j] is C + 4*(4 * i + j) */
43 mov r7, r5 /* r7 ← r5. This is r7 ← j */
44 adds r7, r7, r4, LSL #2 /* r7 ← r7 + (r4 << 2).
45 This is r7 ← j + i * 4.
46 We multiply i by the row size (4 elements) */
47 adds r7, r2, r7, LSL #2 /* r7 ← r2 + (r7 << 2).
48 This is r7 ← C + 4*(j + i * 4)
49 We multiply (j + i * 4) by the size of the element.
50 A single-precision floating point takes 4 bytes.
51 */
52 /* Compute the address of a[i][0] */
53 mov r8, r4, LSL #2
54 adds r8, r0, r8, LSL #2
55 vldmia r8, {s8-s11} /* Load {s8,s9,s10,s11} ← {a[i][0], a[i][1], a[i][2], a[i][3]} */
56
57 /* Compute the address of b[0][j] */
58 mov r8, r5 /* r8 ← r5. This is r8 ← j */
59 adds r8, r1, r8, LSL #2 /* r8 ← r1 + (r8 << 2). This is r8 ← b + 4*(j) */
60 vldr s16, [r8] /* s16 ← *r8. This is s16 ← b[0][j] */
 61 vldr s17, [r8, #16] /* s17 ← *(r8 + 16). This is s17 ← b[1][j] */
62 vldr s18, [r8, #32] /* s18 ← *(r8 + 32). This is s17 ← b[2][j] */
63 vldr s19, [r8, #48] /* s19 ← *(r8 + 48). This is s17 ← b[3][j] */
64
65 vmul.f32 s24, s8, s16 /* {s24,s25,s26,s27} ← {s8,s9,s10,s11} * {s16,s17,s18,s19} */
66 vmov.f32 s0, s24 /* s0 ← s24 */
67 vadd.f32 s0, s0, s25 /* s0 ← s0 + s25 */
68 vadd.f32 s0, s0, s26 /* s0 ← s0 + s26 */
69 vadd.f32 s0, s0, s27 /* s0 ← s0 + s27 */
70
71 vstr s0, [r7] /* Store s0 back to C[i][j] */
72 add r5, r5, #1 /* r5 ← r5 + 1 */
73 b .L1_loop_j /* next iteration of loop j */
74 .L1_end_loop_j: /* Here ends loop j */
75 add r4, r4, #1 /* r4 ← r4 + 1 */
76 b .L1_loop_i /* next iteration of loop i */
77 .L1_end_loop_i: /* Here ends loop i */
78
79 /* Set the LEN field of FPSCR back to 1 (value 0) */
80 mov r5, #0b011 /* r5 ← 3 */
81 mvn r5, r5, LSL #16 /* r5 ← ~(r5 << 16) */
82 fmrx r4, fpscr /* r4 ← fpscr */
83 and r4, r4, r5 /* r4 ← r4 & r5 */
84 fmxr fpscr, r4 /* fpscr ← r4 */
85
86 vpop {s24-s27} /* Restore preserved floating registers */
87 vpop {s16-s19}
88 pop {r4, r5, r6, r7, r8, lr} /* Restore integer registers */
89 bx lr /* Leave function */

Con este enfoque podemos eliminar por completo el bucle k, ya que hacemos 4 operaciones
a la vez. Tenga en cuenta que tenemos que modificar fpscrpara que el campo lense
establezca en 4 (y restaurarlo de nuevo a 1 al salir de la función).

Llenar los registros

En la versión anterior no estamos explotando todos los registros de VFPv2. Cada fila toma
4 registros y también cada columna, por lo que terminamos usando solo 8 registros más 4
para el resultado y uno en el banco 0 para la suma. Eliminamos el bucle kpara procesar C[i]
[j]de una vez. ¿Y si procesamos C[i][j]y C[i][j+1]al mismo tiempo? De esta forma podemos
llenar los 8 registros de cada banco.

1naive_vectorial_matmul_2_4x4:
 2 /* r0 address of A
3 r1 address of B
4 r2 address of C
5 */
6 push {r4, r5, r6, r7, r8, lr} /* Keep integer registers */
7 vpush {s16-s31} /* Floating point registers starting from s16 must be preserved */
8 /* First zero 16 single floating point */
9 /* In IEEE 754, all bits cleared means 0 */
10 mov r4, r2
11 mov r5, #16
12 mov r6, #0
13 b .L2_loop_init_test
14 .L2_loop_init :
15 str r6, [r4], +#4 /* *r4 ← r6 then r4 ← r4 + 4 */
16 .L2_loop_init_test:
17 subs r5, r5, #1
18 bge .L2_loop_init
19
20 /* Set the LEN field of FPSCR to be 4 (value 3) */
21 mov r5, #0b011 /* r5 ← 3 */
22 mov r5, r5, LSL #16 /* r5 ← r5 << 16 */
23 fmrx r4, fpscr /* r4 ← fpscr */
24 orr r4, r4, r5 /* r4 ← r4 | r5 */
25 fmxr fpscr, r4 /* fpscr ← r4 */
26
27 /* We will use
28 r4 as i
29 r5 as j
30 */
31 mov r4, #0 /* r4 ← 0 */
32 .L2_loop_i: /* loop header of i */
33 cmp r4, #4 /* if r4 == 4 goto end of the loop i */
34 beq .L2_end_loop_i
35 mov r5, #0 /* r5 ← 0 */
36 .L2_loop_j: /* loop header of j */
37 cmp r5, #4 /* if r5 == 4 goto end of the loop j */
38 beq .L2_end_loop_j
39 /* Compute the address of C[i][j] and load it into s0 */
40 /* Address of C[i][j] is C + 4*(4 * i + j) */
41 mov r7, r5 /* r7 ← r5. This is r7 ← j */
42 adds r7, r7, r4, LSL #2 /* r7 ← r7 + (r4 << 2).
43 This is r7 ← j + i * 4.
44 We multiply i by the row size (4 elements) */
45 adds r7, r2, r7, LSL #2 /* r7 ← r2 + (r7 << 2).
46 This is r7 ← C + 4*(j + i * 4)
47 We multiply (j + i * 4) by the size of the element.
48 A single-precision floating point takes 4 bytes.
49 */
50 /* Compute the address of a[i][0] */
51 mov r8, r4, LSL #2
52 adds r8, r0, r8, LSL #2
53 vldmia r8, {s8-s11} /* Load {s8,s9,s10,s11} ← {a[i][0], a[i][1], a[i][2], a[i][3]} */
54
55 /* Compute the address of b[0][j] */
56 mov r8, r5 /* r8 ← r5. This is r8 ← j */
57 adds r8, r1, r8, LSL #2 /* r8 ← r1 + (r8 << 2). This is r8 ← b + 4*(j) */
58 vldr s16, [r8] /* s16 ← *r8. This is s16 ← b[0][j] */
59 vldr s17, [r8, #16] /* s17 ← *(r8 + 16). This is s17 ← b[1][j] */
60 vldr s18, [r8, #32] /* s18 ← *(r8 + 32). This is s17 ← b[2][j] */
61 vldr s19, [r8, #48] /* s19 ← *(r8 + 48). This is s17 ← b[3][j] */
62
63 /* Compute the address of b[0][j+1] */
64 add r8, r5, #1 /* r8 ← r5 + 1. This is r8 ← j + 1*/
65 adds r8, r1, r8, LSL #2 /* r8 ← r1 + (r8 << 2). This is r8 ← b + 4*(j + 1) */
66 vldr s20, [r8] /* s20 ← *r8. This is s20 ← b[0][j + 1] */
67 vldr s21, [r8, #16] /* s21 ← *(r8 + 16). This is s21 ← b[1][j + 1] */
68 vldr s22, [r8, #32] /* s22 ← *(r8 + 32). This is s22 ← b[2][j + 1] */
69 vldr s23, [r8, #48] /* s23 ← *(r8 + 48). This is s23 ← b[3][j + 1] */
70
71 vmul.f32 s24, s8, s16 /* {s24,s25,s26,s27} ← {s8,s9,s10,s11} * {s16,s17,s18,s19} */
72 vmov.f32 s0, s24 /* s0 ← s24 */
73 vadd.f32 s0, s0, s25 /* s0 ← s0 + s25 */
74 vadd.f32 s0, s0, s26 /* s0 ← s0 + s26 */
75 vadd.f32 s0, s0, s27 /* s0 ← s0 + s27 */
76
77 vmul.f32 s28, s8, s20 /* {s28,s29,s30,s31} ← {s8,s9,s10,s11} * {s20,s21,s22,s23} */
78
79 vmov.f32 s1, s28 /* s1 ← s28 */
80 vadd.f32 s1, s1, s29 /* s1 ← s1 + s29 */
81 vadd.f32 s1, s1, s30 /* s1 ← s1 + s30 */
82 vadd.f32 s1, s1, s31 /* s1 ← s1 + s31 */
83
84 vstmia r7, {s0-s1} /* {C[i][j], C[i][j+1]} ← {s0, s1} */
85
86 add r5, r5, #2 /* r5 ← r5 + 2 */
87 b .L2_loop_j /* next iteration of loop j */
 88 .L2_end_loop_j: /* Here ends loop j */
89 add r4, r4, #1 /* r4 ← r4 + 1 */
90 b .L2_loop_i /* next iteration of loop i */
91 .L2_end_loop_i: /* Here ends loop i */
92
93 /* Set the LEN field of FPSCR back to 1 (value 0) */
94 mov r5, #0b011 /* r5 ← 3 */
95 mvn r5, r5, LSL #16 /* r5 ← ~(r5 << 16) */
96 fmrx r4, fpscr /* r4 ← fpscr */
97 and r4, r4, r5 /* r4 ← r4 & r5 */
98 fmxr fpscr, r4 /* fpscr ← r4 */
99
100 vpop {s16-s31} /* Restore preserved floating registers */
101 pop {r4, r5, r6, r7, r8, lr} /* Restore integer registers */
102 bx lr /* Leave function */

Tenga en cuenta que debido a que ahora procesamos jy j + 1, r5( j) ahora se incrementa en 2
al final del ciclo. Esto generalmente se conoce como desenrollado de bucle y siempre es
legal hacerlo. Hacemos más de una iteración del ciclo original en el ciclo desenrollado. La
cantidad de iteraciones del ciclo original que hacemos en el ciclo desenrollado es el factor
de desenrollado . En este caso, dado que el número de iteraciones (4) divide perfectamente
el factor de desenrollado (2), no necesitamos un bucle adicional para las iteraciones
restantes (el bucle restante tiene una iteración menos que el valor del factor de
desenrollado).

Como se puede ver, los accesos b[k][j]y b[k][j+1]están empezando a llegar a ser

tedioso. Quizás deberíamos cambiar un poco más el algoritmo de multiplicación de
matrices.

Reordenar los accesos

¿Existe alguna forma de mitigar los accesos escalonados a la matriz B? Sí, hay uno, solo
tenemos que permutar el nido de bucles i, j, k en el nido de bucles k, i, j. Ahora puede que
se pregunte si esto es legal. Bueno, verificar la legalidad de estas cosas está más allá del
alcance de esta publicación, por lo que tendrá que confiar en mí. Tal permutación está
bien. ¿Qué significa esto? Bueno, significa que nuestro algoritmo ahora se verá así.

1float A[N][N];
2float B[M][N];
3// Result
4float C[N][N];
5
6for (int i = 0; i < N; i++)
7 for (int j = 0; j < N; j++)
 8 C[i][j] = 0;
9
10for (int k = 0; k < N; k++)
11 for (int i = 0; i < N; i++)
12 for (int j = 0; j < N; j++)
13 C[i][j] += A[i][k] * B[k][j];

Esto puede parecer poco útil, pero tenga en cuenta que, dado que ahora k está en el bucle
más externo, ahora es más fácil usar instrucciones vectoriales.
for (int k = 0; k < N; k++)
for (int i = 0; i < N; i++)
{
C[i][0] += A[i][k] * B[k][0];
C[i][1] += A[i][k] * B[k][1];
C[i][2] += A[i][k] * B[k][2];
C[i][3] += A[i][k] * B[k][3];
}
Si recuerdas el capítulo 13, las instrucciones VFPv2 tienen un modo mixto cuando
el Rsource2registro está en el banco 0. Este caso hace una combinación perfecta: podemos
cargar C[i][0..3]y B[k][0..3]con un múltiplo de carga y luego cargar A[i][k]en un registro del
banco 0. Entonces podemos haz multiplicar A[i][k]*B[k][0..3]y suma el resultado a C[i]
[0..3]. Como beneficio adicional, el número de instrucciones es mucho menor.

1better_vectorial_matmul_4x4:
2 /* r0 address of A
3 r1 address of B
4 r2 address of C
5 */
6 push {r4, r5, r6, r7, r8, lr} /* Keep integer registers */
7 vpush {s16-s19} /* Floating point registers starting from s16 must be preserved */
8 vpush {s24-s27}
9 /* First zero 16 single floating point */
10 /* In IEEE 754, all bits cleared means 0 */
11 mov r4, r2
12 mov r5, #16
13 mov r6, #0
14 b .L3_loop_init_test
15 .L3_loop_init :
16 str r6, [r4], +#4 /* *r4 ← r6 then r4 ← r4 + 4 */
17 .L3_loop_init_test:
18 subs r5, r5, #1
19 bge .L3_loop_init
20
21 /* Set the LEN field of FPSCR to be 4 (value 3) */
22 mov r5, #0b011 /* r5 ← 3 */
23 mov r5, r5, LSL #16 /* r5 ← r5 << 16 */
24 fmrx r4, fpscr /* r4 ← fpscr */
25 orr r4, r4, r5 /* r4 ← r4 | r5 */
26 fmxr fpscr, r4 /* fpscr ← r4 */
27
28 /* We will use
29 r4 as k
30 r5 as i
31 */
32 mov r4, #0 /* r4 ← 0 */
33 .L3_loop_k: /* loop header of k */
34 cmp r4, #4 /* if r4 == 4 goto end of the loop k */
35 beq .L3_end_loop_k
36 mov r5, #0 /* r5 ← 0 */
37 .L3_loop_i: /* loop header of i */
38 cmp r5, #4 /* if r5 == 4 goto end of the loop i */
39 beq .L3_end_loop_i
40 /* Compute the address of C[i][0] */
41 /* Address of C[i][0] is C + 4*(4 * i) */
42 add r7, r2, r5, LSL #4 /* r7 ← r2 + (r5 << 4). This is r7 ← c + 4*4*i */
43 vldmia r7, {s8-s11} /* Load {s8,s9,s10,s11} ← {c[i][0], c[i][1], c[i][2], c[i][3]} */
44 /* Compute the address of A[i][k] */
45 /* Address of A[i][k] is A + 4*(4*i + k) */
46 add r8, r4, r5, LSL #2 /* r8 ← r4 + r5 << 2. This is r8 ← k + 4*i */
47 add r8, r0, r8, LSL #2 /* r8 ← r0 + r8 << 2. This is r8 ← a + 4*(k + 4*i) */
48 vldr s0, [r8] /* Load s0 ← a[i][k] */
49
50 /* Compute the address of B[k][0] */
51 /* Address of B[k][0] is B + 4*(4*k) */
52 add r8, r1, r4, LSL #4 /* r8 ← r1 + r4 << 4. This is r8 ← b + 4*(4*k) */
53 vldmia r8, {s16-s19} /* Load {s16,s17,s18,s19} ← {b[k][0], b[k][1], b[k][2], b[k][3]} */
54
55 vmul.f32 s24, s16, s0 /* {s24,s25,s26,s27} ← {s16,s17,s18,s19} * {s0,s0,s0,s0} */
56 vadd.f32 s8, s8, s24 /* {s8,s9,s10,s11} ← {s8,s9,s10,s11} + {s24,s25,s26,s7} */
57
58 vstmia r7, {s8-s11} /* Store {c[i][0], c[i][1], c[i][2], c[i][3]} ← {s8,s9,s10,s11} */
59
60 add r5, r5, #1 /* r5 ← r5 + 1. This is i = i + 1 */
61 b .L3_loop_i /* next iteration of loop i */
62 .L3_end_loop_i: /* Here ends loop i */
63 add r4, r4, #1 /* r4 ← r4 + 1. This is k = k + 1 */
64 b .L3_loop_k /* next iteration of loop k */
 65 .L3_end_loop_k: /* Here ends loop k */
66
67 /* Set the LEN field of FPSCR back to 1 (value 0) */
68 mov r5, #0b011 /* r5 ← 3 */
69 mvn r5, r5, LSL #16 /* r5 ← ~(r5 << 16) */
70 fmrx r4, fpscr /* r4 ← fpscr */
71 and r4, r4, r5 /* r4 ← r4 & r5 */
72 fmxr fpscr, r4 /* fpscr ← r4 */
73
74 vpop {s24-s27} /* Restore preserved floating registers */
75 vpop {s16-s19}
76 pop {r4, r5, r6, r7, r8, lr} /* Restore integer registers */
77 bx lr /* Leave function */

Como sumar después de una multiplicación es una secuencia relativamente habitual,

podemos reemplazar la secuencia

55vmul.f32 s24, s16, s0 /* {s24,s25,s26,s27} ← {s16,s17,s18,s19} * {s0,s0,s0,s0} */

56vadd.f32 s8, s8, s24 /* {s8,s9,s10,s11} ← {s8,s9,s10,s11} + {s24,s25,s26,s7} */

con una sola instrucción vmla(multiplicar y sumar).

55vmla.f32 s8, s16, s0 /* {s8,s9,s10,s11} ← {s8,s9,s10,s11} + ({s16,s17,s18,s19} * {s0,s0,s0,s0}) */

Ahora también podemos desenrollar el ciclo i, nuevamente con un factor de desenrollado de

2. Esto nos daría la mejor versión.

1best_vectorial_matmul_4x4:
2 /* r0 address of A
3 r1 address of B
4 r2 address of C
5 */
6 push {r4, r5, r6, r7, r8, lr} /* Keep integer registers */
7 vpush {s16-s19} /* Floating point registers starting from s16 must be preserved */
8
9 /* First zero 16 single floating point */
10 /* In IEEE 754, all bits cleared means 0 */
11 mov r4, r2
12 mov r5, #16
13 mov r6, #0
14 b .L4_loop_init_test
15 .L4_loop_init :
16 str r6, [r4], +#4 /* *r4 ← r6 then r4 ← r4 + 4 */
17 .L4_loop_init_test:
18 subs r5, r5, #1
19 bge .L4_loop_init
20
21 /* Set the LEN field of FPSCR to be 4 (value 3) */
22 mov r5, #0b011 /* r5 ← 3 */
23 mov r5, r5, LSL #16 /* r5 ← r5 << 16 */
24 fmrx r4, fpscr /* r4 ← fpscr */
25 orr r4, r4, r5 /* r4 ← r4 | r5 */
26 fmxr fpscr, r4 /* fpscr ← r4 */
27
28 /* We will use
29 r4 as k
30 r5 as i
31 */
32 mov r4, #0 /* r4 ← 0 */
33 .L4_loop_k: /* loop header of k */
34 cmp r4, #4 /* if r4 == 4 goto end of the loop k */
35 beq .L4_end_loop_k
36 mov r5, #0 /* r5 ← 0 */
37 .L4_loop_i: /* loop header of i */
38 cmp r5, #4 /* if r5 == 4 goto end of the loop i */
39 beq .L4_end_loop_i
40 /* Compute the address of C[i][0] */
41 /* Address of C[i][0] is C + 4*(4 * i) */
42 add r7, r2, r5, LSL #4 /* r7 ← r2 + (r5 << 4). This is r7 ← c + 4*4*i */
43 vldmia r7, {s8-s15} /* Load {s8,s9,s10,s11,s12,s13,s14,s15}
44 ← {c[i][0], c[i][1], c[i][2], c[i][3]
45 c[i+1][0], c[i+1][1], c[i+1][2], c[i+1][3]} */
46 /* Compute the address of A[i][k] */
47 /* Address of A[i][k] is A + 4*(4*i + k) */
48 add r8, r4, r5, LSL #2 /* r8 ← r4 + r5 << 2. This is r8 ← k + 4*i */
49 add r8, r0, r8, LSL #2 /* r8 ← r0 + r8 << 2. This is r8 ← a + 4*(k + 4*i) */
50 vldr s0, [r8] /* Load s0 ← a[i][k] */
51 vldr s1, [r8, #16] /* Load s1 ← a[i+1][k] */
52
53 /* Compute the address of B[k][0] */
54 /* Address of B[k][0] is B + 4*(4*k) */
55 add r8, r1, r4, LSL #4 /* r8 ← r1 + r4 << 4. This is r8 ← b + 4*(4*k) */
56 vldmia r8, {s16-s19} /* Load {s16,s17,s18,s19} ← {b[k][0], b[k][1], b[k][2], b[k][3]} */
57
58 vmla.f32 s8, s16, s0 /* {s8,s9,s10,s11} ← {s8,s9,s10,s11} + ({s16,s17,s18,s19} * {s0,s0,s0,s0}) */
59 vmla.f32 s12, s16, s1 /* {s12,s13,s14,s15} ← {s12,s13,s14,s15} + ({s16,s17,s18,s19} * {s1,s1,s1,s1}) */
 60
61 vstmia r7, {s8-s15} /* Store {c[i][0], c[i][1], c[i][2], c[i][3],
62 c[i+1][0], c[i+1][1], c[i+1][2]}, c[i+1][3] }
63 ← {s8,s9,s10,s11,s12,s13,s14,s15} */
64
65 add r5, r5, #2 /* r5 ← r5 + 2. This is i = i + 2 */
66 b .L4_loop_i /* next iteration of loop i */
67 .L4_end_loop_i: /* Here ends loop i */
68 add r4, r4, #1 /* r4 ← r4 + 1. This is k = k + 1 */
69 b .L4_loop_k /* next iteration of loop k */
70 .L4_end_loop_k: /* Here ends loop k */
71
72 /* Set the LEN field of FPSCR back to 1 (value 0) */
73 mov r5, #0b011 /* r5 ← 3 */
74 mvn r5, r5, LSL #16 /* r5 ← ~(r5 << 16) */
75 fmrx r4, fpscr /* r4 ← fpscr */
76 and r4, r4, r5 /* r4 ← r4 & r5 */
77 fmxr fpscr, r4 /* fpscr ← r4 */
78
79 vpop {s16-s19} /* Restore preserved floating registers */
80 pop {r4, r5, r6, r7, r8, lr} /* Restore integer registers */
81 bx lr /* Leave function */

Comparación de versiones
Por curiosidad probé las versiones, para ver cuál era más rápida.

El benchmark consiste en llamar repetidamente a la función de la matriz de multiplicación

2 21 veces (en realidad 2 21 -1 por un error tipográfico, ver el código) con el fin de
magnificar las diferencias. Si bien la entrada también debe ser aleatoria para un mejor
punto de referencia, el punto de referencia más o menos modela contextos en los que se
realiza una multiplicación de matrices muchas veces (por ejemplo, en gráficos).

Este es el esqueleto del punto de referencia.

main:
push {r4, lr}

ldr r0, addr_mat_A /* r0 ← a */

ldr r1, addr_mat_B /* r1 ← b */
ldr r2, addr_mat_C /* r2 ← c */
mov r4, #1
mov r4, r4, LSL #21
.Lmain_loop_test:
bl <<tested-matmul-routine>> /* Change here with the matmul you want to test */
subs r4, r4, #1
 bne .Lmain_loop_test /* I should have written 'bge' here,
but I cannot change it without
having to run the benchmarks again :) */

mov r0, #0
pop {r4, lr}
bx lr
Aquí están los resultados. El que nombramos el mejor se convirtió en realidad para merecer
ese nombre.

Versión Tiempo (segundos)

naive_matmul_4x4 6,41

naive_vectorial_matmul_4x4 3,51

naive_vectorial_matmul_2_4x4 2,87

better_vectorial_matmul_4x4 2,59

best_vectorial_matmul_4x4 1,51

Ensamblador ARM en Raspberry Pi

- Capítulo 15
11 de agosto de 2013• Roger Ferrer Ibáñez • Raspberry Pi

Puede ser sorprendente, pero la arquitectura ARMv6 no proporciona una instrucción de

división de enteros, mientras que tiene una instrucción de punto flotante en VFPv2. En este
capítulo veremos formas habituales de solucionar esta limitación con diferentes técnicas
que se pueden utilizar en escenarios específicos que involucran divisiones.

¿Qué significa la división de enteros?

Primero debemos definir claramente lo que entendemos por división de enteros. Dados dos
números enteros N (para el numerador) y D (para el denominador, diferente de cero),
definimos la división de números enteros de N y D como el par de números enteros Q (para
el cociente) y R (para el resto) que satisfacen la siguiente igualdad.

N = D × Q + R dónde 0 ≤ |R| < |D|

La igualdad implica que hay dos soluciones 0 < R < |D|y 0 < |-R| < |D|. Por
ejemplo, N=7y D=3tiene dos soluciones (Q=2, R=1)y (Q=3, R=-2). Si bien ambas soluciones
pueden ser útiles, la primera es la preferida, ya que está más cerca de nuestra noción natural
del resto. Pero, ¿y si Des negativo? Por ejemplo, N=7y también D=-3tiene dos
soluciones (Q=-2, R=1)y (Q=-3, R=-2). Cuando se trata de números negativos, la elección del
resto no es intuitiva sino convencional. Se pueden utilizar muchas convenciones para elegir
una solución. Siempre podemos elegir la solución con el resto positivo (esto se
llama división euclidiana ), o el negativo, o la solución donde el signo del resto coincide
con el numerador (o denominador).

La mayoría de las computadoras realizan una división entera donde el resto tiene el mismo
signo que el numerador. Entonces, para N=7y D=3la solución calculada es (Q=2, R=1)y
para N=7y D=-3la solución calculada es (Q=-2, R=1). Asumiremos tal convención de división
de enteros en el resto (sin juego de palabras) de esta publicación.

División sin firmar

Una división de enteros sin signo es una división de enteros que involucra dos enteros sin
signo N y D. Esto tiene la consecuencia de que Q y R siempre serán positivos. Un enfoque
muy ingenuo (y lento) para la división sin firmar es el siguiente.

1unsigned_naive_div:
2 /* r0 contains N */
3 /* r1 contains D */
4 mov r2, r1 /* r2 ← r0. We keep D in r2 */
5 mov r1, r0 /* r1 ← r0. We keep N in r1 */
6
7 mov r0, #0 /* r0 ← 0. Set Q = 0 initially */
8
9 b .Lloop_check
10 .Lloop:
11 add r0, r0, #1 /* r0 ← r0 + 1. Q = Q + 1 */
12 sub r1, r1, r2 /* r1 ← r1 - r2 */
13 .Lloop_check:
14 cmp r1, r2 /* compute r1 - r2 */
15 bhs .Lloop /* branch if r1 >= r2 (C=0 or Z=1) */
16
17 /* r0 already contains Q */
18 /* r1 already contains R */
19 bx lr
Este algoritmo, aunque correcto y fácil de entender, no es muy eficiente (piense en dividir
una N grande con una D pequeña). ¿Hay alguna forma de calcular la división en un período
de tiempo fijo? La respuesta es sí, simplemente adapte la forma de dividir a mano, pero a
números binarios. Calcularemos un resto temporal seleccionando bits, de izquierda a
derecha, del dividendo. Cuando el resto es mayor que el divisor, restaremos el divisor de
ese resto y estableceremos el bit apropiado en el cociente.

1unsigned_longdiv:
2 /* r0 contains N */
3 /* r1 contains D */
4 /* r2 contains Q */
5 /* r3 contains R */
6 push {r4, lr}
7 mov r2, #0 /* r2 ← 0 */
8 mov r3, #0 /* r3 ← 0 */
9
10 mov r4, #32 /* r4 ← 32 */
11 b .Lloop_check1
12 .Lloop1:
13 movs r0, r0, LSL #1 /* r0 ← r0 << 1 updating cpsr (sets C if 31st bit of r0 was 1) */
14 adc r3, r3, r3 /* r3 ← r3 + r3 + C. This is equivalent to r3 ← (r3 << 1) + C */
15
16 cmp r3, r1 /* compute r3 - r1 and update cpsr */
17 subhs r3, r3, r1 /* if r3 >= r1 (C=1) then r3 ← r3 - r1 */
18 adc r2, r2, r2 /* r2 ← r2 + r2 + C. This is equivalent to r2 ← (r2 << 1) + C */
19 .Lloop_check1:
20 subs r4, r4, #1 /* r4 ← r4 - 1 */
21 bpl .Lloop1 /* if r4 >= 0 (N=0) then branch to .Lloop1 */
22
23 pop {r4, lr}
24 bx lr

Este enfoque es un poco más eficiente ya que repite el ciclo un número fijo de veces
(siempre 32). Para cada bit de N a partir del más significativo (línea 13), lo empujamos a la
derecha del valor actual de R (línea 14). Hacemos esto agregando R a sí mismo, esto es 2 *
R que en realidad se está desplazando al bit R 1 derecho. Luego agregamos el acarreo, que
será 1 si el bit más significativo de N antes del cambio (línea 13) fue 1. Luego verificamos
si la R actual ya es mayor que D (línea 16) Si es así, restamos N de R , R ← R - N (línea
17) y luego presionamos un 1 a la derecha de Q (línea 18), nuevamente agregando Q a sí
mismo más el acarreo establecido por la comparación (si R> = N entonces no hay préstamo
por lo que C se convirtió en 1 en la cmplínea 16).
El código que se muestra está bien, pero se puede mejorar de varias maneras. Primero, no
es necesario verificar todos los bits de un número (aunque esto da como límite superior del
costo en el peor de los casos). En segundo lugar, deberíamos esforzarnos por reducir el
número de registros utilizados. Aquí estamos usando 5 registros, ¿hay alguna manera de
que podamos usar menos registros? Para ello, tendremos que utilizar un enfoque
ligeramente diferente.

Dados N y D, primero desplazaremos D tantos bits a la izquierda como sea posible, pero
siempre teniendo N> D. Entonces, por ejemplo, si dividimos N = 1010 (2 por D = 10 (2 ,
ajustaríamos D hasta que fuera D 0 = 1000 (2 (esto se está desplazando dos veces hacia la
izquierda). Ahora comenzamos un proceso similar al anterior: si N i ≥ D i , establecemos 1
en el bit más bajo de Q y luego calculamos un nuevo N i + 1 ← N i - D i y un nuevo D i + 1 ←
D i / 2. Si N i <D i entonces simplemente calculamos un nuevo D i + 1 ← D i/ 2. Nos
detenemos cuando la D i actual es menor que la D inicial (no D 0 ). Tenga en cuenta que
esta condición es lo que hace que dividir N = 1010 (2 entre D = 10 (2) sea diferente de dividir
N = 1010 (2 entre D = 1 (2, aunque el D 0 de ambos casos es el mismo.

1better_unsigned_division :
2 /* r0 contains N and Ni */
3 /* r1 contains D */
4 /* r2 contains Q */
5 /* r3 will contain Di */
6
7 mov r3, r1 /* r3 ← r1 */
8 cmp r3, r0, LSR #1 /* update cpsr with r3 - r0/2 */
9 .Lloop2:
10 movls r3, r3, LSL #1 /* if r3 <= 2*r0 (C=0 or Z=1) then r3 ← r3*2 */
11 cmp r3, r0, LSR #1 /* update cpsr with r3 - (r0/2) */
12 bls .Lloop2 /* branch to .Lloop2 if r3 <= 2*r0 (C=0 or Z=1) */
13
14 mov r2, #0 /* r2 ← 0 */
15
16 .Lloop3:
17 cmp r0, r3 /* update cpsr with r0 - r3 */
18 subhs r0, r0, r3 /* if r0 >= r3 (C=1) then r0 ← r0 - r3 */
19 adc r2, r2, r2 /* r2 ← r2 + r2 + C.
20 Note that if r0 >= r3 then C=1, C=0 otherwise */
21
22 mov r3, r3, LSR #1 /* r3 ← r3/2 */
23 cmp r3, r1 /* update cpsr with r3 - r1 */
24 bhs .Lloop3 /* if r3 >= r1 branch to .Lloop3 */
25
26 bx lr
Podemos evitar el primer bucle en el que cambiamos hasta superar contando los ceros
iniciales . Contando los ceros iniciales del dividendo y el divisor, podemos calcular
directamente cuántos bits necesitamos para desplazar el divisor.

1clz_unsigned_division:
2 clz r3, r0 /* r3 ← CLZ(r0) Count leading zeroes of N */
3 clz r2, r1 /* r2 ← CLZ(r1) Count leading zeroes of D */
4 sub r3, r2, r3 /* r3 ← r2 - r3.
5 This is the difference of zeroes
6 between D and N.
7 Note that N >= D implies CLZ(N) <= CLZ(D)*/
8 add r3, r3, #1 /* Loop below needs an extra iteration count */
9
10 mov r2, #0 /* r2 ← 0 */
11 b .Lloop_check4
12 .Lloop4:
13 cmp r0, r1, lsl r3 /* Compute r0 - (r1 << r3) and update cpsr */
14 adc r2, r2, r2 /* r2 ← r2 + r2 + C.
15 Note that if r0 >= (r1 << r3) then C=1, C=0 otherwise */
16 subcs r0, r0, r1, lsl r3 /* r0 ← r0 - (r1 << r3) if C = 1 (this is, only if r0 >= (r1 << r3) ) */
17 .Lloop_check4:
18 subs r3, r3, #1 /* r3 ← r3 - 1 */
19 bpl .Lloop4 /* if r3 >= 0 (N=0) then branch to .Lloop1 */
20
21 mov r0, r2
22 bx lr

División firmada
La división con signo se puede calcular con una división sin signo pero cuidando los
signos. Primero podemos calcular | N | / | D | (esto es, ignorando los signos de Ny D), esto
producirá un cociente Q + y un resto R + . Si los signos de N y D son diferentes, Q =
-Q + . Si N <0, entonces R = -R + , como dijimos al comienzo del post.

Potencias de dos
Una división sin signo por una potencia de dos 2 N es tan simple como hacer un
desplazamiento lógico a la derecha de N bits. Por el contrario, una división con signo entre
una potencia de dos 2 N es tan simple como hacer un desplazamiento aritmético a la derecha
de N bits. Podemos usar movy los modos de direccionamiento LSRy ASRpara esto. Este caso
es ideal porque es extremadamente rápido.
División por un entero constante
Cuando dividimos un número por una constante, podemos usar una multiplicación por
un número mágico para calcular la división. Todos los detalles y la teoría de esta técnica
son demasiado largos para escribirlos aquí, pero puedes encontrarlos en el capítulo 10
de Hacker's Delight . Sin embargo, podemos resumirlo en tres valores: una constante
mágica M, un desplazamiento S y una bandera adicional. El autor creó una calculadora de
números mágicos que calcula estos números.

No es obvio cómo usar correctamente estos números mágicos, así que elaboré un pequeño
script de Python que emite código para el caso firmado y no firmado. Imagina que quieres
dividir un número sin firmar entre 14. Preguntemos a nuestro guión.
$ ./[Link] 14 code_for_unsigned
u_divide_by_14:
/* r0 contains the argument to be divided by 14 */
ldr r1, .Lu_magic_number_14 /* r1 ← magic_number */
umull r1, r2, r1, r0 /* r1 ← Lower32Bits(r1*r0). r2 ← Upper32Bits(r1*r0) */
adds r2, r2, r0 /* r2 ← r2 + r0 updating cpsr */
mov r2, r2, ROR #0 /* r2 ← (carry_flag << 31) | (r2 >> 1) */
mov r0, r2, LSR #4 /* r0 ← r2 >> 4 */
bx lr /* leave function */
.align 4
.Lu_magic_number_14: .word 0x24924925
De igual forma podemos solicitar la versión firmada:
$ ./[Link] 14 code_for_signed
s_divide_by_14:
/* r0 contains the argument to be divided by 14 */
ldr r1, .Ls_magic_number_14 /* r1 ← magic_number */
smull r1, r2, r1, r0 /* r1 ← Lower32Bits(r1*r0). r2 ← Upper32Bits(r1*r0) */
add r2, r2, r0 /* r2 ← r2 + r0 */
mov r2, r2, ASR #3 /* r2 ← r2 >> 3 */
mov r1, r0, LSR #31 /* r1 ← r0 >> 31 */
add r0, r2, r1 /* r0 ← r2 + r1 */
bx lr /* leave function */
.align 4
.Ls_magic_number_14: .word 0x92492493
Como ejemplo, lo he usado para implementar un pequeño programa que solo divide la
entrada del usuario entre 14.

1/* -- divideby14.s */
2
[Link]
4
[Link] 4
6read_number: .word 0
7
[Link] 4
 9message1 : .asciz "Enter an integer to divide it by 14: "
10
[Link] 4
12message2 : .asciz "Number %d (signed-)divided by 14 is %d\n"
13
[Link] 4
15scan_format : .asciz "%d"
16
[Link]
18
19/* This function has been generated using "[Link] 14 code_for_signed" */
20s_divide_by_14:
21 /* r0 contains the argument to be divided by 14 */
22 ldr r1, .Ls_magic_number_14 /* r1 ← magic_number */
23 smull r1, r2, r1, r0 /* r1 ← Lower32Bits(r1*r0). r2 ← Upper32Bits(r1*r0) */
24 add r2, r2, r0 /* r2 ← r2 + r0 */
25 mov r2, r2, ASR #3 /* r2 ← r2 >> 3 */
26 mov r1, r0, LSR #31 /* r1 ← r0 >> 31 */
27 add r0, r2, r1 /* r0 ← r2 + r1 */
28 bx lr /* leave function */
29 .align 4
30 .Ls_magic_number_14: .word 0x92492493
31
[Link] main
33
34main:
35 /* Call printf */
36 push {r4, lr}
37 ldr r0, addr_of_message1 /* r0 ← &message */
38 bl printf
39
40 /* Call scanf */
41 ldr r0, addr_of_scan_format /* r0 ← &scan_format */
42 ldr r1, addr_of_read_number /* r1 ← &read_number */
43 bl scanf
44
45 ldr r0, addr_of_read_number /* r1 ← &read_number */
46 ldr r0, [r0] /* r1 ← *r1 */
47
48 bl s_divide_by_14
49 mov r2, r0
50
51 ldr r1, addr_of_read_number /* r1 ← &read_number */
 52 ldr r1, [r1] /* r1 ← *r1 */
53
54 ldr r0, addr_of_message2 /* r0 ← &message2 */
55 bl printf /* Call printf, r1 and r2 already
56 contain the desired values */
57 pop {r4, lr}
58 mov r0, #0
59 bx lr
60
61addr_of_message1: .word message1
62addr_of_scan_format: .word scan_format
63addr_of_message2: .word message2
64addr_of_read_number: .word read_number

Usando VFPv2
No recomendaría usar esta técnica. Lo presento aquí en aras de la integridad. Simplemente
convertimos nuestros números enteros a números de punto flotante, los dividimos como
números de punto flotante y convertimos el resultado de nuevo a un número entero.

1vfpv2_division:
2 /* r0 contains N */
3 /* r1 contains D */
4 vmov s0, r0 /* s0 ← r0 (bit copy) */
5 vmov s1, r1 /* s1 ← r1 (bit copy) */
6 vcvt.f32.s32 s0, s0 /* s0 ← (float)s0 */
7 vcvt.f32.s32 s1, s1 /* s1 ← (float)s1 */
8 vdiv.f32 s0, s0, s1 /* s0 ← s0 / s1 */
9 vcvt.s32.f32 s0, s0 /* s0 ← (int)s0 */
10 vmov r0, s0 /* r0 ← s0 (bit copy). Now r0 is Q */
11 bx lr

Comparación de versiones
Después de un comentario a continuación, pensé que sería interesante comparar el
algoritmo de división general. El punto de referencia que utilicé es el siguiente:
.set MAX, 16384
main:
push {r4, r5, r6, lr}

mov r4, #1 /* r4 ← 1 */
 b .Lcheck_loop_i /* branch to .Lcheck_loop_i */
.Lloop_i:
mov r5, r4 /* r5 ← r4 */
b .Lcheck_loop_j /* branch to .Lcheck_loop_j */
.Lloop_j:

mov r0, r5 /* r0 ← r5. This is N */

mov r1, r4 /* r1 ← r4. This is D */

bl <your unsigned division routine here>

add r5, r5, #1

.Lcheck_loop_j:
cmp r5, #MAX /* compare r5 and MAX */
bne .Lloop_j /* if r5 != 10 branch to .Lloop_j */
add r4, r4, #1
.Lcheck_loop_i:
cmp r4, #MAX /* compare r4 and MAX */
bne .Lloop_i /* if r4 != 10 branch to .Lloop_i */

mov r0, #0

pop {r4, r5, r6, lr}

bx lr
Básicamente hace algo como esto
for (i = 1; i < MAX; i++)
for (j = i; j < MAX; j++)
division_function(j, i);
Los tiempos se han obtenido utilizando perf_3.2 stat --repeat=5 -e cpu-clock. En la siguiente
tabla, se __aeabi_uidivmuestra la función libgccque se gccusa para implementar una división
de enteros sin signo.

Versión Tiempo (segundos)

unsigned_longdiv 45,43

vfpv2_division 9,70

clz_unsigned_longdiv 8,48

__aeabi_uidiv 7,37
 better_unsigned_longdiv 6,67

Como puede ver, el desempeño de nuestra división larga sin firmar es pésimo. La razón es
que siempre verifica todos los bits. La versión libgcc es como nuestra versión clz pero el
bucle se ha desenrollado por completo y hay una rama calculada, similar al dispositivo de
Duff . Desafortunadamente, no tengo una explicación convincente de por qué
se better_unsigned_longdivejecuta más rápido que las otras versiones, porque el código, a
priori , me parece peor.

Ensamblador ARM en Raspberry Pi

- Capítulo 16
23 de agosto de 2013• Roger Ferrer Ibáñez • Raspberry Pi

Vimos en los capítulos 6 y 12 varias estructuras de control pero dejamos fuera una habitual:
el interruptor también conocido como select / case . En este capítulo veremos cómo
podemos implementarlo en ensamblador ARM.

Estructura de control de interruptores

Un interruptor en C tiene la siguiente estructura.
switch (E)
{
case V1: S1;
case V2: S2;
default: Sdefault;
}
En el ejemplo anterior, la expresión Ese evalúa y su valor se usa para determinar la
siguiente instrucción ejecutada. Entonces, si se Eevalúa V2, S2será la siguiente declaración
ejecutada. Si no casecoincide, toda la switchconstrucción se ignora a menos que haya
un defaultcaso cuya declaración se ejecute en su lugar.

Tenga en cuenta que, una vez que el flujo salta a una declaración, la ejecución continúa
desde ese punto a menos breakque se encuentre una declaración. La construcción de
la breakdeclaración switch. La mayoría de las veces, el programador agrega un breakpara
finalizar cada caso. De lo contrario , ocurren casos fallidos. En el ejemplo anterior, si
se Eevalúa ay V1no hay interrupción S1, el programa continuará ejecutándose S2y,
a Sdefaultmenos que el programa encuentre una breakdeclaración dentro de S2o Sdefault. La
caída puede parecer un poco extraña y confusa, pero hay algunos casos en los que es útil.

Dicho esto, C es un ejemplo particularmente malo para mostrar esta estructura. La razón es
que la definición de lenguaje exacta de a switchen C es la siguiente.
switch (E)
S;
Spuede ser cualquier cosa, pero el flujo siempre saltará a un caseo un defaultinterior S, por lo
que si Sno contiene ninguna de estas declaraciones, no pasa nada.
switch (E)
printf("This will never be printed\n");
Entonces, para switchque sea útil,necesitaremos al menos una declaración caseo default. Si se
necesita más de uno, entonces podemos usar una declaración compuesta (una lista de
declaraciones incluidas al lado {y }como se muestra en el primer ejemplo anterior.

Tenga en cuenta también que las declaraciones casey defaultsolo son válidas dentro Sde

a, switchpero esto no significa que deban anidarse inmediatamente dentro de ellas.
switch (E)
{
if (X) // Note that the check of the truth value of X will be never run!
{
default: printf ("Hi!\n");
}
else
{
case 10: printf ("Howdy stranger!\n");
}
}
Como puede ver, la switchdeclaración en C es bastante liberal. Otros lenguajes,
como Pascal o Fortran , tienen sintaxis más estrictas que no permiten fallos ni posiciones
sueltas de mayúsculas / minúsculas.
{ Case statement in Pascal }
Case Number of
1 : WriteLn ('One');
2 : WriteLn ('Two');
Else
WriteLn ('Other than one or two');
End;
En este post, no nos preocuparemos por estos extraños casos de switchaunque permitiremos
fallos.

Implementación de interruptor
Probablemente ya se habrá dado cuenta de que un interruptor que no implica fallos en
ninguno de sus casos es equivalente a una secuencia de bloques if-else. Lo siguiente switch,
switch (x)
{
case 5: code_for_case5; break;
case 10: code_for_case10; break;
default: code_for_default; break;
// break would not be required here as this is the last case
}
se puede implementar como
if (x == 5)
code_for_case5;
else if (x == 10)
code_for_case10;
else /* default */
code_for_default;

code_after;
A diferencia de la instrucción if-else habitual, no es necesario que haya una rama que vaya
después de la instrucción if una vez que se haya ejecutado la rama if. Esto es, en el ejemplo
anterior, es opcional tener una rama después de la code_for_case5que va a code_after. Si se
omite dicha rama, entonces code_for_case10ocurre una caída de forma natural. Entonces,
la breakdeclaración dentro de a switches simplemente esa rama incondicional.
/* Here we evaluate x and keep it in r0 */
case_5: /* case 5 */
cmp r0, #5 /* Compute r0 - 5 and update cpsr */
bne case_10 /* if r0 != 5 branch to case_10 */
code_for_case5
b after_switch /* break */

case_10: /* case 10 */
cmp r0, #10 /* Compute r0 - 10 and update cpsr */
bne case_default /* If r0 != 10 branch to case_default */
code_for_case10
b after_switch /* break */

case_default:
code_for_default
/* Note that if default is not the last case
we need a branch to after_switch here */

after_switch:
Podemos poner todas las comprobaciones al principio, siempre que conservemos el orden
de los casos (por lo que el fallo funciona si breakse omite).
/* Here we evaluate x and keep it in r0 */
cmp r0, #5 /* Compute r0 - 5 and update cpsr */
beq case_5 /* if r0 == 5 branch to case_5 */
cmp r0, #10 /* Compute r0 - 10 and update cpsr */
beq case_10 /* if r0 == 10 branch to case_10 */
b case_default /* branch to default case
Note that there is no default case
we would branch to after_switch */

case_5: /* case 5 */
code_for_case5
b after_switch /* break */

case_10: /* case 10 */
code_for_case10
b after_switch /* break */

case_default:
 code_for_default
/* Note that if default is not the last case
we need a branch to after_switch here */

after_switch:
Este enfoque es sensato si el número de casos es bajo. Aquí "bajo" no está muy bien
definido, digamos 10 o menos. ¿Y si tenemos muchos casos? Una secuencia de
comprobaciones if-else hará tantas comparaciones como casos. Si los valores de los N
casos se distribuyen uniformemente durante la ejecución del programa, esto significa que
en promedio tendremos que hacer N / 2 verificaciones. Si los valores no se distribuyen
uniformemente, entonces es obvio que debemos verificar los valores comunes primero y los
raros al final (lamentablemente, la mayoría de las veces no tenemos idea de su frecuencia).

Hay varias formas de reducir el costo de verificar los casos: tablas y búsqueda binaria.

Tablas de salto
Imagina que tenemos uno switchcomo este
switch (x)
{
case 1: do_something_1;
case 2: do_something_2;
...
case 100: do_something_100;
}
Si lo implementamos de la manera que se muestra arriba, haremos en promedio (para un
conjunto de valores distribuidos uniformemente x) 50 comparaciones. Podemos mejorar
esto si simplemente usamos el valor cpara indexar una tabla de direcciones a las
instrucciones de las instrucciones del caso.

Considere el programa a continuación donde usamos el valor argcde un programa en C. En

C, la mainfunción recibe dos parámetros, argcy argv: argces solo un número entero, en el
registro r0como de costumbre; argves una dirección, en el registro r1como de costumbre, a
una matriz de los argumentos pasados en la línea de comandos. Hay tantos
elementos argvcomo el valor de argc, al menos uno. No usaremos argvhoy, solo argc.
int main(int argc, char *argv[])
{
int x;
switch (argc)
{
case 1: x = 1; break;
case 2: x = 2; break;
case 3: x = 3; break;
default: x = 42; break;
}
return x;
}
Estamos usando solo 3 casos más el predeterminado, pero no sería complejo (aunque
engorroso) extenderlo a 100 casos.
 1/* jumptable.s */
[Link]
3
[Link]
5
[Link] main
7
8main:
9 cmp r0, #1 /* r0 - 1 and update cpsr */
10 blt case_default /* branch to case_default if r0 < 1 */
11 cmp r0, #3 /* r0 - 3 and update cpsr */
12 bgt case_default /* branch to case_default if r0 > 3 */
13
14 sub r0, r0, #1 /* r0 ← r0 - 1. Required to index the table */
15 ldr r1, addr_of_jump_table /* r1 ← &jump_table */
16 ldr r1, [r1, +r0, LSL #2] /* r1 ← *(r1 + r0*4).
17 This is r1 ← jump_table[r0] */
18
19 mov pc, r1 /* pc ← r1
20 This will cause a branch to the
21 computed address */
22
23 case_1:
24 mov r0, #1 /* r0 ← 1 */
25 b after_switch /* break */
26
27 case_2:
28 mov r0, #2 /* r0 ← 2 */
29 b after_switch /* break */
30
31 case_3:
32 mov r0, #3 /* r0 ← 3 */
33 b after_switch /* break */
34
35 case_default:
36 mov r0, #42 /* r0 ← 42 */
37 b after_switch /* break (unnecessary) */
38
39 after_switch:
40
41 bx lr /* Return from main */
42
[Link] 4
 44jump_table:
45 .word case_1
46 .word case_2
47 .word case_3
48
[Link] 4
50addr_of_jump_table: .word jump_table

Como puede ver en la línea 43 definimos una tabla de salto, cuyos elementos son las
direcciones de las etiquetas de cada caso (en orden). En las líneas 14 a 16 cargamos el valor
apropiado de esa tabla después de estar seguros de que el valor de argc está entre 1 y 3,
comprobado en las líneas 9 a 12. Finalmente, cargamos la dirección a pc. Esto
efectivamente hará una ramificación al caso adecuado.

Si ejecuta el programa verá diferentes códigos de salida devueltos (recuerde que ellos
vuelven a sintonizarse a través r0de main). El programa solo cuenta los argumentos, si en
lugar de "a b" usa "uno dos", también devolverá 3. Más de dos argumentos y devolverá 42.
$ ./jumptable ; echo $?
1
$ ./jumptable a ; echo $?
2
$ ./jumptable a b ; echo $?
3
$ ./jumptable a b c ; echo $?
42
Para usar la tabla de salto de forma segura, debemos asegurarnos de que el valor del caso se
encuentre dentro de los límites de la tabla. Si m es el valor de caso mínimo y M es el valor
de caso máximo, nuestra tabla tendrá M - m + 1 entradas. En el ejemplo anterior m = 1 y M
= 3, tenemos 3 entradas en la tabla. Tenemos que asegurarnos de que el valor utilizado para
indexar sea m ≤ x ≤ M, de lo contrario estaríamos accediendo a ubicaciones de memoria
incorrectas. Recuerde también que para indexar correctamente la tabla de salto tendremos
que restar m al valor del caso.

Las tablas de salto son geniales, una vez que hemos verificado que el valor del caso está en
el rango adecuado (estas son dos comparaciones), no tenemos que comparar nada
más. Entonces, básicamente, el costo de las comparaciones en este enfoque es constante (es
decir, no aumenta si aumenta el número de casos).

Hay dos grandes desventajas de este enfoque que nos impiden usarlo siempre. El primero
ocurre cuando la diferencia entre M y m es grande, nuestra tabla de salto será grande. Esto
aumenta el tamaño del código. Básicamente, hemos cambiado el tiempo por el
espacio. Ahora nuestro tamaño de código agregará 4 bytes por caso manejado en una tabla
de salto. Una tabla de 256 entradas ocupará hasta 1 Kbyte (1024 bytes) de memoria en
nuestro programa ejecutable. Para ser justos, esta es la cantidad de espacio que ocupan 256
instrucciones. Entonces, si el tamaño del código es una preocupación para usted (y
generalmente lo es en el mundo integrado), este enfoque puede no ser adecuado. La
segunda gran desventaja ocurre cuando hay "huecos" en los casos. Imagine que nuestros
casos son solo 1, 3 y 100. La tabla tendrá 100 elementos, pero solo 1, 3 y 100 tendrán
entradas útiles: todas las entradas restantes tendrán la dirección del caso predeterminado (o
la dirección después del cambio si se omite el caso predeterminado). En este caso, no solo
estamos tomando 400 bytes, estamos desperdiciando 388 bytes (¡el 97% de las entradas
serían inútiles!). Entonces, si el número de casos es bajo y los valores están dispersos en un
rango grande, las tablas de salto no son una buena opción.

Calcule la dirección del caso

Esta estrategia es un poco complicada y tiene más restricciones que una tabla de salto, por
lo que es menos general. Si todos los casos están ordenados y toman la misma cantidad de
instrucciones, podemos calcular la dirección del caso sin usar una tabla de salto. Esto es
arriesgado porque tenemos que tener cuidado al calcular la dirección de la sucursal usando
el valor actual (de lo contrario, saltaremos a una dirección incorrecta y seguramente
sucederán cosas malas).

Si no todos los casos toman la misma cantidad de instrucciones, podemos compensarlos

para que tomen tantas instrucciones como el caso con la mayor cantidad de
instrucciones. Podemos hacer eso usando la nopinstrucción que no hace más que ocupar
espacio. Si la varianza del número de instrucciones entre los casos es pequeña,
terminaremos agregando algunos nopsa algunos casos. Si la varianza es grande, podemos
terminar con un exceso de código , algo que queríamos evitar al usar esta técnica.

Si hay agujeros, podemos simplemente ramificarlos al caso predeterminado y completar las

instrucciones restantes con nops. Nuevamente, si el número de agujeros es grande, esto
también es propenso a que el código se hinche.

En nuestro ejemplo de la tabla de salto, cada caso requiere solo dos instrucciones. Entonces
podemos obtener la dirección del primer caso y usarla como dirección base para calcular la
rama.

1/* calcjump.s */
[Link]
3
[Link]
5
[Link] main
7
8main:
9 cmp r0, #1 /* r0 - 1 and update cpsr */
10 blt case_default /* branch to case_default if r0 < 1 */
11 cmp r0, #3 /* r0 - 3 and update cpsr */
12 bgt case_default /* branch to case_default if r0 > 3 */
13
14 sub r0, r0, #1 /* r0 ← r0 - 1. Required to index the table */
 15 ldr r1, addr_of_case_1 /* r1 ← &case_1 */
16 add r1, r1, r0, LSL #3 /* r1 ← r1 + r0 * 8
17 Each instruction is 4 bytes
18 Each case takes 2 instructions
19 Thus, each case is 8 bytes (4 * 2)
20 */
21
22 mov pc, r1 /* pc ← r1
23 This will cause a branch to the
24 computed address */
25
26 case_1:
27 mov r0, #1 /* r0 ← 1 */
28 b after_switch /* break */
29
30 case_2:
31 mov r0, #2 /* r0 ← 2 */
32 b after_switch /* break */
33
34 case_3:
35 mov r0, #3 /* r0 ← 3 */
36 b after_switch /* break */
37
38 case_default:
39 mov r0, #42 /* r0 ← 42 */
40 b after_switch /* break (unnecessary) */
41
42 after_switch:
43
44 bx lr /* Return from main */
45
[Link] 4
47addr_of_case_1: .word case_1

Búsqueda binaria
Considere nuevamente nuestro ejemplo con 100 casos. Una serie de if-else requerirá en
promedio 50 comparaciones. ¿Podemos reducir el número de comparaciones? Bueno, la
respuesta es sí. Realice una búsqueda binaria del caso.

Una búsqueda binaria descartará la mitad del conjunto de casos cada vez. Esto nos
permitirá reducir drásticamente la cantidad de comparaciones. El siguiente ejemplo
implementa el mismo código en la tabla de salto pero con los casos 1 a 10.
 1/* binsearch.s */
[Link]
3
[Link]
5
[Link] main
7
8main:
9
10 cmp r0, #1 /* r0 - 1 and update cpsr */
11 blt case_default /* if r0 < 1 then branch to case_default */
12 cmp r0, #10 /* r0 - 10 and update cpsr */
13 bgt case_default /* if r0 > 10 then branch to case default */
14
15 case_1_to_10:
16 cmp r0, #5 /* r0 - 5 and update cpsr */
17 beq case_5 /* if r0 == 5 branch to case_5 */
18 blt case_1_to_4 /* if r0 < 5 branch to case_1_to_4 */
19 bgt case_6_to_10 /* if r0 > 5 branch to case_6_to_4 */
20
21 case_1_to_4:
22 cmp r0, #2 /* r0 - 2 and update cpsr */
23 beq case_2 /* if r0 == 2 branch to case_2 */
24 blt case_1 /* if r0 < 2 branch to case_1
25 (case_1_to_1 does not make sense) */
26 bgt case_3_to_4 /* if r0 > 2 branch to case_3_to_4 */
27
28 case_3_to_4:
29 cmp r0, #3 /* r0 - 3 and update cpsr */
30 beq case_3 /* if r0 == 3 branch to case_3 */
31 b case_4 /* otherwise it must be r0 == 4,
32 branch to case_4 */
33
34 case_6_to_10:
35 cmp r0, #8 /* r0 - 8 and update cpsr */
36 beq case_8 /* if r0 == 8 branch to case_8 */
37 blt case_6_to_7 /* if r0 < 8 then branch to case_6_to_7 */
38 bgt case_9_to_10 /* if r0 > 8 then branch to case_9_to_10 */
39
40 case_6_to_7:
41 cmp r0, #6 /* r0 - 6 and update cpsr */
42 beq case_6 /* if r0 == 6 branch to case_6 */
43 b case_7 /* otherwise it must be r0 == 7,
 44 branch to case 7 */
45
46 case_9_to_10:
47 cmp r0, #9 /* r0 - 9 and update cpsr */
48 beq case_9 /* if r0 == 9 branch to case_9 */
49 b case_10 /* otherwise it must be r0 == 10,
50 branch to case 10 */
51
52 case_1:
53 mov r0, #1
54 b after_switch
55 case_2:
56 mov r0, #2
57 b after_switch
58 .
59 . /* Cases from 3 to 9 omitted */
60 .
61 case_10:
62 mov r0, #10
63 b after_switch
64
65 case_default:
66 mov r0, #42 /* r0 ← 42 */
67 b after_switch /* break (unnecessary) */
68
69 after_switch:
70
71 bx lr /* Return from main */

Esta estrategia es capaz de determinar el valor del caso en solo 3 comparaciones (si
ignoramos las dos comparaciones obligatorias para la verificación de rango). Lo que
hacemos es verificar y comparar el valor del caso con el del medio en el rango actual. De
esta forma podemos descartar la mitad de los conjuntos en cada paso de comparación.

Esta estrategia también funciona bien para conjuntos de casos dispersos como [1, 2, 3, 24,
25, 26, 97, 98, 99, 300]. En este caso las comparaciones serían
case_1_to_300:
cmp r0, #25
beq case_25
blt case_1_to_24
bgt case_26_to_300
case_1_to_24:
cmp r0, #2
beq case_2
blt case_1
 bgt case_3_to_24
case_3_to_24:
cmp r0, #3
beq case_3
b case_24
case_26_to_300:
cmp r0, #98
beq case_98
blt case_26_to_97
bgt case_99_to_300
case_26_to_97:
cmp r0, #26
beq case_26
b case_97
case_99_to_300:
cmp r0, #99
beq case_99
b case_300
que son 3 comparaciones como máximo también.

Usando esta estrategia, el número de comparaciones es log (N), donde N es el número de

elementos en el conjunto de casos. Así que para 10 elementos, en el peor de los casos,
tendremos que hacer 3 comparaciones, para 20 como máximo 4, para 40 como máximo 5,
etc.

Retomemos el problema de la hinchazón del código que surgió con las tablas de salto. Si
marca, cada comparación requiere 3 o 4 instrucciones, esto es aproximadamente de 12 a 16
bytes por comparación. Si tenemos un conjunto de casos de 256 elementos, el código
generado requerirá 128 bloques de comparación en total. Si bien el número de
comparaciones realizadas en tiempo de ejecución, 8 en el peor de los casos, todavía
necesitamos 128 case_x_to_ybloques de comparación para realizar la búsqueda binaria. Si
asumimos de manera pesimista que todos los bloques de comparación toman 4
instrucciones, esto será 4 * 128 * 4 = 2048 bytes en instrucciones. Compare eso con una
tabla de salto de 256 posiciones, cada posición ocupa 4 bytes: 256 * 4 = 1024
bytes. Entonces, la búsqueda binaria no es tan competitiva en términos de tamaño de
código.

La búsqueda binaria, por lo tanto, es útil para grandes conjuntos dispersos. Recuerde que
las cadenas if-else no son eficientes para grandes conjuntos de casos y las tablas de salto
desperdician espacio si el rango de casos carece de muchos casos.

Enfoque híbrido
¿Es posible combinar las dos estrategias? La respuesta es sí. Usaremos dos tablas: una tabla
de valores de casos (ordenada, generalmente en orden ascendente) y direcciones para cada
caso en otra tabla, en el mismo orden que la tabla de valores de casos.

Haremos una búsqueda binaria dentro del conjunto de valores del caso. Cuando se
encuentre el valor, usaremos el índice de la coincidencia para calcular un salto. Para el
siguiente ejemplo usaremos el conjunto de casos [1, 2, 3, 24, 25, 26, 97, 98, 99, 300].
 1/* hybrid.s */
[Link]
3
[Link]
5
[Link] main
7
8main:
9 push {r4, r5, r6, lr}
10
11 cmp r0, #1 /* r0 - 1 and update cpsr */
12 blt case_default /* if r0 < 1 then branch to case_default */
13 cmp r0, #300 /* r0 - 300 and update cpsr */
14 bgt case_default /* if r0 > 300 then branch to case default */
15
16 /* prepare the binary search.
17 r1 will hold the lower index
18 r2 will hold the upper index
19 r3 the base address of the case_value_table
20 */
21 mov r1, #0
22 mov r2, #9
23 ldr r3, addr_case_value_table /* r3 ← &case_value_table */
24
25 b check_binary_search
26 binary_search:
27 add r4, r1, r2 /* r4 ← r1 + r2 */
28 mov r4, r4, ASR #1 /* r4 ← r4 / 2 */
29 ldr r5, [r3, +r4, LSL #2] /* r5 ← *(r3 + r4 * 4).
30 This is r5 ← case_value_table[r4] */
31 cmp r0, r5 /* r0 - r5 and update cpsr */
32 sublt r2, r4, #1 /* if r0 < r5 then r2 ← r4 - 1 */
33 addgt r1, r4, #1 /* if r0 > r5 then r1 ← r4 + 1 */
34 bne check_binary_search /* if r0 != r5 branch to binary_search */
35
36 /* if we reach here it means that r0 == r5 */
37 ldr r5, addr_case_addresses_table /* r5 ← &addr_case_value_table */
38 ldr r5, [r5, +r4, LSL #2] /* r5 ← *(r5 + r4*4)
39 This is r5 ← case_addresses_table[r4] */
40 mov pc, r5 /* branch to the proper case */
41
42 check_binary_search:
43 cmp r1, r2 /* r1 - r2 and update cpsr */
44 ble binary_search /* if r1 <= r2 branch to binary_search */
45
46 /* if we reach here it means the case value
47 was not found. branch to default case */
48 b case_default
49
50 case_1:
51 mov r0, #1
52 b after_switch
53 case_2:
54 mov r0, #2
55 b after_switch
56 case_3:
57 mov r0, #3
58 b after_switch
59 case_24:
60 mov r0, #24
61 b after_switch
62 case_25:
63 mov r0, #95
64 b after_switch
65 case_26:
66 mov r0, #96
67 b after_switch
68 case_97:
69 mov r0, #97
70 b after_switch
71 case_98:
72 mov r0, #98
73 b after_switch
74 case_99:
75 mov r0, #99
76 b after_switch
77 case_300:
78 mov r0, #300 /* The error code will be 44 */
79 b after_switch
80
81 case_default:
82 mov r0, #42 /* r0 ← 42 */
83 b after_switch /* break (unnecessary) */
84
85 after_switch:
86
 87 pop {r4,r5,r6,lr}
88 bx lr /* Return from main */
89
90case_value_table: .word 1, 2, 3, 24, 25, 26, 97, 98, 99, 300
91addr_case_value_table: .word case_value_table
92
93case_addresses_table:
94 .word case_1
95 .word case_2
96 .word case_3
97 .word case_24
98 .word case_25
99 .word case_26
100 .word case_97
101 .word case_98
102 .word case_99
103 .word case_300
104addr_case_addresses_table: .word case_addresses_table

En las líneas 21 a 44 implementamos la búsqueda binaria. Esta aplicación es una búsqueda

binaria iterativo donde r1y r2mantener los índices inferior y superior de la tabla que en la
actualidad se busca. Dejaremos la búsqueda si el índice inferior se vuelve más grande que
el superior, líneas 42 a 44. Al buscar el rango dado por r1y r2, calcularemos r4como índice
medio (r1+r2)/2, líneas 27 a 28. Lo compararemos con el valor actual del caso. siendo
buscado, en la r0línea 31. Si el valor,, r5en la tabla de valores de caso (que debe estar en
orden ascendente) es menor que el valor de caso actual que se busca, entonces reducimos el
rango de r1a r4-1, por lo que actualizamos r2solo si r0 < r5, línea 32. Por el contrario, sir0 >
r5luego reducimos el rango de r4+1a r2, línea 33. Si el valor de r5coincidencias, usamos el
índice r4para cargar la dirección del caso y derivar a él, líneas 37 a 40. Tenga en cuenta que
si r0es diferente a r5, debemos omitir este paso así que nos ramificamos al cheque del bucle,
línea 34.

Puedes comprobar que esto funciona.

$ ./hybrid ; echo $?
1
$ ./hybrid 2 ; echo $?
2
$ ./hybrid 2 3 ; echo $?
3
$ ./hybrid 2 3 4 ; echo $?
42
$ ./hybrid 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ; echo $?
24
Este enfoque tiene varias propiedades interesantes. Reduce el número de comparaciones
(haremos el mismo número de comparaciones que en la búsqueda binaria) y evita el exceso
de código debido a tablas de salto grande (evitando entradas inútiles) y bloques de
comparación (usando un bucle). Como inconveniente, este enfoque requiere dos tablas.

Ensamblador ARM en Raspberry Pi

- Capítulo 17
20 de noviembre de 2013• Roger Ferrer Ibáñez • Raspberry Pi

En el capítulo 10 vimos los conceptos básicos para llamar a una función. En este capítulo
cubriremos más temas relacionados con las funciones.

Pasando datos a funciones

Ya sabemos cómo llamar a una función y pasarles parámetros. También sabemos cómo
devolver datos de una función. Sin embargo, hay algunos problemas que aún no hemos
resuelto por completo.

 Pasar grandes cantidades de datos

 Devolver más de un dato

Hay varias formas de abordar este problema, pero la mayoría de ellas implican
sugerencias. Los punteros son temidos por muchas personas, que no los comprenden
completamente, pero son una parte crucial en la forma en que funcionan las
computadoras. Dicho esto, la mayoría de los problemas con los punteros en realidad están
relacionados con la memoria dinámica más que con los punteros en sí. No consideraremos
aquí la memoria dinámica.

Entonces, ¿qué es un puntero?

Un puntero es una ubicación en la memoria cuyo contenido es simplemente una dirección
de la memoria.

Esta definición puede resultar confusa, pero ya hemos estado usando punteros en capítulos
anteriores. Es solo que no los nombramos de esta manera. Por lo general, hablamos
de direcciones y / o etiquetas en el ensamblador. Considere este programa muy simple:
/* first_pointer.s */

.data

.align 4
number_1 : .word 3

.text
.globl main

main:
ldr r0, pointer_to_number /* r0 ← &number */
ldr r0, [r0] /* r0 ← *r0. So r0 ← number_1 */

bx lr

pointer_to_number: .word number_1

Como puede ver, utilicé deliberadamente el nombre pointer_to_numberpara expresar el hecho
de que esta ubicación en la memoria es en realidad un puntero. Es un puntero
a number_1porque contiene su dirección.

Imagine que agregamos otro número, llamémoslo number_2y

queremos pointer_to_numberpoder señalar number_2, esto es, contener la dirección
de number_2también. Hagamos un primer intento.
.data

.align 4
number_1 : .word 3
number_2 : .word 4

.text
.globl main

main:
ldr r1, address_of_number_2 /* r1 ← &number_2 */
str r1, pointer_to_number /* pointer_to_number ← r1, this is pointer_to_number ← &number_2 */

bx lr

pointer_to_number: .word number_1

address_of_number_2: .word number_2
Pero si ejecuta esto, obtendrá una mala educación Segmentation fault. En realidad, no
podemos modificar pointer_to_numberporque, incluso si es una ubicación de la memoria que
contiene una dirección (y contendría otra dirección después de la tienda), no está en
la datasección, sino en la textsección. Así que este es un puntero definido estáticamente,
cuyo valor (es decir, la dirección que contiene) no puede cambiar. Entonces, ¿cómo
podemos tener un puntero que pueda cambiar? Pues tendremos que ponerlo en
el dataapartado, donde solemos poner todos los datos de nuestro programa.
[Link]
[Link] 4
3number_1 : .word 3
4number_2 : .word 4
5pointer_to_number: .word 0
6
[Link]
[Link] main
9
 10
11main:
12 ldr r0, addr_of_pointer_to_number
13 /* r0 ← &pointer_to_number */
14
15 ldr r1, addr_of_number_2 /* r1 ← &number_2 */
16
17 str r1, [r0] /* *r0 ← r1.
18 This is actually
19 pointer_to_number ← &number_2 */
20
21 ldr r1, [r0] /* r1 ← *r0.
22 This is actually
23 r1 ← pointer_to_number
24 Since pointer_to_number has the value &number_2
25 then this is like
26 r1 ← &number_2
27 */
28
29
30 ldr r0, [r1] /* r0 ← *r1
31 Since r1 had as value &number_2
32 then this is like
33 r0 ← number_2
34 */
35
36 bx lr
37
38addr_of_number_1: .word number_1
39addr_of_number_2: .word number_2
40addr_of_pointer_to_number: .word pointer_to_number

De este último ejemplo deberían quedar claras varias cosas. Tenemos punteros estáticos
a number_1, number_2y pointer_to_number(respectivamente
llamados addr_of_number_1, addr_of_number_2y addr_of_pointer_to_number). ¡Tenga en cuenta que
en addr_of_pointer_to_numberrealidad es un puntero a un puntero! ¿Por qué estos punteros
están definidos estáticamente? Bueno, podemos nombrar ubicaciones de memoria (es decir,
direcciones) usando etiquetas (de esta manera no tenemos que saber realmente la dirección
exacta y al mismo tiempo podemos usar un nombre descriptivo). Estas ubicaciones de
memoria, nombradas mediante etiquetas, nunca cambiarán durante la ejecución del
programa, por lo que de alguna manera están predefinidas antes de que se inicie el
programa. Esta es la razón por la que las direcciones
de number_1, number_2y addr_of_pointer_to_numberse definen y almacenan estáticamente en una
parte del programa que no puede cambiar ([Link] no se puede modificar la sección cuando
se ejecuta el programa).

Esto significa que acceder al pointer_to_numberuso addr_of_pointer_to_numberimplica usar un

puntero a un puntero. No es nada lujoso aquí, un puntero a un puntero es solo una ubicación
de la memoria que contiene la dirección de otra ubicación de la memoria que sabemos que
también es un puntero.

El programa simplemente carga el valor 4, almacenado

en number_2using pointer_to_number. Primero cargamos la dirección del puntero (esto es, el
puntero al puntero, pero la dirección del puntero puede ser más clara) r0en la línea 13.
Luego hacemos lo mismo con la dirección de number_2, guardándola en la r1línea 16. Luego,
en la línea 18 actualizamos el valor pointer_to_number(recuerde, el valor de un puntero
siempre será una dirección) con la dirección de number_2. En la línea 22 obtenemos el valor
de pointer_to_numbercargarlo en r1. Insisto de nuevo: el valor de pointer_to_numberes una
dirección, por lo que ahora r1 contiene una dirección. Esta es la razón por la que en la línea
31 cargamos r0el valor de in r1.

Pasar grandes cantidades de datos

Cuando pasamos datos a funciones seguimos las convenciones definidas en
AAPCS. Intentamos llenar los primeros 4 registros r0 a r3. Si se esperan más datos,
debemos usar la pila. Esto significa que si tuviéramos que pasar una gran cantidad de datos
a una función, podríamos terminar gastando mucho tiempo simplemente preparando la
llamada (configurando los registros r0 a r3 y luego empujando todos los datos en la parte
superior de la pila, y recuerde, en orden inverso!) que ejecutar el código de la función en sí.

Hay varios casos en los que surge esta situación. En un lenguaje como C, todos los
parámetros se pasan por valor. Esto significa que la función recibe una copia del valor. De
esta manera, la función puede modificar libremente este valor y la persona que llama no
verá ningún cambio en él. Esto puede parecer ineficiente, pero desde el punto de vista de la
productividad, una función que no causa ningún efecto secundario a sus insumos puede
considerarse más fácil de entender que una que sí lo hace.
struct A
{
// big structure
};

// This function computes a 'thing_t' using a 'struct A'

thing_t compute_something(struct A);

void my_code(void)
{
struct A a;
thing_t something;

a = ...;
something = compute_something(a)
 // a is unchanged here!
}
Tenga en cuenta que en C, los tipos de matriz no se pasan por valor, pero esto es por
diseño: no hay valores de matriz en C aunque hay tipos de matriz (es posible que deba
repetirse esta última oración varias veces antes de comprenderla por completo;)

Si nuestra función va a modificar el parámetro y no queremos ver los cambios después de la

llamada, es poco lo que podemos hacer. Tenemos que invertir algo de tiempo en el paso de
parámetros.

Pero, ¿y si nuestra función no modifica realmente los datos? O, ¿qué pasa si estamos
interesados en los cambios que hizo la función? O mejor aún, ¿qué pasa si el parámetro que
se está modificando es en realidad otra salida de la función?

Bueno, todos estos escenarios involucran punteros.

Pasando una gran matriz por valor

Considere una matriz de enteros de 32 bits y queremos sumar todos los elementos. Nuestra
matriz estará en la memoria, es solo una secuencia contigua de enteros de 32
bits. Queremos pasar, de alguna manera, la matriz a la función (junto con la longitud de la
matriz si la longitud puede no ser constante), sumar todos los enteros y devolver la
suma. Tenga en cuenta que en este caso la función no modifica la matriz, solo la lee.

Hagamos una función sum_array_valueque debe tener la matriz de enteros pasados por

valor. El primer parámetro, r0será el número de elementos de la matriz de
enteros. Registros r1a r3pueden (o no) tener un valor en función del número de elementos
en el array. Entonces, los primeros tres elementos deben manejarse de manera
diferente. Luego, si aún quedan elementos, deben cargarse desde la pila.
1sum_array_value :
2 push {r4, r5, r6, r7, lr}
3
4 /* We have passed all the data by value */
5
6 /* r4 will hold the sum so far */
7 mov r4, #0 /* r4 ← 0 */
8 /* In r0 we have the number of items of the array */
9
10 cmp r0, #1 /* r0 - #1 and update cpsr */
11 blt .Lend_of_sum_array /* if r0 < 1 branch to end_of_sum_array */
12 add r4, r4, r1 /* add the first item */
13
14 cmp r0, #2 /* r0 - #2 and update cpsr */
15 blt .Lend_of_sum_array /* if r0 < 2 branch to end_of_sum_array */
16 add r4, r4, r2 /* add the second item */
17
18 cmp r0, #3 /* r0 - #3 and update cpsr */
19 blt .Lend_of_sum_array /* if r0 < 3 branch to end_of_sum_array */
20 add r4, r4, r3 /* add the third item */
21
22 /*
23 The stack at this point looks like this
24 | | (lower addresses)
25 | |
26 | r4 | ← sp points here
27 | r5 | ← this is sp + 4
28 | r6 | ← this is sp + 8
29 | r7 | ← preserve 8 byte alignment, this is sp + 12
30 | lr | ← this is sp + 12
31 | big_array[3] | ← this is sp + 20 (we want r5 to point here)
32 | big_array[4] |
33 | ... |
34 | big_array[255] |
35 | |
36 | | (higher addresses)
37
38 keep in r5 the address where the stack-passed portion of the array starts */
39 add r5, sp, #20 /* r5 ← sp + 20 */
40
41 /* in register r3 we will count how many items we have read
42 from the stack. */
43 mov r3, #0
44
45 /* in the stack there will always be 3 less items because
46 the first 3 were already passed in registers
47 (recall that r0 had how many items were in the array) */
48 sub r0, r0, #3
49
50 b .Lcheck_loop_sum_array
51 .Lloop_sum_array:
52 ldr r6, [r5, r3, LSL #2] /* r6 ← *(r5 + r3 * 4) load
53 the array item r3 from the stack */
54 add r4, r4, r6 /* r4 ← r4 + r6
55 accumulate in r4 */
56 add r3, r3, #1 /* r3 ← r3 + 1
57 move to the next item */
58 .Lcheck_loop_sum_array:
59 cmp r3, r0 /* r0 - r3 and update cpsr */
 60 blt .Lloop_sum_array /* if r3 < r0 branch to loop_sum_array */
61
62 .Lend_of_sum_array:
63 mov r0, r4 /* r0 ← r4, to return the value of the sum */
64 pop {r4, r5, r6, r7, lr}
65
66 bx lr

La función no es particularmente complejo excepto para el manejo especial de las 3

primeras artículos (almacenado en r1a r3) y que tenemos que tener cuidado cuando se
localizan dentro de la pila de la matriz. Al ingresar a la función, los elementos de la matriz
que se pasan a través de la pila se distribuyen consecutivamente a partir
de sp. La pushinstrucción a los empujes que comienzan en la pila cuatro registros
( r4, r5, r6y lr) por lo que nuestra matriz se encuentra ahora en sp + 16(ver las líneas 30 y
38). Además de estos detalles, simplemente repetimos los elementos de la matriz y
acumulamos la suma en el registro r4. Finalmente, pasamos r4al r0valor de retorno de la
función.

Para llamar a esta función tenemos que poner una matriz en la pila. Considere el siguiente
programa.
[Link]
2
[Link] 4
4
5big_array :
[Link] 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21
[Link] 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41
[Link] 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61
[Link] 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81
[Link] 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100
[Link] 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116
[Link] 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132
[Link] 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148
[Link] 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164
[Link] 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180
[Link] 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196
[Link] 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212
[Link] 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228
[Link] 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244
[Link] 245, 246, 247, 248, 249, 250, 251, 252, 253, 254, 255
21
[Link] 4
23
24message: .asciz "The sum of 0 to 255 is %d\n"
25
[Link]
[Link] main
28
29sum_array_value :
30 /* code shown above */
31
32main:
33 push {r4, r5, r6, r7, r8, lr}
34 /* we will not use r8 but we need to keep the function 8-byte aligned */
35
36 ldr r4, address_of_big_array
37
38 /* Prepare call */
39
40 mov r0, #256 /* Load in the first parameter the number of items
41 r0 ← 256
42 */
43
44 ldr r1, [r4] /* load in the second parameter the first item of the array */
45 ldr r2, [r4, #4] /* load in the third parameter the second item of the array */
46 ldr r3, [r4, #8] /* load in the fourth parameter the third item of the array */
47
48 /* before pushing anything in the stack keep its position */
49 mov r7, sp
50
51 /* We cannot use more registers, now we have to push them onto the stack
52 (in reverse order) */
53 mov r5, #255 /* r5 ← 255
54 This is the last item position
55 (note that the first would be in position 0) */
56
57 b .Lcheck_pass_parameter_loop
58 .Lpass_parameter_loop:
59
60 ldr r6, [r4, r5, LSL #2] /* r6 ← *(r4 + r5 * 4).
61 loads the item in position r5 into r6. Note that
62 we have to multiply by 4 because this is the size
63 of each item in the array */
64 push {r6} /* push the loaded value to the stack */
65 sub r5, r5, #1 /* we are done with the current item,
66 go to the previous index of the array */
67 .Lcheck_pass_parameter_loop:
 68 cmp r5, #2 /* compute r5 - #2 and update cpsr */
69 bne .Lpass_parameter_loop /* if r5 != #2 branch to pass_parameter_loop */
70
71 /* We are done, we have passed all the values of the array,
72 now call the function */
73 bl sum_array_value
74
75 /* restore the stack position */
76 mov sp, r7
77
78 /* prepare the call to printf */
79 mov r1, r0 /* second parameter, the sum itself */
80 ldr r0, address_of_message /* first parameter, the message */
81 bl printf
82
83 pop {r4, r5, r6, r7, r8, lr}
84 bx lr
85
86address_of_big_array : .word big_array
87address_of_message : .word message

En la línea 40 comenzamos a preparar la llamada a sum_array_value. El primer parámetro,

pasado en el registro r0, es el número de elementos de esta matriz (en el ejemplo codificado
a 256 elementos). Luego pasamos los primeros tres elementos de la matriz en
registros r1a r3. Los elementos restantes deben pasarse a la pila. Recuerde que en una pila,
el último elemento empujado será el primero en aparecer, por lo que si queremos que
nuestra matriz se coloque en el mismo orden, tenemos que empujarla hacia atrás. Entonces
comenzamos desde el último elemento, la línea 53, y luego cargamos cada elemento y lo
empujamos a la pila. Una vez que todos los elementos se han insertado en la pila, podemos
llamar sum_array_value(línea 73).

Una advertencia importante al manipular la pila de esta manera es que es muy importante
restaurarla y dejarla en el mismo estado en que estaba antes de preparar la llamada. Esta es
la razón por la que nos mantenemos spen la r7línea 49 y la restauramos justo después de la
llamada en la línea 76. Olvidar hacer esto hará que las operaciones adicionales en la pila
empujen los datos al lugar equivocado o salgan de la pila datos incorrectos. Mantener la
pila sincronizada es esencial al llamar a funciones.

Pasando una gran matriz por referencia

Ahora probablemente esté pensando que pasar una gran matriz a través de la pila (junto con
todo el texto estándar que esto requiere) a una función que no la modifica, es, por decir lo
menos, un desperdicio.
Tenga en cuenta que, cuando la cantidad de datos es pequeña, los registros r0 a r3 suelen
ser suficientes, por lo que pasar por valor es asequible. Pasar algunos datos en la pila
también está bien, pero pasar grandes estructuras en la pila puede dañar el rendimiento
(especialmente si nuestra función se llama muchas veces).

¿Podemos hacerlo mejor? Si. En lugar de pasar copias de los valores de la matriz, ¿sería
posible pasar la dirección a la matriz? La respuesta es, nuevamente, sí. Este es el concepto
de pasar por referencia . Cuando pasamos por valor, el valor de los datos pasados se copia
de alguna manera (ya sea en un registro o en una pila). Aquí pasaremos una referencia (es
decir, una dirección) a los datos. Así que ahora terminamos simplemente pasando el
número de elementos y luego la dirección de la matriz, y dejamos que la función use esta
dirección para realizar su cálculo.

Considere el siguiente programa, que también suma una matriz de enteros pero ahora pasa
la matriz por referencia.
[Link]
2
[Link] 4
4
5big_array :
6 /* Same as above */
7
[Link] 4
9
10message: .asciz "The sum of 0 to 255 is %d\n"
11
[Link]
[Link] main
14
15sum_array_ref :
16 /* Parameters:
17 r0 Number of items
18 r1 Address of the array
19 */
20 push {r4, r5, r6, lr}
21
22 /* We have passed all the data by reference */
23
24 /* r4 will hold the sum so far */
25 mov r4, #0 /* r4 ← 0 */
26 mov r5, #0 /* r5 ← 0 */
27
28 b .Lcheck_loop_array_sum
29 .Lloop_array_sum:
 30 ldr r6, [r1, r5, LSL #2] /* r6 ← *(r1 + r5 * 4) */
31 add r4, r4, r6 /* r4 ← r4 + r6 */
32 add r5, r5, #1 /* r5 ← r5 + 1 */
33 .Lcheck_loop_array_sum:
34 cmp r5, r0 /* r5 - r0 and update cpsr */
35 bne .Lloop_array_sum /* if r5 != r0 go to .Lloop_array_sum */
36
37 mov r0, r4 /* r0 ← r4, to return the value of the sum */
38 pop {r4, r5, r6, lr}
39
40 bx lr
41
42
43main:
44 push {r4, lr}
45 /* we will not use r4 but we need to keep the function 8-byte aligned */
46
47 mov r0, #256
48 ldr r1, address_of_big_array
49
50 bl sum_array_ref
51
52 /* prepare the call to printf */
53 mov r1, r0 /* second parameter, the sum itself */
54 ldr r0, address_of_message /* first parameter, the message */
55 bl printf
56
57 pop {r4, lr}
58 bx lr
59
60address_of_big_array : .word big_array
61address_of_message : .word message

Ahora el código es mucho más simple ya que evitamos copiar los valores de la matriz en la
pila. Simplemente pasamos la dirección de la matriz como el segundo parámetro de la
función y luego la usamos para acceder a la matriz y calcular la suma. Mucho más simple,
¿no?

Modificar datos mediante punteros

Vimos al principio del post que podíamos modificar datos mediante punteros. Si pasamos
un puntero a una función, podemos dejar que la función también la modifique. Imagina una
función que toma un número entero y lo incrementa. Podríamos hacer esto devolviendo el
valor, por ejemplo.
increment:
add r0, r0, #1 /* r0 ← r0 + 1 */
Esto toma el primer parámetro (in r0), lo incrementa y lo devuelve (recuerde que
devolvemos enteros en r0).

Un enfoque alternativo podría ser recibir un puntero a algunos datos y dejar que la función
incremente los datos en la posición definida por el puntero.
increment_ptr:
ldr r1, [r0] /* r1 ← *r0 */
add r1, r1, #1 /* r1 ← r1 + 1 */
str r1, [r0] /* *r0 ← r1 */
Para un ejemplo más elaborado, retomemos el código de la matriz, pero esta vez en lugar de
calcular la suma de todos los valores, multiplicaremos cada elemento por dos y lo
mantendremos en la misma matriz. Para demostrar que lo hemos modificado, también
imprimiremos cada elemento.
1/* double_array.s */
2
[Link]
4
[Link] 4
6big_array :
7 /* Same as above */
8
[Link] 4
10message: .asciz "Item at position %d has value %d\n"
11
[Link]
[Link] main
14
15double_array :
16 /* Parameters:
17 r0 Number of items
18 r1 Address of the array
19 */
20 push {r4, r5, r6, lr}
21
22 mov r4, #0 /* r4 ← 0 */
23
24 b .Lcheck_loop_array_double
25 .Lloop_array_double:
26 ldr r5, [r1, r4, LSL #2] /* r5 ← *(r1 + r4 * 4) */
27 mov r5, r5, LSL #1 /* r5 ← r5 * 2 */
28 str r5, [r1, r4, LSL #2] /* *(r1 + r4 * 4) ← r5 */
29 add r4, r4, #1 /* r4 ← r4 + 1 */
30 .Lcheck_loop_array_double:
31 cmp r4, r0 /* r4 - r0 and update cpsr */
32 bne .Lloop_array_double /* if r4 != r0 go to .Lloop_array_double */
33
34 pop {r4, r5, r6, lr}
35
36 bx lr
37
38print_each_item:
39 push {r4, r5, r6, r7, r8, lr} /* r8 is unused */
40
41 mov r4, #0 /* r4 ← 0 */
42 mov r6, r0 /* r6 ← r0. Keep r0 because we will overwrite it */
43 mov r7, r1 /* r7 ← r1. Keep r1 because we will overwrite it */
44
45
46 b .Lcheck_loop_print_items
47 .Lloop_print_items:
48 ldr r5, [r7, r4, LSL #2] /* r5 ← *(r7 + r4 * 4) */
49
50 /* Prepare the call to printf */
51 ldr r0, address_of_message /* first parameter of the call to printf below */
52 mov r1, r4 /* second parameter: item position */
53 mov r2, r5 /* third parameter: item value */
54 bl printf /* call printf */
55
56 add r4, r4, #1 /* r4 ← r4 + 1 */
57 .Lcheck_loop_print_items:
58 cmp r4, r6 /* r4 - r6 and update cpsr */
59 bne .Lloop_print_items /* if r4 != r6 goto .Lloop_print_items */
60
61 pop {r4, r5, r6, r7, r8, lr}
62 bx lr
63
64main:
65 push {r4, lr}
66 /* we will not use r4 but we need to keep the function 8-byte aligned */
67
68 /* first call print_each_item */
69 mov r0, #256 /* first_parameter: number of items */
 70 ldr r1, address_of_big_array /* second parameter: address of the array */
71 bl print_each_item /* call to print_each_item */
72
73 /* call to double_array */
74 mov r0, #256 /* first_parameter: number of items */
75 ldr r1, address_of_big_array /* second parameter: address of the array */
76 bl double_array /* call to double_array */
77
78 /* second call print_each_item */
79 mov r0, #256 /* first_parameter: number of items */
80 ldr r1, address_of_big_array /* second parameter: address of the array */
81 bl print_each_item /* call to print_each_item */
82
83 pop {r4, lr}
84 bx lr
85
86address_of_big_array : .word big_array
87address_of_message : .word message

Si ejecuta este programa, verá que los elementos de la matriz se han duplicado de manera
efectiva.
...
Item at position 248 has value 248
Item at position 249 has value 249
Item at position 250 has value 250
Item at position 251 has value 251
Item at position 252 has value 252
Item at position 253 has value 253
Item at position 254 has value 254
Item at position 255 has value 255
Item at position 0 has value 0
Item at position 1 has value 2
Item at position 2 has value 4
Item at position 3 has value 6
Item at position 4 has value 8
Item at position 5 has value 10
Item at position 6 has value 12
Item at position 7 has value 14
Item at position 8 has value 16
Item at position 9 has value 18
...

Devolver más de un dato

Las funciones, según la convención AAPCS, devuelven sus valores en el registro r0(y r1si
el elemento devuelto tiene 8 bytes de longitud). Podemos devolver más de una cosa si
simplemente pasamos un puntero a algún almacenamiento (posiblemente en la pila) como
parámetro de la función. Más sobre este tema en el próximo capítulo.
Ensamblador ARM en Raspberry Pi
- Capítulo 18
11 de mayo de 2014• Roger Ferrer Ibáñez • Raspberry Pi

En este capítulo profundizaremos un poco más en la pila.

Datos locales
La mayoría de nuestros ejemplos que involucran datos almacenados en la memoria (en
contraste con los datos almacenados en registros) han usado variables globales . Las
variables globales son nombres globales, es decir, direcciones de la memoria que usamos a
través de etiquetas. Estas direcciones, de alguna manera, preexisten antes de que se ejecute
el programa. Esto se debe a que los definimos al definir el programa en sí.

A veces, sin embargo, es posible que queramos datos almacenados en la memoria cuya
existencia no esté ligada a la existencia del programa sino a la activación dinámica de una
función. Tal vez recuerde de los capítulos anteriores que la pila nos permite almacenar
datos cuya vida útil es la misma que la activación dinámica de una función. Aquí es donde
almacenaremos las variables locales , que a diferencia de las variables globales, solo
existen porque la función a la que pertenecen ha sido activada dinámicamente (es decir,
llamada / invocada).

En el capítulo 17 pasamos una matriz muy grande a través de la pila para pasar la matriz
por valor. Esto nos llevará a la conclusión de que, de alguna manera, los parámetros actúan
como datos locales, en particular cuando se pasan a través de la pila.

El puntero del marco

En ARM, tenemos muchos registros de propósito general (hasta 16, aunque algunos de
ellos con semántica muy estrecha, por lo que en realidad alrededor de 12 son realmente
utilizables como de propósito general) y el AAPCS nos obliga a usar registros para los 4
primeros parámetros. ( r0ar3, observe cómo esto es consistente con el hecho de que estos 4
registros son guardados por la persona que llama mientras que todos los demás registros
son guardados por la persona que llama). Otras arquitecturas, como 386, tienen un número
menor de registros de propósito general (alrededor de 6) y el enfoque habitual cuando se
pasan datos a funciones siempre involucra a la pila. Esto es así porque con una cantidad tan
pequeña de registros, pasar parámetros a través de los registros obligaría al llamador a
guardarlos, generalmente en la pila o en alguna otra memoria, lo que a su vez generalmente
requerirá al menos otro registro para indexar. Al usar la pila, se pueden obtener fácilmente
algunos registros más.
Hasta este punto uno se pregunte por qué la fuerza no siempre pasa todo a través de la pila
y olvidarse de registros r0a r3. Bueno, pasar por los registros será más rápido ya que no
tenemos que meternos con cargas y almacenes en la memoria. Además, la mayoría de las
funciones reciben solo unos pocos parámetros, o al menos no mucho más de 4, por lo que
tiene sentido aprovechar esta función.

Pero entonces surge un problema, ¿qué pasa si estamos pasando parámetros a través de la
pila y al mismo tiempo tenemos variables locales? Ambas entidades se almacenarán en la
pila. ¿Cómo podemos tratar con las dos fuentes de datos que se encuentran almacenadas en
la misma área de memoria?

Aquí es donde aparece el concepto de puntero de marco . Un puntero de marco es una

especie de marcador en la pila que usaremos para diferenciar las variables locales de los
parámetros. Quiero enfatizar el hecho de que un registro de cuadros casi siempre es
innecesario y siempre se pueden idear formas de evitarlo. Dicho esto, un puntero de marco
nos brinda una solución consistente para acceder a datos y parámetros locales en la pila. Por
supuesto, la mayoría de las cosas buenas tienen un precio, y el puntero del marco no es una
excepción: necesitamos usar un registro para ello. A veces, esta restricción puede ser
inaceptable, por lo que, casi siempre, podemos deshacernos del puntero del marco.

Debido a su naturaleza opcional, la AAPCS no especifica ni exige el puntero de

trama. Dicho esto, el enfoque habitual es utilizar el registro r11. Como una extensión
(aparentemente indocumentada, por lo que he podido decir) podemos usar el nombre fpque
es mucho más informativo que solo r11. Nada impone esta elección, podemos usar
cualquier otro registro como puntero de cuadro. Dado que usaremos fp(es decir r11),
tendremos que abstenernos de usar r11para cualquier otro propósito.

Enlace dinámico del registro de activación

El registro de activación es un nombre elegante para especificar el contexto de una función
llamada. Es decir, los datos y parámetros locales (si se pasan a través de la pila) de esa
función. Cuando se escribe una función con un puntero de cuadro, se requiere cierta
contabilidad para mantener correctamente el registro de activación.

Primero examinemos la estructura típica de una función.

1function:
2 /* Keep callee-saved registers */
3 push {r4, lr} /* Keep the callee saved registers */
4 ... /* code of the function */
5 pop {r4, lr} /* Restore the callee saved registers */
6 bx lr /* Return from the function */

Ahora modifiquemos la función para usar un puntero de marco (en el fragmento de código
a continuación, no importa el r5registro que solo aparece aquí para mantener alineada la pila
de 8 bytes).
 1function:
2 /* Keep callee-saved registers */
3 push {r4, r5, fp, lr} /* Keep the callee saved registers.
4 We added r5 to keep the stack 8-byte aligned
5 but the important thing here is fp */
6 mov fp, sp /* fp ← sp. Keep dynamic link in fp */
7 ... /* code of the function */
8 mov sp, fp /* sp ← fp. Restore dynamic link in fp */
9 pop {r4, r5, fp, lr} /* Restore the callee saved registers.
10 This will restore fp as well */
11 bx lr /* Return from the function */

Concéntrese en las instrucciones en las líneas 6 y 8. En la línea 6 mantenemos la dirección

de la parte superior de la pila fp. En la línea 8 restauramos el valor de la pila usando el valor
guardado fp. Ahora debería ver por qué dije que el puntero de marco generalmente es
innecesario: si el spregistro no cambia entre las líneas 6 y 8, tener un puntero de marco no
tendrá sentido, ¿por qué deberíamos restaurar un registro que no cambió?

Supongamos por ahora que el puntero del marco será útil. Lo que hicimos en la línea de
instrucción 6 fue establecer el enlace dinámico . La pila y los registros se verán así después
de haberlos configurado.
Como puede ver, el fpregistro apuntará a la parte superior de la pila. Pero tenga en cuenta
que en la pila tenemos el valor de lo antiguo fp (el valor de fpen la función que nos
llamó). Si asumimos que nuestra persona que llama también usa un puntero de marco,
entonces el fpque mantuvimos en la pila de los destinatarios de la llamada apunta a la parte
superior de la pila cuando se llamó a nuestra persona que llama.

Pero aún así, esto parece inútil porque ambos registros fpy spen la función actual apuntan a
la misma posición en la pila.

Continuemos con el ejemplo, asegúrese de marcar la línea 7.

1function:
2 /* Keep callee-saved registers */
3 push {r4, r5, fp, lr} /* Keep the callee saved registers.
4 We added r5 to keep the stack 8-byte aligned
5 but the important thing here is fp */
6 mov fp, sp /* fp ← sp. Keep dynamic link in fp */
7 sub sp, sp, #8 /* Enlarge the stack by 8 bytes */
8 ... /* code of the function */
9 mov sp, fp /* sp ← fp. Restore dynamic link in fp */
10 pop {r4, r5, fp, lr} /* Restore the callee saved registers.
11 This will restore fp as well */
12 bx lr /* Return from the function */

Ahora, después de la línea 7, la pila y los registros se verán así.

¿Puedes ver el rango de datos de spa fp? Estos son los datos locales de nuestra
función. Mantendremos las variables locales de una función en este espacio cuando usemos
un puntero de marco. Simplemente tenemos que asignar espacio de pila disminuyendo el
valor de sp(y asegurándonos de que esté alineado con 8 bytes según los requisitos de
AAPCS).

Ahora considere la instrucción mov sp, fpcerca del final de la función. Lo que hace es dejar
el estado de los registros como antes de ampliar la pila (antes de sub sp, sp, #8). Y voilà,
hemos liberado toda la pila que estaba usando nuestra función. Una ventaja de este enfoque
es que no requiere mantener en ningún lugar la cantidad de bytes que reservamos en la
pila. Limpio, ¿no es así?

¿Qué pasa con los parámetros pasados en la pila?

Todavía falta un jugador en nuestro enfoque de puntero de cuadro: parámetros pasados a
través de la pila. Supongamos que nuestra función puede recibir parámetros en la pila y
hemos ampliado la pila restando sp. La imagen completa se ve así.
Quiero que noten que solo mentí un poco en las dos primeras cifras. En ellos,
el puntero antiguo fp guardado en la pila apuntaba a la parte superior de la pila de la
persona que llama. No exactamente, apuntará a la base de los datos locales de la persona
que llama, exactamente como sucede con el fpregistro en la función actual.

Indexación a través del puntero del marco

Cuando usamos un puntero de marco, se mantiene una propiedad agradable (que tal vez ya
haya deducido de las figuras anteriores): los datos locales siempre están en direcciones más
bajas que la dirección apuntada, fpmientras que los parámetros pasados en la pila (si los
hay) siempre estarán en direcciones más altas que la señalada por fp. Debe ser posible
acceder a ambos tipos de datos locales a través de fp.

En el siguiente ejemplo usaremos una función que recibe un número entero por referencia
(es decir, una dirección a un número entero) y luego eleva al cuadrado ese número entero.
void sq(int *c)
{
 (*c) = (*c) * (*c);
}
Puede que se pregunte por qué la función sqtiene un parámetro por referencia (¿no debería
ser más fácil devolver un valor?), Pero tenga paciencia conmigo por ahora. Podemos
(¿deberíamos?) Implementar sqsin usar un puntero de marco debido a su simplicidad.

1sq:
2 ldr r1, [r0] /* r1 ← (*r0) */
3 mul r1, r1, r1 /* r1 ← r1 * r1 */
4 str r1, [r0] /* (*r0) ← r1 */
5 bx lr /* Return from the function */

Ahora considere la siguiente función que devuelve la suma de los cuadrados de sus cinco
parámetros. Utiliza la función sqdefinida anteriormente.
int sq_sum5(int a, int b, int c, int d, int e)
{
sq(&a);
sq(&b);
sq(&c);
sq(&d);
sq(&e);
return a + b + c + d + e;
}
Parámetros a, b, cy dse pasaron a través de registros r0, r1, r2, y r3respectivamente. El
parámetro se epasará a través de la pila. Sin sqembargo, la función espera una referencia,
es
decir, una dirección, a un número entero y los registros no tienen una dirección. Esto
significa que tendremos que asignar almacenamiento local temporal para estos
registros. Deberá asignarse al menos un número entero en la pila para poder llamar, sqpero
para simplificar, asignaremos cuatro de ellos.

Esta vez usaremos un puntero de marco para acceder tanto al almacenamiento local como al
parámetro e.

1sq_sum5:
2 push {fp, lr} /* Keep fp and all callee-saved registers. */
3 mov fp, sp /* Set the dynamic link */
4
5 sub sp, sp, #16 /* sp ← sp - 16. Allocate space for 4 integers in the stack */
6 /* Keep parameters in the stack */
7 str r0, [fp, #-16] /* *(fp - 16) ← r0 */
8 str r1, [fp, #-12] /* *(fp - 12) ← r1 */
9 str r2, [fp, #-8] /* *(fp - 8) ← r2 */
10 str r3, [fp, #-4] /* *(fp - 4) ← r3 */
11
12 /* At this point the stack looks like this
13 | Value | Address(es)
 14 +--------+-----------------------
15 | r0 | [fp, #-16], [sp]
16 | r1 | [fp, #-12], [sp, #4]
17 | r2 | [fp, #-8], [sp, #8]
18 | r3 | [fp, #-4], [sp, #12]
19 | fp | [fp], [sp, #16]
20 | lr | [fp, #4], [sp, #20]
21 | e | [fp, #8], [sp, #24]
22 v
23 Higher
24 addresses
25 */
26
27 sub r0, fp, #16 /* r0 ← fp - 16 */
28 bl sq /* call sq(&a); */
29 sub r0, fp, #12 /* r0 ← fp - 12 */
30 bl sq /* call sq(&b); */
31 sub r0, fp, #8 /* r0 ← fp - 8 */
32 bl sq /* call sq(&c); */
33 sub r0, fp, #4 /* r0 ← fp - 4 */
34 bl sq /* call sq(&d) */
35 add r0, fp, #8 /* r0 ← fp + 8 */
36 bl sq /* call sq(&e) */
37
38 ldr r0, [fp, #-16] /* r0 ← *(fp - 16). Loads a into r0 */
39 ldr r1, [fp, #-12] /* r1 ← *(fp - 12). Loads b into r1 */
40 add r0, r0, r1 /* r0 ← r0 + r1 */
41 ldr r1, [fp, #-8] /* r1 ← *(fp - 8). Loads c into r1 */
42 add r0, r0, r1 /* r0 ← r0 + r1 */
43 ldr r1, [fp, #-4] /* r1 ← *(fp - 4). Loads d into r1 */
44 add r0, r0, r1 /* r0 ← r0 + r1 */
45 ldr r1, [fp, #8] /* r1 ← *(fp + 8). Loads e into r1 */
46 add r0, r0, r1 /* r0 ← r0 + r1 */
47
48 mov sp, fp /* Undo the dynamic link */
49 pop {fp, lr} /* Restore fp and callee-saved registers */
50 bx lr /* Return from the function */

Como puede ver, primero almacenamos todos los parámetros (pero e) en el almacenamiento
local. Esto significa que necesitamos ampliar la pila lo suficiente, como de costumbre,
restando sp(línea 5). Una vez que tengamos el almacenamiento, podemos hacer la tienda
real usando el fpregistro (líneas 7 a 10). Tenga en cuenta el uso de compensaciones
negativas, porque los datos locales siempre estarán en direcciones más bajas que la
dirección en fp. Como se mencionó anteriormente, el parámetro eno tiene que ser
almacenado porque ya está en la pila, en un desplazamiento positivo desde fp(es decir, en
una dirección más alta que la dirección en fp).

Tenga en cuenta que, en este ejemplo, el puntero del marco no es indispensable ya que
podríamos haberlo utilizado sppara acceder a todos los datos requeridos (ver la
representación de la pila en las líneas 12 a 21).

Para llamar sqtenemos que pasar las direcciones de varios enteros, entonces calculamos la
dirección restando fpel desplazamiento apropiado y almacenándolo en r0, que será usado
para pasar el primer (y único) parámetro de sq(líneas 27 a 36) . Vea cómo, para pasar la
dirección de e, simplemente calculamos una dirección con un desplazamiento positivo
(línea 35). Finalmente añadimos los valores mediante la carga de nuevo en r0y r1y el
uso r0de acumular las adiciones (líneas 38 a 46).

Un programa de ejemplo que llama se sq_sum5(1, 2, 3, 4, 5)ve así.

1/* squares.s */
[Link]
3
[Link] 4
5message: .asciz "Sum of 1^2 + 2^2 + 3^2 + 4^2 + 5^2 is %d\n"
6
[Link]
8
9sq:
10 <<defined above>>
11
12sq_sum5:
13 <<defined above>>
14
[Link] main
16
17main:
18 push {r4, lr} /* Keep callee-saved registers */
19
20 /* Prepare the call to sq_sum5 */
21 mov r0, #1 /* Parameter a ← 1 */
22 mov r1, #2 /* Parameter b ← 2 */
23 mov r2, #3 /* Parameter c ← 3 */
24 mov r3, #4 /* Parameter d ← 4 */
25
26 /* Parameter e goes through the stack,
27 so it requires enlarging the stack */
28 mov r4, #5 /* r4 ← 5 */
 29 sub sp, sp, #8 /* Enlarge the stack 8 bytes,
30 we will use only the
31 topmost 4 bytes */
32 str r4, [sp] /* Parameter e ← 5 */
33 bl sq_sum5 /* call sq_sum5(1, 2, 3, 4, 5) */
34 add sp, sp, #8 /* Shrink back the stack */
35
36 /* Prepare the call to printf */
37 mov r1, r0 /* The result of sq_sum5 */
38 ldr r0, address_of_message
39 bl printf /* Call printf */
40
41 pop {r4, lr} /* Restore callee-saved registers */
42 bx lr
43
44
45address_of_message: .word message

$ ./square
Sum of 1^2 + 2^2 + 3^2 + 4^2 + 5^2 is 55

Ensamblador ARM en Raspberry Pi

- Capítulo 19
24 de mayo de 2014• Roger Ferrer Ibáñez • Raspberry Pi

Hasta ahora, nuestros pequeños programas ensambladores tienen mensajes de salida

usando printfy algunos de ellos han leído input usando scanf. Estas dos funciones están
implementadas en la biblioteca C, por lo que son más o menos compatibles con cualquier
entorno que admita el lenguaje C. Pero, ¿cómo se comunica realmente un programa con el
mundo?

El sistema operativo
Nuestra Raspberry Pi ejecuta Raspbian . Raspbian es un sistema operativo basado
en Debian sobre el kernel de Linux . El sistema operativo es una pieza de software
(generalmente una colección de piezas que juntas forman un sistema útil) que habilita y
administra los recursos que requieren los programas para ejecutarse. ¿Qué tipo de recursos,
quizás se esté preguntando? Bueno, muchos tipos diferentes de ellos: procesos, archivos,
dispositivos de red, comunicaciones de red, pantallas, impresoras, terminales,
temporizadores, etc.
Desde el punto de vista del programa, el sistema operativo es solo un gran servidor que
brinda muchos servicios al programa. Pero el sistema operativo también es un cuidador,
tomando medidas cuando algo sale mal o los programas (a veces causados por los usuarios
del sistema operativo) intentan hacer algo para lo que no están autorizados. En nuestro
caso, Linux es el núcleo del sistema operativo Raspbian. El kernel proporciona la
funcionalidad más básica necesaria para proporcionar estos servicios (a veces los
proporciona directamente, a veces solo proporciona la funcionalidad esencial mínima para
que puedan implementarse). Puede verse como un programa fundamental que siempre está
en ejecución (o al menos, siempre listo) para que pueda atender las solicitudes de los
programas ejecutados por los usuarios. Linux es similar a UNIX® kernel y, como tal,
comparte muchas características con el largo linaje de sistemas operativos similares a
UNIX®.

Procesos
Para poder asignar recursos, el sistema operativo necesita una entidad a la que otorgue
dichos recursos. Esta entidad se llama proceso. Un proceso es un programa en ejecución. El
mismo programa se puede ejecutar varias veces, cada vez que se ejecuta es un proceso
diferente.

Llamadas al sistema
Un proceso interactúa con el sistema operativo al realizar llamadas al sistema . Una
llamada al sistema es conceptualmente como llamar a una función, pero más sofisticada. Es
más sofisticado porque ahora necesitamos satisfacer algunos requisitos de seguridad
adicionales. Un sistema operativo es una parte crítica de un sistema y no podemos permitir
que los procesos eludan el control del sistema operativo. Una llamada de función habitual
no ofrece protección de ningún tipo. Cualquier estrategia que pudiéramos diseñar sobre una
llamada de función simple sería fácilmente posible eludirla. Como consecuencia de esta
restricción, necesitamos el apoyo de la arquitectura (en nuestro caso ARM) para
implementar de forma segura un mecanismo de llamada al sistema.

En Linux ARM podemos realizar una llamada al sistema usando la instrucción swi. Este

medio de instrucción sa menudo wson interruption y su único objetivo es hacer una llamada
de sistema al sistema operativo. Recibe un operando de 24 bits que el procesador no utiliza
en absoluto, pero que podría ser utilizado por el sistema operativo para indicar qué servicio
se ha solicitado. En Linux, este enfoque no se utiliza y, en su lugar, se establece un 0 como
operando. Entonces, en resumen, en Linux siempre lo usaremos swi #0para realizar una
llamada al sistema.

Un sistema operativo, y particularmente Linux, proporciona muchos servicios a través

de llamadas al sistema, por lo que necesitamos una forma de seleccionar uno de
ellos. Haremos esto usando el registro r7. Las llamadas al sistema son similares a las
llamadas a funciones en que reciben parámetros. Ninguna llamada al sistema en Linux
recibe más de 7 argumentos y los argumentos se pasan en registros r0a r6. Si la llamada al
sistema devuelve algún valor, se devolverá en el registro r0.
Tenga en cuenta que la convención de llamadas al sistema es incompatible con la
convención definida por AAPCS, por lo que los programas necesitarán un código
específico que se ocupe de una llamada al sistema. En particular, tiene
sentido agrupar estas llamadas al sistema en funciones normales, que externamente, es
decir, desde el punto de vista de la persona que llama, siguen el AAPCS. Este es
precisamente el propósito principal de la biblioteca C. En Linux, la biblioteca C suele
ser GNU Libc (pero se pueden usar otras en Linux). Estas bibliotecas ocultan la
complejidad adicional de realizar llamadas al sistema bajo la apariencia de una llamada de
función normal.

Hola mundo, la forma de llamada del sistema

Como una simple ilustración de cómo llamar al sistema operativo, escribiremos el
programa arquetípico "Hola mundo" usando llamadas al sistema. En este caso llamaremos a
la función write. Write recibe tres parámetros: un descriptor de archivo donde escribiremos
algunos datos, un puntero a los datos que se escribirán y el tamaño de dichos datos. De
estos tres, el más oscuro puede ser ahora el descriptor de archivo. Sin entrar en muchos
detalles, es solo un número que identifica un archivo asignado al proceso. Los procesos
suelen comenzar con tres archivos preasignados: la entrada estándar, con el número 0, la
salida estándar, con el número 1, y el error estándar, con el número 2. Escribiremos
nuestros mensajes en la salida estándar, por lo que usaremos el descriptor de archivo 1.

La forma "ea-C"
Continuando con nuestro ejemplo, primero llamaremos a writetravés de la biblioteca C. La
biblioteca C sigue la convención AAPCS. El prototipo de la llamada al sistema de escritura
se puede encontrar en las páginas de manual de Linux y es el siguiente.
ssize_t write(int fd, const void *buf, size_t count);
Aquí ambos size_ty ssize_tson enteros de 32 bits,
donde el primero no está firmado y el
segundo está firmado. Equipados con nuestro conocimiento del ensamblador AAPCS y
ARM, no debería ser difícil para nosotros realizar una llamada como la siguiente
const char greeting[13] = "Hello world\n";
write(1, greeting, sizeof(greeting)); // Here sizeof(greeting) is 13
Aqui esta el codigo
/* write_c.s */

.data

greeting: .asciz "Hello world\n"

after_greeting:

/* This is an assembler constant: the assembler will compute it. Needless to say
that this must evaluate to a constant value. In this case we are computing the
difference of addresses between the address after_greeting and greeting. In this
case it will be 13 */
.set size_of_greeting, after_greeting - greeting
.text

.globl main

main:
push {r4, lr}

/* Prepare the call to write */

mov r0, #1 /* First argument: 1 */
ldr r1, addr_of_greeting /* Second argument: &greeting */
mov r2, #size_of_greeting /* Third argument: sizeof(greeting) */
bl write /* write(1, greeting, sizeof(greeting));

mov r0, #0
pop {r4, lr}
bx lr

addr_of_greeting : .word greeting

La forma de llamada del sistema

Ok, llamar a la llamada al sistema a través de la biblioteca C no fue más difícil que llamar a
una función normal. Intentemos lo mismo directamente realizando una llamada al sistema
Linux. Primero tenemos que identificar el número de la llamada al sistema y ponerlo r7. La
llamada writetiene el número 4 (puede ver los números en el archivo /usr/include/arm-linux-
gnueabihf/asm/unistd.h). Los parámetros suelen ser los mismos que en la función C, por lo que
usaremos registros r0, r1y lo r2mismo.
/* write_sys.s */

.data

greeting: .asciz "Hello world\n"

after_greeting:

.set size_of_greeting, after_greeting - greeting

.text

.globl main

main:
push {r7, lr}

/* Prepare the system call */

mov r0, #1 /* r0 ← 1 */
ldr r1, addr_of_greeting /* r1 ← &greeting */
mov r2, #size_of_greeting /* r2 ← sizeof(greeting) */

mov r7, #4 /* select system call 'write' */

swi #0 /* perform the system call */
 mov r0, #0
pop {r7, lr}
bx lr

addr_of_greeting : .word greeting

Como puede ver, no es tan diferente a la llamada a una función, sino que en lugar de
bifurcarse a una dirección específica de código usando blusamos swi #0. A decir verdad, es
bastante inusual realizar llamadas al sistema directamente. Casi siempre es preferible llamar
a la biblioteca C.

Ensamblador ARM en Raspberry Pi

- Capítulo 20
20 de agosto de 2014• Roger Ferrer Ibáñez • Raspberry Pi

Hoy veremos cómo realizar llamadas indirectas.

Etiquetas
Una de las características distintivas de los ensambladores es la escasez de información
simbólica. El único soporte simbólico disponible en este (bajo) nivel son las etiquetas . Ya
sabemos que las etiquetas son solo direcciones a la memoria del programa (tanto datos
como código).

Cuando definimos una función en ensamblador, definimos una etiqueta para ella.
fun: /* label 'fun' */
push {r4, r5}
...
pop {r4, r5}
bx lr
Posteriormente (o antes, a los montadores normalmente no les importa) usamos la
etiqueta. Entonces una llamada como
bl fun
Lefun está diciendo al ensamblador, estoy usando aquí, pero tienes que poner la dirección
apropiada allí al generar el código de máquina, ¿de acuerdo? .

En realidad, llamar a una función suele ser mucho más complicado pero al final hay una
etiqueta que nos lleva a la función.

Nuestra primera llamada indirecta

¿Qué pasa si en lugar de usar la etiqueta de una función, pudiéramos mantener la dirección
de una función (o varias de ellas) en algún lugar y llamar a una función
indirectamente? Probemos eso. Primero, comenzaremos con un Hola mundo básico que usa
una etiqueta. A esto lo llamaremos una llamada directa .

[Link] /* data section */

[Link] 4 /* ensure the next label is 4-byte aligned */
3message: .asciz "Hello world\n"
4
[Link] /* text section (= code) */
6
[Link] 4 /* ensure the next label is 4-byte aligned */
8say_hello:
9 push {r4, lr} /* keep lr because we call printf,
10 we keep r4 to keep the stack 8-byte
11 aligned, as per AAPCS requirements */
12 /* Prepare the call to printf */
13 ldr r0, addr_of_message /* r0 ← &message */
14 bl printf /* call printf */
15 pop {r4, lr} /* restore r4 and lr */
16 bx lr /* return to the caller */
17
[Link] 4 /* ensure the next label is 4-byte aligned */
19addr_of_message: .word message
20
[Link] main /* state that 'main' label is global */
[Link] 4 /* ensure the next label is 4-byte aligned */
23main:
24 push {r4, lr} /* keep lr because we call say_hello,
25 we keep r4 to keep the stack 8-byte
26 aligned, as per AAPCS requirements */
27 bl say_hello /* call say_hello, directly, using the label */
28
29 mov r0, #0 /* return from the program, set error code */
30 pop {r4, lr} /* restore r4 and lr */
31 bx lr /* return to the caller (the system) */

Ahora agreguemos algo de almacenamiento en la sección de datos para mantener la

dirección say_hello.
.data /* data section */
...
.align 4 /* ensure the next label is 4-byte aligned */
ptr_of_fun: .word 0 /* we set its initial value zero */
Ahora agregaremos una nueva función make_indirect_callque realiza la llamada indirecta
usando el valor almacenado en ptr_of_fun.
.align 4
make_indirect_call:
push {r4, lr} /* keep lr because we call printf,
we keep r4 to keep the stack 8-byte
aligned, as per AAPCS requirements */
ldr r0, addr_ptr_of_fun /* r0 ← &ptr_of_fun */
ldr r0, [r0] /* r0 ← *r0 */
blx r0 /* indirect call to r0 */
pop {r4, lr} /* restore r4 and lr */
bx lr /* return to the caller */

addr_ptr_of_fun: .word ptr_of_fun

La realización de una llamada indirecta se realiza mediante la instrucción blx. Se comporta
como blpero espera un registro en lugar de una etiqueta.

Es posible que Yoy se pregunte si podríamos haber usado en bxlugar de blx. No

podemos. La instrucción bxno establece el lrregistro en la siguiente instrucción,
como bly blxhacer. Por lo tanto, llamaríamos a la función pero no podría regresar: ¡volvería
al lugar equivocado! (trata de pensar en cuál).

Ahora en el mainmantendremos la dirección de say_helloin ptr_of_funy call make_indirect_call.

main:
push {r4, lr} /* keep lr because we call printf,
we keep r4 to keep the stack 8-byte
aligned, as per AAPCS requirements */

ldr r1, addr_say_hello /* r1 ← &say_hello */

ldr r0, addr_ptr_of_fun /* r0 ← &addr_ptr_of_fun */
str r1, [r0] /* *r0 ← r1
this is
ptr_of_fun ← &say_hello */

bl make_indirect_call /* call make_indirect_call */

mov r0, #0 /* return from the program, set error code */

pop {r4, lr} /* restore r4 and lr */
bx lr /* return to the caller (the system) */

addr_ptr_of_fun: .word ptr_of_fun

addr_say_hello : .word say_hello
Tenga en cuenta que, en la función make_indirect_callque hicimos
ldr r0, addr_ptr_of_fun /* r0 ← &ptr_of_fun */
ldr r0, [r0] /* r0 ← *r0 */
mientras que en el mainlo hacemos
ldr r1, addr_say_hello /* r1 ← &say_hello */
Este es un caso similar al de las matrices: cuando cargamos una dirección de matriz, no es
necesario volver a cargarla (como sucede cuando cargamos escalares simples). Esto se debe
a que si hiciéramos eso, estaríamos cargando el primer elemento de la matriz. Con las
funciones sucede algo similar: la función en sí, su etiqueta, ya es una dirección. ¡Si
hiciéramos otra carga, estaríamos cargando una instrucción en el registro! No es
exactamente lo que queremos :)

En la función make_indirect_callno estamos cargando una función sino un puntero a una

función ( addr_ptr_of_fun), por lo que tenemos que hacer la típica carga doble que hacemos
para los escalares (porque al final, un puntero es solo un número entero que resulta ser una
dirección de la memoria de nuestro programa).

Siente el poder
El último ejemplo no parece muy interesante, pero poder llamar a una función
indirectamente es algo muy poderoso. Nos permite mantener la dirección de una función en
algún lugar y llamarla. Nos permite pasar la dirección de una función a otra función. ¿Por
qué querríamos hacer eso? Bueno, es una forma rudimentaria, pero efectiva, de pasar
código a otra función.

A modo de ejemplo, vamos a hacer un genérico bienvenida función que recibe un saludo

función como parámetro. De esta manera, el saludo exacto se difiere realmente a otra
función.
.data /* data section */
.align 4 /* ensure the next label is 4-byte aligned */
message_1: .asciz "Hello\n"
.align 4 /* ensure the next label is 4-byte aligned */
message_2: .asciz "Bonjour\n"

.text /* text section (= code) */

.align 4 /* ensure the next label is 4-byte aligned */

say_hello:
push {r4, lr} /* keep lr because we call printf,
we keep r4 to keep the stack 8-byte
aligned, as per AAPCS requirements */
/* Prepare the call to printf */
ldr r0, addr_of_message_1 /* r0 ← &message */
bl printf /* call printf */
pop {r4, lr} /* restore r4 and lr */
bx lr /* return to the caller */

.align 4 /* ensure the next label is 4-byte aligned */

addr_of_message_1: .word message_1

.align 4 /* ensure the next label is 4-byte aligned */

say_bonjour:
push {r4, lr} /* keep lr because we call printf,
we keep r4 to keep the stack 8-byte
aligned, as per AAPCS requirements */
/* Prepare the call to printf */
ldr r0, addr_of_message_2 /* r0 ← &message */
bl printf /* call printf */
pop {r4, lr} /* restore r4 and lr */
bx lr /* return to the caller */
.align 4 /* ensure the next label is 4-byte aligned */
addr_of_message_2: .word message_2

.align 4
greeter:
push {r4, lr} /* keep lr because we call printf,
we keep r4 to keep the stack 8-byte
aligned, as per AAPCS requirements */
blx r0 /* indirect call to r0 */
pop {r4, lr} /* restore r4 and lr */
bx lr /* return to the caller */

.globl main /* state that 'main' label is global */

.align 4 /* ensure the next label is 4-byte aligned */
main:
push {r4, lr} /* keep lr because we call printf,
we keep r4 to keep the stack 8-byte
aligned, as per AAPCS requirements */

ldr r0, addr_say_hello /* r0 ← &say_hello */

bl greeter /* call greeter */

ldr r0, addr_say_bonjour /* r0 ← &say_bonjour */

bl greeter /* call greeter */

mov r0, #0 /* return from the program, set error code */

pop {r4, lr} /* restore r4 and lr */
bx lr /* return to the caller (the system) */

addr_say_hello : .word say_hello

addr_say_bonjour : .word say_bonjour
Si lo ejecutamos
$ ./greeter_01
Hello
Bonjour
Probablemente no esté impresionado por el resultado de este programa anterior. Así que
tratemos de hacerlo más interesante: saludaremos a la gente de manera genérica, algunas
personas serán recibidas en inglés y otras en francés.

Comencemos a definir un montón de datos que necesitaremos para este ejemplo. Primeros

mensajes de bienvenida en inglés y francés. Tenga en cuenta que saludaremos a la persona
por su nombre, por lo que usaremos una cadena de formato printf.

[Link] /* data section */

2
[Link] 4 /* ensure the next label is 4-byte aligned */
4message_hello: .asciz "Hello %s\n"
[Link] 4 /* ensure the next label is 4-byte aligned */
6message_bonjour: .asciz "Bonjour %s\n"
A continuación, definiremos algunas etiquetas que usaremos para etiquetar personas como
inglés o francés. Esta etiqueta contendrá la dirección de la función de saludo específica. La
etiqueta en inglés tendrá la dirección de say_helloy la etiqueta en francés tendrá la dirección
de say_bonjour.

7/* tags of kind of people */

[Link] 4 /* ensure the next label is 4-byte aligned */
9person_english : .word say_hello /* tag for people
10 that will be greeted
11 in English */
[Link] 4 /* ensure the next label is 4-byte aligned */
13person_french : .word say_bonjour /* tag for people
14 that will be greeted
15 in French */

Definamos algunos nombres que usaremos más adelante, al definir personas.

18/* several names to be used in the people definition */

[Link] 4
20name_pierre: .asciz "Pierre"
[Link] 4
22name_john: .asciz "John"
[Link] 4
24name_sally: .asciz "Sally"
[Link] 4
26name_bernadette: .asciz "Bernadette"

Y ahora defina a algunas personas. Cada persona es en realidad un par formado por una
dirección a su nombre y una dirección a su etiqueta.

[Link] 4
29person_john: .word name_john, person_english
[Link] 4
31person_pierre: .word name_pierre, person_french
[Link] 4
33person_sally: .word name_sally, person_english
[Link] 4
35person_bernadette: .word name_bernadette, person_french

Finalmente, agrupemos a todas las personas en una matriz. La matriz contiene direcciones
para cada persona (no las personas en sí).

38/* array of people */

 39people : .word person_john, person_pierre, person_sally, person_bernadette

Ahora definamos el código. Estas son las dos funciones específicas para cada idioma
(inglés y francés). Tenga en cuenta que ya nombramos sus etiquetas en las etiquetas de
arriba.

[Link] /* text section (= code) */

42
[Link] 4 /* ensure the next label is 4-byte aligned */
44say_hello:
45 push {r4, lr} /* keep lr because we call printf,
46 we keep r4 to keep the stack 8-byte
47 aligned, as per AAPCS requirements */
48 /* Prepare the call to printf */
49 mov r1, r0 /* r1 ← r0 */
50 ldr r0, addr_of_message_hello
51 /* r0 ← &message_hello */
52 bl printf /* call printf */
53 pop {r4, lr} /* restore r4 and lr */
54 bx lr /* return to the caller */
55
[Link] 4 /* ensure the next label is 4-byte aligned */
57addr_of_message_hello: .word message_hello
58
[Link] 4 /* ensure the next label is 4-byte aligned */
60say_bonjour:
61 push {r4, lr} /* keep lr because we call printf,
62 we keep r4 to keep the stack 8-byte
63 aligned, as per AAPCS requirements */
64 /* Prepare the call to printf */
65 mov r1, r0 /* r1 ← r0 */
66 ldr r0, addr_of_message_bonjour
67 /* r0 ← &message_bonjour */
68 bl printf /* call printf */
69 pop {r4, lr} /* restore r4 and lr */
70 bx lr /* return to the caller */
71
[Link] 4 /* ensure the next label is 4-byte aligned */
73addr_of_message_bonjour: .word message_bonjour

Antes de pasar a la función interesante, definamos la mainfunción.

[Link] main /* state that 'main' label is global */

 [Link] 4 /* ensure the next label is 4-byte aligned */
101main:
102 push {r4, r5, r6, lr} /* keep callee saved registers that we will modify */
103
104 ldr r4, addr_of_people /* r4 ← &people */
105 /* recall that people is an array of addresses (pointers) to people */
106
107 /* now we loop from 0 to 4 */
108 mov r5, #0 /* r5 ← 0 */
109 b check_loop /* branch to the loop check */
110
111 loop:
112 /* prepare the call to greet_person */
113 ldr r0, [r4, r5, LSL #2] /* r0 ← *(r4 + r5 << 2) this is
114 r0 ← *(r4 + r5 * 4)
115 recall, people is an array of addresses,
116 so this is
117 r0 ← people[r5]
118 */
119 bl greet_person /* call greet_person */
120 add r5, r5, #1 /* r5 ← r5 + 1 */
121 check_loop:
122 cmp r5, #4 /* compute r5 - 4 and update cpsr */
123 bne loop /* if r5 != 4 branch to loop */
124
125 mov r0, #0 /* return from the program, set error code */
126 pop {r4, r5, r6, lr} /* callee saved registers */
127 bx lr /* return to the caller (the system) */
128
129addr_of_people : .word people

Como puede ver, lo que hacemos aquí es cargar los elementos 0 a 3 del peoplearreglo y
llamar a la función greet_person. Cada elemento de la peoplematriz es un puntero, por lo que
podemos ponerlos en un registro, en este caso r0porque será el primer parámetro
de greet_person.

Veamos ahora el código de la función greet_person.

75/* This function receives an address to a person */

[Link] 4
77greet_person:
78 push {r4, lr} /* keep lr because we call printf,
79 we keep r4 to keep the stack 8-byte
 80 aligned, as per AAPCS requirements */
81
82 /* prepare indirect function call */
83 mov r4, r0 /* r0 ← r4, keep the first parameter in r4 */
84 ldr r0, [r4] /* r0 ← *r4, this is the address to the name
85 of the person and the first parameter
86 of the indirect called function*/
87
88 ldr r1, [r4, #4] /* r1 ← *(r4 + 4) this is the address
89 to the person tag */
90 ldr r1, [r1] /* r1 ← *r1, the address of the
91 specific greeting function */
92
93 blx r1 /* indirect call to r1, this is
94 the specific greeting function */
95
96 pop {r4, lr} /* restore r4 and lr */
97 bx lr /* return to the caller */

En el registro r0tenemos la dirección de una persona. Lo movemos a r4por conveniencia,

ya r0que se usará para la función llamada indirectamente. Luego cargamos el nombre de la
persona, que se encuentra en [r4], esto es [r4, #0](esto es *(r4 + 0), entonces *r4) en r0. Luego
cargamos la etiqueta de persona, que se encuentra 4 bytes después del nombre (recuerde
que el nombre de la persona es una dirección, por lo que ocupa 4 bytes en ARM). La
etiqueta en sí no es muy útil excepto porque nos permite obtener la función de saludo
específica ( say_helloo bien say_bonjour). Entonces cargamos [r4, #4], la dirección de la
etiqueta, en formato r1. Ok, ahora r1contiene la dirección de la etiqueta y sabemos que los
primeros 4 bytes de una etiqueta contienen la función de saludo específica.

Si ejecutamos este programa, la salida es:

$ ./greeter_02
Hello John
Bonjour Pierre
Hello Sally
Bonjour Bernadette

Encuadernación tardía y orientación a objetos

En el último ejemplo hemos implementado, de una manera muy simple, una característica
de la programación orientada a objetos (POO) llamada enlace tardío , lo que significa que
no se sabe qué función se llama para un objeto dado.

En nuestro ejemplo, los objetos son de tipo Person . Todos Personpueden ser saludados, esto

es lo que greet_personhace. Realmente no tenemos objetos de tipo Person,
sino EnglishPersony FrenchPerson. Cuando saluda a un EnglishPerson, espera saludarlo
con Hola , cuando saluda a un FrenchPerson, espera saludarlo con Bonjour .

Si conoce C ++ (o Java), rápidamente se dará cuenta de que nuestro último ejemplo

realmente implementa algo como esto.
struct Person
{
const char* name;
virtual void greet() = 0;
};

struct EnglishPerson : Person

{
virtual void greet()
{
printf("Hello %s\n", this->name);
}
};

struct FrenchPerson : Person

{
virtual void greet()
{
printf("Bonjour %s\n", this->name);
}
};
En el fragmento de arriba, thises el Personque
pasamos a nuestra función greet_person. Ese
parámetro nos permitió recuperar el nombre de la persona ( this->name) y la versión
específica de greetque queríamos.

Espero que este último ejemplo, aunque sea un poco largo, realmente te muestre el poder de
las llamadas indirectas.

Ensamblador ARM en Raspberry Pi

- Capítulo 21
23 de agosto de 2014• Roger Ferrer Ibáñez • Raspberry Pi

Ya sabemos que ARM es una arquitectura de 32 bits: los registros de propósito general
tienen un ancho de 32 bits y las direcciones en la memoria son números de 32 bits. El
tamaño de entero natural para una arquitectura generalmente se llama palabra y en ARM
obviamente son enteros de 32 bits. A veces, sin embargo, tenemos que tratar con datos
de subpalabras : números enteros de tamaño inferior a 32 bits.

Datos de la subpalabra
En este capítulo, los datos de las subpalabras se referirán a un byte oa media palabra . Un
byte es un número entero de 8 bits y una media palabra es un número entero de 16 bits. Por
tanto, una media palabra ocupa 2 bytes y una palabra 4 bytes.

Para definir el almacenamiento de un byte en la sección de datos tenemos que

usar .byte. Para media palabra, la sintaxis es .hword.
.align 4
one_byte: .byte 205
/* This number in binary is 11001101 */

.align 4
one_halfword: .hword 42445
/* This number in binary is 1010010111001101 */
Tenga en cuenta que, como de costumbre, estamos alineando datos a 4 bytes. Más adelante
veremos que para las subpalabras las restricciones de alineación de datos son un poco más
relajadas.

Cargar y almacenar
Antes de que comencemos a operar un entero de subpalabra, necesitamos llevarlo a alguna
parte. Si no vamos a cargarlo / almacenarlo desde / a la memoria, simplemente podemos
usar un registro. Puede que tengamos que comprobar que no sobrepasamos el rango de la
subpalabra, pero eso es todo.

Pero si los datos están en la memoria, es importante cargarlos correctamente, ya que no

queremos leer más datos de los que realmente se necesitan. Recuerde que una dirección en
realidad identifica un solo byte de la memoria: no es posible direccionar nada más pequeño
que un byte. Dependiendo del ancho de la carga / almacenamiento, la dirección cargará /
almacenará 1 byte, 2 bytes o 4 bytes. Un regular ldrcarga una palabra, por lo que
necesitamos alguna otra instrucción.

ARM proporciona las instrucciones ldrby ldrhpara cargar un byte y media palabra

respectivamente. El destino es un registro de propósito general, de 32 bits, por lo que esta
instrucción debe extender el valor de 8 o 16 bits a 32 bits. Ambos ldrby ldrhrealizan una
extensión cero , lo que significa que todos los bits adicionales, no cargados, se pondrán a
cero.
.text

.globl main
main:
push {r4, lr}

ldr r0, addr_of_one_byte /* r0 ← &one_byte */

ldrb r0, [r0] /* r0 ← *{byte}r0 */

ldr r1, addr_of_one_halfword /* r1 ← &one_halfword */

ldrh r1, [r1] /* r1 ← *{half}r1 */
 pop {r4, lr}
mov r0, #0
bx lr

addr_of_one_byte: .word one_byte

addr_of_one_halfword: .word one_halfword
En el ejemplo anterior nota la diferencia entre el ldry la posterior ldrb/ ldrh. La ldrinstrucción
es necesaria para cargar una dirección en el registro. Las direcciones en ARM son números
enteros de 32 bits, por ldrlo que aquí se debe usar una regular . Luego, una vez tenemos la
dirección en el registro usamos ldrbo ldrhpara cargar el byte o la media palabra. Como se
indicó anteriormente, el registro de destino es de 32 bits, por lo que el entero cargado se
extiende a cero. La siguiente tabla muestra lo que sucede con la extensión cero .

Efecto de las cargas de subpalabras con ldrby ldrh.

Contenido en memoria (bytes) Cargado en registro (32 bits)

addr addr + 1

ldrb 11001101 00000000 00000000 00000000 11001101

ldrh 11001101 10100101 00000000 00000000 10100101 11001101

ARM en Raspberry Pi es una pequeña arquitectura endian , esto significa que los bytes en
la memoria se colocan en la memoria (de direcciones inferiores a superiores) comenzando
desde el byte menos significativo hasta el byte más significativo. Las instrucciones de carga
y almacenamiento conservan este pedido. Este hecho generalmente no es importante a
menos que se vea la memoria como una secuencia de bytes. Esta es la razón por la que en la
tabla anterior 11001101 siempre aparece en la primera columna incluso si el número 42445
es 10100101 11001101 en binario.

Ok, cargar usando ldrby ldrhestá bien siempre y cuando solo usemos números naturales. Los
números integrales incluyen números negativos y comúnmente se representan usando el
complemento a dos . Si ampliamos a cero un número negativo, el bit de signo (el bit más
significativo del complemento a dos) no se propagará y terminaremos con un número
positivo no relacionado. Al cargar enteros de subpalabras de complemento a dos,
necesitamos realizar la extensión de signo usando las instrucciones lsrby lsrh.
ldr r0, addr_of_one_byte /* r0 ← &one_byte */
ldrsb r0, [r0] /* r0 ← *{signed byte}r0 */

ldr r1, addr_of_one_halfword /* r1 ← &one_halfword */

 ldrsh r1, [r1] /* r1 ← *{signed half}r1 */
Tenga en cuenta que la extensión de signo es lo mismo que la extensión de cero cuando el
bit de signo es cero, como sucede en las dos últimas filas de la siguiente tabla que muestra
el efecto de ldrsby ldrsh.

Efecto de las cargas de subpalabras con ldrsby ldrsh.

Contenido en memoria (bytes) Cargado en registro (32 bits)

addr addr + 1

ldrsb 11001101 11111111 11111111 11111111 11001101

ldrsh 11001101 10100101 11111111 11111111 10100101 11001101

ldrsb 01001101 00000000 00000000 00000000 01001101

ldrsh 11001101 00100101 00000000 00000000 00100101 11001101

Es muy importante no mezclar ambas instrucciones al cargar datos de subpalabras. Al

cargar números naturales, lrby lrhson la elección correcta. Si el número es un entero que
podría ser negativo, utilice siempre ldrsby ldrsh. La siguiente tabla resume lo que sucede
cuando mezcla interpretaciones y las diferentes instrucciones de carga.

Patrones de bits interpretados como binarios (naturales) o complemento a dos.

Interpretación de bits

Ancho Bits Binario Complemento a d

8 bits 11001101 205 -51

 Patrones de bits interpretados como binarios (naturales) o complemento a dos.

Interpretación de bits

Ancho Bits Binario Complemento a d

32 bits después ldrb 00000000000000000000000011001101 205 205

32 bits después ldrsb 11111111111111111111111111001101 4294967245 -51

16 bits 1010010111001101 42445 -23091

32 bits después ldrh 00000000000000001010010111001101 42445 42445

32 bits después ldrsh 11111111111111111010010111001101 4294944205 -23091

Tienda
Mientras que load requiere tener cuidado si la subpalabra cargada es un número codificado
en binario o en complemento a dos, una instrucción de almacenamiento no requiere nada de
esta consideración. La razón es que las instrucciones correspondientes strby strhsimplemente
tomarán los 8 o 16 bits menos significativos del registro y los almacenarán en la memoria.
ldr r1, addr_of_one_byte /* r0 ← &one_byte */
ldrsb r0, [r1] /* r0 ← *{signed byte}r1 */
strb r0, [r1] /* *{byte}r1 ← r0 */

ldr r0, addr_of_one_halfword /* r0 ← &one_halfword */

ldrsh r1, [r0] /* r1 ← *{signed half}r0 */
strh r1, [r0] /* *{half}r0 ← r1 */

Restricciones de alineación
Al cargar o almacenar un entero de 32 bits desde la memoria, la dirección debe estar
alineada con 4 bytes, esto significa que los dos bits menos significativos de la dirección
deben ser 0. Dicha restricción se relaja si la operación de memoria (cargar o almacenar) es
una subpalabra. uno. Para medias palabras, la dirección debe tener una alineación de 2
bytes. Para bytes, no se aplica ninguna restricción. De esta manera
podemos reinterpretar palabras y medias palabras como medias palabras y bytes si
queremos.

Considere el siguiente ejemplo, donde atravesamos una sola palabra reinterpretando sus
bytes y medias palabras (y finalmente la palabra en sí).

[Link]
2
[Link] 4
4a_word: .word 0x11223344
5
[Link] 4
7message_bytes : .asciz "byte #%d is 0x%x\n"
8message_halfwords : .asciz "halfword #%d is 0x%x\n"
9message_words : .asciz "word #%d is 0x%x\n"
10
[Link]
12
[Link] main
14main:
15 push {r4, r5, r6, lr} /* keep callee saved registers */
16
17 ldr r4, addr_a_word /* r4 ← &a_word */
18
19 mov r5, #0 /* r5 ← 0 */
20 b check_loop_bytes /* branch to check_loop_bytes */
21
22 loop_bytes:
23 /* prepare call to printf */
24 ldr r0, addr_message_bytes
25 /* r0 ← &message_bytes
26 first parameter of printf */
27 mov r1, r5 /* r1 ← r5
28 second parameter of printf */
29 ldrb r2, [r4, r5] /* r2 ← *{byte}(r4 + r5)
30 third parameter of printf */
31 bl printf /* call printf */
32 add r5, r5, #1 /* r5 ← r5 + 1 */
33 check_loop_bytes:
34 cmp r5, #4 /* compute r5 - 4 and update cpsr */
35 bne loop_bytes /* if r5 != 4 branch to loop_bytes */
36
37 mov r5, #0 /* r5 ← 0 */
 38 b check_loop_halfwords /* branch to check_loop_halfwords */
39
40 loop_halfwords:
41 /* prepare call to printf */
42 ldr r0, addr_message_halfwords
43 /* r0 ← &message_halfwords
44 first parameter of printf */
45 mov r1, r5 /* r1 ← r5
46 second parameter of printf */
47 mov r6, r5, LSL #1 /* r6 ← r5 * 2 */
48 ldrh r2, [r4, r6] /* r2 ← *{half}(r4 + r6)
49 this is r2 ← *{half}(r4 + r5 * 2)
50 third parameter of printf */
51 bl printf /* call printf */
52 add r5, r5, #1 /* r5 ← r5 + 1 */
53 check_loop_halfwords:
54 cmp r5, #2 /* compute r5 - 2 and update cpsr */
55 bne loop_halfwords /* if r5 != 2 branch to loop_halfwords */
56
57 /* prepare call to printf */
58 ldr r0, addr_message_words /* r0 ← &message_words
59 first parameter of printf */
60 mov r1, #0 /* r1 ← 0
61 second parameter of printf */
62 ldr r2, [r4] /* r1 ← *r4
63 third parameter of printf */
64 bl printf /* call printf */
65
66 pop {r4, r5, r6, lr} /* restore callee saved registers */
67 mov r0, #0 /* set error code */
68 bx lr /* return to system */
69
70addr_a_word : .word a_word
71addr_message_bytes : .word message_bytes
72addr_message_halfwords : .word message_halfwords
73addr_message_words : .word message_words

Nuestra palabra es el número 11223344 16 (esto es 287454020 10 ). Cargamos la dirección

de la palabra, línea 17, como es habitual con a ldry luego realizamos cargas de distintos
tamaños. El primer ciclo, las líneas 19 a 35, carga cada byte y lo imprime. Tenga en cuenta
que ldrb, la línea 29, simplemente agrega el byte actual (in r5) a la dirección de la palabra
(in r4). No tenemos que multiplicar r5por nada. De hecho ldrby ldrh, a diferencia ldr, no
permiten un operando de cambio de la forma LSL #x. Puede ver cómo esquivar esta
restricción en el bucle que imprime medias palabras, líneas 37 a 55. La instrucción ldrh,
línea 48, que usamos r6es solor4 + r5*2, calculado en la línea 47. Dado que la palabra
original estaba alineada en 4 bytes, podemos leer sus dos medias palabras porque estarán
alineadas en 2 bytes. Sería un error intentar cargar una media palabra utilizando la
dirección del byte 1, solo las medias palabras que comienzan en los bytes 0 y 2 se pueden
cargar como media palabra.

Esta es la salida del programa.

$ ./reinterpret
byte #0 is 0x44
byte #1 is 0x33
byte #2 is 0x22
byte #3 is 0x11
halfword #0 is 0x3344
halfword #1 is 0x1122
word #0 is 0x11223344
Como dijimos anteriormente, ARM en Raspberry Pi es una arquitectura poco endian, por lo
que para enteros de más de un byte, se distribuyen (desde direcciones más bajas hasta
direcciones más altas) comenzando por los bytes menos significativos, por eso el primer
byte es 44 16 y no 11 16 . De manera similar, para las medias palabras, la primera media
palabra será 3344 16 en lugar de 1122 16 .

Ensamblador ARM en Raspberry Pi

- Capítulo 22
20 de diciembre de 2014• Roger Ferrer Ibáñez • Raspberry Pi • brazo , ensamblador

Varias veces en capítulos anteriores hemos hablado de ARM como una arquitectura que
tiene varias características dirigidas a incrustar sistemas. En los sistemas integrados, la
memoria es escasa y costosa, por lo que los diseños que ayudan a reducir la huella de
memoria son muy bienvenidos. Hoy veremos otra de estas características: el conjunto de
instrucciones Thumb.

El conjunto de instrucciones Thumb

En entregas anteriores hemos estado trabajando con el conjunto de instrucciones ARMv6
(el implementado en la Raspberry Pi). En este conjunto de instrucciones, todas las
instrucciones tienen un ancho de 32 bits, por lo que cada instrucción ocupa 4 bytes. Este es
un diseño común desde la llegada de los procesadores RISC . Dicho esto, en algunos
escenarios dicha codificación es excesiva en términos de consumo de memoria: muchas
plataformas son muy simples y rara vez necesitan todas las características proporcionadas
por el conjunto de instrucciones. ¡Si tan solo pudieran usar un subconjunto del conjunto de
instrucciones original que se puede codificar en un número menor de bits!
Entonces, de esto se trata el conjunto de instrucciones Thumb . Son un subconjunto
codificado de las instrucciones ARM que toman solo 16 bits por instrucción. Esto significa
que tendremos que renunciar a algunas instrucciones. Como beneficio, nuestra densidad de
código es mayor: la mayoría de las veces podremos codificar el código de nuestros
programas en la mitad del espacio.

Soporte de Thumb en Raspbian

Si bien el procesador de la Raspberry Pi es compatible correctamente con Thumb, todavía
hay cierto soporte de software que, lamentablemente, no es proporcionado por
Raspbian. Esto significa que podremos escribir algunos fragmentos en Thumb, pero en
general esto no es compatible (si intenta utilizar Thumb para un programa C completo,
terminará con un sorry, unimplementedmensaje del compilador).

Instrucciones
Thumb proporciona alrededor de 45 instrucciones (de alrededor de 115 en ARMv6). La
codificación más estrecha de 16 bits significa que estaremos más limitados en lo que
podemos hacer en nuestro código. Los registros se dividen en dos conjuntos: registros
bajos , r0to r7, y registros altos , r8to r15. La mayoría de las instrucciones solo pueden
funcionar completamente con registros bajos y algunas otras tienen un comportamiento
limitado cuando se trabaja con registros altos.

Además, las instrucciones de Thumb no se pueden predicar. Recuerde que casi todas las
instrucciones ARM se pueden condicionar según los indicadores del cpsrregistro. Este no es
el caso en Thumb, donde solo la instrucción de bifurcación es condicional.

La combinación de ARM y Thumb solo es posible a nivel de función: una función debe ser
completamente ARM o Thumb, no puede ser una combinación de los dos conjuntos de
instrucciones. Recuerde que nuestro sistema Raspbian no es compatible con Thumb, por lo
que en algún momento tendremos que saltar del código ARM al código Thumb. Esto se
hace usando la instrucción (disponible en ambos conjuntos de instrucciones) blx. Esta
instrucción se comporta como la blinstrucción que usamos para las llamadas a funciones,
pero cambia el estado del procesador de ARM a Thumb (o Thumb a ARM).

También tenemos que decirle al ensamblador que una parte del ensamblador es en realidad
Thumb mientras que la otra es ARM. Dado que por defecto el ensamblador espera ARM,
tendremos que cambiar a Thumb en algún momento.

Del brazo al pulgar

Comencemos con un programa muy simple que devuelve un código de error de 2
establecido en Thumb.

1/* thumb-first.s */
[Link]
 3
[Link] 16 /* Here we say we will use Thumb */
[Link] 2 /* Make sure instructions are aligned at 2-byte boundary */
6
7thumb_function:
8 mov r0, #2 /* r0 ← 2 */
9 bx lr /* return */
10
[Link] 32 /* Here we say we will use ARM */
[Link] 4 /* Make sure instructions are aligned at 4-byte boundary */
13
[Link] main
15main:
16 push {r4, lr}
17
18 blx thumb_function /* From ARM to Thumb we use blx */
19
20 pop {r4, lr}
21 bx lr

Las instrucciones de pulgar en nuestra función thumb_function en realidad se parecen a las

instrucciones de ARM. De hecho, la mayoría de las veces no habrá mucha
diferencia. Como se indicó anteriormente, las instrucciones Thumb tienen características
más limitadas que sus contrapartes ARM.

Si ejecutamos el programa, hace lo que esperamos.

$ ./thumb-first; echo $?
2
¿Cómo podemos saber que nuestro programa realmente mezcla ARM y Thumb? Podemos
utilizar objdump -dpara volcar las instrucciones de nuestro [Link].
$ objdump -d thumb-first.o

thumb-first.o: file format elf32-littlearm

Disassembly of section .text:

00000000 <thumb_function>:
0: 2002 movs r0, #2
2: 4770 bx lr
4: e1a00000 nop ; (mov r0, r0)
8: e1a00000 nop ; (mov r0, r0)
c: e1a00000 nop ; (mov r0, r0)

00000010 <main>:
10: e92d4010 push {r4, lr}
 14: fafffff9 blx 0 <thumb_function>
18: e8bd4010 pop {r4, lr}
1c: e12fff1e bx lr
Verifique thumb_function: sus dos instrucciones están codificadas en solo dos bytes (la
instrucción bx lrestá en el desplazamiento 2 de mov r0, #2. Compare esto con las
instrucciones en main: cada una está en el desplazamiento 4 de su instrucción predecesora.
Tenga en cuenta que el ensamblador agregó algo de relleno al final de el thumb_functionen
forma de nops (que no debería ejecutarse, de todos modos).

Funciones de llamada en Thumb

En Thumb queremos seguir la convención AAPCS como lo hacemos cuando estamos en
modo ARM, pero luego ocurren algunas rarezas. Considere el siguiente fragmento de
código where thumb_function_1llamadas thumb_function_2.
.code 16 /* Here we say we will use Thumb */
.align 2 /* Make sure instructions are aligned at 2-byte boundary */
thumb_function_2:
/* Do something here */
bx lr

thumb_function_1:
push {r4, lr}
bl thumb_function_2
pop {r4, lr} /* ERROR: cannot use lr in pop in Thumb mode */
bx lr
Desafortunadamente, esto será rechazado por el ensamblador. Si recuerda el capítulo 10, en
ARM push y pop son nemotécnicos para stmdb sp!y ldmia sp!, respectivamente. Pero en el
modo Pulgar pushy popson instrucciones por sí mismas, por lo que son más
limitadas: pushsolo pueden usar registros bajos y lr, popsolo pueden usar registros bajos
y pc. El comportamiento de estas dos instrucciones es casi el mismo que el de la
mnemomics ARM. Entonces, probablemente ahora se esté preguntando por qué estos dos
casos especiales para lry pc. Este es el truco: en el modo Thumb pop {pc}es equivalente a
sacar el valor valde la pila y luego hacerlo bx val. Entonces, la secuencia de dos
instrucciones: pop {r4, lr}seguida de se bx lrconvierte en simple pop {r4, pc}.

Entonces, nuestro código se verá así.

/* thumb-call.s */
.text

.code 16 /* Here we say we will use Thumb */

.align 2 /* Make sure instructions are aligned at 2-byte boundary */

thumb_function_2:
mov r0, #2
bx lr /* A leaf Thumb function (i.e. a function that does not call
any other function so it did not have to keep lr in the stack)
returns using "bx lr" */

thumb_function_1:
 push {r4, lr}
bl thumb_function_2 /* From Thumb to Thumb we use bl */
pop {r4, pc} /* This is how we return from a non-leaf Thumb function */

.code 32 /* Here we say we will use ARM */

.align 4 /* Make sure instructions are aligned at 4-byte boundary */
.globl main
main:
push {r4, lr}

blx thumb_function_1 /* From ARM to Thumb we use blx */

pop {r4, lr}

bx lr

Del pulgar al brazo

Finalmente, es posible que deseemos llamar a una función ARM desde Thumb. Siempre
que nos ciñamos a AAPCS, todo debería funcionar correctamente. La instrucción Thumb
para llamar a una función ARM es nuevamente blx. A continuación se muestra un ejemplo
de un pequeño programa que dice "Hola mundo" llamando cuatro veces printf, una función
en la biblioteca C que, por supuesto, en Raspbian se implementa mediante instrucciones
ARM.
/* thumb-first.s */

.text

.data
message: .asciz "Hello world %d\n"

.code 16 /* Here we say we will use Thumb */

.align 2 /* Make sure instructions are aligned at 2-byte boundary */
thumb_function:
push {r4, lr} /* keep r4 and lr in the stack */
mov r4, #0 /* r4 ← 0 */
b check_loop /* unconditional branch to check_loop */
loop:
/* prepare the call to printf */
ldr r0, addr_of_message /* r0 ← &message */
mov r1, r4 /* r1 ← r4 */
blx printf /* From Thumb to ARM we use blx.
printf is a function
in the C library that is implemented
using ARM instructions */
add r4, r4, #1 /* r4 ← r4 + 1 */
check_loop:
cmp r4, #4 /* compute r4 - 4 and update the cpsr */
blt loop /* if the cpsr means that r4 is lower than 4
then branch to loop */

pop {r4, pc} /* restore registers and return from Thumb function */
.align 4
addr_of_message: .word message
.code 32 /* Here we say we will use ARM */
.align 4 /* Make sure instructions are aligned at 4-byte boundary */
.globl main
main:
push {r4, lr} /* keep r4 and lr in the stack */
blx thumb_function /* from ARM to Thumb we use blx */
pop {r4, lr} /* restore registers */
bx lr /* return */

Para saber mas

En las próximas entregas volveremos a ARM, por lo que si está interesado en Thumb, es
posible que desee consultar esta Tarjeta de referencia rápida del conjunto de instrucciones
de Thumb de 16 bits proporcionada por ARM. Al verificar esa tarjeta, tenga en cuenta que
el procesador de la Raspberry Pi solo implementa ARMv6T, no ARMv6T2.

Ensamblador ARM en Raspberry Pi

- Capítulo 23
2 de enero de 2015• Roger Ferrer Ibáñez • Raspberry Pi

Hoy veremos qué sucede cuando anidamos una función dentro de otra. Parece algo
inofensivo, pero viene con su propia dosis de detalles interesantes.

Funciones anidadas
A nivel de ensamblador, las funciones no se pueden anidar.

De hecho, las funciones ni siquiera existen a nivel de

ensamblador. Que lógicamente existen porque seguimos algunas convenciones (en ARM
Linux es el AAPCS) y los llamamos funciones . A nivel de ensamblador, todo son datos,
instrucciones o direcciones. Todo lo demás se construye sobre eso. Este hecho, sin
embargo, no nos ha impedido disfrutar de las funciones: hemos llamado funciones
como printfy scanfpara imprimir y leer cadenas y en el capítulo 20 incluso llamamos
funciones indirectamente. Entonces, las funciones son una convención lógica muy útil.

Por lo tanto, puede tener sentido anidar una función dentro de otra. ¿Qué significa anidar
una función dentro de otra? Bueno, significa que esta función solo tendrá significado
mientras su función adjunta esté dinámicamente activa (es decir, haya sido llamada).

A nivel de ensamblador, una función anidada se parecerá mucho a cualquier otra función,
pero tienen suficientes diferencias para ser interesantes.

Enlace dinámico
En el capítulo 18 hablamos sobre el enlace dinámico . El enlace dinámico se establece al
comienzo de la función y usamos el fpregistro (un alias para r11) para mantener una
dirección en la pila, generalmente llamada puntero de marco (de ahí el fpnombre). Es
dinámico porque se relaciona con la activación dinámica de la función. El puntero del
marco nos da una forma coherente de acceder a los datos locales de la función (que siempre
se almacenarán en la pila) y los parámetros que deben pasarse utilizando la pila.

Recuerde que los datos locales, debido a que la pila crece hacia abajo, se encuentran en
desplazamientos negativos de la dirección en fp. Por el contrario, los parámetros pasados
usando la pila estarán en compensaciones positivas. Tenga en cuenta que fp(también
conocido como r11) es un registro de llamadas guardadas según lo especificado por la
AAPCS. Esto significa que tendremos que pushcolocarlo en la pila al ingresar a la
función. Un hecho no obvio de este último paso es que el puntero del cuadro anterior
siempre es accesible desde el actual. De hecho, se encuentra entre los otros registros de
llamadas guardadas en un desplazamiento positivo defp(pero un desplazamiento más bajo
que los parámetros pasados usando la pila porque los registros guardados por el destinatario
se insertan en último lugar). Esta última propiedad puede parecer poco interesante, pero nos
permite encadenarnos a través del puntero del marco de nuestros llamadores. En general,
esto solo es de interés para los depuradores porque necesitan realizar un seguimiento de las
funciones que se están llamando hasta el momento.

La siguiente imagen muestra cómo el diseño de la pila, después de que se ha establecido el

enlace dinámico y se ha ampliado la pila para las variables locales, se parece a una
función gque ha sido llamada por f. El conjunto de datos que se direcciona mediante el
puntero de trama se denomina comúnmente registro de activación , ya que es un conjunto
de información específico de la activación dinámica de la función (es decir, de la llamada
actual).
Enlace estático
Cuando una función llama a una función anidada (también llamada función local ), la
función anidada puede usar variables locales de la función adjunta. Esto significa que debe
haber una forma para que la función anidada acceda a las variables locales desde la función
adjunta. Se podría pensar que el vínculo dinámico debería ser suficiente. De hecho, si el
lenguaje de programación solo permitiera que las funciones anidadas llamaran a otras
funciones anidadas (inmediatamente), esto sería cierto. Pero si esto fuera así, ese lenguaje
de programación sería bastante limitado. Dicho esto, por el momento, supongamos que este
es el caso: revisa nuevamente la imagen de arriba. Si ges una función local de f, entonces
debería ser posible gacceder a las variables locales de fyendo a la anterior fp.

Considere el siguiente código C (tenga en cuenta que el estándar C no permite funciones de

anidamiento, aunque GCC las implementa como una extensión que discutiremos en un
capítulo posterior).

1void f() // non-nested (normal) function

 2{
3 int x;
4 void g() // nested function
5 {
6 x = x + 1; // x ← x + 1
7 }
8
9 x = 1; // x ← 1
10 g(); // call g
11 x = x + 1; // x ← x + 1
12 // here x will be 3
13}

El código anterior presenta este caso simple en el que una función puede llamar a una
anidada. Al final de la función f, xtendrá el valor 2porque la función anidada gmodifica la
variable x, también modificada por fsí misma.

Para acceder a xdesde gnecesitamos obtener el anterior fp. Como solo fnos pueden llamar,

una vez que consigamos este previo fp, será como el fpque teníamos dentro f. Así que ahora
se trata de utilizar el mismo desplazamiento que fusos.

1/* nested01.s */
2
[Link]
4
5f:
6 push {r4, r5, fp, lr} /* keep registers */
7 mov fp, sp /* keep dynamic link */
8
9 sub sp, sp, #8 /* make room for x (4 bytes)
10 plus 4 bytes to keep stack
11 aligned */
12 /* x is in address "fp - 4" */
13
14 mov r4, #1 /* r4 ← 0 */
15 str r4, [fp, #-4] /* x ← r4 */
16
17 bl g /* call (nested function) g
18 (the code of 'g' is given below, after 'f') */
19
20 ldr r4, [fp, #-4] /* r4 ← x */
21 add r4, r4, #1 /* r4 ← r4 + 1 */
22 str r4, [fp, #-4] /* x ← r4 */
23
24 mov sp, fp /* restore dynamic link */
25 pop {r4, r5, fp, lr} /* restore registers */
26 bx lr /* return */
27
28 /* nested function g */
29 g:
30 push {r4, r5, fp, lr} /* keep registers */
31 mov fp, sp /* keep dynamic link */
32
33 /* At this point our stack looks like this
34
35 Data | Address | Notes
36 ------+---------+--------------------------
37 r4 | fp |
38 r5 | fp + 4 |
39 fp | fp + 8 | This is the previous fp
40 lr | fp + 16 |
41 */
42
43 ldr r4, [fp, #+8] /* get the frame pointer
44 of my caller
45 (since only f can call me)
46 */
47
48 /* now r4 acts like the fp we had inside 'f' */
49 ldr r5, [r4, #-4] /* r5 ← x */
50 add r5, r5, #1 /* r5 ← r5 + 1 */
51 str r5, [r4, #-4] /* x ← r5 */
52
53 mov sp, fp /* restore dynamic link */
54 pop {r4, r5, fp, lr} /* restore registers */
55 bx lr /* return */
56
[Link] main
58
59main :
60 push {r4, lr} /* keep registers */
61
62 bl f /* call f */
63
64 mov r0, #0
65 pop {r4, lr}
 66 bx lr

Ok, la idea esencial está establecida. Al acceder a una variable local, siempre necesitamos
obtener el puntero del marco de la función a la que pertenece la variable local. En la línea
43 obtenemos el puntero del marco de nuestro llamador y luego lo usamos para acceder a la
variable x, líneas 49 a 51. Por supuesto, si la variable local pertenece a la función actual, no
se tiene que hacer nada especial ya que fp es suficiente, vea líneas 20 a 22.

Dicho esto, aunque la idea es fundamentalmente correcta, usar el enlace dinámico nos
limita mucho: solo es posible una única llamada desde una función adjunta. ¿Qué pasa si
permitimos que las funciones anidadas llamen a otras funciones anidadas (funciones
hermanas) o, peor aún, qué hubiera pasado si lo ganterior se llamara a sí mismo de forma
recursiva? El enlace dinámico que encontraremos en la pila siempre hará referencia a la
función activada dinámicamente anterior, y en el ejemplo anterior lo era f, pero si se gllama
a sí mismo de forma recursiva, ¡ gserá la función activada dinámicamente anterior!

Está claro que algo anda mal. Usar el enlace dinámico no es correcto porque, al acceder a
una variable local de una función envolvente, necesitamos obtener la última activación de
esa función envolvente en el punto donde se llamó a la función anidada. La forma de
mantener la última activación de la función envolvente se llama enlace estático en contraste
con el enlace dinámico.

El enlace estático es conceptualmente simple, también es una cadena de punteros de cuadro

como el enlace dinámico. En contraste con el enlace dinámico, que siempre es configurado
de la misma manera por el destinatario), el enlace estático puede configurarse de manera
diferente dependiendo de la función que se esté llamando y será configurado por el
llamador. A continuación veremos las reglas exactas.

Considere el siguiente ejemplo más elaborado;

void f(void) // non nested (nesting depth = 0)
{
int x;

void g() // nested (nesting depth = 1)

{
x = x + 1; // x ← x + 1
}
void h() // nested (nesting depth = 1)
{
void m() // nested (nesting depth = 2)
{
x = x + 2; // x ← x + 2
g(); // call g
}

g(); // call g
m(); // call m
x = x + 3; // x ← x + 3
}
 x = 1; // x ← 1
h(); // call h
// here x will be 8
}
Una función puede, obviamente, llamar a una función anidada inmediatamente. Entonces,
desde el cuerpo de la función fpodemos llamar go h. De manera similar, desde el cuerpo de
la función hpodemos llamar m. Una función puede ser llamada por otras funciones (no
anidadas inmediatamente) siempre que la profundidad de anidamiento de la persona que
llama sea mayor o igual que la llamada. Entonces, desde mpodemos
llamar m(recursivamente) h, gy f. No se permitiría eso fni se gllamaría m.

Tenga en cuenta que hy gestán encerrados por f. Entonces, cuando se les llame, su enlace

dinámico será, por supuesto, la persona que llama, pero su enlace estático siempre debe
apuntar al marco de f. Por otro lado, mestá encerrado por h, por lo que su enlace estático
apuntará al marco de h(y en el ejemplo, también a su enlace dinámico porque es la única
función anidada dentro hy tampoco se llama a sí misma de forma recursiva). Cuando
se mllama g, el enlace estático debe ser nuevamente el marco de su función envolvente f.

Configurar un enlace estático

Al igual que sucede con el enlace dinámico, la AAPCS no exige que se utilice ningún
registro como enlace estático. De hecho, cualquier registro guardado de llamadas que no
tenga un propósito específico servirá. Usaremos r10.

Configurar el enlace estático es un poco más complicado porque requiere prestar atención a
la función a la que llamamos. Hay dos casos:

I. La función se anida inmediatamente (como cuando fllamamos desde go h, o

cuando hllamamos desde m). El enlace estático es simplemente el puntero del marco
de la persona que llama.
Para estos casos, por lo tanto, lo siguiente es todo lo que tenemos que hacer antes de la
llamada.
II. mov r10, fp
bl immediately-nested-function

III. La función no está anidada inmediatamente (como cuando mllamamos desde g),

entonces el marco estático debe ser el de la función envolvente del destinatario. Dado
que el eslabón estático forma una cadena, es solo cuestión de avanzar en la cadena
tantas veces como la diferencia de profundidades de anidación.
Por ejemplo, cuando se mllama g, el enlace estático de mes el marco de h. Al mismo
tiempo, el enlace estático de hes el marco de f. Dado que gy hson hermanos, su vínculo
estático debe ser el mismo. Entonces, cuando las mllamadas g, el enlace estático debe
ser el mismo de h.
Para estos casos, tendremos que hacer lo siguiente
IV. ldr r10, [fp, #X0] /* Xi will be the appropiate offset
V. where the previous value of r10 is found
VI. Note that Xi depends on the layout of
VII. our stack after we have push-ed the
VIII. caller-saved registers
 IX. */
X. ldr r10, [r10, #X1] \
XI. ldr r10, [r10, #X2] |
XII. ... | advance the static link as many times
XIII. ... | the difference of the nesting depth
XIV. ... | (it may be zero times when calling a sibling)
XV. ldr r10, [r10, #Xn] /
bl non-immediately-nested-function
Esto puede parecer muy complicado pero no lo es. Dado que en el ejemplo anterior hay
algunas funciones, haremos una función a la vez. Empecemos por f.

31f:
32 push {r4, r10, fp, lr} /* keep registers */
33 mov fp, sp /* setup dynamic link */
34
35 sub sp, sp, #8 /* make room for x (4 + 4 bytes) */
36 /* x will be in address "fp - 4" */
37
38 /* At this point our stack looks like this
39
40 Data | Address | Notes
41 ------+---------+---------------------------
42 | fp - 8 | alignment (per AAPCS)
43 x | fp - 4 |
44 r4 | fp |
45 r10 | fp + 8 | previous value of r10
46 fp | fp + 12 | previous value of fp
47 lr | fp + 16 |
48 */
49
50 mov r4, #1 /* r4 ← 1 */
51 str r4, [fp, #-4] /* x ← r4 */
52
53 /* prepare the call to h */
54 mov r10, fp /* setup the static link,
55 since we are calling an immediately nested function
56 it is just the current frame */
57 bl h /* call h */
58
59 mov sp, fp /* restore stack */
60 pop {r4, r10, fp, lr} /* restore registers */
61 bx lr /* return */

Dado fque no está anidado en ninguna otra función, el valor anterior de r10no tiene ningún
significado especial para nosotros. Simplemente lo conservamos porque r10, a pesar del
significado especial que le daremos, sigue siendo un registro de llamadas guardadas según
lo exige la AAPCS. Al principio, asignamos espacio para la variable xampliando la pila
(línea 35). La variable xsiempre estará adentro fp - 4. Luego lo configuramos xen 1 (línea
51). Nada de lujos aquí, ya que esta es una función no anidada.

Ahora f llama a h (línea 57). Dado que es una función anidada inmediatamente, el enlace
estático es como en el caso I: el puntero del cuadro actual. Así que lo configuramos r10para
ser fp(línea 56).

Veamos el código de hahora.

63/* ------ nested function ------------------ */

64h :
65 push {r4, r5, r10, fp, lr} /* keep registers */
66 mov fp, sp /* setup dynamic link */
67
68 sub sp, sp, #4 /* align stack */
69
70 /* At this point our stack looks like this
71
72 Data | Address | Notes
73 ------+---------+---------------------------
74 | fp - 4 | alignment (per AAPCS)
75 r4 | fp |
76 r5 | fp + 4 |
77 r10 | fp + 8 | frame pointer of 'f'
78 fp | fp + 12 | frame pointer of caller
79 lr | fp + 16 |
80 */
81
82 /* prepare call to g */
83 /* g is a sibling so the static link will be the same
84 as the current one */
85 ldr r10, [fp, #8]
86 bl g
87
88 /* prepare call to m */
89 /* m is an immediately nested function so the static
90 link is the current frame */
91 mov r10, fp
92 bl m
93
94 ldr r4, [fp, #8] /* load frame pointer of 'f' */
95 ldr r5, [r4, #-4] /* r5 ← x */
 96 add r5, r5, #3 /* r5 ← r5 + 3 */
97 str r5, [r4, #-4] /* x ← r5 */
98
99 mov sp, fp /* restore stack */
100 pop {r4, r5, r10, fp, lr} /* restore registers */
101 bx lr

Comenzamos la función como de costumbre, empujando los registros a la pila y

configurando el enlace dinámico (líneas 64 a 65). Ajustamos la pila para que el puntero de
la pila esté alineado en 8 bytes porque hemos introducido un número par de registros (línea
68). Si comprueba el diseño de la pila después de este último ajuste (representado en las
líneas 72 a 79), verá que en fp + 8tenemos el valor del r10cual el llamador de h(solo en este
ejemplo f, pero podría ser otra función) debe asegurarse que es el puntero del marco
de f. Este puntero adicional en la pila es el enlace estático.

Ahora la función llama g(línea 86) pero debe establecer correctamente el enlace estático
antes de la llamada. En este caso, el enlace estático es el mismo que hporque llamamos
al gque es hermano de h, por lo que comparten el mismo enlace estático. Lo obtenemos
de fp + 8(línea 85). Este es, de hecho, el caso II descrito anteriormente: gno es una función
anidada inmediatamente de h. Entonces, tenemos que obtener el enlace estático de la
persona que llama (el enlace estático de h, que se encuentra en fp + 8) y luego avanzar tantas
veces como la diferencia de sus profundidades de anidación. Ser hermanos significa que sus
profundidades de anidación son las mismas, por lo que en realidad no se requiere ningún
avance.

Después de la llamada a g, la función llama m(línea 92) que pasa a ser una función
inmediatamente anidada, por lo que su enlace estático es el puntero del marco actual (línea
91) porque este es nuevamente el caso I.

Veamos ahora el código de m.

104/* ------ nested function ------------------ */

105m:
106 push {r4, r5, r10, fp, lr} /* keep registers */
107 mov fp, sp /* setup dynamic link */
108
109 sub sp, sp, #4 /* align stack */
110 /* At this point our stack looks like this
111
112 Data | Address | Notes
113 ------+---------+---------------------------
114 | fp - 4 | alignment (per AAPCS)
115 r4 | fp |
116 r5 | fp + 4 |
117 r10 | fp + 8 | frame pointer of 'h'
 118 fp | fp + 12 | frame pointer of caller
119 lr | fp + 16 |
120 */
121
122 ldr r4, [fp, #8] /* r4 ← frame pointer of 'h' */
123 ldr r4, [r4, #8] /* r4 ← frame pointer of 'f' */
124 ldr r5, [r4, #-4] /* r5 ← x */
125 add r5, r5, #2 /* r5 ← r5 + 2 */
126 str r5, [r4, #-4] /* x ← r5 */
127
128 /* setup call to g */
129 ldr r10, [fp, #8] /* r10 ← frame pointer of 'h' */
130 ldr r10, [r10, #8] /* r10 ← frame pointer of 'f' */
131 bl g
132
133 mov sp, fp /* restore stack */
134 pop {r4, r5, r10, fp, lr} /* restore registers */
135 bx lr

La función mcomienza bastante similar a h: presionamos los registros, configuramos el

enlace dinámico y ajustamos la pila para que esté alineada en 8 bytes (líneas 106 a
109). Después de esto, nuevamente tenemos el enlace estático en fp + 8. Si se pregunta si el
enlace estático siempre estará activo fp + 8, la respuesta es no, depende de cuántos registros
se hayan empujado antes r10, simplemente sucede que siempre empujamos r4y r5, pero si,
por ejemplo, también empujamos r6, estaría en un desplazamiento mayor. Cada función
puede tener el enlace estático en diferentes desplazamientos (es por eso que estamos
dibujando el diseño de la pila para cada función, ¡téngalo en cuenta!).

Lo primero que hace m es x ← x + 2. Entonces tenemos que obtener la dirección de x. La
dirección de xes relativa al puntero del marco de fporque xes una variable local de f. No
tenemos el puntero del marco de fsino el de h(este es el enlace estático de m). Dado que los
punteros del marco forman una cadena, podemos cargar el puntero del marco de hy luego
usarlo para obtener el enlace estático del hcual será el puntero del marco f. Es posible que
tenga que volver a leer esta última declaración dos veces :) Así que primero obtenemos el
puntero del marco de h(línea 122), recuerde que este es el enlace estático mque se configuró
cuando se hllamóm(línea 91). Ahora tenemos el puntero de cuadro de h, por lo que podemos
obtener su enlace estático (línea 123) que nuevamente está en el desplazamiento, +8pero
esto es por casualidad, ¡podría estar en un desplazamiento diferente! El enlace estático
de hes el puntero del marco de f, por lo que ahora tenemos el puntero del marco fcomo
queríamos y luego podemos proceder a obtener la dirección de x, que está en el
desplazamiento -4del puntero del marco de f. Con esta dirección ahora podemos realizar x ←
x + 2(líneas 124 a 126).

Luego mllama g(línea 131). Este es nuevamente un caso II. Pero esta vez gno es un hermano

de m: sus profundidades de anidamiento difieren en 1. Entonces, primero cargamos el
enlace estático actual (línea 129), el puntero del marco de h. Y luego avanzamos 1 eslabón
a través de la cadena de eslabones estáticos (línea 130). Permítanme insistir nuevamente: es
por casualidad que el enlace estático de hy fse encuentra en fp+8, cada función podría
tenerlo en diferentes desplazamientos.

Veamos ahora el código de g, que es bastante similar al de h excepto que no llama a nadie.

127/* ------ nested function ------------------ */

128g:
129 push {r4, r5, r10, fp, lr} /* keep registers */
130 mov fp, sp /* setup dynamic link */
131
132 sub sp, sp, #4 /* align stack */
133
134 /* At this point our stack looks like this
135
136 Data | Address | Notes
137 ------+---------+---------------------------
138 | fp - 4 | alignment (per AAPCS)
139 r4 | fp |
140 r5 | fp + 4 |
141 r10 | fp + 8 | frame pointer of 'f'
142 fp | fp + 12 | frame pointer of caller
143 lr | fp + 16 |
144 */
145
146 ldr r4, [fp, #8] /* r4 ← frame pointer of 'f' */
147 ldr r5, [r4, #-4] /* r5 ← x */
148 add r5, r5, #1 /* r5 ← r5 + 1 */
149 str r5, [r4, #-4] /* x ← r5 */
150
151 mov sp, fp /* restore dynamic link */
152 pop {r4, r5, r10, fp, lr} /* restore registers */
153 bx lr

Tenga en cuenta eso hy gcalcule la dirección xexactamente de la misma manera, ya que

están a la misma profundidad de anidación.

A continuación se muestra una imagen de cómo se ve el diseño una vez que se mha
llamado g. Tenga en cuenta que el enlace estático de gy hes el mismo, el puntero del marco
de f, porque son hermanos.
A continuación se muestra la misma imagen, pero esta vez usando líneas de colores para
mostrar cómo cada función puede calcular la dirección de x.
Finalmente aquí está el main. Tenga en cuenta que cuando una función no anidada llama a
otra función no anidada, no es necesario hacer nada r10. Esta es la razón por la r10que no
tiene ningún valor significativo en la entrada a f.

[Link] main
153
154main :
155 push {r4, lr} /* keep registers */
156
157 bl f /* call f */
158
159 mov r0, #0
160 pop {r4, lr}
161 bx lr

Discusión
Si se detiene y piensa en todas estas cosas del enlace estático, pronto se dará cuenta de que
hay algo turbio con todo este asunto de funciones anidadas: estamos pasando algún tipo de
parámetro oculto (a través r10) a las funciones anidadas. De hecho, de alguna manera
estamos haciendo trampa, porque lo configuramos r10justo antes de la llamada y luego lo
presionamos en la entrada de las funciones anidadas, incluso si no lo modifican en la
función llamada. ¿Por qué estamos haciendo este paso aparentemente inútil?

Bueno, al presionar siempre r10la pila, solo estamos ocultando la verdad desnuda: las
funciones anidadas requieren un parámetro adicional, algo oculto. Este parámetro adicional
es este enlace estático. A veces también se le llama ámbito léxico . Se llama ámbito léxico
porque nos da el contexto de la función que lo encierra léxicamente (es decir, en el código)
(en contraste, el ámbito dinámico sería el de nuestro llamador, que no nos importa a menos
que seamos un depurador). Con ese contexto léxico podemos obtener las variables locales
de esa función adjunta. Debido a la naturaleza encadenada del enlace estático, podemos
subir los ámbitos léxicos. Esta es la razón por la que mpuede acceder a una variable de f,
simplemente sube a través de los enlaces estáticos como se muestra en la última imagen de
arriba.

¿Podemos pasar el alcance léxico a una función usando la pila, en lugar de un registro
guardado por el destinatario? Seguro. Por conveniencia, puede que tenga que ser el primer
parámetro pasado por la pila (por lo que su desplazamiento desde fpes fácil de calcular). En
lugar de configurar r10antes de la llamada, ampliaremos spsegún sea necesario (al menos 8
bytes, para mantener alineada la pila de 8 bytes) y luego almacenaremos allí el enlace
estático. En el diseño de pila, el enlace estático ahora se encontrará después (es decir,
compensaciones más grandes que) los registros insertados.

Podemos pasar el ámbito léxico utilizando un registro de llamadas-guardado

(como r0, r1, r2o r3)? Sí, pero lo primero que debemos hacer es mantenerlo en la pila, como
una variable local (es decir, compensaciones negativas de fp). ¿Por qué? Porque si no lo
guardamos en la pila no podremos mover hacia arriba los enlaces estáticos.

Como puede ver, cualquier enfoque requiere que mantengamos el enlace estático en la
pila. Si bien nuestro enfoque de consumo r10puede no ser completamente ortodoxo, termina
haciendo lo correcto.

Pero la discusión no estaría completa si no habláramos de punteros. ¿Qué pasa con un

puntero a una función anidada? ¿Es eso siquiera posible? Cuando llamamos (directamente)
a una función anidada, podemos establecer el alcance léxico de manera adecuada porque lo
sabemos todo: sabemos dónde estamos y sabemos a qué función vamos a llamar. Pero, ¿qué
pasa con una llamada indirecta que usa un puntero a una función? No sabemos qué función
(posiblemente anidada) vamos a llamar, cómo podemos establecer apropiadamente su
alcance léxico. Bueno, la respuesta es que no podemos a menos que mantengamos el
alcance léxico en alguna parte. Esto significa que solo la dirección de la función no es
suficiente. Necesitaremos mantener, junto con la dirección de la función, el alcance
léxico. Entonces, un puntero a una función anidada resulta ser diferente a un puntero a una
función no anidada,

No es deseable tener punteros incompatibles para funciones anidadas y no anidadas. Esta

puede ser una razón por la que C (y C ++) no admiten directamente funciones anidadas
(aunque esta limitación se puede solucionar con otros enfoques). En el próximo capítulo,
veremos un enfoque inteligente para evitar, hasta cierto punto, tener diferentes punteros a
funciones anidadas que son diferentes de punteros a funciones no anidadas.

nsamblador ARM en Raspberry Pi -

Capítulo 24
9 de enero de 2015• Roger Ferrer Ibáñez • Raspberry Pi • brazo , ensamblador , frambuesa

Hoy continuaremos con funciones anidadas.

Clasificación
Primero tomaremos un desvío. La función C qsortse puede utilizar para ordenar cualquier
tipo de matriz. Su firma C es la siguiente.
void qsort(void *base,
size_t nmemb,
size_t size,
int (*compar)(const void *, const void *));
qsortdevuelve void, es decir, no devuelvenada porque realiza la ordenación en el lugar . Esto
significa que pasaremos una matriz (potencialmente sin clasificar) llamada basede
longitud nmemba qsort. Cuando qsortregrese, los elementos de esta matriz se
ordenarán. Si qsortpudiera ordenar un tipo específico de matrices, sería bastante
limitado. Para poder ordenar cualquier matriz, se qsortrequiere el valor sizede cada elemento
de la matriz. Tenga en cuenta que la matriz se pasa por referencia (de lo contrario, la
clasificación en el lugar no sería posible): void*es la forma en C de decir «Acepto una
dirección para cualquier tipo de datos».

Volveremos más tarde al comparfragmento de qsort.

Imprimir una matriz

Antes de ordenar una matriz, necesitamos una forma de examinarla. Usaremos para eso una
función print_arrayque imprime una matriz de números enteros.

1/* print-array.s */
2
[Link]
4
5/* declare an array of 10 integers called my_array */
[Link] 4
7my_array: .word 82, 70, 93, 77, 91, 30, 42, 6, 92, 64
8
9/* format strings for printf */
10/* format string that prints an integer plus a space */
[Link] 4
12integer_printf: .asciz "%d "
13/* format string that simply prints a newline */
[Link] 4
15newline_printf: .asciz "\n"
16
[Link]
18
19print_array:
20 /* r0 will be the address of the integer array */
21 /* r1 will be the number of items in the array */
22 push {r4, r5, r6, lr} /* keep r4, r5, r6 and lr in the stack */
23
24 mov r4, r0 /* r4 ← r0. keep the address of the array */
25 mov r5, r1 /* r5 ← r1. keep the number of items */
26 mov r6, #0 /* r6 ← 0. current item to print */
27
28 b .Lprint_array_check_loop /* go to the condition check of the loop */
29
30 .Lprint_array_loop:
31 /* prepare the call to printf */
32 ldr r0, addr_of_integer_printf /* r0 ← &integer_printf */
 33 /* load the item r6 in the array in address r4.
34 elements are of size 4 bytes so we need to multiply r6 by 4 */
35 ldr r1, [r4, +r6, LSL #2] /* r1 ← *(r4 + r6 << 2)
36 this is the same as
37 r1 ← *(r4 + r6 * 4) */
38 bl printf /* call printf */
39
40 add r6, r6, #1 /* r6 ← r6 + 1 */
41 .Lprint_array_check_loop:
42 cmp r6, r5 /* perform r6 - r5 and update cpsr */
43 bne .Lprint_array_loop /* if cpsr states that r6 is not equal to r5
44 branch to the body of the loop */
45
46 /* prepare call to printf */
47 ldr r0, addr_of_newline_printf /* r0 ← &newline_printf */
48 bl printf
49
50 pop {r4, r5, r6, lr} /* restore r4, r5, r6 and lr from the stack */
51 bx lr /* return */
52
53addr_of_integer_printf: .word integer_printf
54addr_of_newline_printf: .word newline_printf
55
[Link] main
57main:
58 push {r4, lr} /* keep r4 and lr in the stack */
59
60 /* prepare call to print_array */
61 ldr r0, addr_of_my_array /* r0 ← &my_array */
62 mov r1, #10 /* r1 ← 10
63 our array is of length 10 */
64 bl print_array /* call print_array */
65
66 mov r0, #0 /* r0 ← 0 set errorcode to 0 prior returning from main */
67 pop {r4, lr} /* restore r4 and lr in the stack */
68 bx lr /* return */
69
70addr_of_my_array: .word my_array

El código anterior es bastante sencillo y no incluye nada que no se haya visto en entregas
anteriores. Ejecutarlo simplemente imprime el contenido actual de la matriz.
$ ./print-array
82 70 93 77 91 30 42 6 92 64

Comparación
Arriba, cuando hablamos qsortnos saltamos el comparparámetro. ¿Qué es compar? Es una
dirección a una función. La sintaxis funky para C nos dice que a esta función, si alguna vez
se la llama, se le pasarán dos direcciones (de nuevo, no le importa cuáles son, entonces
son void*) y devuelve un número entero. El manual de qsort explica que esta función tiene
que devolver menor que cero, cero o mayor que cero. Si el objeto en la dirección del primer
parámetro de compares menor que el objeto en la dirección del segundo parámetro, entonces
tiene que devolver menor que cero. Si son iguales , debería devolver cero. Si el primer
objeto es mayor que el segundo, entonces debería devolver mayor que cero.

Si se pregunta por qué los parámetros de comparson en realidad en const void*lugar de void*,
es la forma en C de decirnos que los datos de los objetos referenciados no pueden cambiar
durante la comparación. Esto puede parecer obvio dado que cambiar las cosas no es el
trabajo de una función de comparación. Pasarlos por referencia nos permitiría
cambiarlos. Así que este es un recordatorio de que no deberíamos.

Dado que nuestra matriz es una matriz de números enteros, tendremos que comparar
enteros: escribamos una función que, dados dos punteros a números enteros (es decir,
direcciones) se comporte como se indicó anteriormente.

19integer_comparison:
20 /* r0 will be the address to the first integer */
21 /* r1 will be the address to the second integer */
22 ldr r0, [r0] /* r0 ← *r0
23 load the integer pointed by r0 in r0 */
24 ldr r1, [r1] /* r1 ← *r1
25 load the integer pointed by r1 in r1 */
26
27 cmp r0, r1 /* compute r0 - r1 and update cpsr */
28 moveq r0, #0 /* if cpsr means that r0 == r1 then r0 ← 0 */
29 movlt r0, #-1 /* if cpsr means that r0 < r1 then r0 ← -1 */
30 movgt r0, #1 /* if cpsr means that r0 > r1 then r0 ← 1 */
31 bx lr /* return */

La función integer_comparisontampoco presenta nada nuevo: simplemente evita las

ramificaciones usando la predicación como vimos en el capítulo 11.

Ahora tenemos el último bit que falta para poder llamar qsort. Aquí hay un programa que
imprime (solo mainse muestra) la matriz dos veces, antes de ordenarla y después de
ordenarla.

[Link] main
67main:
 68 push {r4, lr} /* keep r4 and lr in the stack */
69
70 /* prepare call to print_array */
71 ldr r0, addr_of_my_array /* r0 ← &my_array */
72 mov r1, #10 /* r1 ← 10
73 our array is of length 10 */
74 bl print_array /* call print_array */
75
76 /* prepare call to qsort */
77 /*
78 void qsort(void *base,
79 size_t nmemb,
80 size_t size,
81 int (*compar)(const void *, const void *));
82 */
83 ldr r0, addr_of_my_array /* r0 ← &my_array
84 base */
85 mov r1, #10 /* r1 ← 10
86 nmemb = number of members
87 our array is 10 elements long */
88 mov r2, #4 /* r2 ← 4
89 size of each member is 4 bytes */
90 ldr r3, addr_of_integer_comparison
91 /* r3 ← &integer_comparison
92 compar */
93 bl qsort /* call qsort */
94
95 /* now print again to see if elements were sorted */
96 /* prepare call to print_array */
97 ldr r0, addr_of_my_array /* r0 ← &my_array */
98 mov r1, #10 /* r1 ← 10
99 our array is of length 10 */
100 bl print_array /* call print_array */
101
102 mov r0, #0 /* r0 ← 0 set errorcode to 0 prior returning from main */
103 pop {r4, lr} /* restore r4 and lr in the stack */
104 bx lr /* return */
105
106addr_of_my_array: .word my_array
107addr_of_integer_comparison : .word integer_comparison

Si juntamos todo, podemos verificar que nuestra matriz esté efectivamente ordenada
después de la llamada a la qsortfunción.
$ ./sort-array
82 70 93 77 91 30 42 6 92 64
6 30 42 64 70 77 82 91 92 93

¿Qué está pasando?

La función C qsortimplementa un algoritmo de clasificación (el estándar C no especifica
cuál debe ser, pero generalmente es una versión ajustada de Quicksort ) que en algún
momento requerirá comparar dos elementos. Para hacer esto, qsortllama a la función compar.

Cuente cuántas comparaciones ocurren

Ahora, queremos contar cuántas comparaciones (es decir, cuántas veces integer_comparisonse
llama) al ordenar la matriz. Podríamos cambiar integer_comparisonpara que incremente un
contador global.
.data
global_counter: .word 0

.text
integer_comparison_count_global:
/* r0 will be the address to the first integer */
/* r1 will be the address to the second integer */
push {r4, r5} /* keep callee-saved registers */
ldr r0, [r0] /* r0 ← *r0
load the integer pointed by r0 in r0 */
ldr r1, [r1] /* r1 ← *r1
load the integer pointed by r1 in r1 */

cmp r0, r1 /* compute r0 - r1 and update cpsr */

moveq r0, #0 /* if cpsr means that r0 == r1 then r0 ← 0 */
movlt r0, #-1 /* if cpsr means that r0 < r1 then r0 ← -1 */
movgt r0, #1 /* if cpsr means that r0 > r1 then r0 ← 1 */

ldr r4, addr_of_global_counter /* r4 ← &global_counter */

ldr r5, [r4] /* r5 ← *r4 */
add r5, r5, #1 /* r5 ← r5 + 1 */
str r5, [r4] /* *r4 ← r5 */

pop {r4, r5} /* restore callee-saved registers */

bx lr /* return */
addr_of_global_counter: .word global_counter
Pero esta publicación trata sobre funciones anidadas, por lo que usaremos funciones
anidadas. Recuerde que las funciones anidadas pueden acceder a variables locales de sus
funciones adjuntas. Entonces usaremos una variable local de maincomo contador y una
función anidada (de main) que realiza la comparación y actualiza el contador.

En el último capítulo terminamos con una breve discusión sobre las funciones
anidadas. Una desventaja de las funciones anidadas es que un puntero a una función
anidada requiere dos cosas: la dirección de la función y el alcance léxico. Si vuelves a
revisar el ejemplo anterior donde llamamos qsort, verás que no mencionamos en ninguna
parte el alcance léxico. Y hay una razón para eso, no es posible pasárselo qsort. En C, las
funciones no se pueden anidar, por lo que un puntero a una función puede ser simplemente
la dirección de la función.

Trampolín
Continuaremos usando la convención del último capítulo: r10tendrá el alcance léxico al
ingresar la función. Pero qsort, cuando las llamadas integer_compare_countno nos lo
configuran: no podemos contar con r10tener un valor significativo cuando se nos llama
desde qsort. Esto significa que en qsortrealidad debería llamar a algo que primero se
establece r10con el valor correcto y luego salta a integer_compare_count. Llamaremos a este
código auxiliar (o pseudofunción) un trampolín . La técnica utilizada aquí es similar a la
utilizada por GCC descrita en Lexical Closures for C ++ (Thomas M. Breuel, USENIX C +
+ Conference Proceedings, 17-21 de octubre de 1988) .

El trampolín es una secuencia de instrucciones pequeña, siempre la misma, que se

comporta como una función y su único propósito es configurar r10y luego hacer una
llamada indirecta a la función anidada. Dado que la secuencia de instrucciones es siempre
la misma, las instrucciones en sí parecen una plantilla .

174.Laddr_trampoline_template : .word .Ltrampoline_template /* we will use this below */

175.Ltrampoline_template:
176 .Lfunction_called: .word 0x0
177 .Llexical_scope: .word 0x0
178 push {r4, r5, r10, lr} /* keep callee-saved registers */
179 ldr r4, .Lfunction_called /* r4 ← function called */
180 ldr r10, .Llexical_scope /* r10 ← lexical scope */
181 blx r4 /* indirect call to r4 */
182 pop {r4, r5, r10, lr} /* restore callee-saved registers */
183 bx lr /* return */

Usé la plantilla de Word porque, si bien las instrucciones no van a cambiar, hay dos
elementos en el trampolín, etiquetados function_calledy lexical_scope, que deberán configurarse
adecuadamente antes de usar el trampolín.

Puede ser más fácil de entender si considera el código anterior como si fueran datos: véalo
como una matriz de números enteros. Los dos primeros enteros, function_calledy lexical_scope,
siguen siendo cero, pero se establecerán en algún momento. Los elementos restantes en la
matriz son otros enteros (no nos importa cuáles) que codifican instrucciones ARM. Lo
bueno es que estas instrucciones se refieren a los dos primeros números enteros, por lo que
al cambiarlos estamos cambiando indirectamente lo que hace el trampolín. Este trampolín
ocupa 8 palabras, es decir, 32 bytes.

Comencemos con este ejemplo.

 1/* trampoline-sort-arrays.s */
2
[Link]
4
5/* declare an array of 10 integers called my_array */
[Link] 4
7my_array: .word 82, 70, 93, 77, 91, 30, 42, 6, 92, 64
8
9/* format strings for printf */
10/* format string that prints an integer plus a space */
[Link] 4
12integer_printf: .asciz "%d "
13/* format string that simply prints a newline */
[Link] 4
15newline_printf: .asciz "\n"
[Link] 4 /* format string for number of comparisons */
17comparison_message: .asciz "Num comparisons: %d\n"
18
[Link]

La función print_arrayserá la misma que la anterior. Lo siguiente es main.

[Link] main
55main:
56 push {r4, r5, r6, fp, lr} /* keep callee saved registers */
57 mov fp, sp /* setup dynamic link */
58
59 sub sp, sp, #4 /* counter will be in fp - 4 */
60 /* note that now the stack is 8-byte aligned */
61
62 /* set counter to zero */
63 mov r4, #0 /* r4 ← 0 */
64 str r4, [fp, #-4] /* counter ← r4 */

Nada especial aquí, configuramos el enlace dinámico, asignamos espacio en la pila para el
contador y lo configuramos en cero.

Ahora dejamos espacio para el trampolín en la pila. Recuerde que nuestro trampolín ocupa
32 bytes.

66 /* Make room for the trampoline */

67 sub sp, sp, #32 /* sp ← sp - 32 */
68 /* note that 32 is a multiple of 8, so the stack
 69 is still 8-byte aligned */

Ahora copiaremos la plantilla de trampolín en el almacenamiento de pila que acabamos de

asignar. Hacemos esto con un ciclo que copia una palabra (4 bytes) a la vez.

71 /* copy the trampoline into the stack */

72 mov r4, #32 /* r4 ← 32 */
73 ldr r5, .Laddr_trampoline_template /* r4 ← &trampoline_template */
74 mov r6, sp /* r6 ← sp */
75 b .Lcopy_trampoline_loop_check /* branch to copy_trampoline_loop_check */
76
77 .Lcopy_trampoline_loop:
78 ldr r7, [r5] /* r7 ← *r5 */
79 str r7, [r6] /* *r6 ← r7 */
80 add r5, r5, #4 /* r5 ← r5 + 4 */
81 add r6, r6, #4 /* r6 ← r6 + 4 */
82 sub r4, r4, #4 /* r4 ← r4 - 4 */
83 .Lcopy_trampoline_loop_check:
84 cmp r4, #0 /* compute r4 - 0 and update cpsr */
85 bgt .Lcopy_trampoline_loop /* if cpsr means that r4 > 0
86 then branch to copy_trampoline_loop */

En el ciclo anterior, r4cuenta cuántos bytes quedan por copiar. r5y r6son punteros dentro del
trampolín (fuente) y la pila (destino), respectivamente. Dado que copiamos 4 bytes a la vez,
los tres registros se actualizan en 4.

Ahora tenemos el trampolín copiado en la pila. Recuerde, es solo una serie de palabras, las
dos primeras de las cuales deben actualizarse. Los primeros 4 bytes deben ser la dirección
de la función a llamar, es decir, integer_comparison_county los segundos 4 bytes deben ser el
enlace estático, es decir fp.

88 /* setup the trampoline */

89 ldr r4, addr_of_integer_comparison_count
90 /* r4 ← &integer_comparison_count */
91 str r4, [fp, #-36] /* *(fp - 36) ← r4 */
92 /* set the function_called in the trampoline
93 to be &integer_comparison_count */
94 str fp, [fp, #-32] /* *(fp - 32) ← fp */
95 /* set the lexical_scope in the trampoline
96 to be fp */

Recordemos que nuestro trampolín ocupa 32 bytes pero en la pila también tenemos el
contador. Esta es la razón por la que el trampolín comienza en fp - 36(esta es también la
dirección de la primera palabra del trampolín, por supuesto). La segunda palabra es
entonces fp - 32.

Ahora procedemos como en el ejemplo de clasificación anterior: imprimimos la matriz

antes de clasificarla y después de clasificarla. Antes de imprimir la matriz ordenada,
también imprimiremos el número de comparaciones que se realizaron.

103 /* prepare call to print_array */

104 ldr r0, addr_of_my_array /* r0 ← &my_array */
105 mov r1, #10 /* r1 ← 10
106 our array is of length 10 */
107 bl print_array /* call print_array */
108
109 /* prepare call to qsort */
110 /*
111 void qsort(void *base,
112 size_t nmemb,
113 size_t size,
114 int (*compar)(const void *, const void *));
115 */
116 ldr r0, addr_of_my_array /* r0 ← &my_array
117 base */
118 mov r1, #10 /* r1 ← 10
119 nmemb = number of members
120 our array is 10 elements long */
121 mov r2, #4 /* r2 ← 4
122 size of each member is 4 bytes */
123 sub r3, fp, #28 /* r3 ← fp - 28 */
124 bl qsort /* call qsort */
125
126 /* prepare call to printf */
127 ldr r1, [fp, #-4] /* r1 ← counter */
128 ldr r0, addr_of_comparison_message /* r0 ← &comparison_message */
129 bl printf /* call printf */
130
131 /* now print again the array to see if elements were sorted */
132 /* prepare call to print_array */
133 ldr r0, addr_of_my_array /* r0 ← &my_array */
134 mov r1, #10 /* r1 ← 10
135 our array is of length 10 */
136 bl print_array /* call print_array */

Tenga en cuenta que el argumento comparpasado a qsort (línea 123) no es la dirección de la

función anidada sino el trampolín. De hecho, no es el trampolín sino su tercera palabra ya
que, como sabemos, las dos primeras palabras del trampolín son la dirección de la función
anidada a llamar y el alcance léxico (que establecimos anteriormente, líneas 91 y 94).

Finalmente volvemos de main como de costumbre.

139 mov r0, #0 /* r0 ← 0 set errorcode to 0 prior returning from main */

140
141 mov sp, fp
142 pop {r4, r5, r6, fp, lr} /* restore callee-saved registers */
143 bx lr /* return */
144
145addr_of_my_array: .word my_array
146addr_of_comparison_message : .word comparison_message

La función de comparación anidada es la siguiente.

148 /* nested function integer comparison */

149 addr_of_integer_comparison_count : .word integer_comparison_count
150 integer_comparison_count:
151 /* r0 will be the address to the first integer */
152 /* r1 will be the address to the second integer */
153 push {r4, r5, r10, fp, lr} /* keep callee-saved registers */
154 mov fp, sp /* setup dynamic link */
155
156 ldr r0, [r0] /* r0 ← *r0
157 load the integer pointed by r0 in r0 */
158 ldr r1, [r1] /* r1 ← *r1
159 load the integer pointed by r1 in r1 */
160
161 cmp r0, r1 /* compute r0 - r1 and update cpsr */
162 moveq r0, #0 /* if cpsr means that r0 == r1 then r0 ← 0 */
163 movlt r0, #-1 /* if cpsr means that r0 < r1 then r0 ← -1 */
164 movgt r0, #1 /* if cpsr means that r0 > r1 then r0 ← 1 */
165
166 ldr r4, [fp, #8] /* r4 ← *(fp + 8)
167 get static link in the stack */
168 ldr r5, [r4, #-4] /* r5 ← counter
169 get value of counter */
170 add r5, r5, #1 /* r5 ← r5 + 1 */
171 str r5, [r4, #-4] /* counter ← r5
172 update counter */
173
174 mov sp, fp /* restore stack */
175 pop {r4, r5, r10, fp, lr} /* restore callee-saved registers */
 176 bx lr /* return */

Como puede ver, la función anidada espera r10estar configurada correctamente. Esto es lo

que hace el trampolín.

Arquitectura de Harvard
Si intenta ejecutar el programa como se muestra, probablemente funcionará. Pero lo hará
por casualidad. La razón es que estamos presentando una forma simple de código auto
modificable.

El procesador Raspberry Pi presenta una arquitectura Harvard modificada . Esto significa

que en algún momento existe una distinción entre la memoria de instrucciones ( .text) y la
memoria de datos ( .data). Hoy en día, no hay muchos procesadores que presenten una
distinción estricta entre la memoria de instrucciones y la de datos (por lo que en algún
momento el programa y los datos se encuentran en la memoria principal , comúnmente
llamada RAM), pero dicha diferenciación se mantiene para los cachés .

Un caché es una memoria más pequeña y rápida que se encuentra entre el procesador y la
memoria principal. Se utiliza para acelerar los accesos a la memoria, ya que la mayoría de
las veces dichos accesos ocurren cerca de otros accesos a la memoria (es decir, acceder a
elementos de una matriz, diferentes variables locales en la pila o una instrucción tras otra en
secuenciación implícita) o cerca en el tiempo ( es decir, acceder varias veces a la misma
variable local o ejecutar la misma instrucción cuando el código está en un bucle).

La mayoría de los procesadores modernos cuentan con cachés distinguidos para datos
(llamado caché de datos ) e instrucciones (llamado caché de instrucciones). La razón de tal
diferenciación es que el acceso a la memoria para ejecutar instrucciones tiene un patrón
diferente al acceso a la memoria para cargar / almacenar datos. Es beneficioso hacer tal
distinción pero tiene un precio: cuando un programa manipula datos que luego se
ejecutarán como instrucciones (como hicimos con el trampolín, pero también cuando el
sistema operativo carga un programa en la memoria) la vista del dos cachés con respecto al
estado del programa se vuelve incoherente: los cambios que hicimos en los datos tendrán
efecto en el caché de datos pero no en el caché de instrucciones. Por el contrario, dado que
la caché de instrucciones solo obtendrá datos de la memoria principal (y no de la caché de
datos), debemos volver a escribir todos los cambios que hicimos en la caché de datos en la
memoria principal (esto se llama vaciarel caché). También tenemos que asegurarnos de que
la caché de instrucciones obtenga de manera efectiva las instrucciones de la memoria, en
lugar de reutilizar instrucciones cargadas previamente (que ahora estarían obsoletas), por lo
que tenemos que invalidar (o borrar) la caché de instrucciones.

En ARM, las instrucciones que vacían e invalidan cachés son operaciones privilegiadas
(realizadas a través de instrucciones del coprocesador en el coprocesador 15 que administra
el sistema de memoria de la CPU). Esto significa que solo el sistema operativo puede
ejecutar tales instrucciones. Como puede ver, es posible que el código de usuario deba
solicitar un borrado de caché. Linux proporciona una cacheflushllamada al sistema para este
propósito. Recuerde que en el capítulo 19 vimos cómo realizar llamadas al sistema.

Según el kernel de Linux , el registro r0 debe contener la dirección del comienzo de la

región que se va a limpiar e invalidar. r1debe contener la dirección del primer byte que no
se invalidará. r2debe ser cero. El número de servicio de cacheflush que debe
establecerse r7es 0xf0002.
push {r7} /* keep r7 because we are going to modify it */
mov r7, #0xf0000 /* r7 ← 0xf0000 */
add r7, r7, #2 /* r7 ← r7 + 2. So r7 ← 0xf0002
We do this in two steps because
we cannot encode 0xf0002 in
the instruction */
mov r0, sp /* r0 ← sp */
add r1, sp, #32 /* r1 ← sp + 32 */
mov r2, #0 /* r2 ← 0 */
swi 0 /* system call */
pop {r7} /* restore r7 */
Como alternativa, podemos llamar a una función interna implementada en libgcc( la
biblioteca de tiempo de ejecución de bajo nivel de GCC ) llamada __clear_cache . Esta
función llamará internamente al servicio Linux.

98 /* prepare call to __clear_cache */

99 mov r0, sp /* r0 ← sp */
100 add r1, sp, #32 /* r1 ← sp + 32 */
101 bl __clear_cache /* call __clear_cache */

Invalidaremos y descargaremos los cachés inmediatamente después de instalar el trampolín

(líneas 89 a 94).

Ahora solo queda ejecutar nuestro programa.

$ ./trampoline-sort-array
82 70 93 77 91 30 42 6 92 64
Num comparisons: 22
6 30 42 64 70 77 82 91 92 93
Puedes ver el listado completo aquí .

Discusión
Dado que las funciones anidadas requieren un ámbito léxico, no pueden pasarse
trivialmente como direcciones simples a otras funciones. Hoy hemos visto que al usar un
trampolín es posible pasarlos a funciones que no permiten pasar un ámbito léxico. El precio
es tener que copiar una plantilla, el trampolín, tener que configurarlo con los valores
adecuados. También tenemos que vaciar las cachés para evitar ejecutar código
incorrecto. Es complicado pero factible.
Tener que vaciar la caché no es deseable (aunque no es necesario en todas las arquitecturas)
y puede causar una degradación severa del rendimiento. Las piezas de código críticas para
el rendimiento normalmente no querrían hacer esto.

Sin embargo, una preocupación seria con el enfoque del trampolín se relaciona con el
hecho de que necesitamos una pila ejecutable. Un sistema operativo moderno, como Linux,
puede marcar regiones de memoria para que sean legibles, grabables o ejecutables. Una
región de la memoria que no es ejecutable puede contener instrucciones, pero si nos
ramificamos a esa región, el procesador indicará una falla y el sistema operativo
probablemente matará nuestro proceso. La posibilidad de deshabilitar la ejecución de
regiones de memoria específicas se realiza por motivos de seguridad. La mayoría de las
veces no es necesario ejecutar instrucciones que se encuentran en la pila o en
la .datasección. Solo .texttiene sentido en estos casos que sea ejecutable.

Si comprueba lo que hicimos anteriormente, en realidad copiamos algo de código (que

estaba dentro .text) en la pila y luego, lo qsortramificamos a la pila. Esto se debe a que
nuestros programas permiten una pila ejecutable. Las pilas ejecutables están vinculadas a
vulnerabilidades de programas comunes, como desbordamientos de búfer .

Como hemos visto en este capítulo y en el anterior, las funciones anidadas tienen varias
desventajas, por lo que no es sorprendente que varios lenguajes de programación no
brinden soporte para ellas.

Ensamblador ARM en Raspberry Pi

- Capítulo 25
4 de julio de 2015• Roger Ferrer Ibáñez • Raspberry Pi • brazo , ensamblador , pi , frambuesa

En el capítulo 13 vimos VFPv2 y el hecho de que permite operaciones vectoriales en

números de coma flotante. Quizás se pregunte si existe una característica similar para los
números enteros. La respuesta es sí, aunque de forma más limitada.

SIMD
SIMD significa datos múltiples de una sola instrucción y significa que una instrucción se
puede utilizar para realizar la misma operación en varios operandos al mismo tiempo. En
los capítulos 13 y 14 vimos que al cambiar el lencampo en fpscry usar al menos un operando
en los bancos vectoriales, entonces una instrucción operaba en lenregistros en el banco (s)
vectorial (s), efectivamente haciendo por lentiempos una operación de coma flotante. De
esta manera, una sola instrucción como vadd.f32podría usarse para realizar hasta 8 adiciones
de punto flotante. Esta estrategia de acelerar el cálculo también se denomina paralelismo
de datos .
SIMD con enteros
El soporte SIMD para enteros también existe en ARMv6 pero es más limitado: los datos
múltiples son las subpalabras (ver capítulo 21) de un registro de propósito general. Esto
significa que podemos hacer 2 operaciones en las 2 medias palabras de un registro de
propósito general. De manera similar, podemos hacer hasta 4 operaciones en los 4 bytes de
un registro de propósito general.

Ejemplo motivador
En este punto, es posible que se pregunte cuál es el propósito de esta función y por qué
existe. Supongamos que tenemos dos señales de audio PCM de 16 bits muestreadas a
alguna frecuencia (es decir, 44,1 kHz como en un CD de audio). Esto significa que en el
momento de grabar el "sonido analógico" de cada canal se muestrea muchas veces por
segundo y la muestra, que representa la amplitud de la señal, se codifica usando un número
de 16 bits.

Una operación que podríamos querer hacer es mezclar las dos señales en una señal (por
ejemplo, antes de reproducir esa señal final a través de los altavoces). Una forma
(ligeramente incorrecta) de hacer esto es promediando las dos señales. El siguiente código
es un esquema de lo que queremos hacer.
short int channel1[num_samples]; // in our environment a 'short int' is a half-word
short int channel2[num_samples];

short int channel_out[num_samples];

for (i = 0; i < num_samples; i++)
{
channel_out[i] = (channel1[i] + channel2[i]) / 2;
}
Ahora imagina que queremos implementar esto en ARMv6. Con nuestro conocimiento
actual, el código se vería así (omitiré en estos ejemplos la convención de llamada de
función AAPCS).
naive_channel_mixing:
/* r0 contains the base address of channel1 */
/* r1 contains the base address of channel2 */
/* r2 contains the base address of channel_out */
/* r3 is the number of samples */
/* r4 is the number of the current sample
so it holds that 0 ≤ r4 < r3 */

mov r4, #0 /* r4 ← 0 */
b .Lcheck_loop /* branch to check_loop */
.Lloop:
mov r5, r4, LSL #1 /* r5 ← r4 << 1 (this is r5 ← r4 * 2) */
/* a halfword takes two bytes, so multiply
the index by two. We do this here because
ldrsh does not allow an addressing mode
like [r0, r5, LSL #1] */
 ldrsh r6, [r0, r5] /* r6 ← *{signed half}(r0 + r5) */
ldrsh r7, [r1, r5] /* r7 ← *{signed half}(r1 + r5) */
add r8, r6, r7 /* r8 ← r6 + r7 */
mov r8, r8, ASR #1 /* r8 ← r8 >> 1 (this is r8 ← r8 / 2)*/
strh r8, [r2, r5] /* *{half}(r2 + r5) ← r8 */
add r4, r4, #1 /* r4 ← r4 + 1 */
.Lcheck_loop:
cmp r4, r3 /* compute r4 - r3 and update cpsr */
blt .Lloop /* if r4 < r3 jump to the
beginning of the loop */
Probablemente podríamos estar contentos con este código, pero si estuviera en el negocio
de diseñar procesadores para dispositivos integrados, probablemente sería sensible a los
códigos de sus clientes. Y lo más probable es que su reproductor MP3 portátil (o cualquier
dispositivo capaz de reproducir música) esté "ARM adentro". Así que este es un código que
puede mejorarse desde el punto de vista de la arquitectura.

Sumas y restas paralelas

Las instrucciones paralelas de datos ARMv6 nos permiten sumar / restar las medias
palabras o bytes correspondientes. Los proporciona tanto para enteros sin signo como para
enteros con signo.

 Medias palabras
o Firmado: sadd16,ssub16
o Sin firmar: uadd16,usub16
 Bytes
o Firmado: sadd8,ssub8
o Sin firmar: uadd8,usub8

No debería ser difícil encontrar usos obvios para estas instrucciones. Por ejemplo, el
siguiente ciclo puede beneficiarse de la uadd8instrucción.
// unsigned char is an unsigned byte in our environment
// a, b and c are arrays of N unsigned chars
unsigned char a[N], b[N], c[N];

int i;
for (i = 0; i < N; i++)
{
c[i] = a[i] + b[i];
}
Primero escribamos un enfoque ingenuo para el ciclo anterior, que es similar al del
comienzo de la publicación.

1naive_byte_array_addition:
2 /* r0 contains the base address of a */
3 /* r1 contains the base address of b */
4 /* r2 contains the base address of c */
5 /* r3 is N */
 6 /* r4 is the number of the current item
7 so it holds that 0 ≤ r4 < r3 */
8
9 mov r4, #0 /* r4 ← 0 */
10 b .Lcheck_loop0 /* branch to check_loop0 */
11
12 .Lloop0:
13 ldrb r5, [r0, r4] /* r5 ← *{unsigned byte}(r0 + r4) */
14 ldrb r6, [r1, r4] /* r6 ← *{unsigned byte}(r1 + r4) */
15 add r7, r5, r6 /* r7 ← r5 + r6 */
16 strb r7, [r2, r4] /* *{unsigned byte}(r2 + r4) ← r7 */
17 add r4, r4, #1 /* r4 ← r4 + 1 */
18 .Lcheck_loop0:
19 cmp r4, r3 /* perform r4 - r3 and update cpsr */
20 blt .Lloop0 /* if cpsr means that r4 < r3 jump to loop0 */

Este ciclo nuevamente está bien, pero podemos hacerlo mejor usando la
instrucción uadd8. Tenga en cuenta que ahora podremos agregar 4 bytes a la vez. Esto
significa que tendremos que incrementar r4en 4.

1simd_byte_array_addition_0:
2 /* r0 contains the base address of a */
3 /* r1 contains the base address of b */
4 /* r2 contains the base address of c */
5 /* r3 is N */
6 /* r4 is the number of the current item
7 so it holds that 0 ≤ r4 < r3 */
8
9 mov r4, #0 /* r4 ← 0 */
10 b .Lcheck_loop1 /* branch to check_loop1 */
11
12 .Lloop1:
13 ldr r5, [r0, r4] /* r5 ← *(r0 + r4) */
14 ldr r6, [r1, r4] /* r6 ← *(r1 + r4) */
15 sadd8 r7, r5, r6 /* r7[7:0] ← r5[7:0] + r6[7:0] */
16 /* r7[15:8] ← r5[15:8] + r6[15:8] */
17 /* r7[23:16] ← r5[23:16] + r6[23:16] */
18 /* r7[31:24] ← r5[31:24] + r6[31:24] */
19 /* rA[x:y] means bits x to y of the register rA */
20 str r7, [r2, r4] /* *(r2 + r4) ← r7 */
21 add r4, r4, #4 /* r4 ← r4 + 4 */
22 .Lcheck_loop1:
23 cmp r4, r3 /* perform r4 - r3 and update cpsr */
 24 blt .Lloop1 /* if cpsr means that r4 < r3 jump to loop1 */

Una sutileza del código anterior es que solo funciona si N(se mantiene r3) es un múltiplo de
4. Si no es el caso (y esto incluye cuando 0 ≤ r3 <4), entonces el ciclo hará menos
iteraciones de las esperadas. Si sabemos que Nes un múltiplo de 4, no se debe hacer nada
más. Pero si no es un múltiplo de 4, necesitaremos lo que se llama bucle epílogo , para los
casos restantes. Tenga en cuenta que en nuestro caso, el ciclo del epílogo tendrá que hacer 0
(si N es un múltiplo de 4), 1, 2 o 3 iteraciones. Podemos implementarlo como un switch con
4 casos más fall-through (ver capítulo 16) o si nos preocupa el tamaño del código, con un
bucle. Usaremos un bucle.

Sin embargo, no podemos simplemente agregar un ciclo de epílogo al ciclo anterior, porque
en realidad está haciendo más trabajo del que queremos. Cuando N no es múltiplo de
cuatro, la última iteración agregará 1, 2 o 3 bytes más que no pertenecen a la matriz
original. Esta es una receta para un desastre, así que debemos evitarlo. Tenemos que
asegurarnos de que cuando estamos en el bucle, r4es tal que r4, r4 + 1, r4 + 2y r4 + 3son
elementos válidos de la matriz. Esto significa que debemos comprobar que r4 < N, r4 + 1 <
N, r4 + 2 < Ny r4 + 3 < N. Dado que el último de estos cuatro implica los tres primeros, basta
con comprobarlo r4 + 3 < N.

Tenga en cuenta que la comprobación r4 + 3 < Nnos obligaría a calcular r4 + 3en cada
iteración del ciclo, pero no es necesario. Verificar r4 + 3 < Nes equivalente a verificar r4 < N -
3. N - 3no depende de, por r4lo que se puede calcular antes del ciclo.

1simd_byte_array_addition_2:
2 /* r0 contains the base address of a */
3 /* r1 contains the base address of b */
4 /* r2 contains the base address of c */
5 /* r3 is N */
6 /* r4 is the number of the current item
7 so it holds that 0 ≤ r4 < r3 */
8
9 mov r4, #0 /* r4 ← 0 */
10 sub r8, r3, #3 /* r8 ← r3 - 3
11 this is r8 ← N - 3 */
12 b .Lcheck_loop2 /* branch to check_loop2 */
13
14 .Lloop2:
15 ldr r5, [r0, r4] /* r5 ← *(r0 + r4) */
16 ldr r6, [r1, r4] /* r6 ← *(r1 + r4) */
17 sadd8 r7, r5, r6 /* r7[7:0] ← r5[7:0] + r6[7:0] */
18 /* r7[15:8] ← r5[15:8] + r6[15:8] */
19 /* r7[23:16] ← r5[23:16] + r6[23:16] */
20 /* r7[31:24] ← r5[31:24] + r6[31:24] */
21 str r7, [r2, r4] /* *(r2 + r4) ← r7 */
 22 add r4, r4, #4 /* r4 ← r4 + 4 */
23 .Lcheck_loop2:
24 cmp r4, r8 /* perform r4 - r8 and update cpsr */
25 blt .Lloop2 /* if cpsr means that r4 < r8 jump to loop2 */
26 /* i.e. if r4 < N - 3 jump to loop2 */

En la línea 10, donde calculamos r8cuál se mantendrá N - 3, lo usamos en la línea 24 para

verificar la iteración del ciclo.

Sigue el ciclo del epílogo.

27 /* epilog loop */
28 b .Lcheck_loop3 /* branch to check_loop3 */
29
30 .Lloop3:
31 ldrb r5, [r0, r4] /* r5 ← *{unsigned byte}(r0 + r4) */
32 ldrb r6, [r1, r4] /* r6 ← *{unsigned byte}(r1 + r4) */
33 add r7, r5, r6 /* r7 ← r5 + r6 */
34 strb r7, [r2, r4] /* *{unsigned byte}(r2 + r4) ← r7 */
35
36 add r4, r4, #1 /* r4 ← r4 + 1 */
37 .Lcheck_loop3:
38 cmp r4, r3 /* perform r4 - r3 and update cpsr */
39 blt .Lloop3 /* if cpsr means that r4 < r3 jump to loop 3 */

El ciclo del epílogo es como el ingenuo, pero solo ejecutará 0, 1, 2 o 3 iteraciones. Esto

significa que para valores suficientemente grandes de N, en la práctica, todas las iteraciones
usarán las instrucciones paralelas de datos y solo hasta 3 tendrán que usar el enfoque más
lento.

Instrucciones para dividir a la mitad

Las instrucciones paralelas de datos también vienen en una forma en la que la suma / resta
se divide por la mitad. Esto significa que es posible calcular promedios de medias palabras
y bytes fácilmente.

 Medias palabras
o Firmado: shadd16,shsub16
o Sin firmar: uhadd16,uhsub16
 Bytes
o Firmado: shadd8,shsub8
o Sin firmar: uhadd8,uhsub8
Así, el ejemplo motivador del inicio del post se puede implementar utilizando
la shsub16instrucción. Para simplificar, supongamos que num_sampleses un múltiplo de 2
(ahora estamos tratando con medias palabras), por lo que no es necesario un epílogo.
better_channel_mixing:
/* r0 contains the base address of channel1 */
/* r1 contains the base address of channel2 */
/* r2 contains the base address of channel_out */
/* r3 is the number of samples */
/* r4 is the number of the current sample
so it holds that 0 ≤ r4 < r3 */

mov r4, #0 /* r4 ← 0 */
b .Lcheck_loop /* branch to check_loop */
.Lloop:
ldr r6, [r0, r4] /* r6 ← *(r0 + r4) */
ldr r7, [r1, r4] /* r7 ← *(r1 + r4) */
shadd16 r8, r6, r7 /* r8[15:0] ← (r6[15:0] + r7[15:0]) >> 1*/
/* r8[31:16] ← (r6[31:16] + r7[31:16]) >> 1*/
str r8, [r2, r4] /* *(r2 + r4) ← r8 */
add r4, r4, #2 /* r4 ← r4 + 2 */
.Lcheck_loop:
cmp r4, r3 /* compute r4 - r3 and update cpsr */
blt .Lloop /* if r4 < r3 jump to the
beginning of the loop */

Aritmética de saturación
Volvamos a nuestro ejemplo motivador. Hicimos un promedio de los dos canales de 16 bits
para mezclarlos pero, en realidad, la mezcla se logra simplemente agregando los dos
canales. En general, esto está bien porque las señales no están correlacionadas y la amplitud
de una muestra mixta generalmente se puede codificar en 16 bits. A veces, sin embargo, la
muestra mixta puede tener una amplitud que cae fuera del rango de 16 bits. En este caso,
queremos recortar la muestra dentro del rango representable. Una muestra con una amplitud
demasiado positiva se recortará a 2 15 -1, una muestra con una amplitud demasiado negativa
se recortará a -2 15 .

Con la falta de soporte de hardware, el recorte se puede implementar verificando el

desbordamiento después de cada adición. Entonces, cada suma debe verificar que el
número resultante esté en el intervalo [-32768, 32767]. Escribamos una función que sume
dos enteros de 32 bits y los recorte en el rango de 16 bits.
.data
max16bit: .word 32767

.text

clipped_add16bit:
/* first operand is in r0 */
/* second operand is in r0 */
/* result is left in r0 */
push {r4, lr} /* keep registers */
 ldr r4, addr_of_max16bit /* r4 ← &max16bit */
ldr r4, [r4] /* r4 ← *r4 */
/* now r4 == 32767 (i.e. 2^15 - 1) */

add r0, r0, r1 /* r0 ← r0 + r1 */

cmp r0, r4 /* perform r0 - r4 and update cpsr */
movgt r0, r4 /* if r0 > r4 then r0 ← r4 */
bgt end /* if r0 > r4 then branch to end */

mvn r4, r4 /* r4 ← ~r4

now r4 == -32768 (i.e. -2^15) */
cmp r0, r4 /* perform r0 - r4 and update cpsr */
movlt r0, r4 /* if r0 < r4 then r0 ← r4 */

end:

pop {r4, lr} /* restore registers */

bx lr /* return */
addr_of_max16bit: .word max16bit
Como puede ver, una adición aparentemente simple que recorta el resultado requiere un
montón de instrucciones. Como antes, el código es correcto pero podemos hacerlo mucho
mejor gracias a las saturadas instrucciones aritméticas de ARMv6.

 Medias palabras
o Firmado: qadd16,qsub16
o Sin firmar: uqadd16,uqsub16
 Bytes
o Firmado: qadd8,qsub8
o Sin firmar: uqadd8,uqsub8

Ahora podemos escribir una mezcla más realista de dos canales.

more_realistic_channel_mixing:
/* r0 contains the base address of channel1 */
/* r1 contains the base address of channel2 */
/* r2 contains the base address of channel_out */
/* r3 is the number of samples */
/* r4 is the number of the current sample
so it holds that 0 ≤ r4 < r3 */

mov r4, #0 /* r4 ← 0 */
b .Lcheck_loop /* branch to check_loop */
.Lloop:
ldr r6, [r0, r4] /* r6 ← *(r0 + r4) */
ldr r7, [r1, r4] /* r7 ← *(r1 + r4) */
qadd16 r8, r6, r7 /* r8[15:0] ← saturated_sum_16(r6[15:0], r7[15:0]) */
/* r8[31:16] ← saturated_sum_16(r6[31:16], r7[31:16]) */
str r8, [r2, r4] /* *(r2 + r4) ← r8 */
add r4, r4, #2 /* r4 ← r4 + 2 */
.Lcheck_loop:
cmp r4, r3 /* compute r4 - r3 and update cpsr */
blt .Lloop /* if r4 < r3 jump to the
 beginning of the loop */

Ensamblador ARM en Raspberry Pi

- Capítulo 26
30 de octubre de 2016• Roger Ferrer Ibáñez • Raspberry Pi

En este capítulo hablaremos de un paso fascinante que se requiere para crear un programa,
incluso cuando se usa ensamblador. Hoy hablaremos de vincular.

Linkers, la magia entre símbolos y

direcciones
Los enlazadores son una herramienta esencial pero a menudo olvidada. Su trabajo principal
es pegar todas las piezas que forman nuestro programa de manera que se pueda ejecutar. El
trabajo fundamental de un enlazador es vincular nombres simbólicos con direcciones (es
decir, nombres físicos). Este proceso es conceptualmente simple pero está lleno de detalles
interesantes. La vinculación es un paso necesario cuando se utiliza una compilación
separada.

Compilación y módulos separados

Los módulos son un mecanismo en el que los lenguajes de programación permiten a sus
usuarios dividir programas en diferentes partes lógicas. La modularización requiere cierto
apoyo de las herramientas que implementan el lenguaje de programación. La compilación
separada es un mecanismo para lograr esto. En C, un programa puede descomponerse en
varios archivos fuente. Por lo general, la compilación de un archivo fuente en C genera
un archivo objeto , por lo que varios archivos fuente conducirán a varios archivos
objeto. Estos archivos de objeto se combinan mediante un enlazador. El enlazador genera el
programa final.

DUENDE
Dado que varias herramientas manipulan archivos objeto (compiladores, ensambladores,
enlazadores), un formato común resulta útil. Hay algunos formatos disponibles para este
propósito como COFF, Mach-O o ELF. En el mundo UNIX (incluido Linux), el formato
más popular es ELF (formato ejecutable y de enlace) . Este formato se utiliza para archivos
de objetos (llamados objetos reubicables, veremos a continuación por qué), objetos
compartidos (bibliotecas dinámicas) y ejecutables (el programa en sí).

Para un vinculador, un archivo reubicable ELF es una colección de secciones . Las

secciones representan una parte contigua de datos (que puede ser cualquier cosa:
instrucciones, valores iniciales de variables globales, información de depuración,
etc.). Cada sección tiene un nombre y atributos como si debe asignarse en memoria,
cargarse desde la imagen (es decir, el archivo que contiene el programa), si se puede
ejecutar, si se puede escribir, su tamaño y alineación, etc.

Etiquetas como nombres simbólicos

Cuando usamos variables globales tenemos que usar el siguiente esquema:

[Link]:
2var: .word 42
[Link]
4func:
5 /* ... */
6 ldr r0, addr_of_var /* r0 ← &var */
7 ldr r0, [r0] /* r0 ← *r0 */
8 /* ... */
9addr_of_var : .word var

La razón es que en las instrucciones ARM no podemos codificar la dirección completa de

32 bits de una variable dentro de una instrucción. Por lo tanto, tiene sentido mantener la
dirección en un lugar, en este caso en addr_of_var, que sea adecuado para encontrarla en la
instrucción actual. En el caso que se muestra arriba, el ensamblador reemplaza el uso
de addr_of_varen algo como esto:

6 ldr r0, [pc, #offset]

Lo que significa cargar el valor encontrado en el desplazamiento dado de la instrucción

actual . El ensamblador calcula el desplazamiento correcto aquí para que no tengamos que
hacerlo. Este es un enfoque válido porque addr_of_varse encuentra en la misma sección que
la instrucción. Esto significa que seguramente estará ubicado después de las
instrucciones. También sucede que está lo suficientemente cerca en la memoria. Este modo
de direccionamiento puede codificar cualquier desplazamiento de 12 bits (más un bit de
signo), por lo que cualquier cosa dentro de 4096 bytes (es decir, dentro de 1024
instrucciones) es direccionable de esta manera.

Pero la pregunta que queda es, ¿qué pone el ensamblador en esa ubicación designada
por addr_of_var? Hemos escrito .word varpero ¿qué significa esto? El ensamblador debería
emitir la dirección de var, pero en este punto se desconoce su dirección. Entonces, el
ensamblador solo puede emitir información parcial en este punto. Esta información se
completará más tarde.

Un ejemplo
Consideremos un ejemplo más complejo para ver este proceso en acción. Considere el
siguiente código que toma dos variables globales y las agrega a una variable de
resultado. Luego llamamos a una función, que escribiremos en otro archivo. Esta función
incrementará la variable de resultado en uno. La variable de resultado tiene que ser
accesible desde el otro archivo, por lo que tendremos que marcarla como global (similar a
lo que hacemos con main).
/* main.s */
.data

one_var : .word 42
another_var : .word 66

.globl result_var /* mark result_var as global */

result_var : .word 0

.text

.globl main
main:
ldr r0, addr_one_var /* r0 ← &one_var */
ldr r0, [r0] /* r0 ← *r0 */
ldr r1, addr_another_var /* r1 ← &another_var */
ldr r1, [r1] /* r1 ← *r1 */
add r0, r0, r1 /* r0 ← r0 + r1 */
ldr r1, addr_result /* r1 ← &result */
str r0, [r1] /* *r1 ← r0 */
bl inc_result /* call to inc_result */
mov r0, #0 /* r0 ← 0 */
bx lr /* return */

addr_one_var : .word one_var

addr_another_var : .word another_var
addr_result : .word result_var
Creemos un archivo de objeto. Recuerde que un archivo objeto es un archivo intermedio
que se utiliza antes de crear el programa final. Una vez creado, podemos utilizar objdump
-dpara ver el código contenido en este archivo objeto. (El uso de -march=armv6evita que se
emita información heredada que sería confusa por el bien de la exposición)
$ as -march=armv6 -o main.o main.s # creates object file main.o

Reubicaciones
Dijimos anteriormente que el ensamblador no conoce el valor final y en su lugar puede
poner alguna información parcial (por ejemplo, las compensaciones de .data). También
anota que se requiere alguna corrección aquí. Esta corrección se llama relocation. Podemos
leer las reubicaciones usando banderas -drde objdump.
$ objdump -dr main.o
main.o: file format elf32-littlearm
Disassembly of section .text:

00000000 <main>:
0: e59f0020 ldr r0, [pc, #32] ; 28 <addr_one_var>
4: e5900000 ldr r0, [r0]
8: e59f101c ldr r1, [pc, #28] ; 2c <addr_another_var>
c: e5911000 ldr r1, [r1]
10: e0800001 add r0, r0, r1
14: e59f1014 ldr r1, [pc, #20] ; 30 <addr_result>
18: e5810000 str r0, [r1]
1c: ebfffffe bl 0 <inc_result>
1c: R_ARM_CALL inc_result
20: e3a00000 mov r0, #0
24: e12fff1e bx lr

00000028 <addr_one_var>:
28: 00000000 .word 0x00000000
28: R_ARM_ABS32 .data

0000002c <addr_another_var>:
2c: 00000004 .word 0x00000004
2c: R_ARM_ABS32 .data

00000030 <addr_result>:
30: 00000000 .word 0x00000000
30: R_ARM_ABS32 result_var
Las reubicaciones se representan como la salida anterior como
OFFSET: TYPE VALUE
También se imprimen inmediatamente después del punto al que afectan.

OFFSETes el desplazamiento dentro de la sección para los bytes que necesitarán arreglarse
(en este caso todos ellos dentro .text). TYPEes el tipo de reubicación. El tipo de reubicación
determina qué bytes se arreglan y cómo. VALUEes una entidad simbólica para la que
tenemos que calcular la dirección física. Puede ser un símbolo real,
como inc_resulty result_var, o el nombre de una sección, como .data.

En la lista actual, hay una reubicación en, .text+1cpor lo que podemos llamar al

actual inc_result. Las otras dos reubicaciones en .text+28, .text+2cson las reubicaciones
necesarias para acceder .data. Estas reubicaciones podrían tener
como VALUEsímbolos one_vary, another_varrespectivamente, pero GNU parece preferir
representarlos como compensaciones en relación con la .datasección. Finalmente
se .text+30refiere al símbolo global result_var.

Cada tipo de reubicación se define en términos de unos pocos parámetros: Ses la dirección

del símbolo al que hace referencia la reubicación (lo VALUEanterior), Pes la dirección
del lugar (el OFFSETmás la dirección de la sección en sí), A(para los apéndices) es la valor
que el ensamblador ha dejado en su lugar. En nuestro ejemplo, R_ARM_ABS32es el valor
de .word, ya R_ARM_CALLque es un conjunto de bits en la blpropia instrucción. Usando estos
parámetros, la reubicación de búsqueda tiene una operación relacionada. Las reubicaciones
de tipo R_ARM_ABS32hacen una operación S + A. Las reubicaciones de
tipo R_ARM_CALLhacen una operación (S + A) – P.
Debido a Thumb, las reubicaciones de ARM tienen un parámetro adicional Tque tiene el valor 1si el
símbolo Ses una función Thumb, en 0caso contrario. Este no es el caso de nuestros ejemplos, por lo
que he omitido Ten la descripción de las reubicaciones anteriores.

Antes de que podamos ver el resultado calculado por el enlazador, definiremos, de

lo inc_resultcontrario, el enlace fallará. Esta función incrementará el valor de addr_result(cuyo
almacenamiento se define en el primer archivo main.s).
/* inc_result.s */
.text

.globl inc_result
inc_result:
ldr r1, addr_result /* r1 ← &result */
ldr r0, [r1] /* r0 ← *r1 */
add r0, r0, #1 /* r0 ← r0 + 1 */
str r0, [r1] /* *r1 ← r0 */
bx lr /* return */

addr_result : .word result_var

Revisemos también las reubicaciones.
$ as -march=armv6 -o inc_result.o inc_result.s
$ objdump -dr inc_result.o
inc_result.o: file format elf32-littlearm

Disassembly of section .text:

00000000 <inc_result>:
0: e59f100c ldr r1, [pc, #12] ; 14 <addr_result>
4: e5910000 ldr r0, [r1]
8: e2800001 add r0, r0, #1
c: e5810000 str r0, [r1]
10: e12fff1e bx lr

00000014 <addr_result>:
14: 00000000 .word 0x00000000
14: R_ARM_ABS32 result_var
Podemos ver que tiene una reubicación result_varcomo se esperaba.

Ahora podemos combinar los dos archivos de objeto para generar un binario ejecutable.
$ gcc -o [Link] print_float.o reloc.o
Y verifique el contenido del archivo. Nuestro programa incluirá algunas funciones de la
biblioteca C que podemos ignorar.
$ objdump -d [Link]
...
00008390 <main>:
8390: e59f0020 ldr r0, [pc, #32] ; 83b8 <addr_one_var>
8394: e5900000 ldr r0, [r0]
8398: e59f101c ldr r1, [pc, #28] ; 83bc <addr_another_var>
839c: e5911000 ldr r1, [r1]
83a0: e0800001 add r0, r0, r1
 83a4: e59f1014 ldr r1, [pc, #20] ; 83c0 <addr_result>
83a8: e5810000 str r0, [r1]
83ac: eb000004 bl 83c4 <inc_result>
83b0: e3a00000 mov r0, #0
83b4: e12fff1e bx lr

000083b8 <addr_one_var>:
83b8: 00010578 .word 0x00010578

000083bc <addr_another_var>:
83bc: 0001057c .word 0x0001057c

000083c0 <addr_result>:
83c0: 00010580 .word 0x00010580

000083c4 <inc_result>:
83c4: e59f100c ldr r1, [pc, #12] ; 83d8 <addr_result>
83c8: e5910000 ldr r0, [r1]
83cc: e2800001 add r0, r0, #1
83d0: e5810000 str r0, [r1]
83d4: e12fff1e bx lr

000083d8 <addr_result>:
83d8: 00010580 .word 0x00010580

...
De la salida anterior podemos observar que addr_one_varestá en
dirección 0x00010578, addr_another_varestá en dirección 0x0001057cy addr_resultestá en
dirección 0x00010580. El último aparece repetido, pero esto se debe a que ambos
archivos [Link] se inc_result.srefieren a él, por lo que deben guardar la dirección en algún
lugar. Tenga en cuenta que en ambos casos contiene la misma dirección.

Vamos a empezar con las reubicaciones de addr_one_var, addr_another_vary addr_result. Estas

tres reubicaciones fueron R_ARM_ABS32así su funcionamiento S + A. Ses la dirección de la
sección .datacuya dirección se puede determinar también con objdump -h(el indicador más -
wpara que sea un poco más legible). Un archivo puede contener muchas secciones, por lo
que omitiré las que no sean interesantes.
$ objdump -hw [Link]
[Link]: file format elf32-littlearm

Sections:
Idx Name Size VMA LMA File off Algn Flags
...
13 .text 0000015c 000082e4 000082e4 000002e4 2**2 CONTENTS, ALLOC, LOAD,
READONLY, CODE
...
23 .data 00000014 00010570 00010570 00000570 2**2 CONTENTS, ALLOC, LOAD, DATA
...
La columna VMAdefine la dirección de la sección. En nuestro caso .datase encuentra
en 00010570. Y nuestras variables se encuentran en 0x00010578, 0x0001057c y 0x00010580. Se
trata de compensaciones 8, 12 y 16 respectivamente desde el principio de .data. El enlazador
ha colocado algunas otras variables en esta sección antes que la nuestra. Podemos ver esto
pidiendo al enlazador que imprima un mapa del ejecutable generado.
$ gcc -o [Link] main.o inc_result.o -Wl,--print-map > [Link]
$ cat [Link]
[Link] 0x00010570 0x14
315 0x00010570 PROVIDE (__data_start, .)
316 *(.data .data.* .[Link].d.*)
317 .data 0x00010570 0x4 /usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/crt1.o
318 0x00010570 data_start
319 0x00010570 __data_start
320 .data 0x00010574 0x0 /usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/crti.o
321 .data 0x00010574 0x4 /usr/lib/gcc/arm-linux-gnueabihf/4.6/crtbegin.o
322 0x00010574 __dso_handle
323 .data 0x00010578 0xc main.o
324 0x00010580 result_var
325 .data 0x00010584 0x0 inc_result.o
326 .data 0x00010584 0x0 /usr/lib/arm-linux-gnueabihf/libc_nonshared.a([Link])
327 .data 0x00010584 0x0 /usr/lib/gcc/arm-linux-gnueabihf/4.6/crtend.o
328 .data 0x00010584 0x0 /usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/cr

Si marca las líneas 317 a 322, verá que la .datasección final (que efectivamente

comienza 0x00010570como verificamos arriba) de nuestro programa incluye 4 bytes
de [Link] los símbolos data_start(y su alias __data_start). El archivo [Link]én ha
aportado un símbolo __dso_handle. Estos símbolos globales provienen de la biblioteca
C. result_varAquí solo aparece el símbolo porque es un símbolo global, todas las demás
variables globales no son símbolos globales. El almacenamiento, sin embargo, se
contabiliza para todos ellos en la línea 323. Toman 0xc bytes (es decir, 12 bytes debido a 3
variables cada una de 4 bytes).

Entonces, con esta información podemos inferir lo que sucedió: la variable one_varestá en la

dirección 0x00010570, la variable another_varestá en 0x00010574 y la variable result_var
está en 0x00010578. Si comprueba el resultado de objdump -d [Link] arriba, verá que
000083b8 <addr_one_var>:
83b8: 00010578 .word 0x00010578

000083bc <addr_another_var>:
83bc: 0001057c .word 0x0001057c

000083c0 <addr_result>:
83c0: 00010580 .word 0x00010580
...
000083d8 <addr_result>:
83d8: 00010580 .word 0x00010580
¿Y la llamada a inc_result?
83ac: eb000004 bl 83c4
Este es un poco más complicado. Recuerde que la operación de reubicación es (S + A) -
P. Aquí Aestá 0y Pestá 0x000083ac, S es 0x000083c4. Por lo tanto, la reubicación tiene que
definir un desplazamiento de 24 bytes (83c4 - 83ac es 24 (10 ). La instrucción blcodifica el
desplazamiento desplazándolo 2 bits a la derecha. Por lo tanto, el desplazamiento actual
codificado eb000004es 16. Recuerde que la corriente pcapunta al instrucción actual más 8
bytes, por lo que esta instrucción nos dice exactamente que saltemos a un desplazamiento +
24 bytes, exactamente lo que queríamos.
...
83ac: eb000004 bl 83c4 <inc_result>
83b0: e3a00000 mov r0, #0
83b4: e12fff1e bx lr

000083b8 <addr_one_var>:
83b8: 00010578 .word 0x00010578

000083bc <addr_another_var>:
83bc: 0001057c .word 0x0001057c

000083c0 <addr_result>:
83c0: 00010580 .word 0x00010580

000083c4 <inc_result>:
83c4: e59f100c ldr r1, [pc, #12] ; 83d8 <addr_result>

...

Más información
Los enlazadores son un poco arcanos porque deben manejar las partes de código de nivel
más bajo. Por eso, a veces es difícil encontrar buenos recursos sobre ellos.

Ian Lance Taylor, autor de gold, hizo un ensayo de enlace muy agradable en 20

capítulos . Si quieres un libro, Linkers & Loaders no es malo. El estándar ELF en realidad
se define en dos partes, una genérica y una específica del procesador, incluida una para
ARM .

Ensamblador ARM en Raspberry Pi

- Capítulo 27
17 de abril de 2017• Roger Ferrer Ibáñez • Raspberry Pi

Vimos en el capítulo anterior cuál es el proceso necesario para construir un programa a

partir de diferentes unidades de compilación. Este proceso sucedió antes de que
obtuviéramos el programa final. La pregunta es, ¿puede suceder este proceso cuando se
ejecuta el programa? Es decir, ¿es posible vincular dinámicamente un programa?
Objetos y bibliotecas
En el capítulo 26 vimos el proceso de vinculación, que básicamente combina varios objetos
para formar el binario final. Si todos los objetos que usamos pertenecieran a nuestro
programa, eso sería suficiente. Pero, por lo general, los programas se basan en piezas
reutilizables que utilizan muchos programas. Estos componentes reutilizables suelen
reunirse en lo que se denomina biblioteca.

En la tradición de UNIX, estas bibliotecas se han materializado en lo que se llama

un archivo . Un archivo es, en esencia, una colección de archivos objeto juntos. Al vincular
un programa, especificamos el archivo en lugar del objeto. El enlazador sabe cómo manejar
estos archivos y es capaz de determinar qué objetos de él utiliza el programa. Entonces se
comporta como si solo se hubieran especificado los objetos requeridos.

La biblioteca C es un ejemplo de esto. En ejemplos anteriores hemos

llamado printf, putso random. Estas funciones se definen en la biblioteca C. Al usar el
controlador gcc, internamente llama al vinculador y pasa la biblioteca de tiempo de
ejecución de C, comúnmente conocida como libc. En Linux, la biblioteca C más habitual es
la biblioteca C de GNU . Existen otras bibliotecas de C que tienen propósitos más
específicos: newlib , uClibc , musl , etc.

Los archivos se conocen comúnmente como bibliotecas estáticas porque son solo una

forma conveniente de especificar muchos objetos al mismo tiempo. Pero más allá de eso,
no cambian el hecho de que el programa final está completamente determinado en el
momento del enlace. El enlazador todavía tiene todas las piezas necesarias para construir el
programa final.

Vinculación dinámica
¿Qué pasa si en lugar de construir todo el programa en el momento del enlace, simplemente
ensamblamos las partes mínimas para poder completarlo al ejecutar el programa? ¿Y si en
lugar de bibliotecas estáticas utilizáramos bibliotecas dinámicas ? Por lo tanto, el programa
se vincularía dinámicamente a ellos al ejecutarse.

Al principio, esto parece un poco extravagante, pero tiene algunas ventajas. Al retrasar el
proceso de enlace, obtenemos algunas ventajas. Por ejemplo, un programa que
utilice printfno necesitaría tener el printfarchivo en el programa. Podría usar una biblioteca C
dinámica existente del sistema, que también tendrá su copia de printf. Además, si se
encuentra un error en el printfde esa biblioteca dinámica, solo reemplazar la biblioteca
dinámica sería suficiente y nuestro programa se beneficiaría automáticamente de un
archivo printf. Si lo hubiéramos vinculado estáticamente printf, nos veríamos obligados a
volver a vincularlo para obtener el correcto printf.

Por supuesto, muy pocas cosas son gratuitas en la naturaleza, y los enlaces dinámicos y las
bibliotecas dinámicas requieren más esfuerzo. Necesitamos hablar sobre la carga.
Cargando un programa
Antes de que podamos ejecutar un programa, debemos guardarlo en la memoria. Este
proceso se llama carga . Por lo general, el sistema operativo es responsable de cargar los
programas.

Si recuerda el capítulo anterior, teníamos un ejemplo en el que definimos dos

variables, another_vary result_var, y una función inc_result. También vimos que después de que
ocurre el enlace, las direcciones estaban codificadas en el archivo final del programa. Una
tarea de cargador en este caso es bastante sencilla, simplemente copie los bits relevantes de
nuestro archivo de programa en la memoria. El enlazador ya ha arreglado las direcciones ,
así que mientras copiemos (es decir, carguemos) el programa en la dirección de memoria
correcta, hemos terminado.

Los sistemas operativos modernos, como Linux, proporcionan a los procesos (es decir,
programas en ejecución) lo que se denomina memoria virtual gracias al soporte de
hardware específico para ello. La memoria virtual da la ilusión de que un proceso puede
usar el espacio de la memoria como quiera. Este mecanismo también proporciona
aislamiento: un proceso no puede escribir en la memoria de otro proceso. Ejecutar varios
programas que quieren cargarse en la misma dirección no es un problema porque
simplemente se cargan en la misma dirección virtual. El sistema operativo asigna estas
direcciones virtuales a diferentes direcciones físicas.

En sistemas sin memoria virtual, todas las direcciones son físicas. Esto hace imposible
cargar más de un proceso si alguno de ellos se superpone en la memoria con otro.
Para usar bibliotecas dinámicas, dado que el proceso de vinculación ocurre en tiempo de
ejecución, necesitamos un segundo programa, llamado vinculador dinámico . Esto contrasta
con el enlazador de programas o el enlazador estático . Este enlazador dinámico también
actuará como cargador dinámico porque será responsable de cargar las bibliotecas
dinámicas necesarias en la memoria.

A esta herramienta la llamamos enlazador dinámico porque una vez que haya cargado el
código y los datos de la biblioteca dinámica en la memoria tendrá que resolver algunas
reubicaciones. La cantidad de reubicaciones que debe realizar depende de si el código
es independiente de la posición o no.
Posición de código independiente
El código puede depender de la posición o ser independiente de la posición.

El código dependiente de la posición asume que puede usar direcciones absolutas

directamente. Esto significa que, si podemos cargar el programa en la dirección que espera,
no es necesario hacer nada más, lo cual es genial. La desventaja es, por supuesto, que no
podemos. En este caso, necesitamos fijar todas las direcciones absolutas a las nuevas
direcciones. Esto significa que cargamos el programa en alguna dirección (no la que espera)
y luego arreglamos todas las direcciones absolutas en las nuevas ubicaciones. Para que este
proceso sea sensiblemente eficiente, será necesario utilizar aquí reubicaciones. Estas
reubicaciones ocurren en el código del programa. Esto significa que cada proceso tiene una
versión ligeramente diferente del código original en la memoria. En la práctica, esta idea es
esencialmente la misma que la vinculación estática, pero solo retrasa en qué paso ocurre la
vinculación.

El código independiente de posición (conocido como PIC) no usa direcciones absolutas. En

su lugar, se utiliza algún mecanismo en el que el programa construye direcciones
relativas. En tiempo de ejecución, estas direcciones relativas se pueden convertir, mediante
algún cálculo adicional, en direcciones absolutas. El mecanismo utilizado en ELF utiliza
una tabla llamada Tabla de compensación global. Esta tabla contiene entradas, una entrada
por entidad global a la que queremos acceder. Cada entrada, en tiempo de ejecución,
contendrá la dirección absoluta del objeto. Cada programa y biblioteca dinámica tiene su
propio GOT, que no se comparte con nadie más. Este GOT está ubicado en la memoria de
manera que es posible acceder a él sin usar una dirección absoluta. Para hacer esto, se debe
usar una dirección relativa a la computadora. Entonces, el GOT se ubica en una posición
fija cuya distancia a él, de la instrucción que lo refiere,

Una ventaja de esta técnica es que no hay que realizar reubicaciones en el código en el
momento de la carga. Solo el GOT debe reubicarse correctamente al cargar dinámicamente
el código. Esto puede reducir enormemente el tiempo de carga. Dado que el código en la
memoria no tiene que arreglarse, todos los procesos que usan las mismas bibliotecas
pueden compartirlo. Esto se hace en sistemas operativos que admiten memoria virtual: las
partes del código de las bibliotecas dinámicas se comparten entre procesos. Esto significa
que, aunque el código todavía ocupará espacio en el espacio de direcciones de la memoria
virtual del proceso, no utilizará la memoria física adicional del sistema. La desventaja es
que debido al GOT, el acceso a direcciones globales (variables y funciones globales) es
mucho más complejo.

Accediendo a una variable global

Como ejemplo de cuánto más complejo es acceder a una variable global, comencemos con
un ejemplo simple. Para este ejemplo asumiremos que nuestro programa solo incrementa
una variable global. La variable global la proporciona una biblioteca. (Sé que este es un
escenario horrible, pero esto es solo por el bien de esta exposición)
Biblioteca estática
Nuestra biblioteca estática será muy sencilla. Tendremos un [Link] que solo
contendrá myvar.
/* mylib.s */
.data

.balign 4
.globl myvar
myvar : .word 42 /* 42 as initial value */
.size myvar, .-myvar
La .sizedirectiva será necesaria para el caso de la biblioteca dinámica. Indica el tamaño de
un símbolo, en este caso myvar. Podríamos haber codificado el valor (4) pero aquí estamos
haciendo que el ensamblador lo calcule por nosotros. La expresión resta la dirección actual
(indicada por un punto .) con la dirección de myvar. Debido a la .worddirectiva intermedia,
estas dos direcciones están separadas por 4 bytes.

Nuestro programa será solo un [Link] que accede a la variable y la incrementa. Nada

interesante, solo para mostrar que esto no es diferente a lo que hemos estado haciendo.
/* main.s */
.data
.globl myvar

.text
.globl main

.balign 4
main:
ldr r0, addr_myvar /* r0 ← &myvar */
ldr r1, [r0] /* r1 ← *r0 */
add r1, r1, #1 /* r1 ← r1 + 1 */
str r1, [r0] /* *r0 ← r1 */

mov r0, #0 /* end as usual */

bx lr

addr_myvar: .word myvar

Podemos construir y vincular la biblioteca y el programa como de costumbre.
# (static) library
as -o mylib.o mylib.s
ar cru mylib.a mylib.o
# program
as -o main.o main.s
gcc -o main main.o -L. -l:mylib.a
ar, el archivador, es la herramientaque crea una biblioteca estática, un .aarchivo, a partir de
un conjunto de archivos objeto (solo uno en este ejemplo). Luego vinculamos la
especificación principal final mylibcomo una biblioteca (los dos puntos en la -lbandera son
obligatorios porque el nombre del archivo de la biblioteca no comienza con
el libprefijo habitual ).
En realidad, nada especial hasta ahora.

Biblioteca dinámica
Para generar una biblioteca dinámica, necesitamos decirle al enlazador que no queremos un
programa sino una biblioteca dinámica. En ELF, las bibliotecas dinámicas se denominan
objetos compartidos y, por lo tanto, su extensión .so. Para este propósito usaremos gcc, que
proporciona un indicador útil -sharedque se encarga de todos los indicadores que ld
necesitará para crear una biblioteca dinámica.
# dynamic library
as -o mylib.o mylib.s
gcc -shared -o [Link] mylib.o
Ahora queremos acceder desde nuestro programa a la variable myvarutilizando un acceso
independiente de la posición.

En realidad, el código independiente de la posición solo se requiere para bibliotecas

dinámicas. Nuestro programa principal aún podría usar accesos que no sean PIC y
funcionaría para variables en bibliotecas, el enlazador se encargaría de este caso. Pero nada
nos impide utilizar el código PIC en el programa principal. Un ejecutable independiente de
la posición (PIE) necesita realizar todos los accesos a través de GOT.

Recuerde, no podemos usar un mecanismo que fuerce la reubicación del código (es decir,
que se arreglen sus direcciones). Solo se puede arreglar el GOT (después de todo, no es un
código). La dirección de myvarestará en alguna entrada en el GOT. No sabemos cuál,
exactamente, esto es una preocupación del enlazador. Sin embargo, todavía necesitamos
obtener la dirección base del GOT primero.

Vimos anteriormente, que un acceso PIC será pcrelativo. Dado que el programa y la

biblioteca se cargarán como una sola pieza en la memoria, podemos pedirle al enlazador
estático que ponga el desplazamiento exacto al GOT por nosotros. Podemos hacer esto
simplemente haciendo
...
.word _GLOBAL_OFFSET_TABLE_
...
Desafortunadamente, esto será un desplazamiento relativo de la posición actual en el
código. Idealmente querríamos escribir esto
add r0, pc, .word _GLOBAL_OFFSET_TABLE_ /* r0 ← pc + "offset-to-GOT" */
No es posible codificar una instrucción como esta en los 32 bits de una instrucción
ARM. Por lo tanto, tendremos que utilizar el enfoque típico.
ldr r0, offset_of_GOT /* r0 ← "offset-to-GOT" */
add r0, pc, r0 /* r0 ← pc + r0 */
...
offset_of_GOT: .word _GLOBAL_OFFSET_TABLE_
Pero ese "offset-to-got" debe ser el offset al GOT en el punto donde realmente estamos
agregando pc, esto es, en la segunda instrucción. Esto significa que necesitamos pedirle al
enlazador que lo ajuste para que el desplazamiento tenga sentido para la instrucción que
agrega ese desplazamiento a la PC. Podemos hacer esto usando una etiqueta adicional.
ldr r0, offset_of_GOT /* r0 ← "offset-to-GOT" */
got_address: add r0, pc, r0 /* r0 ← pc + r0 */
...
offset_of_GOT: .word _GLOBAL_OFFSET_TABLE_ - got_address
Tenga en cuenta que el valor de got_addressen esa resta no es la dirección de la
instrucción add r0, pc, r0. En cambio, es el desplazamiento en bytes desde esa dirección (esto
es offset_of_GOT) a la dirección de la etiqueta got_address.

Una peculiaridad de ARM es que leer el pcen una instrucción, nos da el valor
del pcdesplazamiento de 8 bytes. Entonces, es posible que tengamos que restar 8 a
lo r0anterior o simplemente asegurarnos de que la reubicación ya lo esté haciendo por
nosotros. El segundo enfoque es realmente mejor porque evita una instrucción.
ldr r0, offset_of_GOT /* r0 ← "offset-to-GOT" */
got_address: add r0, pc, r0 /* r0 ← pc + r0 */
...
offset_of_GOT: .word _GLOBAL_OFFSET_TABLE_ - (got_address + 8)
Y ahora r0tenemos la dirección absoluta del GOT. Pero queremos acceder myvar. Podemos
pedirle al enlazador estático que indique el uso del desplazamiento (en bytes) en el GOT
para un símbolo usando la sintaxis siguiente.
.word myvar(GOT)
Ahora tenemos todos los ingredientes necesarios para acceder myvarde forma independiente
al puesto.
 1/* main.s */
[Link]
3
[Link]
[Link] main
6
[Link] 4
8
9main:
10 ldr r0, offset_of_GOT /* r0 ← offset-to-GOT
11 (respect to got_address)*/
12 got_address: add r0, pc, r0 /* r0 ← pc + r0
13 this is
14 r0 ← &GOT */
15 ldr r1, myvar_in_GOT /* r1 ← offset-of-myvar-inside-GOT */
16 add r0, r0, r1 /* r0 ← r0 + r1
17 this is
18 r0 ← &GOT + offset-of-myvar-inside-GOT */
19 ldr r0, [r0] /* r0 ← *r0
 20 this is
21 r0 ← &myvar
22 */
23 ldr r1, [r0] /* r0 ← *r1 */
24 add r1, r1, #1 /* r1 ← r1 + 1 */
25 str r1, [r0] /* *r0 ← r1 */
26
27 mov r0, #0 /* end as usual */
28 bx lr
29
30offset_of_GOT: .word _GLOBAL_OFFSET_TABLE_ - (got_address + 8)
31myvar_in_GOT : .word myvar(GOT)

Podemos reemplazar la add(línea 16) y la ldr(línea 19) con un acceso a la memoria más
elaborado.

16 ldr r0, [r0, r1] /* r0 ← *(r0 + r1)

17 this is
18 r0 ← *(&GOT + offset-of-my-var-inside-GOT) */

Ahora podemos construir el programa.

# program
as -o main.o main.s
gcc -o main main.o -L. -l:[Link] -Wl,-rpath,$(pwd)
La -Wl,-rpath,$(pwd)opción le dice al enlazadordinámico que use el directorio actual $(pwd),
para encontrar la biblioteca. Esto se debe a que si no hacemos esto, no podremos ejecutar el
programa ya que el cargador dinámico no podrá encontrarlo.

Llamar a una función

Llamar a una función desde una biblioteca dinámica es un poco más complicado que
simplemente acceder a ella en el GOT. Debido a una característica de ELF
denominada unión diferida , las funciones pueden cargarse de forma diferida. El motivo es
que una biblioteca puede proporcionar muchas funciones, pero es posible que solo se
necesiten unas pocas en tiempo de ejecución. Cuando se utilizan enlaces estáticos, esto rara
vez es un problema porque el enlazador utilizará solo los archivos objeto que definen los
símbolos potencialmente utilizados por el programa. Pero no podemos hacer esto para una
biblioteca dinámica porque debe manejarse como un todo.

Thus, under lazy loading, the first time that we call a function it has to be loaded. Further
calls will use the previously loaded function. This is efficient but requires a bit more of
machinery. In ELF this is achieved by using an extra table called the Procedure Linkage
Table (PLT). There is an entry for each, potentially, used function by the program. These
entries are also replicated in the GOT. In contrast to the GOT, the PLT is code and we do
not want to modify it. Entries in the PLT are small sequences of instructions that just
branch to the entry in the GOT. The GOT entries for functions are initialized by the
dynamic linker with the address to an internal function of the dynamic linker which
retrieves the address of the function, updates the GOT with that address and branches to it.
Because the dynamic linker updated the GOT table, the next call through the PLT (that
recall simply branches to the GOT) will directly go to the function.

Uno puede preguntarse por qué no llamar directamente a la dirección en el GOT o por qué
utilizar un PLT. La razón es que el enlazador dinámico debe saber qué función queremos
cargar la primera vez, si llamamos directamente a la dirección en el GOT necesitamos idear
un mecanismo para poder decir qué función se debe cargar. Una forma podría ser inicializar
las entradas GOT para funciones en una tabla que prepara todo para que el cargador
dinámico sepa la función exacta que debe cargarse. ¡Pero esto es en la práctica equivalente
al PLT!

Todo en este punto parece demasiado complicado, pero la buena noticia es que es el
enlazador quien crea estas entradas PLT y se pueden usar como llamadas de función
regulares. No es necesario obtener la dirección de la entrada GOT y todo lo que tuvimos
que hacer para una variable (¡todavía tenemos que hacer esto si usaremos la dirección de la
función!). Siempre podríamos hacer eso, pero esto inflaría el código ya que cada llamada de
función requeriría una indexación compleja en la tabla GOT. Este mecanismo funciona
tanto para PIC como para no PIC, y es la razón por la que hemos podido llamar a las
funciones de la biblioteca C printfsin tener que preocuparnos si provienen de una biblioteca
dinámica (y lo hacen a menos que usemos -staticpara generar un ejecutable completamente
estático ) o no. Dicho esto, podemos usar explícitamente el sufijo@PLTpara indicar que
queremos llamar a una función a través del PLT. Esto es obligatorio para las llamadas
realizadas dentro de una biblioteca.

Ejemplo completo
Extendamos ahora nuestra biblioteca con una función que imprima el valor de myvar. Dado
que es código en la biblioteca debe ser código PIC: accesos a variables a través del GOT y
llamadas a funciones vía PLT. Nuestra función se llama myfun. Es bastante similar a lo que
hicimos en el main, excepto por el incremento.
/* mylib.s */
.data

.balign 4
.globl myvar
myvar : .word 42 /* global variable "myvar" */
.size myvar, .-myvar

message: .asciz "Value of 'myvar' is %d\n"

.text

.balign 4
.globl myfun
myfun:
push {r4, lr} /* we are going to do a
call so keep lr, and also r4
for a 8-byte aligned stack */
ldr r0, offset_of_GOT /* r0 ← offset-to-GOT
(respect to got_address)*/
got_address: add r0, pc, r0 /* r0 ← pc + r0
this is
r0 ← &GOT */
ldr r1, myvar_in_GOT /* r1 ← offset-of-myvar-inside-GOT */
ldr r0, [r0, r1] /* r0 ← *(r0 + r1)
this is
r0 ← *(&GOT + offset-of-myvar-inside-GOT) */
ldr r1, [r0] /* r0 ← *r1 */

ldr r0, addr_of_message /* r0 ← &message */

/* r1 already contains the value we want */
bl printf@PLT /* call to printf via the PLT */

pop {r4, lr} /* restore registers */

bx lr
offset_of_GOT: .word _GLOBAL_OFFSET_TABLE_ - (got_address + 8)
myvar_in_GOT : .word myvar(GOT)
addr_of_message: .word message
Ahora cambiemos el programa principal para que primero llame myfun,
incremente myvary myfunvuelva a llamar .
/* main.s */
.data

.text
.globl main

.balign 4

main:
push {r4, lr} /* we are going to do a
call so keep lr, and also r4
for a 8-byte aligned stack */
bl myfun@PLT /* call function in library */

ldr r0, offset_of_GOT /* r0 ← offset-to-GOT

(respect to got_address)*/
got_address: add r0, pc, r0 /* r0 ← pc + r0
this is
r0 ← &GOT */
ldr r1, myvar_in_GOT /* r1 ← offset-of-myvar-inside-GOT */
ldr r0, [r0, r1] /* r0 ← *(r0 + r1)
this is
r0 ← *(&GOT + offset-of-myvar-inside-GOT) */
ldr r1, [r0] /* r0 ← *r1 */
add r1, r1, #1 /* r1 ← r1 + 1 */
str r1, [r0] /* *r0 ← r1 */
 bl myfun@PLT /* call function in library a second time */

pop {r4, lr} /* restore registers */

mov r0, #0 /* end as usual */
bx lr

offset_of_GOT: .word _GLOBAL_OFFSET_TABLE_ - (got_address + 8)

myvar_in_GOT : .word myvar(GOT)
Vamos a construirlo.
# Dynamic library
as -o mylib.o mylib.s
gcc -shared -o [Link] mylib.o
# Program
as -o main.o main.s
gcc -o main main.o -L. -l:[Link] -Wl,-rpath,$(pwd)
Podemos comprobar si está utilizando nuestra biblioteca.
$ ldd main
/usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (0xb6f3b000)
[Link] => $(pwd)/[Link] (0xb6f32000)
[Link].6 => /lib/arm-linux-gnueabihf/[Link].6 (0xb6df0000)
/lib/[Link].3 (0x7f5cb000)
Y ejecútelo.
$ ./main
Value of 'myvar' is 42
Value of 'myvar' is 43
¡Hurra! :)