herramienta gráfica para analizar la ocupación de...

UNIVERSIDAD DE BUENOS AIRESFACULTAD DE INGENIERÍA

CARRERA DE ESPECIALIZACIÓN EN SISTEMAS

EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Herramienta Gráfica para Analizar laOcupación de Memoria en Sistemas

Embebidos

Autor:Ing. Alejandro CELERY

Director:Ing. Juan Manuel CRUZ

Jurados:Ing. Juan ALARCÓN

Ms. Ing. Roberto BARNEDAIng. Gerardo SAGER

Este trabajo fue realizado en las Ciudad Autónoma de Buenos Aires, entreagosto de 2015 y julio de 2016.

III

Resumen

En el presente trabajo se plantea el uso de treemaps o gráficos de mapade árbol para representar gráficamente como se ocupan las memorias decódigo y datos de un microcontrolador. Se desarrolla un plugin para Eclipseque dibuja un treemap y presenta una lista de los nombres encontrados enla tabla de símbolos de un archivo binario.

V

AgradecimientosEn primer lugar a mi pareja, Esmeralda Yañez Illera. Solo ella sabe los

sacrificios que ha hecho para permitirme hacer esta especialización.

A mi padre, por haberme permitido llegar hasta donde estoy hoy, porlos valores que me transmitió por el camino, y por el orgullo que siente eneste momento desde donde sea que me esté viendo.

A la comunidad del software libre en general, por haberme brindadolas herramientas con las que ejercí la profesión hasta hoy (y a la que esperopoder devolverle algo con este trabajo).

A las autoridades de la CESE por haberme otorgado una beca para hacereste curso, sin la cual no hubiera sido posible mi presencia.

A Juan Manuel Cruz, siempre presente, tutor de este trabajo puntual yde muchas otras cosas más.

A Roberto Barneda, por la inmensurable cantidad de sabiduría que de-rramó sobre mi persona durante mis años formativos. Ojalá el destino mepermita hacer los mismo por las generaciones futuras.

A Rubén Lozano y Juan Alarcón, compañeros en la profesión, por apo-yarme en esta empresa siendo mis jurados. Espero que mi trabajo les com-pense de alguna manera el tiempo que invirtieron en acompañarme.

A Ben Shneiderman, creador de los diagramas NS y de los treemaps,por compartir su investigación conmigo y por interesarse en mi trabajo.

Al Ingeniero Mirko Serra, incansable compañero con quien comparti-mos el último y el más difícil tramo de la carrera académica. Aún no sedónde estaría sin la exitosa sociedad que supimos formar y que espero con-tinúe durante muchos años.

VII

Índice general

Resumen III

Agradecimientos V

Registro de versiones XI

1. Introducción General 11.1. Problemática de los consumos de memoria en un microcon-

trolador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Presentación de los treemaps . . . . . . . . . . . . . . . . . . 21.3. Presentación de Eclipse y su uso de plugins . . . . . . . . . . 31.4. Solución propuesta . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Introducción Específica 72.1. Tabla de símbolos generada por el compilador . . . . . . . . 72.2. Herramientas disponibles de análisis de la tabla de símbolos 8

2.2.1. Herramienta objdump . . . . . . . . . . . . . . . . . . 92.2.2. Herramienta nm . . . . . . . . . . . . . . . . . . . . . 92.2.3. Herramienta pahole . . . . . . . . . . . . . . . . . . . 10

2.3. Investigacion sobre treemaps . . . . . . . . . . . . . . . . . . 122.4. Diseño y desarrollo de un plugin . . . . . . . . . . . . . . . . 13

3. Diseño e Implementación 153.1. Análisis de la tabla de símbolos . . . . . . . . . . . . . . . . . 153.2. Desarrollo del plugin . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1. Lista completa de símbolos . . . . . . . . . . . . . . . 183.2.2. Lista filtrada de símbolos . . . . . . . . . . . . . . . . 183.2.3. Treemap . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.4. Interacciones entre las views . . . . . . . . . . . . . . 203.2.5. Obtención de la tabla de símbolos a graficar . . . . . 213.2.6. Modelo de los datos en memoria . . . . . . . . . . . . 213.2.7. Presentación de los datos al usuario . . . . . . . . . . 213.2.8. Opciones de configuración del plugin . . . . . . . . . 213.2.9. Depuración del plugin . . . . . . . . . . . . . . . . . . 23

3.3. Adopción de un algoritmo de treemapping . . . . . . . . . . 243.3.1. Resolución gráfica . . . . . . . . . . . . . . . . . . . . 243.3.2. Relación de aspecto . . . . . . . . . . . . . . . . . . . . 253.3.3. Preservación del orden de los datos . . . . . . . . . . 253.3.4. Estabilidad de los datos . . . . . . . . . . . . . . . . . 263.3.5. Algoritmo elegido . . . . . . . . . . . . . . . . . . . . 26

VIII

4. Ensayos y Resultados 294.1. Precisión del análisis de la tabla de símbolos . . . . . . . . . 29

4.1.1. Precisión de la identificación de secciones de la herra-mienta nm . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.2. Resultados del ensayo . . . . . . . . . . . . . . . . . . 304.2. Consumo de recursos de hardware causado por el plugin . . 32

4.2.1. Medición del tiempo de procesamiento . . . . . . . . 324.2.2. Resultados del ensayo . . . . . . . . . . . . . . . . . . 33

4.3. Validación con usuarios finales . . . . . . . . . . . . . . . . . 334.3.1. Esp. Ing. Pablo Ridolfi . . . . . . . . . . . . . . . . . . 344.3.2. Ing. Mirko Serra . . . . . . . . . . . . . . . . . . . . . 35

5. Conclusiones 375.1. Grado de cumplimiento de los requerimientos del proyecto . 37

5.1.1. Representación visual del uso de la memoria internadel MCU . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1.2. Fácil identificación de los principales consumos dememoria . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.1.3. Indicación de a qué zona de memoria fue asignadacada variable . . . . . . . . . . . . . . . . . . . . . . . 38

5.1.4. Presentación de estos datos dentro de una ventana deEclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2. Próximos pasos . . . . . . . . . . . . . . . . . . . . . . . . . . 39

A. Programa usado para los ensayos de medición 41

Bibliografía 43

IX

Índice de figuras

1.1. Vista de la aplicación Windirstat . . . . . . . . . . . . . . . . 21.2. Eclipse dibujando gráficos 2D . . . . . . . . . . . . . . . . . . 41.3. Eclipse dibujando gráficos 3D . . . . . . . . . . . . . . . . . . 41.4. Eclipse usado para diseño basado en modelos . . . . . . . . 5

2.1. Fragmento de un archivo “.map”, sección “.bss” . . . . . . . 72.2. Fragmento de un archivo “.map”, sección “.text” . . . . . . . 82.3. Fragmento de la salida del comando objdump . . . . . . . . 92.4. Fragmento de la salida del comando nm . . . . . . . . . . . . 102.5. Fragmento de la salida del comando pahole . . . . . . . . . . 112.6. Vista del programa TreeViz . . . . . . . . . . . . . . . . . . . 122.7. Detalle de los componentes de la interfaz de usuario de Eclipse 14

3.1. Código de la clase “Shell”. . . . . . . . . . . . . . . . . . . . . 153.2. Códigos con los que el comando nm identifica cada sección

de memoria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3. Código de la clase “Symbol”. . . . . . . . . . . . . . . . . . . 173.4. Lista completa de símbolos generada por el plugin . . . . . . 183.5. Lista filtrada de símbolos generada por el plugin . . . . . . . 193.6. Treemap generado por el plugin . . . . . . . . . . . . . . . . 203.7. Fragmentos del código que genera la lista completa de sím-

bolos del plugin. . . . . . . . . . . . . . . . . . . . . . . . . . . 223.8. Diálogo de opciones de configuración . . . . . . . . . . . . . 233.9. Treemaps con alta relación de aspecto . . . . . . . . . . . . . 253.10. Esquema del algoritmo “Squarify” . . . . . . . . . . . . . . . 27

4.1. Imagen de la salida del size al analizar el programa de prueba. 304.2. Vista de la sumatoria del tamaño de los símbolos en la sec-

ción .bss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.3. Vista de la sumatoria del tamaño de los símbolos en la sec-

ción .data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.4. Vista de la sumatoria del tamaño de los símbolos en la sec-

ción .text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.1. Resultado final del desarrollo . . . . . . . . . . . . . . . . . . 37

A.1. Programa usado para contrastar los reportes del plugin con-tra el comando size. . . . . . . . . . . . . . . . . . . . . . . . . 42

XI

Registro de versiones

Revisión Cambios realizados Fecha1.0 Creación del documento 27/06/20161.1 Correcciones de formato 29/06/20161.2 Se agrega el capítulo “Ensayos y resultados” 10/07/20161.3 Se agregan reportes de uso a la sección “Vali-

dacion con usuarios finales.”15/07/2016

1

Capítulo 1

Introducción General

1.1. Problemática de los consumos de memoria en unmicrocontrolador

Los microcontroladores son dispositivos electrónicos omnipresentes enel mundo de hoy. Están formados por un microprocesador capaz de ejecu-tar un programa almacenado previamente en su memoria interna y por unconjunto de periféricos de comunicación e interfaces eléctricas que le per-miten interactuar con el mundo exterior. Su costo ha bajado mucho en losúltimos años, causando que en la gran mayoría de los casos sean la soluciónelectrónica que mejor se adapta a cualquier requerimiento de un dispositivode control.

La memoria interna en la que almacenan el programa a ejecutar y losdatos que este utiliza tiene una capacidad finita, por lo que debe observarsecómo se emplea la misma.

El dato de cómo se consume la memoria en una aplicación con micro-controlador era de uso cotidiano en la época de los microcontroladores conunos pocos cientos de bytes de memoria de datos pero se fue perdiendocon el advenimiento de dispositivos con cada vez más capacidad de memo-ria (actualmente hay microcontroladores con 1Mb de memoria de código y192Kb de memoria de datos, contra los 8Kb y 256 bytes del primer micro-controlador con el que el autor tuvo su bautismo de fuego en la profesión).

La infromación del consumo de memoria la emite el compilador cadavez que compila la aplicación, pero lo hace en un formato cuasi críptico quees de difícil asimilación por programadores no experimentados. Aún en elcaso de programadores con trayectoria probada, buscar la información enese formato conlleva un gasto improductivo de tiempo.

La experiencia ha demostrado que se presentan dos situaciones cotidia-nas en el desarrollo de sistemas embebidos en las que este consumo se debetener muy presente:

Al encarar un desarrollo nuevo, se debe reducir al mínimo posible lamemoria utilizada por la aplicación con el fin de elegir el microcon-trolador más económico que la pueda contener.

Al ampliar un diseño existente, se puede agotar la memoria disponi-ble y ser necesario agregar una nueva funcionalidad.

Ante esta problemática, las herramientas de compilación gratuitas dis-ponibles hoy en día al programador no ofrecen al mismo una solución. Sibien existe la posibilidad de que las herramientas de uso profesional sí lohagan, esta posibilidad no se ha estudidado por el costo prohibitivo que lasmismas exhiben.

