jump to navigation

Nuevo Parche 0.0.3 9 noviembre, 2006

Posted by pjmicrocontroladores in Información general, Parches.
trackback

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.

Anuncios

Comentarios»

No comments yet — be the first.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: