Optimización de código de programa generado por compilador.

Procedimiento para la optimización de código (38) de programa generado por compilador,

que está previsto para un soporte (10) de datos portátil con un núcleo (12) de procesador así como una primera (24) y una segunda zona (26) de almacenamiento,

- en el que la primera zona (24) de almacenamiento está prevista para recibir el código (44) de programa optimizado,

- en el que la segunda zona (26) de almacenamiento está prevista para recibir una biblioteca (28) con una pluralidad de fragmentos (30x) de código de biblioteca,

- en el que en el código (38) de programa generado por compilador se buscan fragmentos (42) de código de programa que, al menos con respecto a su acción, corresponden en cada caso a un fragmento (30x) de código de biblioteca, en el que los fragmentos (42) de código de programa encontrados de este modo se sustituyen por en cada caso una llamada del fragmento (30x) de código de biblioteca correspondiente,

caracterizado porque

la biblioteca está predefinida, de modo que la biblioteca no depende del código de programa procesado en la ejecución de optimización actual y se fija de manera invariable para la segunda zona (26) de almacenamiento, antes de que se optimice el código de programa generado por compilador.

Optimización de código de programa generado por compilador.

La invención se refiere a la programación de soportes de datos portátiles así como a la ejecución de programa por soportes de datos portátiles. Un soporte de datos portátil en el sentido del presente documento puede ser en particular una tarjeta chip (smart card, tarjeta inteligente) en diferentes formas de construcción o un módulo chip.

Los soportes de datos portátiles, tal como son habituales en la actualidad, presentan un núcleo de procesador y varias memorias fabricadas en diferentes tecnologías. En una configuración típica están previstas, por ejemplo, una ROM programada por máscara, una EEPROM programable y borrable eléctricamente y una RAM escribible. La RAM sirve como memoria de trabajo durante la ejecución del programa, mientras que el código de programa que va a ejecutarse por el núcleo de procesador puede estar almacenado en la ROM y/o en la EEPROM. En el apartado 3.4 del libro “Handbuch der Chipkarten” de W. Rankl y W. Effing, Hanser Verlag, 3ª edición 1999, se describen éstas configuraciones y configuraciones similares de soportes de datos portátiles.

Normalmente una celda de memoria en la EEPROM ocupa aproximadamente cuatro veces la superficie de chip de una celda de memoria de ROM. Por tanto, por motivos de ahorro de superficie o de mayor capacidad de memoria disponible con la misma superficie es deseable disponer el código de programa que va a ejecutarse en su mayor parte posible en la ROM. No obstante, el contenido de la ROM programada por máscara debe fijarse ya de manera invariable en la fabricación para grandes números de unidades del soporte de datos. Por el contrario, la EEPROM sólo se escribe al completar e inicializar una serie de soportes de datos o al personalizar los soportes de datos individuales. Por ello, debido a la mayor flexibilidad es ventajoso un almacenamiento del código de programa ejecutable en su mayor parte posible en la EEPROM. Esto se refiere tanto a la programación de menores números de unidades de soportes de datos como a la corrección de errores y la introducción de funciones adicionales en el caso de grandes series.

Por tanto, en la programación de soportes de datos portátiles, por un lado existe el problema de aprovechar la ROM programada por máscara o una memoria comparable en su mayor parte posible y, por otro lado, conseguir una flexibilidad lo más elevada posible para modificaciones de programa y/o para la fabricación de soportes de datos en menores números de unidades.

Según la invención, este problema se soluciona en su totalidad o en parte mediante un procedimiento con las características de la reivindicación 1, un producto de programa informático según la reivindicación 8 y un soporte de datos portátil según la reivindicación 10. Las reivindicaciones dependientes definen configuraciones preferidas de la invención. El orden de enumeración de las etapas en las reivindicaciones de procedimiento no debe entenderse como limitación del alcance de protección. Más bien están previstas configuraciones de la invención en las que estas etapas se realizan en otro orden o total o parcialmente en paralelo o total o parcialmente combinadas.

La invención parte de la idea básica de utilizar, para la optimización del código de programa, una biblioteca predefinida que contiene una pluralidad de fragmentos de código de biblioteca. En la operación de optimización según la invención, en el código de programa que va a optimizarse se buscan a su vez fragmentos de código de programa que, con respecto a su acción o función, corresponden en cada caso a un fragmento de código de biblioteca. Tales fragmentos de código de programa se sustituyen en cada caso por una llamada del fragmento de código de biblioteca correspondiente. El código de programa optimizado se almacena en una primera zona de almacenamiento del soporte de datos (por ejemplo, en la EEPROM) , mientras que la biblioteca está prevista para su almacenamiento en una segunda zona de almacenamiento (por ejemplo, en la ROM) .

La operación de optimización según la invención llevó, en las pruebas llevadas a cabo por los inventores, a una reducción considerable del tamaño del código de programa previsto para la primera zona de almacenamiento. Este resultado es sorprendente porque de manera intuitiva se supondría que con un volumen realista de la biblioteca sólo se obtendrían unas pocas coincidencias de partes del código de programa con los fragmentos de código de biblioteca.

La reducción del tamaño de código provocada por la invención tiene como consecuencia que con un soporte de datos con un equipamiento de memoria predeterminado pueden recibirse códigos de programa para funciones adicionales en la primera zona de almacenamiento. En caso de que la primera zona de almacenamiento esté configurada como EEPROM o en una tecnología comparable, entonces este código de programa sólo tiene que cargarse al completar o inicializar o personalizar el soporte de datos. Por tanto, una modificación o nueva generación del código de programa, que por su compacidad implementa un gran número de funciones, en primer lugar es rápida y en segundo lugar ya es posible para pequeños números de unidades de soportes de datos o incluso para soportes de datos individuales.

La biblioteca predefinida se encuentra según la invención en la segunda zona de almacenamiento, esto es, por ejemplo, en la ROM programada por máscara. Por regla general, el ahorro de código de programa conseguido mediante la optimización según la invención es menor que el tamaño de la biblioteca. Sin embargo, también en este caso es ventajosa la utilización de la invención, porque la primera zona de almacenamiento valiosa se aprovecha mejor. En caso de que en el código de programa generado por compilador se encuentren muchos fragmentos de código que en cada caso pueden sustituirse por grupos por en cada caso un único fragmento de código de la biblioteca, y en caso de que la biblioteca sólo contenga unos pocos fragmentos de código no necesarios, el código de programa, mediante la optimización, puede disminuir incluso en más de la longitud de biblioteca. En este caso, el uso de la invención es ventajoso incluso cuando la primera y la segunda zona de almacenamiento sólo son segmentos conceptuales del mismo campo de memoria físico.

Según la invención, para la optimización se buscan fragmentos de código de programa, es decir, segmentos en el código de programa generado por compilador que pueden sustituirse por fragmentos de código de biblioteca correspondientes. En la creación del programa, el programador no tiene que tener en cuenta esta operación de optimización posterior; en particular, no es necesario que prevea en el programa llamadas de rutinas de biblioteca. Por tanto, el desarrollo del programa no se ve dificultado de ningún modo por la invención.

En la terminología utilizada en el presente documento, los términos “código de programa” o “fragmento de código” se referirán tanto a código de máquina ejecutable antes o después del enlace como al código fuente de ensamblador correspondiente. Dicho de otro modo, en diferentes configuraciones de la invención, la operación de optimización según la invención puede llevarse a cabo tanto basándose en el código fuente de ensamblador generado por compilador como basándose en el código de máquina ya ensamblado. En el caso mencionado en primer lugar, el ensamblaje y dado el caso el enlace sólo se producen tras la optimización. La biblioteca, durante la optimización, también puede estar presente como código fuente de ensamblador y/o como código de máquina ya ensamblado.

En general, una sustitución de un fragmento de código de programa por un fragmento de código de biblioteca siempre es posible cuando ambos fragmentos de código ejecutan funciones mutuamente correspondientes. En este caso pueden llevarse a cabo cálculos complejos con respecto a las acciones precisas de los fragmentos de código para, por ejemplo, activar una operación de sustitución también cuando instrucciones individuales en los fragmentos de código están cambiadas de manera no perjudicial. Por el contrario, en ejemplos de realización especialmente sencillos, sólo se lleva a cabo una sustitución cuando los fragmentos de código son idénticos con respecto al código de máquina definido por los mismos. Sin embargo, también en esta configuración sencilla es necesario un cierto análisis de los fragmentos de código, porque por regla general no debe sustituirse por ejemplo un fragmento de código que presenta un salto con un destino de salto que no está situado en el fragmento de código.

Se obtienen posibilidades... [Seguir leyendo]

1. Procedimiento para la optimización de código (38) de programa generado por compilador, que está previsto para un soporte (10) de datos portátil con un núcleo (12) de procesador así como una primera (24) y una segunda zona (26) de almacenamiento,

- en el que la primera zona (24) de almacenamiento está prevista para recibir el código (44) de programa optimizado,

- en el que la segunda zona (26) de almacenamiento está prevista para recibir una biblioteca (28) con una pluralidad de fragmentos (30x) de código de biblioteca,

- en el que en el código (38) de programa generado por compilador se buscan fragmentos (42) de código de programa que, al menos con respecto a su acción, corresponden en cada caso a un fragmento (30x) de código de biblioteca, en el que los fragmentos (42) de código de programa encontrados de este modo se sustituyen por en cada caso una llamada del fragmento (30x) de código de biblioteca correspondiente,

caracterizado porque la biblioteca está predefinida, de modo que la biblioteca no depende del código de programa procesado en la ejecución de optimización actual y se fija de manera invariable para la segunda zona (26) de almacenamiento, antes de que se optimice el código de programa generado por compilador.

2. Procedimiento según la reivindicación 1, caracterizado porque se sustituye un fragmento (42) de código de programa por un fragmento (30x) de código de biblioteca sólo cuando ambos fragmentos (42, 30x) de código son idénticos en su forma como código de máquina ejecutable.

3. Procedimiento según la reivindicación 1, caracterizado porque al menos algunos fragmentos (30x) de código de biblioteca están parametrizados.

4. Procedimiento según una de las reivindicaciones 1 a 3, caracterizado porque un fragmento (42) de código de programa que va a sustituirse se sustituye al menos cuando no interviene en el flujo de programa por una instrucción

(46) de llamada de subrutina para el fragmento (30x) de código de biblioteca correspondiente.

5. Procedimiento según una de las reivindicaciones 1 a 4, caracterizado porque el código (38) de programa generado por compilador está presente en forma de código fuente de ensamblador, y porque la operación de optimización se realiza a nivel de código fuente.

6. Procedimiento según una de las reivindicaciones 1 a 5, caracterizado porque la biblioteca (28) predefinida está adaptada al hardware del soporte (10) de datos portátil y/o a un sistema operativo del soporte (10) de datos portátil y/o a un compilador (36) utilizado en la generación del código (38) de programa generado por compilador.

7. Procedimiento según una de las reivindicaciones 1 a 6, caracterizado porque la primera zona (24) de almacenamiento puede programarse eléctricamente, y/o porque la segunda zona (26) de almacenamiento puede programarse por máscara, y/o porque la primera zona (24) de almacenamiento en el soporte (10) de datos portátil requiere más superficie de chip por celda de memoria que la segunda zona (26) de almacenamiento.

8. Producto de programa informático con instrucciones de programa para un ordenador de propósito general, que hacen que el ordenador de propósito general ejecute un procedimiento según una de las reivindicaciones 1 a 7.

9. Producto de programa informático según la reivindicación 8, caracterizado porque las instrucciones de programa implementan además un compilador (36) para convertir un código (34) fuente de alto nivel en el código (38) de programa generado por compilador.

10. Soporte (10) de datos portátil con un núcleo (12) de procesador, una primera zona (24) de almacenamiento y una segunda zona (26) de almacenamiento, en el que en la primera zona (24) de almacenamiento está contenido un código (44) de programa optimizado, que se generó mediante un procedimiento según una de las reivindicaciones 1 a 7, y en la segunda zona (26) de almacenamiento está contenida una biblioteca (28) predefinida independientemente del código (44) de programa optimizado con una pluralidad de fragmentos (30x) de código de biblioteca.