2 Capítulo 1. Introducción General

1.2. Presentación de los treemaps

Los treemaps (o mapas de árbol) son un tipo de diagrama muy útil quepuede ayudar con la problemática presentada anteriormente. Siendo unaherramienta 100 % visual, se prefiere mostrarla antes que intentar describir-la. Para contextualizar, la figura 1.1 muestra una imagen de una aplicaciónllamada WinDirStat [18] que sirve para analizar cómo se está ocupando elespacio disponible en un disco rígido, indicando cuáles archivos y/o car-petas ocupan el mayor espacio.

Figura 1.1: Vista de la aplicación Windirstat

En la figura 1.1 se pueden apreciar varias cuestiones:

En la ventana superior izquierda, una lista de las carpetas presentesen el disco rígido ordenadas de mayor a menor.

En la parte derecha, una lista de los tipos de archivo encontrados(imágenes, música, documentos, etc.) con un color asociado a cadatipo.

En la parte inferior, un mapa gráfico con numerosos rectángulos dedistintos colores y tamaños. Cada archivo presente en el disco rígidoestá representado por un rectángulo, donde su tamaño relativo al to-tal del espacio ocupado se aprecia en el tamaño del rectángulo (paraejemplificar, si un archivo ocupara la mitad del espacio en disco, surectángulo ocuparía la mitad del área graficada) y el color correspon-de al tipo de archivo indicado en la parte superior derecha.

Cabe mencionar que para analizar un disco rígido no se lo recorre físi-camente sector por sector sino que al comienzo del mismo hay una tablallamada FAT (File Allocation Table), que contiene el índice de qué archivoestá ubicado en qué parte del disco y qué tamaño ocupa.

1.3. Presentación de Eclipse y su uso de plugins 3

Recapitulando, existe una herramienta capaz de mostrar en forma gráfi-ca e inmediata las relaciones de tamaño entre una gran cantidad de archivosidentificados al analizar una tabla de ubicación de un disco rígido. El lectorcon experiencia en sistemas embebidos tal vez esté asociando en este mo-mento esta herramienta con la problemática presentada en la sección 1.1,que fue lo que hiciera el autor al verla por primera vez. Se discute esta po-sibilidad en la sección 1.4.

1.3. Presentación de Eclipse y su uso de plugins

La herramienta de uso más popularizado en el desarrollo de sistemasembebidos es sin duda un programa llamado Eclipse. Su historia se pue-de leer en Wikipedia [1], pero basta mencionar aquí su característica fun-damental: es un programa libre y sumamente modular compuesto por unpequeño núcleo cuya única función es cargar módulos conteniendo la fun-cionalidad deseada llamados “plugins” o “enchufables”.

De este modo, una única herramienta se puede utilizar para un sinnú-mero de propósitos siempre y cuando tenga disponibles los plugins nece-sarios. La aplicación es 100 % libre y de código abierto, y están sumamentedocumentados su uso y las técnicas de programación requeridas para desa-rrollar nuevos plugins. Por este motivo se han escrito módulos para per-mitirle funcionar para muchos propósitos. Sin ir más lejos, el plugin objetode este trabajo fue escrito en un entorno Eclipse y también lo fue este do-cumento en su totalidad, en ambos casos con el agregado de los pluginscorrespondientes.

En el desarrollo de sistemas embebidos se ha impuesto por sus nume-rosas virtudes, entre otras:

Es una herramienta libre y sin costo alguno.

Es muy sencillo de integrar con otras herramientas libres.

Es sumamente personalizable

Funciona indistintamente en Linux, Windows y MAC-OS.

Permite un uso muy flexible del espacio disponible en la pantalla.Esto es muy útil en estos días de trabajar con computadores portátilesadosados a un segundo monitor o un proyector.

Las siguientes tres figuras muestran sendas imágenes de Eclipse cum-pliendo roles bien diferentes con el espíritu de transmitir su versatilidad.

El único requisito para poder programar un plugin es hacerlo en el len-guaje Java, pero el mismo es lo bastante similar al lenguaje C++ y de algunamanera al lenguaje C (el de mayor uso en el desarrollo de SE) como paraque un programador de SE lo bastante motivado pueda emprender el desa-rrollo de un plugin.

1.4. Solución propuesta

De los expuesto anteriormente, se puede inferir que tomando los si-guientes recaudos se puede obtener una herramienta de gran valor:

www.eclipse.org

https://es.wikipedia.org/wiki/Eclipse_(software)


Figura 1.2: Eclipse dibujando gráficos 2D

Figura 1.3: Eclipse dibujando gráficos 3D

En lugar de analizar una tabla de ubicación de archivos en un dis-co rígido, se debe analizar una tabla de ubicación de variables en lamemoria de un microcontrolador.

Se debe contemplar que las relaciones de anidamiento (es decir, un ar-chivo dentro de una carpeta dentro de otra carpeta) no están presen-tes en la memoria de un microcontrolador (se discutirán más adelantealgunas excepciones).

1.4. Solución propuesta 5

Figura 1.4: Eclipse usado para diseño basado en modelos

Hay que obtener de alguna manera el algoritmo o receta para dibujarun mapa propio, producto del análisis anterior.

Todo esto se discutirá en el capítulo 2.Habiendo visto la problemática de los consumos de memoria, las bon-

dades de los gráficos de treemap para representarla y la posibilidad de am-pliar la herramienta de trabajo de uso cotidiano para incluir estos diagra-mas, resulta interesante la posibilidad de desarrollar un plugin para Eclipseque atendiera esta problemática.

Entonces, con la motivación de diseñar y desarrollar una herramientade software que asista a los programadores de sistemas embebidos en sufunción, permitiéndoles ver rápidamente cómo se está empleando la me-moria interna del microcontrolador en uso; con la esperanza de que estaherramienta ahorre tiempo al desarrollador al ejercer su función y le per-mita tomar mejores decisiones a la hora de elegir un microcontrolador paraun proyecto nuevo es que se eligió esta temática para desarrollar el presentetrabajo.

Durante el curso de gestión de proyectos se planificó este trabajo, y sepusieron los siguientes requerimientos:

1. Representación visual del uso de la memoria interna de un microcon-trolador.

2. Fácil identificación de los principales consumos de memoria.

3. Indicación de a qué zona de memoria fue asignada cada variable (FLASH,RAM, EEPROM, etc).

4. Presentación de estos datos dentro de una ventana de Eclipse.

Se definió el alcance del proyecto como “la realización de dicho pluginintegrable a Eclipse y la entrega de un manual de usuario que permita la


instalación y uso del mismo. En este proyecto no se contemplan cursos decapacitación en el uso de la herramienta generada.”

Fundamentado en los siguientes supuestos:

1. No hay actualmente una herramienta que cumpla estos requisitos.

2. Hay una población de programadores de sistemas embebidos que sebeneficiaría de tener tal herramienta.

3. El programador no experimentado suele ignorar esta problemática ytal herramienta lo ayudará a superar la misma.

Habiendo expuesto el panorama encontrado al momento de planificarel proyecto y los supuestos sobre los que se decidió llevarlo adelante, sepasa a la siguiente sección en la que se describen en detalle los componentesque formaron parte de la solución y sus problemáticas asociadas.

7

Capítulo 2

Introducción Específica

2.1. Tabla de símbolos generada por el compilador

El punto de partida del análisis detallado tiene que ser necesariamentela identificación de los datos a graficar. El primer contacto con ellos es unarchivo llamado “map file” o mapa del archivo, que el compilador generaluego de hacer una compilación. La figura 2.1 presenta un fragmento delmismo para referencia del lector:

.bss.bufferColumnaVacia0x10002b88 0x7f ...(CM3_Display_C12.o)0x10002b88 bufferColumnaVacia

.bss.bufferColumnaGrafica0x10002c07 0x7f ...(CM3_Display_C12.o)0x10002c07 bufferColumnaGrafica

.bss.buffer10medicionesPong0x10002c86 0xa ...(CM3_Display_C12.o)0x10002c86 buffer10medicionesPong

.bss._ZZ16BSP_DibujarPuntoiimbE14tocaTransferir0x10002c90 0x1 ...(CM3_Display_C12.o)

*fill* 0x10002c91 0x3

Figura 2.1: Fragmento de un archivo “.map”, sección “.bss”

El programador experimentado puede inferir rápidamente la siguienteinformación:

Todos los símbolos están ubicados en una misma sección llamada“bss”.

Los símbolos identificados son: bufferColumnaVacia, bufferColum-naGrafica, buffer10medicionesPong, tocaTransferir.

El símbolo tocaTransferir es declarado con el modificador “static” yes local a la función BSP_DibujarPunto

Las direcciones de memoria comienzan en 0x10002b88

Los tamaños ocupados por los símbolos son de 127, 127, 10 y 1 bytes(en el orden en que se reconocen los símbolos).

El último símbolo de la lista ocupa 1 byte pero luego de él se reser-va un espacio desperdiciado de 3 bytes, para que todos los símbolosempiecen en una dirección múltiplo de 4.

8 Capítulo 2. Introducción Específica

Todos pertenecen al archivo CM3_Display_C12

Por la propia experiencia del autor, se concluye que estas determina-ciones escapan al programador principiante. Ciertamente durante la for-mación académica recibida en la carrera de Ingeniería Electrónica (que ge-neralmente son quienes suelen dedicarse a los sistemas embebidos) no sellega a examinar el software producido con el nivel de detalle suficientepara percibir estas cuestiones.

En el fragmento analizado se hizo incapié en unas declaraciones de va-riables en el segmento de datos. Si ahora miramos un fragmento del mismoarchivo referido al segmento de código y la declaración de funciones vemosque la situación es similar, como se puede ver en la figura 2.2:

.text.ColaReset0x00016db4 0x1a ...(ColaCircular.o)0x00016db4 ColaReset

.text.ColaInit0x00016dce 0x24 ...(ColaCircular.o)0x00016dce ColaInit

.text.ColaCantidad0x00016df2 0x12 ...(ColaCircular.o)0x00016df2 ColaCantidad

.text.ColaDisponible0x00016e04 0x16 ...(ColaCircular.o)0x00016e04 ColaDisponible

Figura 2.2: Fragmento de un archivo “.map”, sección “.text”

En este caso se pueden sacar similares conclusiones, con la salvedad deque los símbolos están en la sección “text”.

Para contextulizar finalmente la complejidad de encontrar estos datosen el archivo, vale mencionar que el ejemplo del que se tomaron estos frag-mentos tiene 7230 líneas de largo y que el mismo incluye numerosos arte-factos producidos por el compilador durante el proceso de compilación queno tienen importancia para el programador.

2.2. Herramientas disponibles de análisis de la tablade símbolos

Habiendo visto las vicisitudes de analizar manualmente el resultado delproceso de compilación, vale mencionar que existen herramientas de soft-ware que hacen ese trabajo notablemente más fácil. Dos de ellas son partedel grupo de herramientas llamadas “binutils” y están disponibles a partirde que se instalan las herramientas para programar un microcontrolador(en adelante “toolchain” o “cadena de herramientas”). Es importante recor-dar que la salida producida por estas herramientas solo sirve si puede serrecogida y tabulada para su posterior uso por herramientas gráficas, estefue el criterio que se utilizó para elegir una de las tres.

2.2. Herramientas disponibles de análisis de la tabla de símbolos 9

<1><894a>: Número de Abrev: 143 (DW_TAG_variable)<894c> DW_AT_decl_line : 835<894e> DW_AT_decl_file : 50<8950> DW_AT_type : <0x8aeb><8954> DW_AT_external : 1<8955> DW_AT_location : bloque de byte 5: 3 ...<895b> DW_AT_name : buffer_tx

<1><8965>: Número de Abrev: 130 (DW_TAG_variable)<8967> DW_AT_type : <0x8b28><896b> DW_AT_external : 1<896c> DW_AT_declaration : 1<896d> DW_AT_name : c

<1><8998>: Número de Abrev: 130 (DW_TAG_variable)<899a> DW_AT_type : <0x89c9><899e> DW_AT_external : 1<899f> DW_AT_declaration : 1<89a0> DW_AT_name : hayContraseniaCorrecta

Figura 2.3: Fragmento de la salida del comando objdump

2.2.1. Herramienta objdump

Objdump fue la primera herramienta analizada. Es la más conocida delas tres por los programadores, ya que forma parte del proceso estándar decompiación de un programa para microcontrolador. El siguiente es un frag-mento de su documentación disponible en forma online: “objdump muestrainformación sobre uno o más archivos objeto. Tiene opciones para controlar qué in-formación en particular se muestra. Esta información es mayormente útiles paralos programadores que trabajan en las herramientas de compilación y no para losprogramadores que solo quieren que su programa compile y funcione. . . ” [10].

Es una herramienta sumamente versátil y como tal tiene muchas op-ciones para configurar su uso. La dificultad en su uso se menciona en ladescripción precedente: al estar orientada a desarrolladores de herramien-tas no hay ningún interés en presentar la información en forma sencilla.La figura 2.3 muestra un ejemplo de lo que se puede esperar cuando se lautiliza:

Se puede ver que por cada entidad encontrada en el archivo analizadose produce un bloque que empieza con la línea que contiene “Número deAbrev”. A simple vista no se puede extraer la información de tamaño delos símbolos encontrados ni de la sección en la que fueron ubicados. Másaún, esta información probablemente esté en otra parte de la salida y seanecesario hacer una correlación de más de una.

Habiendo visto la dificultad de encontrar la información buscada y másaún recogerla programáticamente para procesarla, se detuvo el análisis pre-liminar de esta herramienta en este punto y se pasó a la siguiente.

2.2.2. Herramienta nm

Nm es una herramienta más sencilla, con un propósito más específico:“nm lista los símbolos encontrados en una lista de archivos objeto. . . ” [9].


00049418 00000148 t _ProcEstadoInterfazBloqueada00070334 00000148 t _ControlaPresionSeteada00032192 00000142 t _VerificaFuentesGases...08388612 00000010 D _umbralEstadosBateriaDescarga08388622 00000010 D _umbralEstadosBateriaCarga...08388804 00000032 B _flags_t_svc08389492 00000032 B _flags_t_est08389540 00000016 B _estado_equipo

Figura 2.4: Fragmento de la salida del comando nm

Por su descripción, nm parece ser la herramienta hecha a medida parael propósito buscado. La figura 2.4 muestra un ejemplo de su uso paracompararlo con la anterior:

Se puede ver a simple vista el formato de lista en el que se muestran losresultados. En una segunda inspección, se aprecia la siguiente información:

La primera columna contiene la dirección en memoria de cada símbo-lo.

La segunda muestra el tamaño de los mismos.

Luego sigue una letra que el observador experimentado puede reco-nocer como la sección en la que se ubica el símbolo. Recuérdese querecabar esta información es uno de los requerimientos del proyecto.

A esta altura el autor pudo apreciar que esta herramienta supera concreces a la anterior. En la sección 4.1 se analizará el grado de precisión conel que se extrae la información de esta tabla para tener una métrica cuanti-tativa de los resultados de este trabajo.

2.2.3. Herramienta pahole

Pahole es una herramienta complementaria para los objetivos de estetrabajo. “pahole muestra la disposición de las estructuras de datos que se almacenaen los símbolos de depuración. . . ” [11].

Su propósito no es identificar los símbolos declarados en un progra-ma sino hacer un análisis de cómo el compilador organiza las estructurasde datos declaradas por el programador. Para contextualizar este análisisse menciona que muchas veces estas estructuras se usan cuando se escri-be código para acceder a hardware, y en estos casos es necesario que elcompilador respete la ubicación exacta de cada bit y byte declarado por elprogramador. En algunos casos los compiladores no hacen esto sino queagregan bits de relleno en las estructuras buscando un acceso más rápido ala memoria.

Por completitud, se muestra un ejemplo de su uso en la figura 2.5 :

2.2. Herramientas disponibles de análisis de la tabla de símbolos 11

struct st_evento {unsigned char cod_evento; /* 0 1 */unsigned char detalle_evento; /* 1 1 */unsigned char dia; /* 2 1 */unsigned char mes; /* 3 1 */unsigned char anio; /* 4 1 */unsigned char hora; /* 5 1 */unsigned char minutos; /* 6 1 */unsigned char segundos; /* 7 1 */

/* size: 8, cachelines: 1, members: 8 *//* last cacheline: 8 bytes */};struct st_tabla_estado {unsigned short estado_on_off; /* 0 2 */unsigned short boot_count; /* 2 2 */unsigned short estado_falla; /* 4 2 */unsigned short horas_uso_cpu; /* 6 2 */unsigned short horas_ultimo_service; /* 8 2 */unsigned char minutos_uso_cpu; /* 10 1 */unsigned char t_est_reservado; /* 11 1 */unsigned short ciclos_valvulas; /* 12 2 */unsigned short horas_uso_turbina; /* 14 2 */

/* size: 16, cachelines: 1, members: 9 *//* last cacheline: 16 bytes */};

Figura 2.5: Fragmento de la salida del comando pahole


2.3. Investigacion sobre treemaps

Habiendo establecido la conveniencia de los mapas de árbol para repre-sentar información, resulta apropiado indagar un poco más sobre ellos. Sepuede leer un racconto muy detallado de su historia en [13] contado por elpropio Ben Shneiderman de la Universidad de Maryland, Estados Unidos,creador de estos diagramas.

El comienzo de su investigación lo explica así (traducido por el autor):“En 1990, en respuesta a la problemática común de un disco rígido lleno, me ob-sesioné con la idea de producir una visualización compacta de las estructuras deárbol de directorios. Dado que el disco rígido de 80 Megabytes usado en el labora-torio de Interacción hombre-computador era compartido por 14 usuarios, era muydifícil determinar cómo y dónde se usaba su capacidad. . . ”

“Los diagramas con estructura de árbol y vinculados en los nodos se volvíanmuy grandes para ser útiles, así que exploré maneras de mostrar un árbol en unformato con espacio limitado. Rechacé las estrategias que dejaban espacios en blan-co.(. . . ) Mostrar el tamaño de los archivos codificándolo por área parecía atractivo,pero las formas rectangulares, triangulares y circulares todas tenían problemas. Fi-nalmente un día meditando sobre esto en el salón de la facultad, tuve el momentoAjá! de dividir la pantalla en rectángulos alternando las direcciones vertical y ho-rizontal a medida que se atraviesan los distintos niveles.”

En el marco de su investigación, Ben Shneiderman y Brian Johnson es-cribieron la primera implementación de un visor de ocupación de espacioen disco rígido y lo bautizaron TreeViz. La figura 2.6 muestra una imagendel mismo.

Figura 2.6: Vista del programa TreeViz, primero en imple-mentar la visualización mediante treemaps. Figura tomada

de [13]

Luego en la misma página menciona el software que se adoptó en es-te trabajo: “Para apoyar a investigadores y estudiantes, Ben Bederson y Martin

2.4. Diseño y desarrollo de un plugin 13

Wattenberg escribieron una librería de código abierto en Java 1.1 con 5 algorit-mos de treemap. Son genéricos y debieran poder usarse sencillamente en cualquieraplicación. Cada una toma una lista de números y un rectángulo, y genera un con-junto de sub-rectángulos que son proporcionales en área a los números de entraday particiona el espacio del rectángulo de entrada. Los 5 algoritmos implementadosson:

BinaryTree - Partially ordered, not very good aspect ratios, stable

Ordered - Partially ordered, medium aspect ratios, medium stability

SliceAndDice - Ordered, very bad aspect ratios, stable

Squarified - Unordered, best aspect ratios, medium stability

Strip - Ordered, medium aspect ratios, medium stability”

En este punto vale aclarar que un “algoritmo de treemapping” se debeentender como un criterio para repartir el espacio disponible entre los dis-tintos rectángulos. Shneiderman ordena estos 5 algoritmos según sus capa-cidades de orden, relación de aspecto y estabilidad. La eleccción de uno deestos algoritmos y las características mencionadas de los mismos se discu-tirá en la sección 3.3.

Lo último que resulta interesante citar son funciones adicionales quese desarrollaron durante la investigación: “La implementación del estudian-te de doctorado Brian Johnson agregó muchas otras funciones interesantes, comoser zooming, sonido (como una codificación redundante, por ejemplo los archivosmás grandes tenían un sonido más grave), control de matiz y saturación, muchasvariantes de bordes y control de etiquetado. . . ” . Algunas de estas funciones adi-cionales se tomaron como ideas para los próximos pasos posteriores a estetrabajo, como se muestra en la sección 5.2.

2.4. Diseño y desarrollo de un plugin

Se ha dicho anteriormente que Eclipse es una plataforma formada porun pequeño núcleo capaz de cargar módulos externos a él y que le brindanfuncionalidad. A continuación analizamos estos módulos y cómo se desa-rrolla uno propio.

Tanto el núcleo de Eclipse como los plugins se escriben en el lenguajeJava. De hecho, Eclipse nace dentro de la firma IBM [1] como un entornopara programar en dicho lenguaje y se lo considera el mejor entorno paratal función. Así las cosas, un plugin no es más que un pequeño programaen Java que se desarrolla usando el mismo Eclipse.

Para simplificar el proceso de desarrollo, el mismo no se hace partiendode un lienzo en blanco sino que se parte de diversas plantillas de pluginsque luego el programador modifica para sus propósitos. Tanto estas plan-tillas como las herramientas de software necesarias para escribir, ensayar yvalidar un plugin están contenidas dentro del llamado PDE o “Plugin De-velopment Environment”, es menester instalarlo para encarar el desarrollode un plugin. Casualmente, el PDE es un conjunto de plugins diseñadospara permitir el desarrollo de otros plugins.


Los plugins tienen una característica particular: por un lado se listan enforma declarativa las capacidades que aportan a Eclipse y su funcionalidadse programa en lenguaje Java en otro lugar. Esto permite que al iniciar Eclip-se no haya que cargar todos los plugins que le fueron instalados sino quetan solo lee estas listas logrando así arrancar muy rápidamente. Es reciéncuando el usuario invoca alguno de estos plugins que se procede a cargarloen memoria.

La figura 2.7 muestra una imagen básica de una ventana de Eclipse parapresentar sus elementos:

Figura 2.7: Detalle de los componentes de la interfaz deusuario de Eclipse

Como regla general, a todos los elementos destacados en la imagen sepuede agregar funcionalidad. Pongamos algunos ejemplos:

A la barra de menúes se pueden agregar nuevos menúes, y a estosnuevas opciones.

A la barra de herramientas se pueden agregar nuevos botones.

Se pueden agregar editores especializados en algún lenguaje en par-ticular.

Lo más importante (y lo que se ha hecho en el presente trabajo) es agre-gar nuevas ventanas (llamadas “Views” en la jerga). Estas pueden contenercualquier información de interés y se pueden hacer varias operaciones so-bre ellas. En la sección 3.2 se expone en detalle la funcionalidad que seimplementó.

15

Capítulo 3

Diseño e Implementación

3.1. Análisis de la tabla de símbolos

Para extraer la información de la tabla de símbolos se eligió finalmentela herramienta “nm”. Su formato tabular hace que sea muy sencillo proce-sar la información y capturarla en el plugin.

Para invocar a nm se usa la clase Shell (presentada en la figura 3.1), quetiene un único método estático “command”. El mismo genera un nuevoproceso para el sistema operativo que invoca al proceso recibido como pa-rámetro. En este caso la llamada es “nm –print-size –size-sort –reverse-sort–radix=dec nombreArchivo.elf”.

1 publ ic c l a s s S h e l l{

3 s t a t i c ArrayList <Str ing > output ;

5 publ ic s t a t i c ArrayList <Str ing > command( f i n a l S t r i n g cmdline ,f i n a l S t r i n g d i r e c t o r y )

7 throws IOException , InterruptedExcept ion{

9 Process process =new ProcessBui lder (new S t r i n g [ ] { " bash " , "−c " , cmdline

} )11 . r e d i r e c t E r r o r S t r e a m ( true )

. d i r e c t o r y (new F i l e ( d i r e c t o r y ) )13 . s t a r t ( ) ;

15 output = new ArrayList <Str ing > ( ) ;BufferedReader br = new BufferedReader (

17 new InputStreamReader ( process . getInputStream ( ) ) ) ;

19 S t r i n g l i n e = n u l l ;while ( ( l i n e = br . readLine ( ) ) != n u l l ) {

21 output . add ( l i n e ) ;}

23

i f (0 != process . waitFor ( ) ) {25 re turn n u l l ;

}27

re turn output ;29 }

}

Figura 3.1: Código de la clase “Shell”.

16 Capítulo 3. Diseño e Implementación

Esta llamada devuelve una lista donde cada elemento es una línea detexto con una columna para cada dato que contiene, por ejemplo: 0003219200000142 t VerificaFuentesGases

Las mismas se interpretan de la siguiente manera:

1. Dirección de memoria del símbolo. En este plugin no se hace uso estedato ya que no es un requerimiento del mismo hacer un mapa to-pográfico de la memoria. En una segunda mirada, los microcontrola-dores organizan las secciones de código y datos en ciertos rangos dedirecciones, con lo cual con de la dirección de memoria de un símbolose puede inferir la sección en la que está ubicado. Esta posibilidad sedescartó en este trabajo dado que impondría al usuario la necesidadde aprender el mapa de memoria del microcontrolador en uso y comose verá en breve la tercera columna da esta información.

2. Tamaño en memoria del símbolo.

3. Una letra que indica la sección de memoria donde el símbolo fue ubi-cado.

4. Nombre del símbolo.

La figura 3.2 muestra como identifica nm las secciones [9]:

"B""b" The symbol is in the uninitialized data section

(known as BSS).

"D""d" The symbol is in the initialized data section.

"T""t" The symbol is in the text (code) section.

"?" The symbol type is unknown, or object fileformat specific.

Figura 3.2: Códigos con los que el comando nm identificacada sección de memoria.

Para alojar estos datos se diseñó la clase Symbol, presentada en la figura3.3:

Se puede ver en el método “Symbol” el proceso de análisis, donde segúnel valor del carácter en la columna 3 (en el código se ve 2 porque cuentadesde 0) se asigna el nombre por el que los programadores conocen a lassecciones.

3.2. Desarrollo del plugin

A la hora de presentar la información al usuario, fue necesario decidirla mejor manera de hacerlo. Se optó por un esquema con 3 views:

1. Lista completa de símbolos

3.2. Desarrollo del plugin 17

