Porting de GCC a PIC16

En esta versión se han revisado las insn a nivel de sintaxis, y se ha incluido la posibilidad de paso de parámetros a las funciones. En un plazo de dos o tres semanas iré revisando todas las insn a nivel de código, es decir que el código ensamblador generado haga realmente lo que tiene que hacer. Si alguien se anima…

Lanzada nueva versión en la que el modo QI se completa a falta de la multiplicación y división. La linea de trabajo fundamental es acabar de crear las insn o patrones de instrucción del modo QI y pasar a realizar el modo HI y SI. En breve también un mini manual para compilar GCC con la arquitectura PIC para aquellos que quieran ver los avances.

Publico una nueva versión en la que podremos ver la mentalidad número 3 mentada en la publicación anterior. Por lo tanto, tenemos ahora 32 registros más el W que permiten un funcionamiento completo de la compilación. Se pueden realizar copias, sumas y restas en variables de 1 byte.

Hay tres niveles de especificación de modo de operando cuya diferencia es el tamaño de palabra. El modo QI es de 1 byte y corresponde a variables de tipo char o short. El modo HI de 2 bytes y corresponde a enteros y el modo SI de 4 bytes y usado para long. No tiene sentido (aunque se podría) aumentar los modos de operación dado que en un PIC usar más de 4 bytes para un dato es realmente improbable. Por lo tanto solo se usarán estos tres modos en la definición de la arquitectura, pero de usarse modos mayores, no hay problema dado que si GCC no encuentra una operación en la especificación de la máquina para un tipo mayor, usará una librería (conocida como libgcc) para crear las operaciones necesarias a partir de las existentes.

Por ahora el desarrollo será dirigido al modo QI de 1 byte. La extensión a otros modos se realizará en posteriores fases de desarrollo a partir de lo hecho para el modo QI. Además en lo que respecta al uso de W como registro, por el momento solo le veo problemas, por lo que cuando lo valore a fondo será usado o excluido definitivamente.

Hasta pronto.

Por problemas de salud no he hecho todo lo que quería, pero por lo menos me ahorro el pinchazo de la vacuna de la gripe .

Bien, subido un nuevo parche que esta vez consigue crear el CC1 que compila código. No se cuelga sino que informa de lo que le falta para seguir compilando. Con esto, basta con rellenar lo que pide para seguir adelante. Llegados a este punto ahora si tenemos que fijar una idea del objetivo del porting a crear. Pese a que quería documentar más a fondo las ideas existentes, las resumo aquí y dejo la promesa de explicar la definitiva más adelante.

El motivo de tener varias ideas es GCC. Este tiene sus más y sus menos en las arquitecturas y en principio esta orientado a modelos de memoria más grandes que un microcontrolador. En un PIC como el 16F877 tenemos 352 posiciones de RAM. En ellas tienes que entrar la pila y el espacio de memoria local de cada función entre otros parámetros. Esto sumado a que el espacio no es continuo sino dividido en 4 bancos hace la gestión de memoria complicada. Además tenemos un solo registro, el W, pero toda la memoria puede accederse de manera directa, por lo que se podría pensar que tenemos 352 registros más uno. Todo esto lleva a tres modelos de memoria – registros cuya elección final lo dará el código generado por GCC. Obviamente será el más eficiente.

Los tres modos de memoria son:

1) Un solo registro, el W y todo lo demás es memoria. Pros: el código es más fácil y GCC traduce las instrucciones a un solo nemotécnico por instrucción. Contras: GCC trabaja con infinitos registros, optimiza, y después establece estos registros en registros reales, pasando los que no puede recargar a la pila o memoria. Con un solo registro no se como funcionará esto, ya que la mayoría serán pasados a memoria o pila y por omisión parece que GCC siempre elije registros a memoria, por lo que se formaría el circulo vicioso.

2) Todo son registros, menos lo mínimamente necesario para que GCC tenga memoria. Pros: se acerca a la idea de GCC de muchos registros. Contras: GCC quiere memoria, según que programa compile se pedirá más o menos. Ajustar esto en tiempo de compilación es complicado desde ya, imaginaos cuando lo hagamos. Según la documentación de GCC, éste usará un espacio de memoria al que llama “frame” (marco), con un puntero que será (o puede ser) reasignado en cada llamada para ajustarse a necesidades. Esto lleva a no poder usar toda la memoria como registros y con ello a la idea 3.

3) Habrá x registros, y el resto es memoria a usar. Pros: Con esto llegamos a una solución de compromiso entre 1 y 2. Contras: pues suponiendo que usemos un banco para pila, y otro para registros, quedan dos bancos para memoria. Esto lleva a moverse entre dos bancos, lo que no es ni eficiente, ni fácil.

Pues de estas ideas primero escogí la número 1, para definir la estructura del porting, pero cada vez más veo más negro su futuro. De escoger la siguiente idea cogería la 3, pero comenzaría con un solo banco para memoria de frame y dejaría los otros para registros y pila (en un futuro ya buscaría optimizar memoria). Con esto retraso la gestión de memoria hasta que el porting sea funcional, con lo que alivio la complejidad del trabajo.

Sin más hasta pronto.