Cuando en gcc hay direcciones de 16 bits, y de repente la memoria es de 256k

... o cómo dispararte en el pie con un Arduino

En la escuela de informática de verano, utilizamos una computadora antigua hecha por nosotros mismos para enseñar el desarrollo de juegos.

Ahora tiene una placa Arduino Mega con un procesador ATmega2560, en el que hay hasta 256 kilobytes de memoria flash. Se suponía que esto duraría mucho tiempo, porque los juegos son simples (la pantalla es de solo 64x64 píxeles). En realidad, encontramos algunos problemas cuando el firmware alcanzó aproximadamente 128 kilobytes.

En la memoria del programa, a pesar de su nombre, además del código ejecutable del juego, se almacenan todo tipo de datos sin cambios, como sprites y tablas de niveles. Estos datos no son tanto.

Pero cuando conectamos el chip de sonido YM2149F a nuestra computadora y descargamos un par de docenas de melodías en la misma memoria de programa, comenzaron los problemas.


El prefijo se bloqueó al intentar tocar una melodía o dibujó algo de basura en el menú del juego. No estaba claro cómo depurar esto en absoluto, porque el procesador no solo se ocupa de la lógica del juego, sino que también muestra la imagen y el sonido. Como resultado, resultó que el compilador gcc-avr usa variables de dos bytes de tamaño para almacenar punteros. ¡Pero abordar 256 kilobytes con solo dos bytes es imposible! ¿Cómo sale él?

Punteros de código

Primero, las instrucciones de llamada a funciones y los saltos pueden usar direcciones de tres bytes. Por lo tanto, es suficiente que el vinculador sustituya la dirección completa en dicha instrucción y funcionará. Si la dirección de la función se pasa a través de un puntero, ese número no pasará, porque tenemos un puntero de doble byte.

En esta situación, gcc inserta un "trampolín" en los 64 kb inferiores, la instrucción jmp, que cambia a la función deseada. Entonces, la dirección de este trampolín actuará como la dirección de la función que debe almacenarse en la variable; después de todo, se coloca en dos bytes. Y cuando se llame, habrá una transición donde sea necesario.

Punteros de datos

Pero almacenamos en la memoria del programa no solo el código ejecutable. Por lo tanto, los saltos no ayudarán aquí: estamos desreferenciando los punteros, pero no vamos a ellos.

La biblioteca AVR incluso tiene funciones / macros como pgm_read_byte_far (addr) para desreferenciar el puntero completo (se pasan valores de cuatro bytes). Pero gcc no sabe cómo obtener estos punteros utilizando el lenguaje C.

Afortunadamente, hay una macro pgm_get_far_address (var) para obtener la dirección completa de una variable. Esto se hace utilizando el ensamblador incorporado (el caso cuando el ensamblador es más inteligente que el compilador).

Queda por reescribir todo el código que usa los datos en la ROM. Es decir, un reproductor de música, sprites de renderizado, salida de texto, ... No es una experiencia muy agradable. Sí, y el código se volverá más inhibitorio, y para los gráficos es muy crítico. Por lo tanto,

Distribuimos datos en ROM

Linker está intentando poner datos para la memoria del programa en los 64k inferiores. Esto no funciona si hay demasiados datos. Pero los datos más importantes que tenemos son los archivos de música. Por lo tanto, si solo los elimina, todo lo demás quedará en la memoria inferior y no tendrá que rehacer la parte principal del código.

Para hacer esto, explotaremos las características del script enlazador. Una de las últimas secciones que el enlazador coloca en la ROM se llama .fini7. Guarde todos los arreglos de música en esta sección:

#define MUSICMEM __attribute__((section(".fini7"))) const uint8_t tetris2[] MUSICMEM = { ... }; 

Ahora avr-nm nos dice que todo está en orden: los datos con sprites y niveles resultaron estar en la parte inferior de la ROM, y la música en la parte superior.

 00002f9c t _ZL10level_menu 00002e0f t _ZL10rope_lines 000006de t _ZL10ShipSprite 00023a09 t tetris2 00024714 T the_last_v8 

Queda por rehacer el reproductor para usar punteros de cuatro bytes y en lugar de usar un puntero a una matriz con el código de melodía, use la función para obtener su dirección. Las funciones son necesarias porque tenemos una aplicación de reproductor donde puedes escuchar todas las melodías que elijas. Ahora almacena punteros para funciones de este tipo:

 00006992 <_Z12tetris2_addrv>: 6992: 61 ef ldi r22, 0xF1 ; 241 6994: 7a e3 ldi r23, 0x3A ; 58 6996: 82 e0 ldi r24, 0x02 ; 2 6998: 99 27 eor r25, r25 699a: 08 95 ret 

El fin del mundo se retrasa hasta que los sprites tocan el fondo 64k. Esto es poco probable, porque todavía hay más código que sprites, lo que significa que la memoria probablemente terminará en general.

Bono

Este verano escribimos un juego al estilo de Sokoban. Algunos niveles resultaron ser bastante difíciles. Intenta, por ejemplo, pasar este:

Referencias

1. Página del proyecto Github
2. Arduino y pantalla LED
3. Arduino y la piedra musical del filósofo
4. Juegos del año pasado