publ ic c l a s s Symbol {2 p r i v a t e S t r i n g name ;

p r i v a t e I n t e g e r s i z e ;4 p r i v a t e S t r i n g s e c t i o n ;

p r i v a t e boolean enabled ;6

publ ic Symbol ( S t r i n g name , I n t e g e r s ize , S t r i n g s e c t i o n ) {8 t h i s . name = name ;

t h i s . s i z e = s i z e ;10 t h i s . s e c t i o n = s e c t i o n ;

t h i s . enabled = true ;12 }

14 publ ic Symbol ( S t r i n g nmOutput ) {t h i s . enabled = true ;

16

S t r i n g [ ] tokens = nmOutput . s p l i t ( " " ) ;18 t h i s . s i z e = I n t e g e r . p a r s e I n t ( tokens [ 1 ] ) ;

t h i s . name = tokens [ 3 ] ;20

i f ( tokens [ 2 ] . equalsIgnoreCase ( " b " ) )22 t h i s . s e c t i o n = " BSS " ;

e l s e i f ( tokens [ 2 ] . equalsIgnoreCase ( "d" ) )24 t h i s . s e c t i o n = " Data " ;

e l s e i f ( tokens [ 2 ] . equalsIgnoreCase ( " t " ) )26 t h i s . s e c t i o n = " Text " ;

e l s e i f ( tokens [ 2 ] . equalsIgnoreCase ( "w" ) )28 t h i s . s e c t i o n = " Text−Weak" ;

e l s e30 t h i s . s e c t i o n = tokens [ 2 ] ;

}32

@Override34 publ ic S t r i n g t o S t r i n g ( ) {

re turn name + " − " + s i z e ;36 }

38 publ ic boolean isInROM ( ) {re turn s e c t i o n . equals ( " Text " ) || s e c t i o n . equals ( " Text−Weak

" ) ;40 }

42 publ ic boolean isInRAM ( ) {re turn ! isInROM ( ) ;

44 }}

Figura 3.3: Código de la clase “Symbol”.

2. Lista filtrada de símbolos

3. Treemap.

Primero se introducirá cada una por separado con sus capacidades y lue-go se analizará la interacción entre ellas que es lo que genera el valor delplugin.


3.2.1. Lista completa de símbolos

Este es el punto de partida del desarrollo. Se optó por presentar el totalde los símbolos identificados en el archivo binario en un formato de ta-bla con 3 columnas. En estas se presentan respectivamente el nombre delsímbolo, su tamaño en memoria y la sección en la que fue ubicado por elcompilador. Podría decirse que solo con esta lista se brinda una gran ayudaal programador. Como se ve en la figura 3.4, el objetivo principal de estalista es presentar la visión total de los contenidos del archivo analizado.

Figura 3.4: Lista completa de símbolos generada por el plu-gin

Su principal característica es que cada símbolo tiene una casilla de verifi-cación que indica si será graficado o no en el mapa y en la lista filtrada. Estopermite que el plugin presente información sobre la totalidad del archivo osolo sobre el subconjunto del mismo que sea de interés para el usuario.

Además de mostrar los símbolos, se incluyeron dos ayudas para el usua-rio: un campo de búsqueda en el cual se puede escribir una parte del sím-bolo buscado y que la lista oculte los que no coinciden con él y un filtro quepermite seleccionar todos los símbolos que correspondan a una sección enparticular. De este modo es fácil ver el mapa de todos los símbolos, el mapade la memoria de código, el mapa de la memoria de datos y una distinciónentre dos secciones de la memoria de datos: las llamadas “bss” y “data”que representan los datos que no tienen un valor inicial y los que sí debentenerlo respectivamente.

3.2.2. Lista filtrada de símbolos

La figura 3.5 muestra la lista filtrada de símbolos. Esta lista es la que ali-menta el treemap, todos los símbolos que esté mostrando son graficados. Sibien podría haberse mantenido oculta al usuario se decidió dejarla visible.


El plugin puede funcionar con o sin ella habilitada. Incluye un totalizadorque suma el tamaño de todos los símbolos mostrados.

Figura 3.5: Lista filtrada de símbolos generada por el plugin

3.2.3. Treemap

La vista treemap se puede apreciar en la figura 3.6. Muestra el mapa deárbol de los símbolos contenidos en la lista filtrada. Lo hace ordenando lossímbolos por tamaño descendente, ya que se encontró que este es el criteriode mayor utilidad según los requerimientos del proyecto.

En la imagen se pueden apreciar tres cuestiones importantes:

Un símbolo muy grande en color gris oscuro que representa el espaciolibre en memoria (si bien esta imagen no lo muestra, se verá luego enla interacción con la lista que sí lo hace). De esto se puede inferir queeste microntrolador tiene capacidad de sobra para seguir agregándolefuncionalidad.

Un símbolo en verde oscuro en la parte inferior izquierda que ocupauna parte significativa comparado con las demás. De ser necesarioliberar algo de memoria en esta aplicación, este sería el primer lugara revisar.

Una región en la esquina inferior derecha donde hay un sinnúmerode variables de tamaño muy pequeño. Es razonable suponer que sonvariables de 1 byte que representan estados de algún proceso en par-ticular o contadores de 1 byte, con el rango de 0 a 256. Se ve que pararecuperar el tamaño equivalente a tan solo UN símbolo de los de laparte superior derecha habría que eliminar muchos. Este es el puntomencionado previamente de los rendimientos decrecientes, donde noes provechoso aplicar un proceso de optimización. Si esta región fuesemuy grande solo se puede concluir que el programador responsablede esta aplicación tiene algunos vicios que debe corregir.

El mapa se dibuja con una paleta de 5 colores generada en la web [14].Para que los rectángulos adyacentes se puedan diferenciar fácilmente entre


Figura 3.6: Treemap generado por el plugin

sí se tomaron dos medidas: Por un lado, cada símbolo se dibuja con undegradé entre su color base y uno que es un 20 % más oscuro, y por el otrose los dibuja con un recuadro negro fino.

Para destacar el rectángulo que el usuario haya seleccionado, al mismose le dibuja un reborde blanco grueso alrededor.

3.2.4. Interacciones entre las views

El treemap es el objetivo principal del desarrollo, pero para que tengauna utilidad práctica es necesario tener control sobre lo que se está grafi-cando. Para esto se decidió conectarlas de la siguiente manera:

Se puede trabajar con solo un subconjunto de lo símbolos del archivo:Esto se logra destildando todos los símbolos de la lista completa y lue-go tildando los pocos que sean de interés. Esto último se ve ayudadopor el campo de búsqueda de la lista completa.

Cuando se quiere excluir un símbolo particular del análisis, se puededestildar únicamente ese y el mapa se redibujará sin él.

Se puede concentrar el análisis en una sola sección, lo que se lograeligiéndola en el filtro de secciones de la lista completa.


Se pueden ordenar ambas listas por nombre, por tamaño y por sec-ción, lo que permite ver más fácil los símbolos de interés. Esto nomodifica el treemap, que siempre se grafica ordenado por tamaño.

Se puede seleccionar un rectángulo en particular en el treemap paraver a qué símbolo corresponde. Al hacer esto las listas lo muestranseleccionado y resaltado para que sea más fácil encontrarlo.

3.2.5. Obtención de la tabla de símbolos a graficar

Para adquirir la tabla de símbolos se hace desde el plugin una llamadaal comando “nm” usando la clase de Java “ProcessBuilder”. Esta se encargade generar un nuevo proceso del sistema operativo que se encarga de eje-cutar el comando “nm” con las opciones discutidas previamente y recogerla salida del mismo. El motivo de hacer esto fue mantener toda la funcio-nalidad en lenguaje Java y dentro del mismo plugin, para no imponer alusuario final la instalación de herramientas adicionales.

3.2.6. Modelo de los datos en memoria

Al programar en un lenguaje orientado a objetos como es Java se sim-plifica mucho la organización de los datos en la memoria. Se empezó pordefinir una clase “Símbolo” que representa la información que se puede ex-traer del análisis de los datos: nombre, tamaño y sección. Luego se armauna lista con estos Símbolos, a la que se llama Modelo.

3.2.7. Presentación de los datos al usuario

Las buenas prácticas de programación mandan que hay que separar elcontenido de la presentación del mismo, de modo que se puedan alterarambas por separado. En este caso, Eclipse hace uso copioso de los llamados“JFace viewers” [17]. Son numerosos visualizadores de datos a los que tansolo hay que darles una semblanza de cómo los mismos están organizados.

La figura 3.7 se muestra el código (algo recortado) que genera la listacompleta de símbolos para demostrar la sencillez que se puede trabajar unavez que se supera la curva de aprendizaje de estas herramientas:

En la línea viewer.setContentProvider(new ArrayContentProvider()); se ledice a la tabla que los datos tienen forma de “Array” o vector, es decir queestán todos uno a continuación del otro y con el mismo formato.

Luego en viewer.setInput(Activator.getModel().getSymbols()); se le dice quesus datos de entrada provienen de la lista de símbolos contenida en el mo-delo.

De la misma manera sencilla se ve como se programa el criterio paraordenar las listas por cualquiera de las tres columnas.

3.2.8. Opciones de configuración del plugin

Se implementaron 4 opciones que permiten personalizar el funciona-miento del plugin:

1. Indicar la ruta hacia el comando “nm”. Esto es fundamental para queel plugin pueda funcionar en cualquier instalación que el usuario ha-ya podido hacer de las herramientas de compilación.


1 p r i v a t e void createViewer ( Composite parent ) {viewer = new CheckboxTableViewer ( new Table ( parent , . . . ) ) ;

3 createColumns ( parent , viewer ) ;

5 viewer . setContentProvider (new ArrayContentProvider ( ) ) ;viewer . se t Input ( Act iva tor . getModel ( ) . getSymbols ( ) ) ;

7 g e t S i t e ( ) . s e t S e l e c t i o n P r o v i d e r ( viewer ) ;

9 viewer . addCheckStateListener (new I C h e c k S t a t e L i s t e n e r ( ) {@Override

11 publ ic void checkStateChanged ( CheckStateChangedEvent event ) {Object [ ] ce = viewer . getCheckedElements ( ) ;

13 Act iva tor . getModel ( ) . s e t E n a b l e d L i s t ( ce ) ;}

15 } ) ;}

17

p r i v a t e void createColumns ( f i n a l Composite parent , f i n a lTableViewer viewer ) {

19 S t r i n g [ ] t i t l e s = { "Name" , " S ize " , " S e c t io n " } ;i n t [ ] bounds = { 200 , 100 , 100 } ;

21

// name column23 TableViewerColumn c o l = createTableViewerColumn ( t i t l e s [ 0 ] ,

bounds [ 0 ] , 0 ) ;c o l . se tLabe lProvider (new ColumnLabelProvider ( ) {

25 @Overridepubl ic S t r i n g getText ( Object element ) {

27 Symbol p = ( Symbol ) element ;re turn p . getName ( ) ;

29 }} ) ;

31

// s i z e column33 // s e c t i o n column

}35

p r i v a t e Selec t ionAdapter getSe lec t ionAdapter ( f i n a l TableColumncolumn , f i n a l i n t index ) {

37 Select ionAdapter se lec t ionAdapter = new Select ionAdapter ( ) {@Override

39 publ ic void widgetSelected ( Se lec t ionEvent e ) {comparator . setColumn ( index ) ;

41 i n t d i r = comparator . g e t D i r e c t i o n ( ) ;viewer . getTable ( ) . s e t S o r t D i r e c t i o n ( d i r ) ;

43 viewer . getTable ( ) . setSortColumn ( column ) ;viewer . r e f r e s h ( ) ;

45 }} ;

47 re turn se lec t ionAdapter ;}

Figura 3.7: Fragmentos del código que genera la lista com-pleta de símbolos del plugin.

2. Indicar la ruta hacia el archivo binario que se analizará. Si bien lasprácticas habituales en el desarrollo de plugins dictan que el mismo


reconozca automáticamente en qué proyecto está trabajando el usua-rio y que de este mismo se pueda inferir cuál es el archivo a analizar,las limitaciones de tiempo no permitieron lograr esta funcionalidady por esta razón debe indicarse al plugin cuál archivo se usará. Estamejora quedó para un próximo avance del trabajo como se puede veren la sección 5.2.

3. Tamaño de la memoria de código y datos del microcontrolador enuso. Estos dos valores son para completar la presentación de la infor-mación, permiten calcular el espacio libre en cada una.

Para acomodar estas opciones fue necesario agregar un diálogo o pan-talla de configuración del plugin. El mismo se muestra a continuación en lafigura 3.8.

Figura 3.8: Diálogo de opciones de configuración

3.2.9. Depuración del plugin

El proceso de depuración es realmente sencillo, teniendo presente quese está generando un agregado a la propia plataforma de desarrollo y quela misma es sobresaliente a la hora de trabajar en el lenguaje Java.

Para probar el plugin no se puede hacer otra cosa que iniciar una nuevaventana instancia de Eclipse donde el plugin está incorporado. Esto puedeser algo lento si el computador en el que se hace el desarrollo no tiene unhardware moderno. Al momento de escribir este trabajo el autor acababade adquirir un disco rígido de estado sólido y se pudo apreciar la ventajade los tiempos reducidos de carga que los mismos ofrecen.

El otro aspecto importante es que debido a las características técnicas deJava, es posible reemplazar un pedazo del código en ejecución “en calien-te”, es decir sin tener que detener el programa e iniciarlo de nuevo.

Se puede concluir esta sección mencionando que la parte de manipu-lación de datos no tiene ninguna novedad para el progamador versado enprogramación orientada a objetos. La dificultad radica en aprender a usarcorrectamente las herramientas que ofrece la plataforma Eclipse, pero una


vez logrado esto se ve que son lo bastante completas y poderosas como paraque la programación se vea reducida a descubrir como indicar claramentea la plataforma la funcionalidad deseada.

3.3. Adopción de un algoritmo de treemapping

La pieza final de la solución es finalmente el algoritmo de treemappinga usar.

3.3.1. Resolución gráfica

El primer intento se hizo con una implementación propia del más ele-mental, “SliceAndDice”. El mismo funciona particionando el área gráficaen rectángulos en una sola dirección.

Se asumía que el área donde se dibujaría sería más ancha que alta ypor tanto cada fracción del tamaño total a representar se dibujaba medianteun rectángulo con orientación vertical donde su ancho representaba el altodel símbolo. Esto expuso inmediatamente la problemática de la representa-ción gráfica: Supóngase que se está graficando en un rectángulo de 800x600píxels un mapa de memoria de un microcontrolador de 512 Kbytes de me-moria de código (una situación cotidiana, esa capacidad la tiene el LPC1769que es el microcontrolador usado en el kit LPCXpresso usado ampliamenteen numerosas universidades en los últimos años). Un sencillo cálculo arrojaque hay que representar 524288 bytes en un rango de 800 píxels. Esto arrojaunos 655 bytes por píxel, de lo que se puede inferir que una cantidad dememoria de menos de 655 bytes no amerita un píxel en la pantalla.

Ese tamaño de memoria genera una muy mala resolución gráfica, en lapráctica cotidiana lo suelen ocupar solamente los buffers de comunicacióny algunas estructuras de control de ciertos protocolos con muchos camposde texto. Lo mismo ocurre en la sección de código, quedarían ocultas en elgráfico numerosísimas funciones y resultaría un análisis muy pobre de laocupación de memoria.

La situación cambia al partir el espacio como sugiere Schneiderman,alternando las dimensiones horizontal y vertical. En este caso un área de800x600 píxels representa permite representar los 524288 bytes mediante480000, quedando casi un pixel por byte. Es en este punto que se comen-zó a buscar la adaptación de uno de los algoritmos implementados por laUniversidad de Maryland en lugar de seguir con el propio.

Estos algoritmos se pueden descargar libremente del Human-ComputerInteraction Laboratory (HCIL) [5]. Al estar desarrollados en Java es sencillointegrarlos al plugin desarrollado. En este paquete de software se incluyeuna aplicación de demostración que genera una lista de 20 rectángulos contamaños aleatorios distribuidos en forma Gaussiana y los dibuja en unaventana. Esto permite experimentar con los distintos algoritmos y elegir elmás conveniente.

Se recordará que Shneiderman [4] los clasifica según tres atributos quese analizan a continuación.

3.3. Adopción de un algoritmo de treemapping 25

3.3.2. Relación de aspecto

Shneiderman define la relación de aspecto de un rectángulo en su papercomo “el mayor de ancho/alto y alto/ancho”, y luego dice “usando esta defini-ción, cuanto menor sea la relación de aspecto de un rectángulo, más parecido a uncuadrado es. Un cuadrado tiene una relación de aspecto de 1, que es el mínimo valorposible.”

Figura 3.9: Treemaps con una relación de aspecto promediomuy alta, producido por el algoritmo “Slice and dice”. A laizquierda aplicado a un solo nivel de datos. A la derecha,

aplicado a datos organizados jerárquicamente.

La relación de aspecto resulta la principal métrica de calidad de un tree-map por dos motivos:

Como se puede apreciar en la figura 3.9 resulta mucho más sencillocomparar tamaños relativos de cuadrados que de franjas. Los huma-nos tendemos a percibir la información visual buscando una suertede “centro de masa” de la misma, o un punto central sobre el que sepueda sacar una conclusión rápida sin tener que explorar el detallecompleto. Los cuadrados tienen esta propiedad, dado que se puedepercibir rápidamente que la figura es cuadrada explorándola visual-mente en cualquier dirección. El rectángulo sin embargo obliga a re-correr la dirección en la que es más largo hasta encontrar el borde.

De acuerdo al análisis anterior sobre la resolución gráfica, los rectán-gulos con relación de aspecto muy alta obligan a dibujar franjas quecorren el riesgo de caer por debajo de la resolución mínima y por endedesperdiciar pixels.

3.3.3. Preservación del orden de los datos

La propiedad de ordenamiento de un treemap es su capacidad de pre-servar en la representación gráfica el orden que pudiera existir en los datosa mostrar.

Al analizar este punto debe tenerse presente el uso que se da a los tree-maps como herramienta de visualización. Schneiderman dice en su paper:


“muchos conjuntos de datos contienen información de ordenación que es útil pa-ra ver patrones o para localizar objetos particulares en el mapa. Por ejemplo, losdatos de bonos descritos en Johnson[1994] están ordenados naturalmente por fe-cha de madurez y tasa de interés. En muchos otros casos, el orden de los datos esalfabético”.

Haciendo foco en los datos que se buscaron representar en este trabajo,se puede ver que en el mapa la información de nombre del símbolo no ge-nera una ordenación que se deba preservar, y lo mismo pasa con la secciónde memoria a la que pertenece cada uno ya que es muy sencillo dibujar unmapa para cada una haciendo uso del campo de filtrado.

En una futura versión del plugin desarrollado sería util poder mostrar elagrupamiento de los símbolos según el archivo en el que fueron declaradosy estos según la biblioteca a la que pertenecen. En ese caso sí sería de interéselegir un algoritmo de treemapping que preservara este orden, pero estaposibilidad queda por fuera del presente trabajo.

3.3.4. Estabilidad de los datos

La estabilidad de los datos se refiere a cuánto cambian de posición losrectángulos en un mapa al cambiar sus datos de entrada. Esto debe pensarsepara el caso de visualizar datos dinámicos como por ejemplo cotizacionesde acciones de la bolsa de valores.

Una buena estabilidad hace que al mirar y asimilar un mapa, si sus da-tos cambian de alguna manera un símbolo representando un valor en par-ticular no se mueva drásticamente en el mapa. Se dice que un algoritmo esinestable cuando un cambio en el tamaño de un rectángulo hace que el mis-mo deba dibujarse en un lugar distinto (imagínese la progresión desde laesquina inferior derecha a la superior izquierda de un rectángulo a medidaque crece en tamaño).

Si bien es una propiedad muy importante, en el trabajo presente los da-tos a representar no tienden a cambiar bruscamente salvo cuando se estáoptimizando la asignación de la memoria.

3.3.5. Algoritmo elegido

Habiendo ponderado las tres propiedades de los cinco algoritmos dis-ponibles, se eligió “Squarified” como el más apropiado por ser el que damejor relación de aspecto. Esta característica se juzgó de mayor importan-cia que las otras dos. En la figura 3.10 se muestra el proceso mediante elcual el algoritmo particiona el espacio disponible en subrectángulos, bus-cando la mejor relación de aspecto y perdiendo cualquier otro orden quelos datos pudieran tener.

3.3. Adopción de un algoritmo de treemapping 27

Figura 3.10: Particionado del espacio disponible en rectán-gulos, según el algoritmo “Squarify”. Figura tomada de [6]

29

Capítulo 4

Ensayos y Resultados

4.1. Precisión del análisis de la tabla de símbolos

El presente trabajo se basó en la siguiente hipótesis: La suma de la tota-lidad de los tamaños en memoria reportados por nm para los símbolos decada sección tiene como resultado el tamaño total ocupado en la memoriadel microcontrolador. Para esta hipótesis se realizó el siguiente ensayo.

4.1.1. Precisión de la identificación de secciones de la herramientanm

Se ha dicho en la subsección 2.2.2 que la herramienta nm asigna unaletra (’t’, ’b’ o ’d’) a cada símbolo que encuentra en su análisis de la ta-bla de símbolos y que cada una corresponde a una sección. En el apéndiceA se presenta un programa de prueba con símbolos de distintos tamañosubicados en las distintas secciones, usado como patrón de referencia paraverificar que el reporte es correcto.

El lector puede buscar la definición de los segmentos .text, .bss y .dataen [2] y [3]. De todos modos se presenta a continuación una breve reseña:

.text Sección de memoria donde se ubican las instrucciones de máquina aejecutar por el microprocesador. Esta sección de memoria no se mo-difica durante la ejecución del programa (existen excepciones a estaregla pero su discusión no es relevante a este ensayo).

.bss Sección de memoria reservada a variables que no tienen un valor ini-cial dado.

.data Sección de memoria reservada a variables que sí tienen un valor ini-cial dado por el programador. Este valor inicial se almacena en la me-moria de programa (sección .text) y tiene un impacto en la misma.

Los valores reportados por el plugin desarrollado se contrastaron con-tra la herramienta “size” [12], cuyo propósito es listar “los tamaños de lassecciones -y el tamaño totalde cada objeto (. . . ) en su lista de argumentos. . . )”.La salida del mismo se muestra en la figura 4.1 como ejemplo, con la salve-dad de que los valores reportados son arbitrarios y no deben tomarse comoparte del ensayo.

El programa de prueba se generó partiendo de un asistente (wizard)para un nuevo proyecto utilizando las librerías LPCOpen en el entornoLPCXpresso 8.1.4, e incluye las librerías estáticas “lpc_chip_ 175x_6x” y“lpc_board_nxp _lpcxpresso_1769”. Luego se declararon las variables ne-cesarias para el ensayo.

De acuerdo a Erich Styger [16], el resultado esperado es el siguiente:

30 Capítulo 4. Ensayos y Resultados

arm-none-eabi-size "TestProject1.axf"text data bss dec hex filename4004 200 8 4212 1074

TestProject1.axf

Figura 4.1: Imagen de la salida del size al analizar el progra-ma de prueba.

En la sección .bss se espera que la suma de los tamaños reportadospor nm ocupe exactamente el tamaño reportado por el comando size.

En la sección .data se espera lo mismo.

En la sección .text hay que ponderar otras cuestiones que ponderar,ya que se sabe que a veces los compiladores organizan las funcionesen direcciones de memoria múltiplo de 2 o 4 para optimizar el accesoa las funciones y sobre esto no se encontró mención en la documen-tación del comando “size”. También hay una situación con las decla-raciones “Weak”, que son funciones definidas con cierto nombre peroque luego el programador puede sobreescribir (es decir, agregar unasegunda definición de esa función) y no está claro cómo se contabilizaesto tampoco.

En este caso, el ensayo consiste en inspeccionar los totales reportadospor el plugin y compararlos contra la salida del comando size.

4.1.2. Resultados del ensayo

La suma de los tamaños de las variables ubicadas en la sección .bss tuvoun error de 3 bytes. Como se puede ver en la figura 4.2, size reportó 172bytes y el plugin identificó lo esperado por el programador que fueron 165.4 de esos 172 se encuentran en la variable SystemCoreClock, que no la de-clara el programador sino una de las librerías que incluye el programa deejemplo.

La figura 4.3 muestra que en la sección .data se encontró la misma dis-crepancia de 3 bytes.

En ambos casos (.bss y .data ) se considera despreciable el error de 3bytes por la siguiente razón: Al trabajar con procesadores con una arqui-tectura de 32 bits, una declaración de variable de tipo int (el valor genéricode un entero sin aplicarle ningún calificador ni modificador) ocupa 4 bytes,por esta razón podría pensarse que 4 bytes es a efectos prácticos la resolu-ción de la medición o la mínima variación del dígito menos significativo.Por lo tanto una discrepancia inferior a 4 bytes no afecta la medición deninguna manera.

La figura 4.4 deja ver que en la sección .text sí se registraron algunasdiscrepancias, a saber:

1. El comando size reportó 4204 bytes.

2. La sumatoria de los tamaños reportados en la sección .text fue de 3846bytes.

4.1. Precisión del análisis de la tabla de símbolos 31

Figura 4.2: Vista de la sumatoria del tamaño de los símbolosen la sección .bss

Figura 4.3: Vista de la sumatoria del tamaño de los símbolosen la sección .data

3. El plugin por ahora no identifica símbolos con el atributo Weak, pe-ro una exploración manual del archivo binario con el comando nmmostró 274 bytes en símbolos con ese atributo.

Obviando las declaraciones “weak”, la diferencia es de 358 bytes o del8,5 %. Si en cambio se suman esos 274 bytes la discrepancia baja a 84 bytes oun 2 %. Debe notarse que la suma reportada por el plugin es en ambos casosmenor a lo reportado por el comando size, con lo cual se puede inferir queel mismo contabiliza otras cosas además de la sumatoria de los símbolosubicados en dicha sección.

No se encontró documentación acerca de cómo exactamente contabilizael tamaño de la sección .text el comando size. Esto impidió incrementar laprecisión del análisis más allá del 8,5 % reportado en este caso. En una fu-tura revisión de este trabajo se puede encontrar esta información haciendo


Figura 4.4: Vista de la sumatoria del tamaño de los símbolosen la sección .text

un análisis del código fuente del mismo, disponible en [8]. Esta posibilidadquedó fuera del presente trabajo debido a limitaciones de tiempo.

Finalmente, se concluye que si bien un 8,5 % de diferencia no es lo bas-tante bueno como para dimensionar un microcontrolador para una aplica-ción, no se afecta el cumplimiento de ninguno de los requerimientos delproyecto.

4.2. Consumo de recursos de hardware causado por elplugin

Otro ensayo que se consideró relevante realizar es evaluar el impactoque el plugin causa en los recursos del computador en uso.

Se midió el tiempo de procesamiento que lleva dibujar el treemap y sedescartó la posibilidad de medir la memoria solicitada por el plugin. Lasaplicaciones en Java se ejecutan en una instancia de la JVM (Máquina Vir-tual Java) con una cantidad de memoria disponible predefinida, y duranteel desarrollo del plugin la misma nunca se agotó. Al no haber sido necesa-rio agrandar la cantidad de memoria disponible para la JVM en cuestión seconcluyó que el consumo de memoria no resulta problemático.

4.2.1. Medición del tiempo de procesamiento

Para esta medición se usa el método “nanoTime” incluído en el lenguajeJava [7]. El mismo “Devuelve el valor actual del temporizador más preciso delsistema, en nanosegundos”.

Este ensayo no buscó una medición exacta sino conocer el orden demagnitud del tiempo invertido para determinar si el uso del plugin entor-pece la labor cotidiana del programador.

El ensayo se realizó en las siguiemtes condiciones:

4.3. Validación con usuarios finales 33

Hardware: Computador portátil Asus K455L [15], al que se agregaron4GB de memoria RAM adicionales para un total de 12Gb y se le re-emplazó el disco rígido mecánico por uno de estado sólido SamsungEVO 850 de 250Gb.

Sistema operativo: Ubuntu Mate 16.04, 64 bits, con el kernel 4.6.0-040600rc6-generic.

Versión de Java: openjdk version “1.8.0_91”.

Versión de Eclipse: Mars 4.5.2.

Se compiló el programa de prueba como figura en el apéndice A.

El procedimiento de ensayo fue el siguiente:

1. Se tomó el tiempo actual del sistema con la funcion nanoTime.

2. Se provocó el redibujo del mapa dentro de un lazo cien veces.

3. Se tomó el tiempo final del ensayo.

4. Se lo dividió por cien.

5. Se repitieron los puntos anteriores 30 veces y se anotaron los resulta-dos.

6. Se buscaron los valores mínimo y máximo.

7. Se sacó el promedio y el desvío estándar.

4.2.2. Resultados del ensayo

Se observaron los siguientes valores (en microsegundos): 453, 612, 436,819, 463, 729, 752, 429, 499, 772, 396, 504, 534, 761, 406, 400 393, 792, 403, 392,409, 408, 395, 393, 389, 395, 436, 476, 392, 390.

Las mediciones presentan un promedio de 501 uS, y un desvío estándarde 147 uS. El valor mínimo es de 389 uS y el máximo es de 819 uS.

El promedio se ponderó contra el tiempo que conlleva el proceso decompilación (en la corrida de prueba fue reportado en 324ms) y resultódespreciable. En segunda instancia se aplicó un criterio más estricto quefue el de redimensionar la ventana que contiene el mapa (esto implica unredibujo de la misma así sea que el tamaño cambia en un solo píxel) y nose observó ningún enlentecimiento de la interfaz. Si bien esta apreciaciónes puramente subjetiva se la puede tomar como un criterio de máxima y elresultado es satisfactorio.

4.3. Validación con usuarios finales

El paso final para la validación de un software nuevo es la llamada“Beta-test”: una prueba previa a su distribución realizada por parte de unamuestra de los usuarios finales. A los usuarios que participan de esta prue-ba se los llama “Beta-testers”.


Se dice que el software está en estado “Beta” cuando no ha sido utiliza-do aún por su público objetivo pero que ya está lo bastante maduro comopara un primer contacto con el mismo. Es fundamental hacer estas prue-bas porque los usuarios no tienen el conocimiento interno del software quetienen los desarrolladores del mismo, y por lo tanto tienen una perspectivaimparcial sobre el uso y capacidades del mismo. De estas pruebas se espe-ra que los testers descubran defectos y/o aporten nuevas perspectivas quehayan escapado a la óptica del programador.

Cuando el software no ha llegado aún a este punto se lo llama “Alfa”.Un software en este estado funciona bien en la medida que lo use una per-sona que conoce los defectos y limitaciones del mismo y lo use dentro deestas.

Tanto en la industria del software como en la comunidad del softwarelibre, se suele buscar que las “Beta-tests” lleguen a la mayor cantidad deusuarios posibles y en algunos casos se pide a los “Beta-testers” que pre-vio a su participación informen algunos datos personales. Esto se hace paratener un volumen significativo de realimentación acerca del uso del soft-ware y poder ponderarlo de acuerdo al perfil de los testers. Si bien este esel procedimiento que aporta mayor valor estadístico, requiere de un equi-po de personas que procese los reportes recibidos y que pueda actuar enconsecuencia. Al ser este un desarrollo académico hecho por un solo pro-gramador se optó en cambio por armar un “focus-group”, o una pequeñamuestra formada por un grupo reducido de usuarios con perfiles bien dife-renciados que represente a un grupo genérico de usuarios.

A quienes se les envió el software para evaluar también se les sugirió elsiguiente cuestionario con impresiones que se buscaban recabar acerca deluso del software:

1. La instalación es confusa o se parece a cualquier otro plugin?

2. En qué variante y versión de Eclipse lo instalaron?

3. Las instrucciones le sirvieron para instalar y usar el software?

4. El uso del software resulta intuitivo?

5. El software le resultó útil?

6. El uso del software hizo que se ponga lento el entorno donde fue ins-talado?

7. Alguna otra impresión que le haya causado?

Los siguientes son los reportes que se alcanzaron a recibir a la fecha decierre de este trabajo, sin ningún orden particular.

4.3.1. Esp. Ing. Pablo Ridolfi

Pablo Ridolfi es Ingeniero en electrónica, graduado de la UTN-FRH.También tiene el título de Especialista en Sistemas Embebidos. Actualmentees coordinador general del proyecto CIAA.

4.3. Validación con usuarios finales 35

1. Tuve que deshabilitar la opción de mostrar por categorías, sino noaparece nada. Salvo eso (fijate si lo podés corregir y te vas a ahorrar unmontón de comentarios tipo "no me aparece nada") instaló perfecto,avisando que no está firmado digitalmente.

2. LPCXpresso v8.1.4 [Build 606] [2016-03-14]

3. Sí, sirvieron, al menos yo lo entendí, pero es obvio que no somos nova-tos. Deberías mandarle esto a un alumno que recién está empezandopara ver si lo puede hacer.

4. Sí, pero idem anterior.

5. Creo que si estuviera justo de recursos y necesito hacer un análisispara priorizarlos me resultaría útil.

6. No.

7. Estaría bueno poder hacer zoom en el treemap. Cuando hay muchaRAM/Flash libre lo demás te queda muy chiquito, aunque se puedendeshabilitar las áreas “Free ROM” y “Free RAM”. Al menos agregaríauna opción tipo toolbar sobre el treemap para deshabilitarlas rápi-damente y ver sólo lo que está ocupando espacio. Por lo demás meparece muy copado lo que hiciste, felicitaciones!

4.3.2. Ing. Mirko Serra

Mirko Serra es Ingeniero en electrónica, graduado de la UTN-FRBA. Sededica al desarrollo de sistemas embebidos en forma independiente.

1. Hay que asegurarse de que no esté tildado Group items by categorypara que lo muestre cuando se instala localmente. En el caso del ser-vidor lo muestra dentro de la categoría ESMP.

2. LPCXpresso v8.1.4 [Build 606] [2016-03-14].

3. Lo quise instalar en el Eclipse que tenía funcionando y no andaba. Re-sulta que es una versión vieja. Me deja instalarlo pero no encontrabael Memory Profiler.

4. No encontré la forma fácil de visibilizar todo de una. Vine a la capturaque me mandaste vos y ahí pude visibilizarlos poniendo en QuickAccess una por una las vistas de Treemap Views, Symbol List, FilteredSymbol List.

5. Resulta MUY práctico el manejo general. Elijo Text y tengo una ideadel uso de memoria (libre vs ocupada); hago click en el cuadradogrande, lo destildo y saqué la memoria libre de la ecuación y puedover el uso desde el programa.

6. No.

7. La pestaña Memory Profiler aparece vacía. Sería bueno que aparecieraconvalores por defecto.

37

Capítulo 5

Conclusiones

5.1. Grado de cumplimiento de los requerimientos delproyecto

Para beneficio del lector se reproducen los 4 objetivos originales del pro-yecto, luego se analiza el grado de cumplimiento de cada uno en particular:

1. Representación visual del uso de la memoria interna del MCU.

2. Fácil identificación de los principales consumos de memoria.

3. Indicación de a qué zona de memoria fue asignada cada variable.

4. Presentación de estos datos dentro de una ventana de Eclipse.

La figura 5.1 muestra el resultado final del plugin y sirve de sustento alanálisis siguiente.

Figura 5.1: Resultado final del desarrollo

5.1.1. Representación visual del uso de la memoria interna delMCU

El primer objetivo se considera perfectamente logrado. Al incluirse unsímbolo representando la memoria disponible (el recuadro oscuro de ma-yor tamaño), al usuario no le quedan dudas de que lo que está mirando

38 Capítulo 5. Conclusiones

inicialmente es la memoria completa del microprocesador, y con esto enmente, se pueden hacer rápida y visualmente varios análisis:

Determinar el grado de ocupación del CPU, algo sumamente útil enel desarrollo para saber si el microprocesador está bien dimensionadopara el desarrollo o si será menester cambiarlo.

Discernir si es provechoso optimizar el uso de memoria de la apli-cación. Se sabe que todo proceso de optimización tiene un punto derendimientos decrecientes, esto es un punto a partir del cuál el tiempoinvertido en mejorarlo rinde menos que los beneficios obtenidos. Enel caso de una aplicación con microprocesador, este es el punto en elque el gasto principal de memoria no está concentrado en unos pocasvariables sino que hay numerosas variables que ocupan 4 o 2 bytescuando podrían haber ocupado 2 o 1.

Si resultara provechoso hacer un proceso de optimización, sería evi-dente el punto de partida del mismo.

5.1.2. Fácil identificación de los principales consumos de memo-ria

El segundo objetivo también se considera logrado al 100 %. El autor con-sidera que la representación visual mediante tamaños relativos es muchomás rápida de asimilar que extraer información numérica de una tabla, ten-ga esta el formato que tenga. Como ejemplo de esto se puede citar el diseñode los tableros de mandos de las aeronaves comerciales, en el que un pilotodebe monitorear una cantidad apreciable de indicadores y por esta razón seprefieren indicadores del tipo de aguja en lugar de indicadores numéricos.Esto último permite hacer una rápida inspección visual y detectar rápida-mente una aguja con una inclinación distinta a las demás.Adicionalmente, el proceso de obtener información numérica para proce-sarla conlleva un pequeño esfuerzo mental que si bien es despreciable encada ocasión, a lo largo de un día completo de trabajo acumula un gastoque redunda en un cansancio adicional y una caída en la productividad delprogramador.

5.1.3. Indicación de a qué zona de memoria fue asignada cada va-riable

El objetivo número 3 también está logrado. Esta información se ve noen los mapas gráficos sino en las listas de símbolos completa y filtrada,ambas tienen una columna llamada “Section” donde se expone el nombrede la sección en la que el compilador ubicó cada símbolo. Este objetivo nose ha logrado en la misma medida que los demás, ya que esta ubicación síse debe obtener de una tabla con los perjuicios mencionados anteriormente.Se podría haber utilizado una segunda paleta de colores para diferenciar lasdistintas secciones en el mapa gráfico, pero se consideró que no reportaríaun beneficio significativo. Esto sumado a la falta de tiempo hizo que estafuncionalidad quedara por fuera del proyecto.

5.2. Próximos pasos 39

5.1.4. Presentación de estos datos dentro de una ventana de Eclip-se

El último objetivo se logró también por completo. La figura 5.1 hablapor sí misma en este punto.

5.2. Próximos pasos

Si bien el proyecto logró sus objetivos iniciales, durante el desarrollose identificaron varias posibilidades de mejora que el tiempo no permitióabordar, pero que de todos modos se listan a continuación con la esperanzade que este trabajo pueda ser continuado por otra persona o por el mismoautor en el camino de una maestría.

Mejorar la precisión de la medición de la sección .text Como se mencionóen la sección 4.1.1 la medición de la ocupación de la memoria de có-digo tiene un error apreciable, pero hay fuentes de información quepermiten seguir investigando este tema cuando el tiempo lo permita.

Extensión al lenguaje C++ El mismo presenta algunos desafíos a la horade identificar los nombres de los símbolos ya que el compilador losdeforma en pos de soportar algunas características avanzadas del len-guaje. Esta dificultad se evitó en esta instancia del trabajo.

Agrupación jerárquica de librerías y módulos El algoritmo actual dibujalos símbolos ordenados por tamaño, sin que se pueda apreciar en quéarchivo fueron declarados. A veces en el desarrollo puede ser útil verla jerarquía de qué símbolos provienen de qué archivos y a su vezqué archivos forman qué bibliotecas de código. Esto se obvió ya queno forma parte de los requerimientos del proyecto, pero resulta unabuena adición en una próxima etapa.

Distribución automatizada En la jerga se le llama a esto “deployment”. Eneste ámbito se refiere al proceso mediante el cual se construye y em-paca el software para su distribución a los usuarios finales del mismo.Actualmente esto se hace con unos cuantos procedimientos manualesque resultan algo tediosos. Se experimentó someramente con progra-mas para hacer la distribución automáticamente pero no se los pudoponer en práctica por falta de tiempo.

Mejorar la integración del plugin con la interfaz de usuario de Eclipse Elprogramador con experiencia en el uso de Eclipse como herramientade programación seguramente notará que si bien el plugin desarro-llado cumple con su función, resuelve algunas cuestiones de formadiferente a lo esperado. Esto se debe a la inexperiencia desarrollan-do plugins del autor de este trabajo (recuérdese que este es el primeroque escribe), en un próximo avance esta situación debería remediarse.

Representación gráfica de vectores y estructuras como mapas anidados Parabeneficio del lector inexperto en software se recuerda que los vectoresson una suerte de listas de elementos donde todos son del mismo ti-po, y que las estructuras son agrupaciones de elementos que pueden

40 Capítulo 5. Conclusiones

ser de distintos tipos. Lo que ambos tienen en común es que son con-juntos de varios elementos, y en su representación en el mapa podríahacerse esta distinción. Esta posibilidad se descartó porque no apor-ta a ninguno de los requerimientos iniciales del proyecto, serviríancomo un refinamiento gráfico.

I18N I18N es una suerte de abreviatura de la palabra inglesa “internatio-nalization” (se cuentan 18 letras entre la ’I’ y la ’N’) y representa elproceso de traducir fácilmente una aplicación a varios idiomas. En elplugin actual no se contempló esta posibilidad sino que se optó porusar el idioma inglés en la interfaz de usuario para llegar a la ma-yor cantidad de usuarios posibles. En un futuro desarrollo se deberíapoder traducir la interfaz de usuario a otros idiomas.

41

Apéndice A

Programa usado para losensayos de medición

42 Apéndice A. Programa usado para los ensayos de medición

2 // Name : T e s t P r o j e c t 1 . c// Author : Ing . Alejandro Celery

4 // Version : 1 . 0// Descr ipt ion : Programa para ensayar mediciones de nm

6

# include " board . h"8 # include <cr_sect ion_macros . h>

# include < s t d i n t . h>10

# def ine N 1012

i n t 8 _ t i n t 8 _ n o I n i t ;14 i n t 1 6 _ t i n t 1 6 _ n o I n i t ;

i n t 3 2 _ t i n t 3 2 _ n o I n i t ;16 i n t 6 4 _ t i n t 6 4 _ n o I n i t ;

18 i n t 8 _ t i n t 8 _ n o I n i t _ v e c 1 0 [N] ;i n t 1 6 _ t i n t 1 6 _ n o I n i t _ v e c 1 0 [N] ;

20 i n t 3 2 _ t i n t 3 2 _ n o I n i t _ v e c 1 0 [N] ;i n t 6 4 _ t i n t 6 4 _ n o I n i t _ v e c 1 0 [N] ;

22

i n t 8 _ t i n t 8 _ i n i t = 0x12 ;24 i n t 1 6 _ t i n t 1 6 _ i n i t = 0 x1234 ;

i n t 3 2 _ t i n t 3 2 _ i n i t = 0 x12345678 ;26 i n t 6 4 _ t i n t 6 4 _ i n i t = 0 x1234567812345678 ;

28 i n t 8 _ t i n t 8 _ i n i t _ v e c 1 0 [N] = { 0x12 } ;i n t 1 6 _ t i n t 1 6 _ i n i t _ v e c 1 0 [N] = { 0 x1234 } ;

30 i n t 3 2 _ t i n t 3 2 _ i n i t _ v e c 1 0 [N] = { 0 x12345678 } ;i n t 6 4 _ t i n t 6 4 _ i n i t _ v e c 1 0 [N] = { 0 x1234567812345678 } ;

32

i n t main ( void ) {34

SystemCoreClockUpdate ( ) ;36 Board_Ini t ( ) ;

Board_LED_Set ( 0 , t rue ) ;38

i n t i = 0 ; //Var iable l o c a l , no s a l e en e l repor te40

while ( 1 ) {42 f o r ( i = 0 ; i < N; ++ i ) {

i f ( i n t 8 _ i n i t > 0 ) i n t 8 _ n o I n i t = 1 ;44 i f ( i n t 1 6 _ i n i t > 0 ) i n t 1 6 _ n o I n i t = 1 ;

i f ( i n t 3 2 _ i n i t > 0 ) i n t 3 2 _ n o I n i t = 1 ;46 i f ( i n t 6 4 _ i n i t > 0 ) i n t 6 4 _ n o I n i t = 1 ;

48 i f ( i n t 8 _ i n i t _ v e c 1 0 [ i ] > 0 ) i n t 8 _ n o I n i t _ v e c 1 0 [ i ] = 1 ;i f ( i n t 1 6 _ i n i t _ v e c 1 0 [ i ] > 0 ) i n t 1 6 _ n o I n i t _ v e c 1 0 [ i ] = 1 ;

50 i f ( i n t 3 2 _ i n i t _ v e c 1 0 [ i ] > 0 ) i n t 3 2 _ n o I n i t _ v e c 1 0 [ i ] = 1 ;i f ( i n t 6 4 _ i n i t _ v e c 1 0 [ i ] > 0 ) i n t 6 4 _ n o I n i t _ v e c 1 0 [ i ] = 1 ;

52 }}

54 re turn 0 ;}

Figura A.1: Programa usado para contrastar los reportes delplugin contra el comando size.

43

Bibliografía

[1] Artículo de Wikipedia sobre Eclipse. [Online]. Disponible: https://es.wikipedia.org/wiki/Eclipse_(software). Fecha deúltima actualización. 2016.

[2] Artículo de Wikipedia sobre el segmento de código. [Online]. Disponible:https://en.wikipedia.org/wiki/Code_segment. Fecha deúltima actualización. 2016.

[3] Artículo de Wikipedia sobre el segmento de datos. [Online]. Disponible:https://en.wikipedia.org/wiki/Data_segment. Fecha deúltima actualización. 2016.

[4] B. B. Bederson, Ben Shneiderman y Martin Wattenberg. «Ordered andQuantum Treemaps: Making Effective Use of 2D Space to DisplayHierarchies». En: ACM Transactions on Graphics 21.12 (oct. de 2002),págs. 833-854. URL: http://portal.acm.org/citation.cfm?doid=571647.571649.

[5] Ben Bederson y Martin Wattenberg. Librería de algoritmos de treemap-ping. [Online]. Disponible: www.cs.umd.edu/hcil/treemap-history/Treemaps-Java-Algorithms.zip.

[6] Mark Bruls, Kees Huizing y Jarke van Wijk. «Squarified Treemaps».En: In Proceedings of the Joint Eurographics and IEEE TCVG Symposiumon Visualization. Press, 1999, págs. 33-42.

[7] Documentación de la clase System, método nanoTime. [Online]. Disponi-ble: http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/System.html. Fecha de consulta. 2016.

[8] Index of /gnu/binutils. [Online]. Disponible: https://ftp.gnu.org/gnu/binutils/. Fecha de consulta. 2016.

[9] Manpage del comando nm. [Online]. Disponible: https://sourceware.org/binutils/docs/binutils/nm.html. Fecha de consulta.2016.

[10] Manpage del comando objdump. [Online]. Disponible: https://sourceware.org/binutils/docs/binutils/objdump.html. Fecha de con-sulta. 2016.

[11] Manpage del comando pahole. [Online]. Disponible: http://linux.die.net/man/1/pahole. Fecha de consulta. 2016.

[12] Manpage del comando size. [Online]. Disponible: https://sourceware.org/binutils/docs/binutils/size.html. Fecha de consulta.2016.

[13] Ben Shneiderman. Treemaps for space-constrained visualization of hierar-chies. [Online]. Disponible: http://www.cs.umd.edu/hcil/treemap-history/. Fecha de primera publicación. 1998.



https://en.wikipedia.org/wiki/Code_segment

https://en.wikipedia.org/wiki/Data_segment

http://portal.acm.org/citation.cfm?doid=571647.571649

http://portal.acm.org/citation.cfm?doid=571647.571649

www.cs.umd.edu/hcil/treemap-history/Treemaps-Java-Algorithms.zip

www.cs.umd.edu/hcil/treemap-history/Treemaps-Java-Algorithms.zip

http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/System.html

http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/System.html

https://ftp.gnu.org/gnu/binutils/

https://ftp.gnu.org/gnu/binutils/

https://sourceware.org/binutils/docs/binutils/nm.html

https://sourceware.org/binutils/docs/binutils/nm.html

https://sourceware.org/binutils/docs/binutils/objdump.html

https://sourceware.org/binutils/docs/binutils/objdump.html

http://linux.die.net/man/1/pahole

http://linux.die.net/man/1/pahole

https://sourceware.org/binutils/docs/binutils/size.html

https://sourceware.org/binutils/docs/binutils/size.html

http://www.cs.umd.edu/hcil/treemap-history/

http://www.cs.umd.edu/hcil/treemap-history/

44 BIBLIOGRAFÍA

[14] Sitio web coolors.co. [Online]. Disponible: https://coolors.co/app. Fecha de consulta. 2016.

[15] Sitio web de Asus, descripción del producto usado para el ensayo. [Onli-ne]. Disponible: https://www.asus.com/latin/Notebooks/X455LJ/specifications/. Fecha de consulta. 2016.

[16] text, data and bss: Code and Data Size Explained. [Online]. Disponible:https://mcuoneclipse.com/2013/04/14/text-data-and-bss-code-and-data-size-explained. Fecha de publicación.2013.

[17] Lars Vogel y Simon Sholz. Eclipse JFace Overview - Tutorial. [Online].Disponible: http://www.vogella.com/tutorials/EclipseJFace/article.html. Fecha de publicación. 2014.

[18] Windirstat. [Online]. Disponible: https://windirstat.info/.

https://coolors.co/app

https://coolors.co/app

https://www.asus.com/latin/Notebooks/X455LJ/specifications/

https://www.asus.com/latin/Notebooks/X455LJ/specifications/

https://mcuoneclipse.com/2013/04/14/text-data-and-bss-code-and-data-size-explained

https://mcuoneclipse.com/2013/04/14/text-data-and-bss-code-and-data-size-explained

http://www.vogella.com/tutorials/EclipseJFace/article.html

http://www.vogella.com/tutorials/EclipseJFace/article.html

https://windirstat.info/

herramienta gráfica para analizar la ocupación de...

Documents