ES2963352T3

ES2963352T3 - Mantenimiento de la compatibilidad para funciones complejas a lo largo de múltiples generaciones de máquina

Info

Publication number: ES2963352T3
Application number: ES20707213T
Authority: ES
Inventors: Matthias Klein; Bruce Giamei; Anthony Sofia; Mark Farrell; Scott Swaney; Timothy Slegel
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2019-02-27
Filing date: 2020-02-20
Publication date: 2024-03-26
Anticipated expiration: 2040-02-20
Also published as: WO2020173808A1; US11226839B2; HUE063682T2; JP2022522113A; EP3931693B1; JP7430195B2; KR20210118094A; US20200272491A1; EP3931693A1; EP3931693C0; PL3931693T3; SG11202105494SA; CN113454593A

Abstract

Un sistema que incluye una pluralidad de máquinas incluye una máquina de primera generación y una máquina de segunda generación. Cada una de la pluralidad de máquinas incluye una versión de máquina. La máquina de primera generación ejecuta una primera máquina virtual y un nivel de arquitectura virtual. La máquina de segunda generación ejecuta una segunda máquina virtual y el nivel de arquitectura virtual. El nivel de arquitectura virtual proporciona un nivel de compatibilidad para una instrucción interrumpible compleja para la primera y segunda máquinas virtuales. El nivel de compatibilidad está diseñado para una versión de máquina con el mínimo común denominador en la pluralidad de máquinas. El nivel de compatibilidad incluye un indicador del mínimo común denominador que identifica la versión de la máquina con el mínimo común denominador. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Mantenimiento de la compatibilidad para funciones complejas a lo largo de múltiples generaciones de máquina

Antecedentes

La presente invención se refiere en general al mantenimiento de la compatibilidad para funciones complejas a lo largo de múltiples generaciones de máquina.

Con respecto a permitir la migración de cargas de trabajo entre máquinas de diferentes generaciones de máquina, cada máquina debe poder continuar el trabajo iniciado por otra máquina. Por ejemplo, cuando se ejecuta en un entorno en el que un sistema puede migrar entre diferentes ordenadores, es necesario que haya un nivel de arquitectura común entre esos entornos. Para instrucciones con formatos de bloques de parámetros complejos que pueden cambiar entre arquitecturas, una máquina debe poder crear y consumir el formato de bloques de parámetros de cada generación anterior utilizando ese nivel de arquitectura común entre esos entornos. Sin embargo, crear y consumir el formato de bloques de parámetros de cada generación anterior puede producir complejidad en la implementación y la verificación. Por ejemplo, para una instrucción compleja que puede ver una definición de bloques de parámetros diferentes a lo largo de cinco generaciones, la máquina de última generación necesita entender y producir cinco bloques de parámetros diferentes. El documento US20110320825A1 describe una función instalada seleccionada de una instrucción multifunción que está oculta de tal manera que, aunque un procesador sea capaz de realizar la función instalada oculta, la disponibilidad de la función oculta está oculta de tal modo que, en respuesta a la instrucción multifunción que consulta la disponibilidad de las funciones, solo las funciones no ocultas se notifican como instaladas. El documento US8701109B1 describe tecnologías para garantizar que los datos almacenados a largo plazo sean accesibles en el futuro. Al almacenar los datos en un almacenamiento a largo plazo, se crea una instancia bien definida de recursos de procesamiento de datos en una plataforma informática anfitriona para la instalación y prueba de una aplicación relacionada que sea capaz de acceder a los datos almacenados. Una vez completadas las pruebas de la aplicación relacionada, se genera una imagen de máquina a partir de la instancia y se almacena con los datos en el almacenamiento a largo plazo. Si se requiere el acceso a los datos almacenados en el almacenamiento a largo plazo en una fecha futura, se pueden recuperar los datos y la imagen de la máquina asociada, y se puede crear una instancia compatible de recursos de procesamiento de datos en la que se puede restaurar la imagen de la máquina. A continuación, las aplicaciones relacionadas que se ejecutan en la instancia recién creada pueden acceder a los datos del almacenamiento a largo plazo. El documento US20150066878A1 describe una estrategia en la que un acelerador dehardwarerecibe una solicitud para descomprimir un flujo de datos que incluye múltiples bloques dedeflatey múltiples elementos dedeflatecomprimidos de acuerdo con la información de configuración de compresión específica del bloque. El acelerador dehardwareidentifica un punto de compromiso que se basa en una interrupción de una primera sesión de descompresión del flujo de datos y corresponde a uno de los bloques de deflate. Como tal, el acelerador dehardwareconfigura un motor de descompresión en función de la información de configuración del bloque de deflate correspondiente y, a su vez, reanuda la descompresión del flujo de datos en una ubicación de bits de entrada correspondiente al punto de compromiso.

Compendio

De acuerdo con realizaciones de la presente invención se proporciona un sistema que incluye una pluralidad de máquinas. La pluralidad de máquinas incluye una máquina de primera generación y una máquina de segunda generación. Cada una de la pluralidad de máquinas incluye una versión de máquina. La máquina de primera generación ejecuta una primera máquina virtual y un nivel de arquitectura virtual. La máquina de segunda generación ejecuta una segunda máquina virtual y el nivel de arquitectura virtual. El nivel de arquitectura virtual proporciona un nivel de compatibilidad para una instrucción interrumpible compleja para la primera y la segunda máquinas virtuales. El nivel de compatibilidad está diseñado para una versión de máquina con el mínimo común denominador en la pluralidad de máquinas. El nivel de compatibilidad incluye un indicador de mínimo común denominador que identifica la versión de máquina de mínimo común denominador. La instrucción interrumpible compleja comprende un estado que se ha de guardar y que cumple con un formato de bloques de parámetros. El nivel de compatibilidad comprende un formato de bloques de parámetros asociado con el indicador de mínimo común denominador. Los efectos y beneficios técnicos de realizaciones de la presente memoria pueden incluir cuando, para una instrucción/función compleja, cada generación de máquinas solo admite como máximo dos bloques de parámetros diferentes (su propio bloque de parámetros y un nivel de compatibilidad), la verificación y la validación se reducen a probar solo con la versión actual y de compatibilidad de los bloques de parámetros.

El nivel de compatibilidad incluye un formato de bloques de parámetros local para la instrucción interrumpible compleja para cada una de la pluralidad de máquinas, diseñándose el formato de bloques de parámetros local para la versión de máquina local para cada una de la pluralidad de máquinas.

El indicador de mínimo común denominador es generado por una máquina de la pluralidad de máquinas para ejecutar primero la instrucción interrumpible compleja.

El indicador de mínimo común denominador se propaga desde una máquina de la pluralidad de máquinas para ejecutar primero la instrucción interrumpible compleja a un número restante de la pluralidad de máquinas. Los efectos y beneficios técnicos de realizaciones de la presente memoria pueden incluir, para la primera generación, que su formato de bloques de parámetros represente el formato de “génesis” y solo es necesario admitir/probar un formato. Por lo tanto, el contenido de bloques de parámetros específico de cualquier máquina de generación posterior se puede optimizar para esta máquina sin crear un impacto posterior para las generaciones futuras de máquinas.

De acuerdo con una o más realizaciones de la presente invención o cualquiera de las anteriores realizaciones del sistema, el indicador del mínimo común denominador dentro del nivel de compatibilidad se controla a través de una serie de bits de instalación que identifican qué funciones están disponibles en una máquina virtual particular.

De acuerdo con una o más realizaciones de la presente invención o cualquiera de las anteriores realizaciones del sistema, la instrucción interrumpible compleja incluye una instrucción de Llamada de Conversión DEFLATE.

De acuerdo con una o más realizaciones de la presente invención o cualquiera de las anteriores realizaciones del sistema, la instrucción interrumpible compleja incluye una instrucción de un conjunto complejo de instrucciones que se ejecutan en un acelerador.

De acuerdo con una o más realizaciones de la presente invención, cualquiera de las anteriores realizaciones del sistema puede implementarse como un método o un producto de programa informático.

De acuerdo con una o más realizaciones se proporciona un método que implementa una instrucción interrumpible compleja mediante una primera máquina e indica en un nivel de arquitectura virtual que un bloque de parámetros de la primera máquina es compatible con la instrucción interrumpible compleja. La instrucción interrumpible compleja comprende un estado que se ha de guardar y cumple con un formato de bloques de parámetros. El nivel de compatibilidad comprende un formato de bloques de parámetros asociado con el indicador de mínimo común denominador. Los efectos y beneficios técnicos de realizaciones de la presente memoria pueden incluir reducir la verificación y la validación para las pruebas con una versión actual y de compatibilidad del bloque de parámetros.

El método incluye identificar el bloque de parámetros de la primera máquina como el mínimo común denominador en todas las versiones de máquina del complejo y propagar el bloque de parámetros de la primera máquina a la nueva máquina.

De acuerdo con una o más realizaciones de la presente invención, cualquiera de las anteriores realizaciones del método puede implementarse como un sistema o un producto de programa informático.

A través de las técnicas de la presente descripción se obtienen características y ventajas adicionales. En la presente memoria se describen detalladamente realizaciones y aspectos de la invención y se consideran parte de la invención reivindicada. Para un mejor entendimiento, véanse la descripción detallada y los dibujos.

Breve descripción de los dibujos

Los detalles de los derechos exclusivos descritos en la presente memoria se señalan particularmente y se reivindican claramente en las reivindicaciones al final de la memoria descriptiva. Las anteriores y otras características y ventajas de las realizaciones de la invención son evidentes a partir de la siguiente descripción detallada tomada junto con los dibujos adjuntos, en los que:

la FIG. 1A representa un ejemplo de un entorno informático para incorporar y usar uno o más aspectos de la presente invención;

la FIG. 1B representa detalles adicionales de un procesador de la FIG. 1A, de acuerdo con uno o más aspectos de la presente invención;

la FIG. 2 representa otro ejemplo de un entorno informático para incorporar y usar uno o más aspectos de la presente invención;

la FIG. 3A representa un formato de una instrucción de Llamada de Conversión DEFLATE (DFLTCC), de acuerdo con un aspecto de la presente invención;

la FIG. 3B representa un ejemplo de campos de un registro implícito, el registro general 0, utilizado por la instrucción de Llamada de Conversión DEFLATE, de acuerdo con un aspecto de la presente invención;

la FIG. 3C representa un ejemplo de códigos de función para la instrucción de Llamada de Conversión DEFLATE, de acuerdo con un aspecto de la presente invención;

la FIG. 3D representa un ejemplo de un campo de un registro implícito, el registro general 1, utilizado por la instrucción de Llamada de Conversión DEFLATE, de acuerdo con un aspecto de la presente invención;

la FIG. 3E representa un ejemplo de contenido de un registro, R1, especificado por la instrucción de Llamada de Conversión DEFLATE, de acuerdo con un aspecto de la presente invención;

la FIG. 3F representa un ejemplo de contenido de un registro, R1 1, usado por la instrucción de Llamada de Conversión DEFLATE, de acuerdo con un aspecto de la presente invención;

la FIG. 3G representa un ejemplo de contenido de un registro, R2, especificado por la instrucción de Llamada de Conversión DEFLATE, de acuerdo con un aspecto de la presente invención;

la FIG. 3H representa un ejemplo de contenido de un registro, R2 1, usado por la instrucción de Llamada de Conversión DEFLATE, de acuerdo con un aspecto de la presente invención;

la FIG. 3I representa un ejemplo de contenido de un registro, R3, especificado por la instrucción de Llamada de Conversión DEFLATE, de acuerdo con un aspecto de la presente invención;

la FIG. 3J representa un ejemplo de contenido de un bloque de parámetros utilizado por la función DFLTCC-QAF (consultar funciones disponibles) de la instrucción de Llamada de Conversión DEFLATE, de acuerdo con un aspecto de la presente invención;

la FIG. 3K representa un ejemplo de contenido de un bloque de parámetros utilizado por la función DFLTCC-GDHT (generar tabla de Huffman dinámica) de la instrucción de Llamada de Conversión DEFLATE, de acuerdo con un aspecto de la presente invención;

la FIG. 3L representa un ejemplo de contenido de un bloque de parámetros usado por las funciones DFLTCC-CMPR (comprimir) y DFLTCC-XPND (expandir) de la instrucción de Llamada de Conversión DEFLATE,

de acuerdo con un aspecto de la presente invención;

la FIG. 4 representa un ejemplo de un límite de subbytes, de acuerdo con uno o más aspectos de la presente invención;

las FIGS. 5A-5C representan ejemplos que ilustran cómo se aplica un límite de subbytes a la función DFTLCC-CMPR, de acuerdo con un aspecto de la presente invención;

la FIG. 6 representa un ejemplo de un bloque de datos sin compresión, de acuerdo con un aspecto de la presente invención;

la FIG. 7 representa un ejemplo de un bloque con datos comprimidos que usa una tabla de Huffman fija (FHT), de acuerdo con un aspecto de la presente invención;

la FIG. 8 representa un ejemplo de un bloque con datos comprimidos que usa una tabla de Huffman dinámica (DHT), de acuerdo con un aspecto de la presente invención;

la FIG. 9 representa un ejemplo de un conjunto de datos comprimidos en almacenamiento, de acuerdo con un aspecto de la presente invención;

la FIG. 10 representa un ejemplo de una muestra de un programa que comprime datos en tres bloques de un conjunto de datos comprimidos, de acuerdo con un aspecto de la presente invención;

la FIG. 11 representa un ejemplo de contenido de un bloque de parámetros para una función DFLTCC-CMPR que funciona en un primer bloque de datos comprimido de un conjunto, de acuerdo con un aspecto de la presente invención;

la FIG. 12 representa un ejemplo de contenido de un bloque de parámetros para una función DFLTCC-CMPR que funciona en un segundo bloque de datos comprimido de un conjunto, de acuerdo con un aspecto de la presente invención;

la FIG. 13 representa un ejemplo de una muestra de un programa que descomprime datos de un conjunto de datos comprimidos, de acuerdo con un aspecto de la presente invención;

las FIGS. 14A-14C representan ejemplos de una memoria intermedia de historial en línea antes y después de ejecutar DFLTCC-CMPR varias veces, de acuerdo con un aspecto de la presente invención;

las FIGS. 15A-15E representan ejemplos de una memoria intermedia de historial circular antes y después de ejecutar DFLTCC varias veces, de acuerdo con un aspecto de la presente invención;

las FIGS. 16A-16C representan ejemplos de una memoria intermedia de historial en línea antes y después de ejecutar DFLTCC-XPND varias veces, de acuerdo con un aspecto de la presente invención;

la FIG. 17 representa un ejemplo de uso de la instrucción de Llamada de Conversión DEFLATE, de acuerdo con un aspecto de la presente invención;

la FIG. 18 representa un ejemplo del uso de una memoria intermedia de historial circular, de acuerdo con un aspecto de la presente invención;

la FIG. 19 representa un sistema de acuerdo con realizaciones de la presente invención;

la FIG. 20 representa un flujo de proceso de acuerdo con realizaciones de la presente invención;

la FIG. 21 representa un sistema de acuerdo con realizaciones de la presente invención; y

la FIG. 22 representa un sistema de procesamiento de acuerdo con una o más realizaciones.

Los diagramas representados en la presente memoria son ilustrativos. Puede haber muchas variaciones en los diagramas o las operaciones descritas en los mismos sin salir del alcance de la invención. Además, el término “acoplado” y variaciones del mismo describen que existe una ruta de comunicaciones entre dos elementos y no implica una conexión directa entre los elementos sin elementos/conexiones intermedios entre ellos. Todas estas variaciones se consideran parte de la memoria descriptiva.

En las figuras adjuntas y en la siguiente descripción detallada de las realizaciones divulgadas, los diversos elementos ilustrados en las figuras están provistos de números de referencia de dos o tres dígitos. Con excepciones menores, el o los dígitos más a la izquierda de cada número de referencia corresponden a la figura en la que su elemento se ilustra por primera vez.

Descripción detallada

De acuerdo con una o más realizaciones, la presente invención se refiere a un nivel de arquitectura virtual que incluye un nivel de compatibilidad para una instrucción interrumpible compleja de modo que cualquier máquina virtual pueda utilizar la instrucción interrumpible compleja. A este respecto, el nivel de compatibilidad está diseñado para una versión de máquina con el mínimo común denominador en todas las máquinas virtuales, con un indicador del mínimo común denominador que identifica esta versión de máquina.

De acuerdo con un aspecto de la presente invención se proporciona una capacidad para facilitar el procesamiento dentro de un entorno informático. Como ejemplo se proporciona una única instrucción (por ejemplo, una única instrucción de máquina dehardwarediseñada en la interfaz dehardware/software)para realizar una función (también denominada operación), tal como una función de compresión o descompresión, para comprimir y/o descomprimir datos. La instrucción forma parte de una arquitectura de conjunto de instrucciones de procesador (ISA) de propósito general, que se envía mediante un programa (por ejemplo, un sistema operativo o un programa de usuario) en el procesador de uso general. Al utilizar una instrucción ISA para realizar la compresión/descompresión, el sistema operativo no necesita conmutadores de tareas para realizar las operaciones de compresión/descompresión, lo que ahorra ciclos de ejecución. Además, al usar una única instrucción para comprimir y/o descomprimir datos, se reduce el tiempo de ejecución dentro de un procesador, tal como un procesador de uso general.

En un ejemplo, la instrucción realiza operaciones de compresión y descompresión que cumplen con un estándar industrial, denominado estándar DEFLATE, y la instrucción se designa como instrucción de Llamada de Conversión DEFLATE. El estándar DEFLATE incluye descripciones de símbolos de datos comprimidos que representan cadenas duplicadas en la forma original de los datos (en la forma no comprimida de los datos). Dichos símbolos incluyen un puntero y una longitud de una cadena duplicada que describen la ubicación y la longitud de la cadena duplicada, que se procesó previamente, en relación con la ubicación actual de los datos que se están procesando. La forma descomprimida previamente procesada de los datos se designa como historial. En un ejemplo, el historial es un número contiguo de bytes en la memoria, que puede ser tan grande como, por ejemplo, 32 K-bytes.

Con referencia a la FIG. 1A se describe una realización de un entorno informático para incorporar y usar uno o más aspectos de la presente invención. Un entorno informático 100 incluye, por ejemplo, un procesador 102 (por ejemplo, una unidad central de procesamiento), una memoria 104 (por ejemplo, memoria principal, también conocida como memoria de sistema, almacenamiento principal, almacenamiento central, almacenamiento) y uno o más dispositivos de entrada/salida (I/O) y/o interfaces 106 acoplados entre sí mediante, por ejemplo, uno o más buses 108 y/u otras conexiones.

En un ejemplo, el procesador 102 se basa en la arquitectura dehardwarez/Architecture® ofrecida por International Business Machines Corporation, Armonk, Nueva York, y forma parte de un servidor, tal como un servidor IBM Z®, que también ofrece International Business Machines Corporation e implementa la arquitectura dehardwarez/Architecture. Una realización de la arquitectura dehardwarez/Architecture se describe en una publicación titulada “z/Architecture Principles of Operation”, publicación de IBM n.° SA22-7832-11, 12a edición, septiembre de 2017. Sin embargo, la arquitectura dehardwarez/Architecture es solo un ejemplo de arquitectura; otras arquitecturas y/u otros tipos de entornos informáticos pueden incluir y/o usar uno o más aspectos de la presente invención. En un ejemplo, el procesador ejecuta un sistema operativo, tal como el sistema operativo z/OS®, también ofrecido por International Business Machines Corporation.

El procesador 102 incluye una pluralidad de componentes funcionales utilizados para ejecutar instrucciones. Como se representa en la FIG. 1B, estos componentes funcionales incluyen, por ejemplo, un componente 120 de búsqueda de instrucciones para buscar instrucciones que han de ser ejecutadas; una unidad 122 de descodificación de instrucciones para descodificar las instrucciones buscadas y obtener operandos de las instrucciones descodificadas; un componente 124 de ejecución de instrucciones para ejecutar las instrucciones descodificadas; un componente 126 de acceso a memoria para acceder a la memoria para la ejecución de instrucciones, si es necesario; y un componente 130 de reescritura para proporcionar los resultados de las instrucciones ejecutadas. Uno o más de estos componentes pueden, de acuerdo con uno o más aspectos de la presente invención, incluir al menos una parte de o tener acceso a uno o más componentes adicionales usados en el procesamiento de compresión/descompresión (u otro procesamiento que pueda usar uno o más aspectos de la presente invención), tal como se describe en la presente memoria. El o los componentes adicionales incluyen, por ejemplo, un componente 136 de compresión/descompresión (u otro componente).

Otro ejemplo de un entorno informático para incorporar y usar uno o más aspectos de la presente invención se describe con referencia a la FIG. 2. En un ejemplo, el entorno informático se basa en la arquitectura dehardwarez/Architecture; sin embargo, el entorno informático puede basarse en otras arquitecturas ofrecidas por International Business Machines Corporation u otros.

Con referencia a la FIG. 2, en un ejemplo, el entorno informático incluye un complejo electrónico central (CEC) 200. El CEC 200 incluye una pluralidad de componentes, tales como, por ejemplo, una memoria 202 (también conocida como memoria del sistema, memoria principal, almacenamiento principal, almacenamiento central, almacenamiento) acoplada a uno o más procesadores (también conocidos como unidades 204 centrales de procesamiento (CPU)) y a un subsistema 206 de entrada/salida.

La memoria 202 incluye, por ejemplo, una o más particiones lógicas 208, un hipervisor 210 que gestiona las particiones lógicas y elfirmware212 del procesador. Un ejemplo de hipervisor 210 es el hipervisor Processor Resource/System Manager (PR/SM™), ofrecido por International Business Machines Corporation, Armonk, Nueva York. Tal como se usa en la presente memoria, elfirmwareincluye, por ejemplo, el microcódigo del procesador. Incluye, por ejemplo, las instrucciones de nivel dehardwarey/o las estructuras de datos utilizadas en la implementación del código máquina de nivel superior. En una realización incluye, por ejemplo, un código exclusivo que normalmente se entrega como un microcódigo que incluyesoftwarefiable o un microcódigo específico para elhardwaresubyacente y controla el acceso del sistema operativo alhardwaredel sistema.

Cada partición lógica 208 es capaz de funcionar como un sistema independiente. Es decir, cada partición lógica se puede restablecer de forma independiente, ejecutar un sistema operativo invitado 220, tal como un sistema operativo z/OS, u otro sistema operativo, y operar con diferentes programas 222. Un sistema operativo o un programa de aplicación que se ejecuta en una partición lógica parece tener acceso a un sistema entero y completo, pero en realidad solo una parte de él está disponible.

La memoria 202 está acoplada a los procesadores (por ejemplo, las CPU) 204, que son recursos de procesadores físicos que pueden asignarse a las particiones lógicas. Por ejemplo, una partición lógica 208 incluye uno o más procesadores lógicos, cada uno de los cuales representa la totalidad o una parte de un recurso 204 de procesador físico que puede asignarse dinámicamente a la partición lógica.

Además, la memoria 202 está acoplada al subsistema 206 de I/O. El subsistema 206 de I/O puede formar parte del complejo electrónico central o estar separado del mismo. Dirige el flujo de información entre el almacenamiento principal 202 y las unidades 230 de control de entrada/salida y los dispositivos 240 de entrada/salida (I/O) acoplados al complejo electrónico central.

Se pueden usar muchos tipos de dispositivos de I/O. Un tipo particular consiste en un dispositivo 250 de almacenamiento de datos. El dispositivo 250 de almacenamiento de datos puede almacenar uno o más programas 252, una o más instrucciones 254 de programa legibles por ordenador y/o datos, etc. Las instrucciones de programa legibles por ordenador pueden configurarse para llevar a cabo funciones de realizaciones de aspectos de la invención.

Como ejemplo, cada procesador 204 incluye al menos una memoria caché 260 (por ejemplo, una memoria caché local) de una jerarquía de memoria caché que incluye una pluralidad de niveles de memoria caché, que incluyen una o más memorias caché locales y/o una o más memorias caché compartidas. Además, en una realización, las memorias caché locales y la memoria 202 están acopladas a un componente 262 de compresión/descompresión (u otro componente) utilizado para realizar una o más operaciones de compresión y/o descompresión de datos (y/u otras operaciones de uno o más aspectos de la presente invención). En varios ejemplos, puede haber uno o más componentes que realicen estas tareas. Son posibles muchas variaciones.

En una realización, un procesador (por ejemplo, el procesador 204) obtiene la instrucción (por ejemplo, la instrucción de Llamada de Conversión DEFLATE), descodifica la instrucción, realiza la configuración de la instrucción, incluyendo la traducción de las direcciones que han de ser utilizadas por la instrucción, y envía comandos para la instrucción a un componente acoplado al procesador, como el componente 262, para realizar una función especificada por la instrucción. El componente 262 tiene acceso a la jerarquía de caché y a la memoria, de modo que, al realizar la función especificada, lee datos, los procesa y almacena los datos procesados. Como ejemplo, el componente 262 es un componente dehardware.

En otra realización, al menos una parte del componente 262 está incluida como parte del procesador. Son posibles muchas variaciones.

El complejo electrónico central 200 puede incluir y/o estar acoplado a medios de almacenamiento de sistemas informáticos extraíbles/no extraíbles, volátiles/no volátiles. Por ejemplo, puede incluir y/o estar acoplado a un medio magnético no extraíble y no volátil (normalmente denominado “disco duro”), una unidad de disco magnético para leer y escribir en un disco magnético extraíble y no volátil (por ejemplo, un “disquete”) y/o una unidad de disco óptico para leer o escribir en un disco óptico extraíble y no volátil, tal como un CD-ROM, DVD-ROM u otros medios ópticos. Debe entenderse que podrían usarse otros componentes dehardwarey/osoftwarejunto con el complejo electrónico central 200. Los ejemplos incluyen, pero no se limitan a: microcódigo, controladores de dispositivos, unidades de procesamiento redundantes, matrices de unidades de disco externas, sistemas RAID, unidades de cinta y sistemas de almacenamiento de archivos de datos, etc.

Además, el complejo electrónico central 200 puede funcionar con muchos otros entornos o configuraciones de sistemas informáticos de uso general o de propósito especial. Los ejemplos de sistemas, entornos y/o configuraciones informáticos bien conocidos que pueden ser adecuados para su uso con el complejo electrónico central 200 incluyen, pero no se limitan a, sistemas de ordenador personal (PC), sistemas informáticos de servidor, clientes ligeros, clientes pesados, dispositivos de mano o portátiles, sistemas multiprocesadores, sistemas basados en microprocesadores, cajas de conexión, electrónica de consumo programable, PC de red, sistemas de miniordenadores, sistemas de ordenadores centrales y entornos de computación en la nube distribuidos que incluyen cualquiera de los anteriores sistemas o dispositivos, y similares.

Aunque en la presente memoria se describen varios ejemplos de entornos informáticos, uno o más aspectos de la presente invención se pueden usar con muchos tipos de entornos. Los entornos informáticos proporcionados en la presente memoria son solo ejemplos.

De acuerdo con un aspecto de la presente invención, un entorno informático, tal como el entorno informático 100 o el complejo electrónico central 200, emplea una instalación de conversión que proporciona un mecanismo para comprimir y descomprimir datos. En un ejemplo, la instalación de conversión consiste en una instalación de conversión DEFLATE que proporciona un mecanismo para comprimir y descomprimir datos utilizando el formato de datos comprimidos D<e>FLAT<e>. En un ejemplo, la instalación de conversión se instala en el sistema cuando se establece un indicador de instalación, por ejemplo, en uno. Como un ejemplo particular de la arquitectura dehardwarez/Architecture, el bit 151 de instalación se establece, por ejemplo, en uno cuando la instalación de conversión se instala en el modo de arquitectura z/Architecture. La instalación incluye, por ejemplo, la instrucción de Llamada de Conversión DEFLATE, una realización de la cual se describe más abajo.

En un ejemplo, la instrucción de Llamada de Conversión DEFLATE realiza funciones relacionadas con la transformación del estado de los datos entre la forma original (sin comprimir) de los datos y una representación comprimida de los datos, según lo especificado en un estándar seleccionado, como la especificación RFC (Solicitud de Comentarios) 1951 de IETF (Grupo de Trabajo de Ingeniería de Internet), que se describe en la Especificación de Formato de Datos Comprimidos DEFLATE versión 1.3 del Grupo de Trabajo de Ingeniería de Internet, Solicitud de Comentarios 1951, mayo de 1996.

En un ejemplo, los datos sin comprimir son una secuencia de bytes, y la representación comprimida de los datos incluye símbolos. Los símbolos representan un byte individual de datos sin comprimir, denominado byte literal, o representan una secuencia recurrente de bytes de datos sin comprimir, denominada cadena duplicada. Una tabla de Huffman, como ejemplo, especifica la codificación y la descodificación entre símbolos de datos comprimidos y datos sin comprimir. Hay dos tipos de tablas de Huffman: una tabla de Huffman fija (FHT), que es una especificación predeterminada que incluye, por ejemplo, todas las codificaciones posibles; y una tabla de Huffman dinámica (DHT), que es un conjunto de codificaciones creadas específicamente para los datos que han de ser comprimidos, que puede ser un subconjunto de todas las codificaciones posibles. Una representación comprimida de datos generados con una DHT suele ser más pequeña que una representación comprimida de los mismos datos generada con una FHT. Una parte de los datos no comprimidos procesados más recientemente, denominados historial, se mantiene para codificar y descodificar símbolos de datos comprimidos que representan cadenas duplicadas. El historial es la fuente de referencia para las cadenas duplicadas. El historial se actualiza a medida que se procesan datos durante una operación.

Como se indica, en un ejemplo, la instrucción de Llamada de Conversión DEFLATE usa el formato de datos comprimidos DEFLATE, que se describe en RCF 1951, Especificación de Formato de Datos Comprimidos DEFLATE, versión 1.3. Los atributos del estándar DEFLATE que se aplican a la instrucción de Llamada de Conversión DEFLATE incluyen, por ejemplo:

• Un conjunto de datos comprimidos incluye una serie de bloques. Hay tres tipos de bloques. Un tipo incluye un encabezado de 3 bits seguido de información de longitud y datos sin comprimir, y dos tipos de bloques incluyen un encabezado de 3 bits seguido de elementos de datos comprimidos.

• Los elementos de datos comprimidos pueden incluir una representación comprimida de una tabla de Huffman dinámica, símbolos de datos comprimidos y un símbolo de fin de bloque (EOB).

• Los elementos de datos comprimidos tienen varias longitudes de bits.

• Los elementos de datos comprimidos pueden comenzar o terminar entre límites de bytes en el almacenamiento.

• Los elementos de datos comprimidos se cargan en bytes en orden desde, por ejemplo, la posición de bits más a la derecha hasta la posición de bits más a la izquierda.

Cuando un elemento de datos comprimido ocupa parte de un byte almacenado, y no todo él, se accede a todo el byte almacenado. Las longitudes de los operandos de almacenamiento especifican el número de bytes direccionables, que pueden especificar más bits de los que ocupan los datos comprimidos.

Los detalles adicionales con respecto a los bloques de datos comprimidos se describen con mayor detalle más abajo.

Una realización de la instrucción de Llamada de Conversión DEFLATE (DFLTCC) se describe con referencia a las FIGS. 3A-3L. La instrucción se ejecuta, en un ejemplo, utilizando un procesador de uso general (por ejemplo, el procesador 102 o 204). En la descripción de la presente memoria se indican ubicaciones específicas, campos específicos y/o tamaños específicos de los campos (por ejemplo, bytes y/o bits específicos). Sin embargo, se pueden proporcionar otras ubicaciones, campos y/o tamaños. Además, aunque se especifica el ajuste de un bit a un valor particular, por ejemplo, uno o cero, esto es solo un ejemplo. El bit puede establecerse en un valor diferente, tal como el valor opuesto o en otro valor, en otros ejemplos. Son posibles muchas variaciones.

En una realización, un programa (por ejemplo, un sistema operativo o un programa de usuario) puede ejecutar la instrucción de Llamada de Conversión DEFLATE varias veces para comprimir o descomprimir un único flujo de datos. Por ejemplo, cuando una aplicación comprime o descomprime un flujo de datos grande (por ejemplo, de más de 1 M bytes), la operación puede incluir múltiples llamadas para comprimir o descomprimir partes almacenadas en memoria intermedia del flujo de datos. Según un aspecto de la presente invención, un programa declara una memoria intermedia (por ejemplo, una memoria intermedia de 32 K bytes), que se usa para acumular el historial de datos sin comprimir procesados durante una operación que abarca múltiples ejecuciones de la instrucción de Llamada de Conversión DEFLATE. La memoria intermedia se denomina memoria intermedia de historial circular, que se define utilizando la instrucción de Llamada de Conversión DEFLATE, tal como se describe en la presente memoria.

Con referencia a la FIG. 3A, en un ejemplo, un formato de una instrucción 300 de Llamada de Conversión DEFLATE (DFLTCC) es un formato RRF que indica un registro y operación de registro con un campo de código de operación extendido (opcode) y un campo de registro adicional. Como ejemplo, la instrucción incluye un campo 302 de código de operación (por ejemplo, los bits 0-15) que tiene un código de operación que indica una operación de Llamada de Conversión DEFLATE; un primer campo 304 de registro (R1) (por ejemplo, los bits 24-27) que designa un primer par de registros generales; un segundo campo 306 de registro (R2) (por ejemplo, los bits 28-31) que designa un segundo par de registros generales; y un tercer campo 308 de registro (R3) (por ejemplo, los bits 16-19) que designa un tercer registro general. El contenido de un registro designado por el campo R1 304 especifica la ubicación de un primer operando (en almacenamiento); el contenido de un registro designado por el campo R2306 especifica la ubicación de un segundo operando (en almacenamiento); y el contenido de un registro designado por el campo R3308 especifica la ubicación de un tercer operando (en almacenamiento). El contenido de R1 1 especifica la longitud del primer operando y el contenido de R2 1 especifica la longitud del segundo operando. En un ejemplo, los bits 20-23 de la instrucción están reservados y deben contener ceros; de lo contrario, es posible que el programa no funcione de manera compatible en el futuro. Como se usa en la presente memoria, el programa es el que emite la instrucción de Llamada de Conversión DEFLATE. Puede ser un programa de usuario, un sistema operativo u otro tipo de programa.

En una realización, la ejecución de la instrucción incluye el uso de uno o más registros generales implícitos (es decir, registros no designados explícitamente por la instrucción). Por ejemplo, los registros generales 0 y 1 se usan en la ejecución de la instrucción de Llamada de Conversión DEFLATE, tal como se describe en la presente memoria. El registro general 0 se usa, en un ejemplo, para especificar una función que ha de ser realizada (así como un tipo de memoria intermedia de historial, que se describe más abajo), y el registro general 1 se usa para proporcionar una ubicación de un bloque de parámetros usado por la instrucción.

Como ejemplo, con referencia a la FIG. 3B, un registro general 0 (309) incluye un campo 310 de tipo de memoria intermedia de historial y un campo 312 de código de función. En un ejemplo particular, la posición de bits 56 del registro general 0 incluye un tipo de memoria intermedia de historial, y las posiciones de bits 57-63 del registro general 0 contienen un código de función; pero en otras realizaciones se pueden usar otros bits para contener el tipo de memoria intermedia de historial y/o el código de función. En un ejemplo, cuando los bits 57-63 del registro general 0 designan un código de función no asignado o desinstalado, se reconoce una excepción de especificación.

Los ejemplos de códigos de función asignados para la instrucción de Llamada de Conversión DEFLATE se muestran en la FIG. 3C e incluyen, por ejemplo: el código de función 0 (313) que indica una función DFLTCC-QAF (consultar funciones disponibles); el código de función 1 (315) que indica una función DFLTCC-GDHT (Generar Tabla de Huffman Dinámica); el código de función 2 (317) que indica una función DFLTCC-CMPR (comprimir); y el código de función 4 (319) que indica una función DFLTCC-XPND (expandir). Cada código usa un bloque de parámetros y el tamaño del bloque de parámetros depende, en un ejemplo, de la función. Por ejemplo, para la función DFLTCC-QAF, el bloque de parámetros es de 32 bytes; para la función DFLTCC-GDHT, el bloque de parámetros es de 384 bytes; y para las funciones DFLTCC-CMPR y DFLTCC-XPND, el bloque de parámetros es de 1536 bytes. Otros códigos de función no están asignados en este ejemplo. Aunque se describen funciones y códigos de función ejemplares, se pueden usar otras funciones y/o códigos de función.

Cuando la función especificada es DFLTCC-CMPR o DFLTCC-XPND, el bit 56 del registro general 0 especifica el tipo de memoria intermedia de historial (HBT) utilizado durante la operación. Cuando el HBT es cero, la memoria intermedia de historial se denomina memoria intermedia de historial en línea. Cuando se usa una memoria intermedia de historial en línea, el historial está, por ejemplo, inmediatamente a la izquierda del segundo operando cuando se especifica DFLTCC-CMPR y, por ejemplo, está inmediatamente a la izquierda del primer operando cuando se especifica DFLTCC-XPND. Cuando HBT es uno, la memoria intermedia de historial se denomina memoria intermedia de historial circular. Cuando se utiliza una memoria intermedia de historial circular, el historial es una parte o la totalidad del tercer operando cuando se especifica DFLTCC-CMPR o DFLTCC-XPND. Cuando se especifica la función DFLTCC-QAF o DFLTCC-GDHT, se ignora el bit 56 del registro general 0. En un ejemplo se ignoran las posiciones de bits 0-31 del registro general 0. Además, en un ejemplo, las posiciones de bits 32-55 del registro general 0 están reservadas y deberían contener ceros; de lo contrario, es posible que el programa no funcione de manera compatible en el futuro.

Con referencia a la FIG. 3D se describen detalles adicionales con respecto a otro registro implícito, el registro general 1, utilizado por la instrucción de Llamada de Conversión DEFLATE. El contenido del registro general 1 (314) especifica, por ejemplo, una dirección lógica 316 del byte situado más a la izquierda de un bloque de parámetros almacenado. En un ejemplo, el bloque de parámetros debe designarse en un límite de 4K bytes; de lo contrario, se reconoce una excepción de especificación. Más abajo se describen más detalles con respecto al bloque de parámetros.

Para las funciones especificadas (por ejemplo, DFLTCC-QAF, DFLTCC-GDHT, DFLTCC-CMPR, DFLTCC-XPND), el contenido de los registros generales 0, 1 y R3 no se modifica. Además, en un ejemplo, el campo R1 304 designa un par par-impar de registros generales. Es para designar un registro par y no para designar el registro general 0; de lo contrario, se reconoce una excepción de especificación.

Tal como se representa en las FIGS. 3E-3F y se describe con más detalle en la presente memoria, el contenido del registro general R1 318 indica una dirección 320 de primer operando, y el contenido del registro general R1 1322 se usa para determinar la longitud 324 del primer operando. Por ejemplo, cuando la función especificada es DFLTCC-CMPR o DFLTCC-XPND, el contenido del registro general R1 318 especifica una dirección lógica del byte más a la izquierda del primer operando. Cuando la función especificada es DFLTCC-CMPR, el contenido del registro general R1 1, junto con los valores de los campos de nueva tarea (NT) y límite de subbytes (SBB) del bloque de parámetros (que se describe más abajo), especifican la longitud del primer operando. La siguiente tabla proporciona ejemplos que demuestran la longitud del primer operando para la función DFLTCC-CMPR en función del contenido del registro general R1 1, el campo NT y el campo SBB:

Contenido de GR R1 1(hexadecimal)NT SBB (binario) Longitud del primer operando

0000000000000002 0 001 15 bits

0000000000000001 1<--->8 bits

0000000000000001 0 000 8 bits

0000000000000001 0 011 5 bits

0000000000000001 0 111 1 bit

0000000000000000<->--- 0 bits

Cuando la función especificada es DFLTCC-XPND, el contenido del registro general R1 1 especifica la longitud del primer operando. Cuando la función especificada es DFLTCC-CMPR o DFLTCC-XPND, los resultados de la compresión o descompresión de los datos se almacenan en la ubicación del primer operando. Cuando se especifica la función DFLTCC-QA<f>o DFLTCC-GDHT, se ignora el contenido de los registros generales R1 y R1 1.

Además, para las funciones especificadas (por ejemplo, DFLTCC-QAF, DFLTCC-GDHT, DFLTCC-CMPR y DFLTCC-XPND), en un ejemplo, el campo R2306 designa un par par-impar de registros generales. Es para designar un registro par y no para designar el registro general 0; de lo contrario, se reconoce una excepción de especificación.

Como se representa en las FIGS. 3G-3H y se describe con más detalle en la presente memoria, el contenido del registro general R2326 indica una dirección de segundo operando 328, y el contenido del registro general R2 1330 se usa para determinar la longitud 332 del segundo operando. Por ejemplo, cuando la función especificada es DFLTCC-GDHT, DFLTCC-CMPR o DFLTCC-XPND, el contenido del registro general R2 especifica una dirección lógica del byte más a la izquierda del segundo operando. Cuando la función especificada es DFLTCC-CMPR o DFLTCC-GDHT, el contenido del registro general R2 1 especifica la longitud del segundo operando. Cuando la función especificada es DFLTCC-XPND, el contenido del registro general R2 1, junto con los valores de los campos NT y SBB del bloque de parámetros, especifica la longitud del segundo operando. Cuando se hace referencia a la longitud del segundo operando y tiene un valor distinto de cero al comienzo de la ejecución de la instrucción, los datos se obtienen de la ubicación del segundo operando. Cuando se hace referencia a la longitud del segundo operando, tiene un valor de cero al comienzo de la ejecución de la instrucción y el campo del indicador de continuación (CF) del bloque de parámetros es uno al comienzo de la ejecución de la instrucción, no se accede al segundo operando.

Cuando se especifica la función DFLTCC-QAF, se ignora el contenido de los registros generales R2 y R2 1. Cuando se especifica la función DFLTCC-GDHT y el contenido del registro general R2 1 especifica una longitud igual a cero, se reconoce una excepción de especificación y no se accede al segundo operando. Cuando se especifica la función DFLTCC-CMPR o DFLTCC-XPND, el campo del indicador de continuación (CF) del bloque de parámetros es cero al principio de la ejecución de la instrucción, y el contenido del registro general R2 1 especifica una longitud igual a cero, se reconoce una excepción de especificación y no se accede al segundo operando.

Como se muestra en la FIG. 3I, cuando la función especificada es DFLTCC-CMPR o DFLTCC-XPND y el tipo de memoria intermedia de historial (HBT) es circular (por ejemplo, HBT 310 = 1), el contenido del registro general R3335 especifica una dirección 337 de memoria intermedia de historial circular. Por ejemplo, se especifica una dirección lógica del byte situado más a la izquierda del tercer operando. Es para designar, por ejemplo, un límite de 4 K bytes; de lo contrario se reconoce una excepción de especificación. En un ejemplo, la memoria intermedia de historial circular se encuentra en la ubicación del tercer operando. Cuando la función especificada es DFLTCC-CMPR o DFLTCC-XPND y el HBT es cero, se ignora el contenido del registro general R3. Cuando se especifica la función DFLTCC-QAF o DFLTCC-GDHT, se ignora el contenido del registro general R3. Para las funciones especificadas (por ejemplo, DFLTCC-QAF, DFLTCC-GDHT, DFLTCC-CMPR y DFLTCC-XPND), el campo R3 no designa el registro general 0 ni el registro general 1; de lo contrario, en un ejemplo se reconoce una excepción de especificación.

Como parte de la operación, cuando la función especificada es DFLTCC-CMPR, la dirección en el registro general R1 se incrementa en el número de bytes procesados del primer operando que incluía la posición de bit de procesamiento 0, y la longitud en el registro general R1 1 se reduce en el mismo número; la dirección en el registro general R2 se incrementa en el número de bytes procesados del segundo operando, y la longitud en el registro general R2 1 se reduce en el mismo número. El número de bytes procesados del primer operando que incluía la posición 0 del bit de procesamiento es, por ejemplo, el cociente entero resultante de una división entera, siendo el dividendo la suma del número de bits de salida procesados y el valor original del SBB, y siendo el divisor un valor de ocho. La formación y actualización de las direcciones y longitudes dependen del modo de direccionamiento, tal como se describe más abajo.

Como parte de la operación, cuando la función especificada es DFLTCC-XPND, la dirección en el registro general R1 se incrementa en el número de bytes procesados del primer operando, y la longitud en el registro general R1 1 se reduce en el mismo número; la dirección en el registro general R2 se incrementa en el número de bytes procesados del segundo operando que incluida la posición de bit de procesamiento 0, y la longitud en el registro general R2 1 se reduce en el mismo número. El número de bytes procesados del segundo operando que incluía la posición de bit de procesamiento 0 es, por ejemplo, el cociente entero resultante de una división entera, siendo el dividendo la suma del número de bits de entrada procesados y el valor original del SBB, siendo el divisor un valor de ocho. La formación y actualización de las direcciones y longitudes dependen del modo de direccionamiento, tal como se describe más abajo.

En una realización, en el modo de direccionamiento de 24 bits, se aplica lo siguiente:

• El contenido de las posiciones de bits 40-63 de los registros generales 1, R1, R2 y R3 constituye las direcciones del bloque de parámetros, el primer operando, el segundo operando y la memoria intermedia de historial circular, respectivamente, y se ignora el contenido de las posiciones de bits 0-39.

• Los bits 40-63 de las direcciones actualizadas del primer operando y del segundo operando sustituyen a los bits correspondientes en los registros generales R1 y R2, respectivamente. Las salidas de la posición de bits 40 de las direcciones actualizadas se ignoran, y el contenido de las posiciones de bits 32-39 de los registros generales R1 y R2 se establece en ceros. El contenido de las posiciones de bits 0-31 de los registros generales R1 y R2 permanece sin cambios.

• Cuando la instrucción termina con una finalización parcial o normal, y una dirección de operando actualizada es igual a la dirección del operando al principio de la ejecución de la instrucción, las posiciones de bits 32-39 del registro general correspondiente se establecen en ceros.

• El contenido de las posiciones de bits 32-63 de los registros generales R1 1 y R2 1 forma, por ejemplo, números enteros binarios sin signo de 32 bits que especifican el número de bytes en los operandos primero y segundo, respectivamente. El contenido de las posiciones de bits 0-31 de los registros generales R1 1 y R2 1 se ignora.

• Los bits 32-63 de las longitudes actualizadas del primer operando y del segundo operando sustituyen a los bits correspondientes en los registros generales R1 1 y R2 1, respectivamente. El contenido de las posiciones de bits 0-31 de los registros generales R1 1 y R2 1 permanece sin cambios.

En una realización se aplica lo siguiente en el modo de direccionamiento de 31 bits:

• El contenido de las posiciones de bits 33-63 de los registros generales 1, R1, R2 y R3 constituye las direcciones del bloque de parámetros, el primer operando, el segundo operando y la memoria intermedia de historial circular, respectivamente, y se ignora el contenido de las posiciones de bits 0-32.

• Los bits 33-63 de las direcciones actualizadas del primer operando y del segundo operando sustituyen a los bits correspondientes en los registros generales R1 y R2, respectivamente. Las salidas de la posición de bits 33 de las direcciones actualizadas se ignoran, y el contenido de la posición de bits 32 de los registros generales R1 y R2 se establece en cero. El contenido de las posiciones de bits 0-31 de los registros generales R1 y<r>2 permanece sin cambios. Cuando la instrucción termina con una finalización parcial o normal, y una dirección de operando actualizada es igual a la dirección del operando al principio de la ejecución de la instrucción, la posición de bits 32 del registro general correspondiente se establece en cero.

• El contenido de las posiciones de bits 32-63 de los registros generales R1 1 y R2 1 forma números enteros binarios sin signo de 32 bits que especifican el número de bytes en los operandos primero y segundo, respectivamente. El contenido de las posiciones de bits 0-31 de los registros generales R1 1 y R2 1 se ignora.

En una realización, en el modo de direccionamiento de 64 bits se aplica lo siguiente:

• El contenido de las posiciones de bits 0-63 de los registros generales 1, R1, R2 y R3 constituye las direcciones del bloque de parámetros, el primer operando, el segundo operando y la memoria intermedia de historial circular, respectivamente.

• Los bits 0-63 de las direcciones actualizadas del primer operando y del segundo operando sustituyen a los bits correspondientes en los registros generales R1 y R2, respectivamente.

• Las salidas de bits de la posición 0 de las direcciones actualizadas se ignoran.

• El contenido de las posiciones de bits 0-63 de los registros generales R1 1 y R2 1 forma números enteros binarios sin signo de 64 bits que especifican el número de bytes en los operandos primero y segundo, respectivamente.

• Los bits 0-63 de las longitudes actualizadas del primer operando y del segundo operando sustituyen a los bits correspondientes en los registros generales R1 1 y R2 1, respectivamente.

En el modo de registro de acceso, los registros de acceso 1, R1, R2 y R3 especifican los espacios de direcciones que contienen el bloque de parámetros, el primer operando, el segundo operando y la memoria intermedia de historial circular, respectivamente. Cuando se especifica un DFTCC-CMPR con una memoria intermedia de historial en línea en el modo de registro de acceso, el registro de acceso R2 especifica el espacio de direcciones que contiene el historial en línea. Cuando se especifica un DFTCC-XPND con una memoria intermedia de historial en línea en el modo de registro de acceso, el registro de acceso R1 especifica el espacio de direcciones que contiene el historial en línea.

A continuación se describen más detalles sobre las diversas funciones:

Código de función 0: DFLTCC-QAF (Consultar Funciones Disponibles)

La función DFLTCC-QAF (consultar funciones disponibles) proporciona un mecanismo para indicar la disponibilidad de las funciones instaladas y los formatos de bloques de parámetros instalados. Un formato ejemplar de un bloque de parámetros para la función DFLTCC-QAF se describe con referencia a la FIG. 3J. En un ejemplo, un bloque 340 de parámetros para la función DFLTCC-QAF (por ejemplo, el código de función 0) incluye un vector 342 de funciones instaladas y un vector 346 de formatos de bloques de parámetros instalados. En un ejemplo particular, estos vectores se almacenan en los bytes 0-15 y los bytes 24-25, respectivamente, del bloque de parámetros. Más abajo se describe con mayor detalle cada uno de los vectores.

Como ejemplo, los bits 0-127 del vector 342 de funciones instalado corresponden a los códigos de función 0-127, respectivamente, de la instrucción de Llamada de Conversión DEFLATE. Cuando un bit es, por ejemplo, uno, se instala la función correspondiente; de lo contrario, la función no se instala.

Además, en un ejemplo, los bits 0-15 del vector 346 de formatos de bloques de parámetros instalados corresponden a los formatos de bloques de parámetros 0-15, respectivamente, para las funciones DFLTCC-GDHT, DFLTCC-CMPR y DFLTCC-XPND. Cuando un bit es, por ejemplo, uno, se instala el formato de bloque de parámetros correspondiente; de lo contrario, el formato de bloque de parámetros no se instala. En un ejemplo, los ceros se almacenan en los bytes reservados 16-23 y 26-31 del bloque de parámetros.

Aunque ciertos campos se describen con respecto al bloque 340 de parámetros, en otras realizaciones se pueden incluir campos adicionales, menos campos y/u otros campos.

En una realización, la función DFLTCC-QAF ignora el contenido de los registros generales R1, R2, R3, R1 1 y R2 1.

Se reconoce un evento de alteración de almacenamiento PER (grabación de eventos de programa), en caso aplicable, para el bloque de parámetros. Se reconoce un evento de detección de dirección cero<p>E<r>, en caso aplicable, para el bloque de parámetros.

En un ejemplo, el código de condición 0 se establece cuando se completa la ejecución de la función DFLTCC-QAF; en un ejemplo, los códigos de condición 1, 2 y 3 no son aplicables a la función de consulta.

Código de función 1: DFLTCC-GDHT (Generar tabla de Huffman dinámica)

Cuando se especifica la función DFLTCC-GDHT, el segundo operando se usa, por ejemplo, como fuente para generar una representación comprimida de una tabla de Huffman dinámica (DHT), tal como se especifica en el estándar DEFLATE.

En un ejemplo, la función DFLTCC-GDHT usa un bloque de parámetros, un ejemplo del cual se describe con referencia a la FIG. 3k . En el bloque de parámetros ejemplares descrito en la presente memoria se indican ubicaciones específicas dentro del bloque de parámetros para campos específicos y tamaños específicos de los campos (por ejemplo, bytes y/o bits específicos). Sin embargo, se pueden prever otras ubicaciones y/o tamaños para uno o más de los campos. Además, aunque se especifica el ajuste de un bit a un valor particular, por ejemplo, uno o cero, esto es solo un ejemplo. En otros ejemplos, el bit puede establecerse en un valor diferente, tal como el valor opuesto o en otro valor. Son posibles muchas variaciones.

Además, en un ejemplo, el bloque de parámetros incluye uno o más campos conservados y uno o más campos reservados. La función DFLTCC-GDHT no modifica los campos conservados. Los campos conservados se distinguen de los campos reservados para permitir que un programa inicialice una única ubicación de almacenamiento, utilice esa ubicación de almacenamiento para el bloque de parámetros de una función de DFLTCC-GDHT y, posteriormente, utilice la misma ubicación de almacenamiento para el bloque de parámetros de una función de DFLTCC-CMPR. Los campos reservados deben contener ceros; de lo contrario, es posible que el programa no funcione de manera compatible en el futuro. Cuando finaliza una operación, los campos reservados pueden almacenarse como ceros o pueden permanecer sin cambios.

Además, algunos de los campos son utilizados por otras funciones (por ejemplo, DFLTCC-CMPR o DFLTCC-XPND) y, por lo tanto, los aspectos relacionados con esas funciones también pueden describirse con la descripción de esos campos.

En un ejemplo, un bloque 360 de parámetros para la función DFLTCC-GDHT incluye los siguientes campos:

Número de versión del bloque de parámetros (PBVN) 362: Los bytes 0-1 del bloque de parámetros especifican la versión y el tamaño del bloque de parámetros. Los bits 0-11 del PBVN están reservados y deben contener ceros; de lo contrario, es posible que el programa no funcione de manera compatible en el futuro. Los bits 12-15 del PBVN contienen un entero binario sin signo que especifica el formato del bloque de parámetros. La función DFLTCC-QAF proporciona un mecanismo para indicar los formatos de bloques de parámetros disponibles. Cuando el modelo no admite el formato del bloque de parámetros especificado, se reconoce una excepción general de datos del operando. El PBVN lo especifica el programa y no se modifica durante la ejecución de la instrucción.

Número de versión del modelo (MVN) 363: El byte 2 del bloque de parámetros es un entero binario sin signo que identifica el modelo que ejecutó la instrucción. El programa no es necesario para inicializar el MVN. El MVN se actualiza durante la ejecución de la instrucción. El valor almacenado en el MVN depende del modelo.

Control de generación de tabla de Huffman dinámica (DHT) (DHTGC) 364: El bit 2 del byte 17 del bloque de parámetros se aplica a la generación de una tabla de Huffman dinámica (DHT). La DHT especifica los códigos de Huffman para los símbolos que representan bytes literales, longitudes de cadenas duplicadas, símbolos de final de bloque (EOB) y distancias de punteros de cadenas duplicadas. El valor de un código de Huffman para un símbolo en particular es una función del recuento de sucesos de la entidad, que el símbolo representa, en la forma descomprimida de los datos. Cuando el recuento de un símbolo es cero, no hay ningún código de Huffman en la DHT para el símbolo. En un ejemplo el DHTGC especifica que los recuentos iguales a cero se tratarán de la siguiente manera:

DHTGC Significado

0 Tratar los recuentos de bytes literales, las longitudes de cadenas duplicadas y las distancias de puntero iguales a cero como iguales a uno (generar una DHT universal).

1 Tratar los recuentos de longitudes de cadenas duplicadas y distancias de puntero iguales a cero como iguales a uno.

Una DHT que especifica un código de Huffman para cada valor posible de bytes literales, un símbolo EOB, longitudes de cadena duplicadas y distancias de puntero de cadenas duplicadas se designa como una DHT universal. Una DHT que no especifica códigos de Huffman para valores de bytes literales, longitudes de cadenas duplicadas o distancias de punteros de cadenas duplicadas que no se producen en la forma sin comprimir a partir de los datos se designa como una DHT no universal.

Para todos los valores del DHTGC, la DHT resultante especifica códigos de Huffman para todas las posibles longitudes de cadenas duplicadas y distancias de puntero, tal como se define en el estándar DEFLATE. Por lo tanto, los subelementos HLIT (literal de Huffman) y HDIST (distancias de Huffman) de la forma comprimida resultante de la DHT, que se describe más abajo, contienen cada uno el valor de, por ejemplo, 29.

El DHTGC es una entrada para la operación cuando se especifica la función DFLTCC-GDHT. El DHTGC no se aplica a la operación cuando se especifica la función DFLTCC-CMPR o DFLTCC-XPND. En una realización, el DHTGC no se modifica durante la ejecución de la instrucción.

Código suplementario de finalización de operación (OESC) 365: El byte 19 del bloque de parámetros es un número entero binario sin signo que proporciona información adicional sobre la condición que se notifica al programa. Dado que este campo es usado por múltiples funciones, algunas de las condiciones se refieren a campos de un bloque de parámetros usado por otras funciones (por ejemplo, el bloque de parámetros de la FIG. 3L usado por las funciones DFLTCC-CMPR y DFLTCC-XPND). Cuando la condición que se notifica es una excepción de datos de operando general, la operación se considera suprimida, aunque se actualice el campo OESC del bloque de parámetros, en cuyo caso se define de la siguiente manera, en un ejemplo:

OESC (hexadecimal) Significado

00 No se proporciona información adicional.

01 El modelo no admite el formato del bloque de parámetros, tal como se especifica en el número 362 de versión del bloque de parámetros.

02 Se especifica la función DFLTCC-CMPR o DFLTCC-XPND, un campo 385 de longitud de historial (FIG. 3L) es mayor que, por ejemplo, 32.768, y un campo 374 de nueva tarea (FIG.

3L) es cero.

11 Un bloque de datos comprimido con BTYPF. Se encuentra (Tipo de Bloque) igual a 11 binario.

12 Se encuentra un bloque de datos comprimido con BTYPE igual a 00 binario y NLEN no igual al complemento uno de LEN (longitud).

21 Se aplica el campo CDHTL 366 (FIG. 3L) y es, por ejemplo, inferior a 42 o superior a 2283.

22 El subelemento HLIT de una DHT comprimida utilizada durante la operación es, por ejemplo, superior a 29 (DHT no válida)

23 El subelemento HLIT de una DHT comprimida utilizada durante la operación es, por ejemplo, superior a 29 (DHT no válida)

24 Una DHT comprimida utilizada durante la operación especifica un código que está en la secuencia de códigos que especifican las longitudes de bits para las posibles longitudes de código (por ejemplo, 19) definidas para una DHT comprimida y es menor que la longitud requerida por el algoritmo de Huffman para especificar un árbol de Huffman funcional (DHT no válida).

26 Una DHT comprimida utilizada durante la operación especifica la longitud de código 16

(copia la longitud del código anterior) como la primera longitud de código para el conjunto de elementos que consiste en bytes literales, un símbolo EOB y longitudes de cadenas duplicadas (DHT no válida).

27 Una DHT comprimida utilizada durante la operación especifica un código que está en la secuencia de códigos que especifican longitudes de código para bytes literales, y el código no coincide con ninguno de los códigos determinados para representar el conjunto de longitudes de código de referencia, como se especificó anteriormente en la DHT comprimida (DHT no válida).

28 Una DHT comprimida utilizada durante la operación especifica un código que asigna una longitud de código 0 (CLO) al símbolo EOB. En este caso, la DHT correspondiente no especifica un código de Huffman para representar un símbolo EOB (DHT no válida).

29 Una DHT comprimida utilizada durante la operación especifica un código que está en la secuencia de códigos que especifican longitudes de código para longitudes de cadenas duplicadas y distancias de puntero, y el código no coincide con ninguno de los códigos determinados para representar el conjunto de longitudes de código de referencia, como se especificó anteriormente en la DHT comprimida (DHT no válida).

2A Una DHT comprimida utilizada durante la operación especifica un número de longitudes de código que es mayor que el número de códigos de Huffman en la DHT, tal como se especifica mediante la suma de los valores en el campo HLIT, el campo HDIST y, por ejemplo, 258. Esto es posible con un uso inadecuado de las longitudes de código 16, 17 y 18, como ejemplos (DHT no válido).

2B Una DHT comprimida utilizada durante la operación especifica una longitud de código para el conjunto de bytes literales, el símbolo EOB y las longitudes de cadenas duplicadas, que es inferior a la longitud requerida por el algoritmo de Huffman para especificar un árbol de Huffman funcional (DHT no válida).

2D Una DHT comprimida utilizada durante la operación especifica una longitud de código para el conjunto de distancias de puntero de cadenas duplicadas, que es inferior a la longitud requerida por el algoritmo de Huffman para especificar un árbol de Huffman funcional (DHT no válida).

2F El campo CDHTL 366 (FIG. 3L) se aplica y no es igual a la longitud de la DHT comprimida en el campo CDHT 367 (FIG. 3L) usado durante la operación.

31 Una DHT comprimida utilizada durante la operación no especifica un código de Huffman correspondiente a un byte literal o una longitud de cadenas duplicadas procesada durante la operación (DHT no universal deficiente), o se especifica la función DFLTCC-XPND y un símbolo de datos comprimidos, que se encuentra en un bloque de datos comprimido con un BTYPE igual a 01 binario, especifica un código no válido para una longitud de cadenas duplicadas (11000110 o 11000111 binario).

32 Una DHT comprimida utilizada durante la operación no especifica un código de Huffman correspondiente a una distancia de puntero de cadenas duplicadas procesada durante la operación (DHT no universal deficiente), o se especifica la función DFLTCC-XPND y un símbolo de datos comprimidos, que se encuentra en un bloque de datos comprimido con un BTYPE igual a 01 binario, especifica un código no válido para un puntero de cadenas duplicadas (11110 o 11111 binario).

40 Se encuentra un símbolo de datos comprimidos que es un puntero de cadenas duplicadas y especifica una distancia mayor que la longitud del historial disponible en el punto de procesamiento del símbolo.

Cuando la operación finaliza sin notificar una excepción de datos de operando general, los ceros se almacenan en el campo OESC.

La compatibilidad con códigos suplementarios distintos de cero depende del modelo. Cuando existen múltiples condiciones, depende del modelo qué código, si lo hay, se notifica en el campo OESC.

Longitud de tabla de Huffman dinámica comprimida (CDHTL) 366: Doce bits, empezando por el bit 4 del byte 56 hasta el bit 7 del byte 57, del bloque de parámetros contienen un número entero binario sin signo que especifica la longitud, como un recuento de bits, del formato comprimido de la DHT en el campo CDHT del bloque de parámetros (por ejemplo, CDHT 367).

La CDHTL es una salida de la operación cuando se especifica la función DFLTCC-GDHT.

La CDHTL es una entrada a la operación cuando se especifica la función DFLTCC-CMPR y el tipo de tabla de Huffman (por ejemplo, HTT 376 de la FIG. 3L) es uno. Cuando la CDHTL no especifica una longitud apropiada para la CDHT, se reconoce una excepción de datos de operando general. La CDHTL no se modifica cuando se especifica la función DFLTCC-CMPR.

Cuando se especifica la función DFLTCC-XPND y la operación finaliza después de descodificar solo una parte de un bloque con bTy PE 10 binario, la longitud de la representación comprimida de la DHT en el bloque se almacena en este campo. Cuando se especifica la función DFLTCC-XPND y la operación termina en un límite de bloque o después de descodificar solo una parte de un bloque con BTYPE 00 o 01 binario, se almacenan ceros en este campo. Cuando se reanuda una operación de descompresión dentro de un bloque con BTYPE 10 binario (es decir, cuando CF (indicador 373 de continuación de la FIG. 3L) es igual a uno e IFS (estado 383 de función incompleta) es igual a C o D hexadecimal, como se describe más abajo), este campo es una entrada a la operación.

Tabla de Huffman dinámica comprimida (CDHT) 367: Los bytes 64-351 del bloque de parámetros contienen un formato comprimido de una tabla de Huffman dinámica (DHT).

La DHT especifica códigos de Huffman (secuencias de bits) para representar dos conjuntos de elementos. Los elementos de un conjunto incluyen bytes literales, un símbolo EOB y longitudes de cadenas duplicadas. Los elementos del otro conjunto incluyen distancias de puntero de cadenas duplicadas.

La representación comprimida de la DHT define un conjunto de longitudes de código y especifica una longitud de código (CL) para cada elemento de cada conjunto. El código de Huffman para un elemento al que se espera hacer referencia durante una operación se deriva de la CL especificada para ese elemento y del número de elementos del mismo conjunto con la misma CL especificada. Específicamente, la representación comprimida de la DHT incluye lo siguiente, a modo de ejemplo:

• Un campo HLIT para especificar el número de códigos de Huffman que representan bytes literales, un símbolo EOB y longitudes de cadenas duplicadas.

• Un campo HDIST para especificar el número de códigos de Huffman que representan distancias de puntero de cadenas duplicadas.

• Un campo HCLEN (longitudes de código de Huffman) para especificar el número de códigos de Huffman que representan longitudes de códigos.

• Una secuencia de códigos que especifican una longitud de bits para cada una de las, por ejemplo, 19 longitudes de código definidas para la DHT comprimida.

• Una secuencia de códigos que especifican una longitud de código para cada uno de los elementos del conjunto consistente en bytes literales, un símbolo EOB y longitudes de cadena duplicadas.

• Una secuencia de códigos que especifican una longitud de código para cada uno de los elementos del conjunto que consiste en distancias de puntero de cadenas duplicadas.

Más abajo se describen detalles adicionales de una representación comprimida de una DHT con referencia a la descripción de un bloque de datos comprimido con tipo de bloque 10 binario.

En un ejemplo, la representación comprimida de la DHT queda justificada a la izquierda en el campo CDHT. Es decir, el bit más a la derecha del byte 64 contiene el bit menos significativo del subelemento HLIT de la representación comprimida de la DHT.

La representación comprimida de una DHT es un resultado de la operación cuando se especifica la función DFLTCC-GDHT.

La representación comprimida de una DHT es una entrada a la operación cuando se especifica la función DFLTCC-CMPR, y HTT, que se describe más abajo, es una de ellas. La función DFLTCC-CMPR no modifica el campo CDHT.

Cuando se especifica la función DFLTCC-XPND y la operación finaliza después de descodificar solo una parte de un bloque con<b>T<y>PE 10 binario, la representación comprimida de la DHT en el bloque se almacena en este campo. Cuando se especifica la función DFLTCC-XPND y la operación termina en un límite de bloque o después de descodificar solo una parte de un bloque con BTYPE 00 o 01 binario, se almacenan ceros en este campo. Cuando se reanuda una operación de descompresión dentro de un bloque con BTYPE 10 binario (es decir, cuando CF es igual a uno e IFS es igual a C o D hexadecimal), este campo es una entrada para la operación.

Cuando se modifica la CDHT, los bits del campo que no se utilizan para representar la representación comprimida de la DHT se almacenan como ceros.

Aunque más arriba se describen diversos campos con respecto al bloque 360 de parámetros, en otras realizaciones se pueden incluir campos adicionales, menos campos y/u otros campos.

El programa especifica los aspectos de la generación de DHT a la máquina utilizando el campo 364 de control de generación de tablas de Huffman dinámicas (DHTGC) del bloque de parámetros. Se pretende que la fuente contenga datos sin comprimir y, una vez completada la operación, el resultado generado se especifica con la función DFLTCC-CMPR para comprimir la misma fuente.

En una realización no hay ningún historial al que hacer referencia de las operaciones anteriores mientras se procesa la operación actual.

En un ejemplo, cuando el contenido del registro general R2 1 especifica una longitud superior, por ejemplo, a 32 K bytes, se aplica lo siguiente:

• Solo los primeros 32 K-bytes del segundo operando se usan para generar la DHT.

• Las excepciones de acceso no se reconocen para ubicaciones más allá de los primeros 32 K bytes del segundo operando.

Cuando el contenido del registro general R2 1 especifica una longitud igual a cero, se reconoce una excepción de especificación y no se accede al segundo operando.

La DHT comprimida resultante incluye un código de Huffman que representa un símbolo de fin de bloque (EOB). Un formato comprimido de la DHT generada se almacena en el campo 367 de tabla de Huffman dinámica comprimida (CDHT) del bloque de parámetros. La longitud del formato comprimido de la DHT generada se almacena en el campo CDHTL 366 del bloque de parámetros.

La operación incluye almacenar una identificación de modelo en un campo 363 de número de versión del bloque de parámetros.

Cuando la operación finaliza sin reconocer una excepción de datos de operando general, se almacenan ceros en el campo 365 de código suplementario de finalización de operación (OESC) del bloque de parámetros.

El código de condición 0 se establece cuando se completa la ejecución de la función DFLTCC-GDHT; los códigos de condición 1, 2 y 3 no son aplicables a la función DFLTCC-GDHT.

La operación no modifica los registros generales R2 y R2 1.

El contenido de los registros generales R1, R1 1 y R3 se ignora cuando se especifica la función DFLTCC-GDHT. Un evento de detección de dirección PER cero se reconoce, cuando es aplicable, para la ubicación del segundo operando y para el bloque de parámetros.

Código de función 2: DFLTCC-CMPR (Comprimir)

Cuando se especifica la función DFLTCC-CMPR, se realiza una operación de compresión. La operación incluye codificar datos de la ubicación del segundo operando en símbolos de datos comprimidos, que se almacenan en la ubicación del primer operando.

En un ejemplo, la función DFLTCC-CMPR usa un bloque de parámetros, un ejemplo del cual se describe con referencia a la FIG. 3L. Algunos de los campos se han descrito anteriormente con respecto al bloque 360 de parámetros y, por lo tanto, se enumeran más abajo con el mismo número de referencia y no se describen con más detalle.

En un ejemplo, el bloque 370 de parámetros incluye:

Número de versión del bloque de parámetros (PBVN) 362.

Número de versión de modelo (MVN) 363.

Indicador de continuación (CF) 373: El bit 63 del bloque de parámetros, cuando es uno, indica que la operación está parcialmente completa y el contenido de la memoria intermedia de estado de continuación (por ejemplo, en el campo 392 de memoria intermedia de estado de continuación) puede usarse para reanudar la operación. El programa debe inicializar el indicador de continuación (CF) a cero y no modificar el CF en caso de que la instrucción se haya de volver a ejecutar con el fin de reanudar la operación; de lo contrario, los resultados son impredecibles.

Nueva tarea (NT) 374: El bit 0 del byte 16 del bloque de parámetros, cuando es uno, indica que la operación se aplica al comienzo de un conjunto de datos comprimido. Por lo tanto, no se aplica ningún historial ni valor de comprobación de una operación anterior a la operación actual. Cuando NT es uno al principio de la operación y la operación termina después de una finalización parcial, se almacena cero en el campo<n>T. Cuando NT es cero, el historial y un valor de comprobación de una operación anterior se aplican a la operación actual.

Tipo de valor de comprobación (CVT) 375: El bit 2 del byte 16 del bloque de parámetros especifica el tipo de valor de comprobación contenido en el campo de valor de comprobación del bloque de parámetros (por ejemplo, el campo 387). Cuando el CVT es cero, el tipo de valor de comprobación es, por ejemplo, una comprobación de redundancia cíclica de 32 bits (CRC-32). Cuando el CVT es uno, el tipo de valor de comprobación es, por ejemplo, una suma de comprobación de Adler de 32 bits (Adler-32). El bit CVT no se modifica durante la ejecución de la instrucción.

Tipo de tabla de Huffman (HTT) 376: El bit 4 del byte 16 del bloque de parámetros, cuando es cero, especifica que durante una operación de compresión se usa una tabla que contiene códigos de Huffman fijos (FHT), tal como se define en el estándar DEFLATE. Cuando HTT es uno, durante una operación de compresión se usa una tabla que contiene códigos de Huffman dinámicos (DHT), tal como se especifica en el campo CDH<t>del bloque de parámetros. El HTT no se aplica a operaciones de descompresión. El bit HTT no se modifica durante la ejecución de la instrucción.

Indicador de continuación de bloques (BCF) 377: El bit 5 del byte 16 del bloque de parámetros se aplica cuando se especifica la función DFLTCC-CMPR. Cuando es cero, un encabezado de bloque de 3 bits y, cuando sea aplicable, el formato comprimido de una tabla de Huffman dinámica, tal como se especifica en el campo CDHT del bloque de parámetros (por ejemplo, el campo 367), se almacenan en la ubicación del primer operando antes de almacenar cualquier elemento de datos comprimidos. Cuando es uno, en la ubicación del primer operando no se almacena un encabezado de bloque ni un formato comprimido de una DHT. Cuando NT es uno, el BCF se trata como igual a cero. El bit BCF no se modifica durante la ejecución de la instrucción.

Control de cierre de bloques (BCC) 378: El bit 6 del byte 16 del bloque de parámetros se aplica cuando se especifica la función DFLTCC-CMPR. Cuando es uno, después de almacenar todos los símbolos de datos comprimidos, se almacena un símbolo de final de bloque (EOB) en la ubicación del primer operando. Cuando el HTT especifica el uso de una FHT, el código de Huffman 0000000 binario (que corresponde a la representación de un entero intermedio de 256 en la tabla que especifica códigos para bytes literales, un símbolo EOB y longitudes de cadenas duplicadas), como ejemplo, se usan para el símbolo EOB. Cuando el HTT especifica el uso de una DHT, el código de Huffman para el símbolo EOB se especifica en la DHT. Cuando el bit BCC es cero, no se almacena un símbolo EOB en la ubicación del primer operando. El bit BCC no se modifica durante la ejecución de la instrucción.

Final de encabezado de bloque (BHF) 379: El bit 7 del byte 16 del bloque de parámetros se aplica cuando se especifica la función DFLTCC-CMPR y el BCF 377 es cero o el<n>T 374 es uno; de lo contrario, la BHF no se aplica. Cuando sea aplicable y uno, el primer bit del encabezado de bloque (BFINAL) se establece en uno antes de almacenar el encabezado de bloque en la ubicación del primer operando. Cuando sea aplicable y uno, el primer bit del encabezado de bloque (BFINAL) se establece en cero antes de almacenar el encabezado de bloque en la ubicación del primer operando. El bit BHF no se modifica durante la ejecución de la instrucción.

Control de generación de DHT (DHTGC) 364: El DHTGC no se aplica a la operación cuando se especifica la función DFLTCC-CMPR. El DHTGC no se modifica durante la ejecución de la instrucción.

Límite de subbytes (SBB) 381: Los bits 5-7 del byte 18 del bloque de parámetros contienen un entero binario sin signo que especifica el límite entre los bits procesados y no procesados dentro de un byte del flujo de datos comprimidos. El byte del flujo al que se hace referencia es el último byte al que se hace referencia, es decir, el byte situado más a la derecha, cuando finaliza una operación, y es el primer byte al que se hace referencia, es decir, el byte situado más a la izquierda, cuando comienza o se reanuda una operación. Cuando se especifica la función DFLTCC-CMPR, el SBB se aplica al byte designado por la dirección del primer operando. Cuando se especifica la función DFLTCC-XPND, el SBB se aplica al byte designado por la dirección del segundo operando. El SBB especifica el número de bits más a la derecha que se han procesado. El SBB es una entrada a la operación y una salida de la operación.

En la FIG. 4 se representa un ejemplo de un flujo de datos comprimidos cuando el SBB tiene un valor de 011 binario. Los datos que se han procesado después del final de la operación se representan en 400; y los datos que han de ser procesados antes del inicio de la operación se representan en 402.

Además, las FIGS. 5A-5C proporcionan ejemplos que demuestran cómo se aplica el SBB a la función DFLTCC-CMPR. Por ejemplo, en la FIG. 5A se representa un ejemplo de cómo se aplica el<s>B<b>antes y después de ejecutar la función DFLTCC-CMPR. Otros ejemplos se representan en las FIGS. 5B-5C. Cuando NT 374 es uno, el Sb B 381 se trata como igual a 000 binario.

Volviendo a la FIG. 3L, se describen campos adicionales del bloque 370 de parámetros:

Código suplementario de finalización de operación (OESC) 365:

Estado de función incompleta (IFS) 383: Los bits 4-7 del byte 21 del bloque de parámetros contienen información de estado cuando finalizan ciertas operaciones. En un ejemplo, cuando finaliza una operación de descompresión, el IFS transmite información sobre el segundo operando de la siguiente manera:

IFS (binario) Significado

0000 La operación finalizó después de descodificar el último elemento de un bloque con BFINAL igual a uno.

1000 La operación finalizó después de descodificar un elemento, distinto del último elemento, de un bloque con BTYPE igual a 00 binario y BFINAL igual a cero.

1001 La operación finalizó después de descodificar un elemento, distinto del último elemento, de un bloque con BTYPE igual a 00 binario y BFINAL igual a uno.

1010 La operación finalizó después de descodificar un elemento, distinto del último elemento, de un bloque con BTYPE igual a 01 binario y BFINAL igual a cero.

1011 La operación finalizó después de descodificar un elemento, distinto del último elemento, de un bloque con BTYPE igual a 01 binario y BFINAL igual a uno.

1100 La operación finalizó después de descodificar un elemento, distinto del último elemento, de un bloque con BTYPE igual a 10 binario y BFINAL igual a cero.

1101 La operación finalizó después de descodificar un elemento, distinto del último elemento, de un bloque con BTYPE igual a 10 binario y BFINAL igual a uno.

1110 La operación finalizó en un límite de bloque, el último elemento de un bloque con BFINAL igual a uno no se ha descodificado y el primer elemento del encabezado de bloque del bloque subsiguiente aún no se ha procesado.

En una realización, una operación de descompresión puede terminar con un IFS igual a 0000 binario y no satisfacer la finalización normal. En tales casos, la operación finaliza con el código de condición 1 o 3 establecido.

Cuando finaliza una operación de compresión, el campo IFS no está definido, pero puede modificarse.

El IFS no es una entrada para la operación.

Longitud de función incompleta (IFL) 384: Los bytes 22-23 del bloque de parámetros contienen información de longitud cuando finalizan ciertas operaciones. Para una operación de descompresión, la IFL se aplica al segundo operando. Cuando una operación de descompresión termina después de descodificar parte, pero no la totalidad, de un bloque con BTYPE igual a 00 binario, la<i>F<l>contiene un número entero binario sin signo que especifica el número de bytes del bloque en el segundo operando, que aún no se han procesado. Los bytes 22-23 contienen la IFL, por ejemplo, en orden de bytes de extremo mayor, a diferencia del campo LEN de un bloque con BTYPE igual a 00 binario, que está, por ejemplo, en orden de bytes de extremo menor.

Cuando finaliza una operación de descompresión después de descodificar un bloque completo con BTYPE igual a 00 binario y BFINAL igual a uno, los ceros se almacenan en el campo IFL. Cuando una operación de descompresión termina después de descodificar parte, pero no la totalidad, de un bloque con un BTYPE distinto de cero, o termina en un límite de bloque, el campo IFL no está definido, pero puede modificarse.

Cuando finaliza una operación de compresión, el campo IFL no está definido, pero puede modificarse.

La IFL no es una entrada para la operación.

Longitud de historial (HL) 385: Los bytes 44-45 del bloque de parámetros contienen un entero binario sin signo que especifica el número de bytes de historial en la memoria intermedia de historial a los que se puede hacer referencia durante una operación. La HL se aplica a las memorias intermedias de historial circular y en línea. Cuando la nueva tarea (NT) es igual a uno, no se aplica ningún historial al principio de la operación y la longitud de historial se trata como cero como una entrada de la operación.

Cuando la longitud de historial es mayor que, por ejemplo, 32.768 y NT es igual a cero, se reconoce una excepción de datos de operando general.

La longitud de historial se modifica durante las operaciones de compresión y descompresión. Cuando la suma de la HL original y el número de bytes de datos sin comprimir procesados durante la operación es menor o igual que, por ejemplo, 32.768, la HL actualizada es igual a la suma de la HL original y el número de bytes de datos sin comprimir procesados durante la operación; de lo contrario, la HL actualizada es igual al valor de 32.768.

Desplazamiento de historial (HO) 386: Quince bits, empezando por el bit 1 del byte 46, hasta el bit 7 del byte 47, del bloque de parámetros, contienen un número entero binario sin signo que especifica un desplazamiento en el tercer operando cuando el tipo de memoria intermedia de historial es circular. La suma del contenido de R3 y el desplazamiento de historial designa la ubicación del primer byte del historial dentro de la memoria intermedia de historial circular, que es el byte procesado menos recientemente de datos sin comprimir en la memoria intermedia. Cuando el tipo de memoria intermedia de historial es circular, el desplazamiento de historial es una entrada para la operación y se actualiza al final de la operación. Cuando la suma de la HL original y el número de bytes de datos sin comprimir procesados durante la operación es menor o igual que, por ejemplo, 32.768, el HO actualizado es igual al HO original; de lo contrario, el HO actualizado es igual a la suma del HO original, la HL original y el número de bytes de datos sin comprimir procesados durante la operación, módulo 32.768.

Cuando el tipo de memoria intermedia de historial está en línea, el campo HO del bloque de parámetros no está definido, pero puede modificarse.

Valor de comprobación 387: Los bytes 48-51 del bloque de parámetros contienen un valor de comprobación. Como parte de la operación, se genera un valor de comprobación. El valor de comprobación se aplica al operando de datos sin comprimir. Es decir, el valor de comprobación se aplica al segundo operando para la función DFLTCC-CMPR y se aplica al primer operando para la función DFLTCC-XPND. Cuando el bit 375 del CVT es cero, se genera, por ejemplo, un valor de comprobación de redundancia cíclica de 32 bits (CRC-32). Cuando el bit CVT es uno, se genera, por ejemplo, un valor de comprobación de suma de comprobación de Adler de 32 bits (Adler-32).

Las entradas para generar un valor de comprobación son, por ejemplo, una base de 4 bytes y los datos sin comprimir procesados durante la operación. La entrada base proporciona los medios para calcular un valor de comprobación único y coherente para un conjunto de bloques de datos comprimidos, independientemente del número de veces que se ejecute la instrucción DFLTCC para procesar el conjunto completo de bloques de datos comprimidos. Cuando el bit NT es cero, el valor original en el campo de valor de comprobación se usa como entrada base para generar un valor de comprobación.

En un ejemplo, cuando se genera un valor de comprobación Adler-32, se aplica lo siguiente:

• Cuando el bit NT es uno, se usa un valor uno para la entrada base de 4 bytes.

• Las sumas definidas en la generación del valor de comprobación Adler-32 son módulo 65.521.

• El resultado se almacena en el campo de valores de comprobación en orden de bytes de extremo mayor. Es decir, el byte más significativo del valor de comprobación está ubicado en el byte 48 y el byte menos significativo del valor de comprobación está ubicado en el byte 51.

En una realización, cuando se genera un valor de comprobación de CRC-32, se aplica lo siguiente:

• Cuando el bit NT es uno, se usa un valor cero para la entrada base de 4 bytes.

• El polinomio utilizado como divisor para generar un valor de comprobación de CRC-32 es x32 x26 x23 x22 x16 x12 x11 x10 x8 x7 x5 x4 x2 x1 x0, que se representa como 104C11DB7 hexadecimal. En esta representación, el bit más a la izquierda corresponde al bit más significativo.

• Las etapas primera y final de la generación del valor de comprobación consisten en calcular el complemento uno de la entrada base y calcular el complemento uno del resultado, antes de almacenar el resultado, respectivamente.

• El resultado se almacena en el campo de valores de comprobación en orden de bytes de extremo menor. Es decir, el byte menos significativo del valor de comprobación está ubicado en el byte 48 y el byte más significativo del valor de comprobación está ubicado en el byte 51.

En un ejemplo, el valor de comprobación solo es significativo para el programa cuando la operación termina con el código de condición 0 establecido; de lo contrario, el valor de comprobación es solo un resultado intermedio y solo es significativo para reanudar la operación. Cuando se especifica la función DFLTCC-CMPR y la operación termina con el código de condición 1,2 o 3 establecido, algunos bytes a la izquierda del byte designado por el segundo operando, es posible que la dirección no se incluya en el cálculo del valor de comprobación resultante. Cuando se especifica la función DFLTCC-XPND y la operación termina con el código de condición 1, 2 o 3 establecido, algunos bytes todavía no almacenados a la derecha del byte designado por el primer operando, es posible que la dirección ya se incluya en el cálculo del valor de comprobación resultante.

Símbolo de fin de bloque (EOBS) 388: Quince bits, empezando por el bit 0 del byte 52, hasta el bit 6 del byte 53, del bloque de parámetros, contienen un símbolo de fin de bloque (EOB). El campo 389 de longitud de final de bloque (EOBL) del bloque de parámetros especifica la longitud del símbolo EOB en el campo EOBS. El símbolo EOB está justificado a la izquierda en el campo EOBS. Los bits del campo EOBS no ocupados por el símbolo EOB se almacenan como ceros. El campo EOBS es una salida de la operación al comprimir datos, independientemente del tipo de tabla de Huffman que se aplique. El campo EOBS no se utiliza como una entrada para la operación.

El bit 0 del byte 52 contiene el bit más significativo del símbolo EOB. Cuando la longitud del símbolo EOB es de 7 bits, el bit 6 del byte 52 contiene el bit menos significativo del símbolo EOB. Cuando la longitud del símbolo EOB es de 15 bits, el bit 6 del byte 53 contiene el bit menos significativo del símbolo EOB.

Para los bloques que utilizan una FHT, el símbolo EOB es 0000000 binario, tal como se define en el estándar DEFLATE. Para los bloques que utilizan una DHT, la DHT define el símbolo EOB. El símbolo EOB se transmite para proporcionar la capacidad del programa de cerrar un bloque.

El campo EOBS no está definido cuando se especifica la función DFLTCC-XPND, pero puede modificarse.

Longitud de final del bloque (EOBL) 389: Los bits 0-3 del byte 54 del bloque de parámetros contienen un entero binario sin signo que especifica la longitud del símbolo de fin de bloque (EOB) en el campo EOBS 388 del bloque de parámetros. La longitud especifica el número de bits que ocupa el símbolo EOB en el campo EOBS. El campo EOBS es una salida de la operación al comprimir datos, independientemente del tipo de tabla de Huffman que se aplique. El campo EOBS no se utiliza como una entrada para la operación.

Longitud de tabla de Huffman dinámica comprimida (CDHTL) 366:

Tabla de Huffman dinámica comprimida (CDHT) 367: La representación comprimida de una DHT es una entrada a la operación cuando se especifica la función DFLTCC-CMPR, y HTT es uno. La función DFLTCC-CMPR no modifica el campo CDHT.

Memoria intermedia de estado de continuación (CSB) 392: Cuando las condiciones hacen que se almacene un valor de uno en el campo CF 373, los datos de estado interno se almacenan en los bytes 384-1535 del bloque de parámetros; de lo contrario, los bytes 384-1535 del bloque de parámetros no están definidos y pueden modificarse. Los datos de estado interno almacenados dependen del modelo y pueden usarse posteriormente para reanudar la operación. Se espera, pero no es obligatorio, que el programa inicialice la memoria intermedia de estado de continuación para que contenga, por ejemplo, todo ceros. Después de que la instrucción termine con un conjunto de códigos de condición distinto de cero, y antes de volver a ejecutar la instrucción con el fin de reanudar la operación, el programa no debe modificar la memoria intermedia de estado de continuación; de lo contrario, los resultados son impredecibles.

Aunque más arriba se describen diversos campos con respecto al bloque 370 de parámetros, en otras realizaciones se pueden incluir campos adicionales, menos campos y/u otros campos.

Más abajo se describe un ejemplo de la operación de compresión con respecto a la Compresión de Datos.

La finalización normal de la función DFLTCC-CCMPR tiene lugar cuando todo el segundo operando se comprime y almacena en la ubicación del primer operando. En un ejemplo, cuando la operación finaliza debido a una finalización normal, ocurre lo siguiente:

• Un valor dependiente del modelo se almacena en el campo 363 del número de versión del modelo (MVN) del bloque de parámetros.

• El campo 373 de indicador de continuación (CF) del bloque de parámetros se establece en cero.

• Se actualiza el campo 381 de límite de subbytes (SBB) del bloque de parámetros. Se actualizan los campos 389 de longitud de final de bloque (EOBL) y 388 de símbolo de final de bloque (EOBS) del bloque de parámetros.

• Se actualiza el campo 385 de longitud de historial (HL) del bloque de parámetros.

• El campo 386 de desplazamiento de historial (HO) del bloque de parámetros se actualiza, en caso aplicable.

• El campo 365 de código suplementario de finalización de operación (OESC) del bloque de parámetros se establece en ceros.

• Se actualiza el campo 387 de valor de comprobación del bloque de parámetros.

• La dirección en el registro general R1 se incrementa en el número de bytes procesados del primer operando que incluía el bit de procesamiento 0, y la longitud en el registro general R1 1 se reduce en el mismo número. El número de bytes procesados del primer operando que incluía el bit de procesamiento 0 es el cociente entero resultante de una división entera, siendo el dividendo la suma del número de bits de salida procesados y el valor original del SBB, y siendo el divisor un valor de ocho.

• La dirección en el registro general R2 se incrementa en el número de bytes de origen procesados, y la longitud en el registro general R2 1 se reduce en el mismo número.

• Se establece el código de condición 0.

La formación y actualización de las direcciones y longitudes dependen del modo de direccionamiento.

Cuando se produce una finalización normal, el campo CSB 392 del bloque de parámetros no está definido una vez finalizada la operación.

En un ejemplo, cuando se ha procesado un número de bytes determinado por la CPU, la operación finaliza y ocurre lo siguiente:

• El bit 373 de indicador de continuación (CF) en el bloque de parámetros se establece en uno.

• El campo 392 de memoria intermedia de estado de continuación (CSB) en el bloque de parámetros se actualiza.

• El campo 381 de límite de subbytes (SBB) del bloque de parámetros se actualiza.

• El campo 385 de longitud de historial (HL) del bloque de parámetros se actualiza.

• El campo 387 de valor de comprobación del bloque de parámetros se actualiza.

• Un valor dependiente del modelo se almacena en el campo 363 del número de versión de modelo (MVN) del bloque de parámetros.

• Los campos 389 de longitud de final de bloque (EOBL) y 388 de símbolo de final de bloque (EOBS) del bloque de parámetros se actualizan.

• La dirección en el registro general R1 se incrementa en el número de bytes procesados del primer operando que incluía el bit de procesamiento 0, y la longitud en el registro general R1 1 se reduce en el mismo número. El número de bytes procesados del primer operando que incluía el bit de procesamiento 0 es el cociente entero resultante de una división entera siendo el dividendo la suma del número de bits de salida procesados y el valor original del SBB, y siendo el divisor un valor de ocho.

• Se establece el código de condición 3.

El número de bytes determinado por la CPU depende del modelo y puede ser un número diferente cada vez que se ejecuta la instrucción.

Después de que la instrucción termine con el código de condición 3 establecido, se espera que el programa no modifique ninguna especificación de entrada o salida de la instrucción y se ramifique para volver a ejecutar la instrucción para reanudar la operación.

En ciertas situaciones, a pesar de finalizar la instrucción con el código de condición 3 establecido, el bloque de parámetros y los registros generales no se actualizan. Estas situaciones pueden producirse cuando la CPU realiza una operación de inactividad o reintenta la CPU mientras ejecuta la instrucción de Llamada de Conversión DEFLATE. En estos casos, el número de bytes procesados determinado por la CPU es cero, los datos pueden haberse almacenado en la ubicación del primer operando, los datos pueden haberse almacenado en la ubicación del tercer operando, en caso aplicable, y se han establecido bits de cambio correspondientes.

En un ejemplo, la longitud del primer operando no es suficiente para completar la operación cuando se cumple alguna de las siguientes condiciones:

• La longitud del primer operando, tal como se especifica en el contenido del registro general R1 1, es cero al comienzo de la ejecución de la instrucción.

• La longitud del primer operando pasa a ser igual a cero durante la ejecución de la instrucción y no se produce una finalización normal.

En un ejemplo, la longitud del primer operando es cero cuando el contenido del registro general R1 1 es cero, independientemente de los valores en los campos NT y SBB del bloque de parámetros.

En una realización, cuando la longitud del primer operando pasa a ser igual a cero durante la ejecución de la instrucción, la operación finaliza y ocurre lo siguiente:

• El bit 373 del indicador de continuación (CF) en el bloque de parámetros se establece en uno.

• El campo 386 de desplazamiento de historial (HO) del bloque de parámetros se actualiza, en caso aplicable. • El campo 387 de valor de comprobación del bloque de parámetros se actualiza.

• Un valor dependiente del modelo se almacena en el campo 363 de número de versión del modelo (MVN) del bloque de parámetros.

• Se establece el código de condición 1.

En una realización, cuando la longitud del primer operando es cero al principio de la ejecución de la instrucción, la operación finaliza y tiene lugar lo siguiente:

• Se establece el código de condición 1.

Después de que la instrucción termine con el código de condición 1 establecido, se espera que el programa modifique la longitud del primer operando, la dirección del primer operando, o ambas, y vuelva a ejecutar la instrucción para reanudar la operación.

Se reconoce un evento de alteración de almacenamiento PER, en caso aplicable, para lo siguiente:

• Almacena en el bloque de parámetros, como se describe más abajo.

• Almacena en la ubicación del primer operando.

• Almacena en la ubicación del tercer operando, lo que tiene lugar, por ejemplo, cuando el tipo de memoria intermedia de historial (HBT) es uno (circular).

Cuando todo el bloque de parámetros se superpone a la designación de área de almacenamiento PER, se reconoce un evento de alteración de almacenamiento PER, en caso aplicable, para el bloque de parámetros. Cuando solo una parte del bloque de parámetros se superpone a la designación de área de almacenamiento PER, depende del modelo cuál de las siguientes situaciones tiene lugar:

• Se reconoce un evento de alteración de almacenamiento PER, en caso aplicable, para el bloque de parámetros.

• Se reconoce un evento de alteración de almacenamiento PER, en caso aplicable, para la parte del bloque de parámetros que se almacena.

En caso aplicable, se reconoce un evento PER de detección de dirección cero para el bloque de parámetros, la ubicación del primer operando, la ubicación del segundo operando y la ubicación del tercer operando cuando el HBT es uno (circular).

El código de condición 2 no es aplicable a la función DFLTC-CCMPR.

Cuando la instrucción termina con el código de condición 1 o 3 establecido, los datos de entrada referenciados desde la ubicación del segundo operando pueden procesarse por completo, o solo parcialmente. Cuando los datos de entrada se procesan solo parcialmente, los resultados de la ubicación del primer operando, la dirección del primer operando, la longitud del primer operando y el campo SBB del bloque de parámetros no representan un estado coherente con la dirección y longitud del segundo operando actualizadas. En estos casos, los datos parcialmente procesados y la información de estado interno pueden situarse en el campo CSB del bloque de parámetros. La cantidad de datos procesados parcialmente depende de las condiciones existentes en el momento en que finaliza la operación y del modelo. Aunque algunos datos solo pueden procesarse parcialmente, los resultados almacenados a la izquierda de la ubicación designada por la dirección del primer operando actualizada están completos y no se modificarán cuando se reanude la operación. Además, se espera que el programa vuelva a ejecutar a continuación la instrucción para reanudar la operación, momento en el que se hace referencia al contenido del campo CSB antes de reanudar la operación. Cuando la instrucción termina con el código de condición 0 establecido, todos los datos se procesan por completo y todos los resultados asociados con los datos de entrada y salida representan un estado coherente.

Después de que la instrucción termine con un conjunto de códigos de condición distinto de cero, y antes de volver a ejecutar la instrucción con el fin de reanudar la operación, el programa no debe modificar ningún campo del bloque de parámetros; de lo contrario, los resultados son impredecibles.

Código de función 4: DFLTCC-XPND (Expandir)

Cuando se especifica la función DFLTCC-XPND, se realiza una operación de descompresión. La operación incluye descodificar símbolos de datos comprimidos de la ubicación del segundo operando en símbolos de datos descomprimidos, que se almacenan en la ubicación del primer operando.

En un ejemplo, la función DFLTCC-XPND usa un bloque de parámetros, un ejemplo del cual se ha descrito más arriba con respecto a las FIGS. 3K-3L.

Un ejemplo de la operación DFLTCC-XPND se describe más abajo con respecto a la Descompresión de Datos.

La finalización normal tiene lugar cuando todos los elementos del bloque final del conjunto de datos en el segundo operando se descodifican y todos los datos sin comprimir se almacenan en la ubicación del primer operando. El último bloque del conjunto de datos se identifica cuando el bit BFINAL del encabezado de bloque es uno. En una realización, cuando la operación termina debido a una finalización normal, ocurre lo siguiente:

• Un valor dependiente del modelo se almacena en el campo 363 de número de versión de modelo (MVN) del bloque de parámetros.

• El campo 373 de indicador de continuación (CF) del bloque de parámetros se establece en cero. El campo 381 de límite de subbytes (SBB) del bloque de parámetros se actualiza.

• Los campos 367 de tabla de Huffman dinámica comprimida (CDHT) y 366 de longitud de tabla de Huffman dinámica comprimida (CDHTL) del bloque de parámetros se establecen en ceros.

• La dirección en el registro general R1 se incrementa en el número de bytes almacenados en la ubicación del primer operando, y la longitud en el registro general R1 1 se reduce en el mismo número.

• La dirección en el registro general R2 se incrementa en el número de bytes procesados del segundo operando que incluía el bit de procesamiento 0, y la longitud en el registro general R2 1 se reduce en el mismo número. El número de bytes procesados del segundo operando que incluía la posición de bit de procesamiento 0 es el cociente entero resultante de una división entera, siendo el dividendo la suma del número de bits de entrada procesados y el valor original del SBB, y siendo el divisor un valor de ocho.

• Se establece el código de condición 0.

En una realización, cuando se ha procesado un número de bytes determinado por la CPU, la operación finaliza y ocurre lo siguiente:

• Los campos 367 de tabla de Huffman dinámica comprimida (CDHT) y 366 de longitud de tabla de Huffman dinámica comprimida (CDHTL) del bloque de parámetros se actualizan. Cuando se produce una finalización parcial mientras se procesa un bloque con un valor BTYPE de 10 binario, los bytes del campo CDHT que no son necesarios para representar la tabla se almacenan como ceros. Cuando se produce una finalización parcial mientras se procesa un bloque con un valor BTYPE de 00 o 01 binario, los ceros se almacenan en los campos CDHT y CDHTL.

• El campo 383 de estado de función incompleta (IFS) del bloque de parámetros se actualiza.

• El campo 384 de longitud de función incompleta (IFL) del bloque de parámetros se actualiza, en caso aplicable.

• La dirección en el registro general R2 se incrementa en el número de bytes procesados del segundo operando que incluía el bit de procesamiento 0, y la longitud en el registro general R2 1 se reduce en el mismo número. El número de bytes procesados del segundo operando que incluía el bit de procesamiento 0 es el cociente entero resultante de una división entera, siendo el dividendo la suma del número de bits de entrada procesados y el valor original del SBB, y siendo el divisor un valor de ocho.

• Se establece el código de condición 3.

En ciertas situaciones, a pesar de finalizar la instrucción con el código de condición 3 establecido, el bloque de parámetros y los registros generales no se actualizan. Estas situaciones pueden producirse cuando la CPU realiza una operación de inactividad o reintenta la CPU mientras ejecuta la instrucción de Llamada de Conversión DEFLATE. En estos casos, el número de bytes procesados determinado por la CPU es cero, los datos pueden haberse almacenado en la ubicación del primer operando, los datos pueden haberse almacenado en la ubicación del tercer operando, en caso aplicable, y se han establecido los bits de cambio correspondientes.

La longitud del segundo operando no es suficiente para completar la operación cuando se aplica lo siguiente, por ejemplo:

• El último elemento de un bloque de datos comprimido con BFINAL igual a uno no se ha descodificado durante la operación, y el número de bits en el segundo operando, tal como se designa mediante la longitud del segundo operando y el SBB, es menor que el número de bits del siguiente elemento que ha de ser descodificado y todos los resultados de los datos de descodificación de la ubicación del segundo operando se han situado en la ubicación del primer operando.

Cuando la longitud del segundo operando no es suficiente para completar la operación, la operación se ha completado parcialmente, la operación finaliza y ocurre lo siguiente, en una realización:

• Los campos 367 de tabla de Huffman dinámica comprimida (CDHT) y 366 de longitud de tabla de Huffman dinámica comprimida (CDHTL) del bloque de parámetros se actualizan. Cuando se produce una finalización parcial mientras se procesa un bloque con un valor BTYPE de 10 binario, los bytes del campo CDHT que no son necesarios para representar la tabla se almacenan como ceros. Cuando se produce una finalización parcial mientras se procesa un bloque con un valor BTYPE de 00 o 01 binario, se almacenan ceros en los campos CDHT y CDHTL.

• Se establece el código de condición 2.

Después de que la instrucción termine con el código de condición 2 establecido, se espera que el programa modifique la longitud del segundo operando, la dirección del segundo operando, o ambas, y vuelva a ejecutar la instrucción para reanudar la operación.

• Los resultados de la descodificación de datos de la ubicación del segundo operando no se pueden situar en la ubicación del primer operando debido a que la longitud del primer operando es igual a cero.

Cuando la longitud del primer operando no es suficiente para completar la operación, la operación se ha completado parcialmente, la operación finaliza y ocurre lo siguiente, en una realización:

• El campo 386 de desplazamiento de historial (HO) del bloque de parámetros se actualiza, en caso aplicable. • El campo de valor de comprobación 387 del bloque de parámetros se actualiza.

• Se establece el código de condición 1.

• Almacena en el bloque de parámetros, tal como se describe en la presente memoria.

• Almacena en la ubicación del primer operando.

• Almacena en la ubicación del tercer operando, lo que ocurre, por ejemplo, cuando el tipo de memoria intermedia de historial (HBT) es uno (circular).

En un ejemplo, cuando todo el bloque de parámetros se superpone a la designación de área de almacenamiento PER, se reconoce un evento de alteración de almacenamiento PER, en caso aplicable, para el bloque de parámetros. En una realización, cuando solo una parte del bloque de parámetros se superpone a la designación de área de almacenamiento PER, depende del modelo cuál de las siguientes situaciones tiene lugar:

En caso aplicable se reconoce un evento de detección de dirección cero PER para el bloque de parámetros, la ubicación del primer operando, la ubicación del segundo operando y la ubicación del tercer operando cuando el HBT es uno (circular).

Cuando la instrucción termina con el código de condición 1, 2 o 3 establecido, los datos de entrada a los que se hace referencia desde la ubicación del segundo operando pueden procesarse por completo, o solo parcialmente. Cuando los datos de entrada se procesan solo parcialmente, dan como resultado la ubicación del primer operando, la dirección del primer operando, la longitud del primer operando, el campo SBB del bloque de parámetros, el campo del valor de comprobación del bloque de parámetros, el campo HL del bloque de parámetros, el campo IFS del bloque de parámetros y, en caso aplicable, la ubicación del tercer operando y el campo HO del bloque de parámetros no representan un estado coherente con la dirección y longitud del segundo operando actualizadas. En estos casos, los datos parcialmente procesados y la información de estado interno pueden situarse en el campo CSB del bloque de parámetros. La cantidad de datos procesados parcialmente depende de las condiciones existentes en el momento en que finaliza la operación y del modelo. Aunque algunos datos solo pueden procesarse parcialmente, los resultados almacenados a la izquierda de la ubicación designada por la dirección del primer operando actualizada están completos y no se modificarán cuando se reanude la operación. Además, se espera que el programa vuelva a ejecutar posteriormente la instrucción para reanudar la operación, momento en el que se hace referencia al contenido del campo CSB antes de reanudar la operación. Cuando la operación termina con el código de condición 0 establecido, todos los datos se procesan por completo y todos los resultados asociados con los datos de entrada y salida representan un estado coherente.

Bloques de datos comprimidos

En un ejemplo, los bytes de un bloque de datos comprimido almacenado se procesan, por ejemplo, de izquierda a derecha. Los bloques de datos comprimidos pueden, o no, comenzar o terminar en los límites de los bytes. Un bloque de datos comprimido es, por ejemplo, un flujo de bits. Los elementos del bloque se cargan en el almacenamiento bit a bit. El flujo de bits se carga, por ejemplo, de derecha a izquierda dentro de cada byte de almacenamiento y en orden de bytes, por ejemplo, de izquierda a derecha. Cuando el elemento es un código de Huffman, los bits se almacenan en orden, por ejemplo, del bit más significativo al bit menos significativo del elemento. Cuando el elemento es un código de Huffman, los bits se almacenan en orden, por ejemplo, del bit más significativo al bit menos significativo del elemento.

La FIG. 6 ilustra un ejemplo de un bloque 600 con un de tipo de bloque 00 binario, que no contiene símbolos de datos comprimidos. Lo siguiente se aplica a este ejemplo, en una realización:

• El bloque 600 de datos comprimidos consiste en un flujo 602 de bits que comienza con el bit 4 del byte 0, identificado como b0, y termina con el bit 0 del byte 7, identificado como b60.

• El primer elemento encontrado en el flujo de bits es BFINAL (bit final de encabezado de bloque) en el bit 4 del byte 0.

• El segundo elemento encontrado en el flujo de bits es BTYPE (tipo de bloque) en los bits 2-3 del byte 0. En este ejemplo, el BTYPE es 00 binario.

• Los bits a la izquierda del BTYPE y a la derecha de un límite de byte se ignoran cuando el BTYPE es 00 binario, que son los bits 0-1 del byte 0 en este ejemplo.

• El tercer elemento encontrado en el flujo de bits es el byte menos significativo (LSB) del campo LEN, al que sigue el byte más significativo (MSB) del campo LEN. El campo LEN especifica el número de bytes del bloque con datos literales. Los datos literales son, por ejemplo, datos sin comprimir. Los bytes con datos literales siguen al campo NLEN en el flujo de bits. La NLEN es el complemento uno de LEN. En un ejemplo, los bytes 1-2 contienen el campo LEN en orden de bytes de extremo menor.

• Los elementos encontrados en el flujo de bits que sigue al campo LEN son el byte menos significativo del campo NLEN, seguido del byte más significativo del campo NLEN, respectivamente. Los bytes 3 y 4 contienen el campo NLEN en un orden de bytes de extremo menor. El campo NLEN es el complemento uno del campo LEN.

• Los elementos que se encuentran en el flujo de bits que sigue al campo NLEN son datos sin comprimir, identificados como bytes literales. Los bytes 5-7 contienen datos sin comprimir, que no se modifican con respecto a los datos de origen utilizados para generar este bloque.

• Ninguno de los elementos contenidos en este bloque es un código de Huffman. Cada elemento de este bloque se almacena en el orden del flujo de bits desde el bit menos significativo hasta el bit más significativo del elemento, tal como se define en el estándar DEFLATE. Dado que los elementos LEN, NLEN y literales son cada uno un número entero de bytes alineados en los límites de bytes, estos elementos pueden procesarse como unidades de bytes y no necesariamente como unidades de bits.

La FIG. 7 ilustra un ejemplo de un bloque 700 con un tipo de bloque 01 binario, que contiene símbolos de datos comprimidos generados utilizando una tabla de Huffman fija (FHT). Lo siguiente se aplica a este ejemplo, en una realización:

• El bloque 700 de datos comprimidos consiste en un flujo 702 de bits que comienza con el bit 4 del byte 0, identificado como b0, y termina con el bit 3 del byte 11, identificado como b89.

• El primer elemento encontrado en el flujo de bits es BFINAL en el bit 4 del byte 0.

• El segundo elemento encontrado en el flujo de bits es BTYPE en los bits 2-3 del byte 0. En este ejemplo, el BTYPE es 01 binario.

• La tabla de Huffman fija (FHT) no es un componente del bloque.

• El tercer elemento encontrado en el flujo de bits es el primer símbolo de datos comprimidos, que comienza en el bit 1 del byte 0. Un símbolo de datos comprimidos consiste en los siguientes subelementos que se encuentran en el flujo de bits en el orden en que se enumeran, en un ejemplo:

1. Un código de Huffman de longitud variable. Los bits más significativos del código designan la longitud del código. El código se encuentra en el flujo de bits que comienza con el bit más significativo del código y termina con el bit menos significativo del código. Cuando el código representa un valor literal o el símbolo de fin de bloque, el código es el único subelemento del símbolo de datos comprimidos. Cuando el código representa la longitud de un puntero a la memoria intermedia de historial, el código va seguido de subelementos subsiguientes del símbolo de datos comprimidos.

2. En caso aplicable, según lo especificado por el estándar DEFLATE, los bits de longitud adicional pueden seguir al código de Huffman que representa una longitud de puntero. Los bits de longitud adicional se encuentran en el flujo de bits que comienzan con el bit menos significativo y terminan con el bit más significativo de los bits de longitud adicional.

3. El siguiente subelemento encontrado en el flujo de bits es un código de distancia de 5 bits de un puntero a la memoria intermedia de historial. El código de distancia se encuentra en el flujo de bits que comienza con, por ejemplo, el bit más significativo del código y termina con el bit menos significativo del código de distancia.

4. En caso aplicable, según lo especificado en el estándar DEFLATE, los bits de distancia adicionales pueden seguir el código de distancia. Los bits de distancia adicionales se encuentran en el flujo de bits que comienzan con el bit menos significativo y terminan con el bit más significativo de los bits de distancia adicionales.

• Los bits 0-1 del byte 0, todos los bits de los bytes del 1 al 9 y los bits 2-7 del byte 10 contienen bits de símbolos de datos comprimidos, por ejemplo.

• El último elemento encontrado en el flujo de bits es un símbolo de datos comprimidos que contiene un único subelemento, que es el código de Huffman que representa el símbolo de fin de bloque (EOB). El símbolo EOB para un bloque con BTYPE 01 binario es 0000000 binario. En este ejemplo, el bit 1 del byte 10 contiene el bit más significativo del símbolo EOB y el bit 3 del byte 11 contiene el bit menos significativo del símbolo EOB.

• El bit 3 del byte 11 contiene el último bit del flujo de bits, que es el último bit del bloque de datos comprimido.

La FIG. 8 ilustra un ejemplo de un bloque 800 con un tipo de bloque 10 binario, que contiene símbolos de datos comprimidos generados utilizando una tabla de Huffman dinámica (DHT). En una realización, lo siguiente se aplica a este ejemplo:

• El bloque 800 de datos comprimidos consiste en un flujo 802 de bits que comienza con el bit 4 del byte 0, identificado como b0, y termina con el bit 3 del byte 11, identificado como b89.

• El segundo elemento encontrado en el flujo de bits es BTYPE en los bits 2-3 del byte 0. En este ejemplo, el BTYPE es 10 binario.

• El tercer elemento encontrado en el flujo de bits es la representación comprimida de la tabla de Huffman dinámica (DHT), que comienza en el bit 1 del byte 0. La representación comprimida de la DHT consiste en los siguientes subelementos, que se encuentran en el flujo de bits en el orden en que se enumeran, en un ejemplo:

1. HLIT: La suma del subelemento HLIT de 5 bits y 257 especifica el número de códigos de Huffman que representan bytes literales, un símbolo EOB y longitudes de cadenas duplicadas. Los valores válidos de HLIT oscilan, por ejemplo, entre 0 y 29. Los bits de HLIT se encuentran en el flujo de bits que comienza con el bit menos significativo y termina con el bit más significativo del subelemento de HLIT. En este ejemplo, el bit 1 del byte 0, identificado como b3, es el bit menos significativo del subelemento HLIT.

2. HDIST: La suma del subelemento HDIST de 5 bits y 1 especifica el número de códigos de Huffman que representan distancias de punteros de cadenas duplicadas. Los valores válidos de HDIST oscilan, por ejemplo, entre 0 y 29. Los bits de HDIST se encuentran en el flujo de bits que comienza con el bit menos significativo y termina con el bit más significativo del subelemento de HDIST.

3. HCLEN: La suma del subelemento HCLEN de 4 bits y 4 especifica el número de códigos de Huffman que representan longitudes de códigos. Los valores válidos de HCLEN oscilan, por ejemplo, entre 0 y 15. Los bits de HCLEN se encuentran en el flujo de bits que comienza con el bit menos significativo y termina con el bit más significativo del subelemento de HCLEN.

4. Una secuencia de códigos que especifican una longitud de bits para cada una de las longitudes de código definidas para la DHT comprimida. El número de códigos es igual a la suma de HCLEN y 4. Cada código es de 3 bits.

5. Una secuencia de códigos que especifica una longitud de código para cada uno de los elementos del conjunto formado por bytes literales, un símbolo EOB y longitudes de cadena duplicadas. El número de longitudes de código especificadas es igual a la suma de HLIT y 257.

Cuando la última longitud de código (CL) para el conjunto de bytes literales, un símbolo EOB y longitudes de cadenas duplicadas es 16, 17 o 18, y los bits adicionales que siguen a la CL especifican la repetición de la CL para más elementos que los definidos para el conjunto, la longitud de código también se aplica al conjunto de distancias de puntero de cadenas duplicadas. La secuencia de códigos que especifican longitudes de código para el conjunto de bytes literales, un símbolo EOB y longitudes de cadenas duplicadas, seguida de la secuencia de códigos que especifica longitudes de código para las distancias de puntero de cadenas duplicadas, es una secuencia contigua para ambos conjuntos.

6. Una secuencia de códigos que especifica una longitud de código para cada uno de los elementos del conjunto que consiste en distancias de puntero de cadenas duplicadas. El número de longitudes de código especificadas es igual a la suma de HDIST y 1.

• El cuarto elemento encontrado en el flujo de bits es el primer símbolo de datos comprimidos. Un símbolo de datos comprimidos consiste en los siguientes subelementos, que se encuentran en el flujo de bits en el orden en el que se enumeran, en una realización:

1. Un código de Huffman de longitud variable. Los bits más significativos del código designan la longitud del código. El código se encuentra en el flujo de bits que comienza con el bit más significativo del código y termina con el bit menos significativo del código. Cuando el código representa un valor literal o el símbolo de fin de bloque, el código es el único subelemento del símbolo de datos comprimidos. Cuando el código representa la longitud de un puntero a la memoria intermedia de historial, el código va seguido de subelementos del símbolo de datos comprimidos.

2. En caso aplicable, según lo especificado por el estándar DEFLATE, los bits de longitud adicional pueden seguir al código de Huffman que representa una longitud de puntero. Los bits de longitud adicional se encuentran en el flujo de bits que comienzan, por ejemplo, con el bit menos significativo y terminan con el bit más significativo de los bits de longitud adicional.

3. El siguiente subelemento encontrado en el flujo de bits es un código de distancia de 5 bits de un puntero a la memoria intermedia de historial. El código de distancia se encuentra en el flujo de bits que comienza, por ejemplo, con el bit más significativo del código y termina con el bit menos significativo del código de distancia.

4. En caso aplicable, según lo especificado en el estándar DEFLATE, los bits de distancia adicional pueden seguir el código de distancia. Los bits de distancia adicional se encuentran en el flujo de bits que comienza, por ejemplo, con el bit menos significativo y termina con el bit más significativo de los bits de distancia adicional.

• Los bits subsiguientes encontrados en el flujo de bits, hasta e inclusive, por ejemplo, el bit 5 del byte 10, contienen bits de símbolos de datos comprimidos.

• El último elemento encontrado en el flujo de bits es un símbolo de datos comprimidos que contiene un único subelemento, que es el código de Huffman que representa el símbolo de fin de bloque (EOB). En este ejemplo, el bit 4 del byte 10 contiene el bit más significativo del símbolo EOB y el bit 3 del byte 11 contiene el bit menos significativo del símbolo EOB.

• El bit 3 del byte 11 contiene el último bit del flujo de bits, que es el último bit del bloque de datos comprimidos.

En las descripciones anteriores de los diversos tipos de bloques se especifican ciertos valores constantes, así como bits, bytes, direcciones, etc. específicos. Estos son solo ejemplos. En otras realizaciones se pueden especificar otros valores constantes, bits, bytes, direcciones, etc.

Procesamiento de un conjunto de datos comprimidos

Se proporcionan ejemplos de procesamiento de un conjunto de datos comprimidos para ilustrar usos ejemplares de la instrucción de Llamada de Conversión DEFLATE y aumentar las descripciones de varios campos del bloque de parámetros. Los ejemplos no describen todos los escenarios, requisitos y capacidades posibles, pero ilustran varios de los escenarios, requisitos y/o capacidades. Los ejemplos y descripciones se aplican, por ejemplo, a un conjunto de datos comprimidos almacenado, un ejemplo del cual se ilustra en la FIG. 9. Como se muestra, un conjunto 900 de datos comprimidos incluye una pluralidad de bloques 902 de datos comprimidos, y el comienzo del conjunto 900 de datos se indica mediante una dirección 904 de inicio del conjunto de datos comprimidos (CDSBA).

Para los ejemplos descritos en la presente memoria, se pretende que un programa que procesa el conjunto de datos comprimidos tenga en cuenta lo siguiente, en una realización:

• Se puede definir y referenciar un único bloque de parámetros mediante múltiples usos de la instrucción de Llamada de Conversión DEFLATE para procesar todo el conjunto de datos comprimidos. Los campos 387 de valor de comprobación y 375 de tipo de valor de comprobación del bloque de parámetros se aplicarán a los bloques de datos comprimidos (por ejemplo, todos los bloques) del conjunto de datos comprimidos. El campo 381 de límite de subbytes del bloque de parámetros se aplicará a transiciones entre bloques individuales. La longitud 385 de historial y el desplazamiento 386 de historial pueden aplicarse a múltiples bloques. Los campos restantes del bloque de parámetros solo se aplican, en un ejemplo, al bloque de datos comprimido individual que se procesa mediante una ejecución específica de una instrucción de Llamada de Conversión DEFLATE.

• Un valor de comprobación individual se aplica, por ejemplo, a todos los datos sin comprimir representados por el conjunto de datos comprimidos.

• No hay ningún historial para el primer símbolo de datos comprimidos en el bloque 1 al que hacer referencia. Los símbolos subsiguientes en el bloque 1 pueden hacer referencia al historial correspondiente a los símbolos previamente encontrados en el bloque 1. Los símbolos en el bloque 2 pueden hacer referencia al historial correspondiente a los símbolos previamente encontrados en los bloques 2 y 1. Los símbolos en el bloque 3 pueden hacer referencia al historial correspondiente a los símbolos previamente encontrados en los bloques 3, 2 y 1.

La FIG. 10 enumera un ejemplo de una parte de un programa 1000 de muestra usado para comprimir datos en el conjunto 900 de datos comprimidos descrito en la FIG. 9. Además, la FIG. 11 enumera los valores para ciertos campos del bloque de parámetros usado durante la ejecución de la instrucción DFLTCC ubicada en la dirección de instrucción etiquetada como IABLK1 (1002) en la FIG. 10. Por ejemplo, la FIG. 11 representa varios campos 1100 de bloques de parámetros; valores para esos campos al inicio de la operación 1102 de compresión; valores para esos campos al final de la operación cuando el código de condición 1,2 o 3 se establece 1104; y valores para esos campos al final de la operación cuando el código de condición 0 se establece 1106.

De manera similar, la figura 12 enumera los valores para ciertos campos del bloque de parámetros usado durante la ejecución de la instrucción DFLTCC ubicada en la dirección de instrucción etiquetada como IABLK2 (1004) de la figura 10. Estas figuras muestran algunos de los detalles relacionados con el uso de la instrucción de Llamada de Conversión DEFLATE varias veces para procesar un conjunto completo de datos comprimidos.

Además, haciendo referencia a la FIG. 13, en ella se representa un ejemplo de una parte de un programa 1300 de muestra utilizado para descomprimir datos del conjunto de datos comprimidos de la FIG. 9.

Compresión de datos

El proceso de compresión de datos incluye generar uno o más bloques de datos comprimidos. La función de compresión de la instrucción de Llamada de Conversión DEFLATE se usa para construir una parte de un bloque individual. La parte puede consistir en todo el bloque. Esta función genera partes de un bloque con tipo de bloque (BTYPE) 01 o 10 binario, y no 00 binario. Cuando el nuevo bit de tarea (NT) del bloque de parámetros es uno, se genera el primer bloque de datos comprimidos y no hay ningún historial al que hacer referencia de las operaciones de compresión previamente realizadas.

En un ejemplo, un bloque individual contiene los siguientes elementos en el orden en que se enumeran:

1. Indicación de bloqueo final (BFINAL).

2. Tipo de bloque (BTYPE).

3. Formato comprimido de una tabla de Huffman dinámica, en caso aplicable.

4. Símbolos de datos comprimidos.

5. Símbolo de fin de bloque (EOB).

La operación de compresión genera los elementos especificados en el orden definido para un bloque. Los elementos pueden comenzar o terminar entre los límites de bytes en el almacenamiento. El límite de subbytes (SBB) se aplica al almacenamiento del primer elemento en la ubicación del primer operando. Un bloque de datos comprimidos es un flujo de bits. Los componentes del bloque se cargan en el almacenamiento bit a bit. El flujo de bits se carga, por ejemplo, de derecha a izquierda dentro de cada byte de almacenamiento y en orden de bytes de izquierda a derecha.

Cuando el SBB no es cero, la referencia al primer byte en la ubicación del primer operando es una referencia de actualización.

Los datos descomprimidos de la ubicación del segundo operando se comprimen y almacenan como símbolos de datos comprimidos en la ubicación del primer operando.

Cuando la longitud del primer operando es cero al comienzo de la ejecución de la instrucción, no se accede al primer operando, y la dirección del primer operando y la longitud del primer operando en los registros generales R1 y R1 1, respectivamente, no se cambian. Esto se aplica cuando el valor del campo CF 373 (FIG. 3L) es cero o uno al comienzo de la ejecución de la instrucción.

Cuando la longitud del segundo operando es cero al comienzo de la ejecución de la instrucción, no se accede al segundo operando, y la dirección del segundo operando y la longitud del segundo operando en los registros generales R2 y R2 1, respectivamente, no se cambian. La longitud del segundo operando es cero al principio de la ejecución de la instrucción para el siguiente caso, a modo de ejemplo:

• La instrucción se vuelve a ejecutar para reanudar la operación (el campo CF 373 del bloque de parámetros es uno al comienzo de la ejecución de la instrucción) y la finalización de la operación se puede realizar con referencias al campo CSB 392 del bloque de parámetros y sin referencias al segundo operando.

En una realización, el programa no debe utilizar la instrucción de Llamada de Conversión DEFLATE para realizar las siguientes operaciones:

• Generar un bloque de datos comprimidos vacío. Un bloque de datos comprimidos vacío consiste, por ejemplo, en un encabezado de bloque, un formato comprimido de una DHT en caso aplicable, y un símbolo EOB.

• Cerrar un bloque de datos comprimidos abierto. Es decir, almacenar solo un símbolo EOB al final del bloque de datos comprimidos.

El algoritmo de compresión incluye buscar un historial actualizado de datos comprimidos recientemente para una cadena de bytes que coincida con los datos que se están comprimiendo actualmente desde la ubicación del segundo operando. En una realización, antes de que comience o se reanude la operación de compresión, se aplica lo siguiente:

• Cuando la nueva tarea (NT) 374 es uno, no hay ningún historial inicial disponible como referencia.

• Cuando NT es cero y el bit 56 del registro general 0 (HBT) es cero (en línea), el historial inicial disponible como referencia está situado a la izquierda y adyacente al byte más a la izquierda del segundo operando, y la longitud del historial inicial se especifica mediante el campo 385 de longitud de historial (HL) del bloque de parámetros.

• Cuando NT es cero y el bit 56 del registro general 0 (HBT) es uno (circular), el historial inicial disponible como referencia está situado en la ubicación del tercer operando, tal como se especifica en los campos 386 de desplazamiento de historial (HO) y 385 de longitud de historial (HL) del bloque de parámetros.

Durante la operación de compresión se pueden hacer referencias de tipo búsqueda a todo el historial, independientemente de qué bytes de historial se utilicen para realizar la operación. Además, cuando el tipo de memoria intermedia de historial es circular, se pueden hacer referencias de tipo búsqueda a toda la memoria intermedia de historial de 32 K bytes, independientemente de qué bytes de historial se usen para realizar la operación.

Durante la operación de compresión se actualiza el historial. Después de codificar uno o más bytes de datos de origen en un símbolo de datos comprimidos sin encontrar una condición general de excepción de datos de operando, los bytes de origen se concatenan al final del historial. Los bytes procesados más recientemente de los datos de origen, hasta un máximo de 32 K bytes, constituyen el historial actualizado disponible para hacer referencia al procesar bytes posteriores de datos de origen.

Cuando finaliza la operación de compresión, se aplica lo siguiente, en un ejemplo, al historial resultante disponible para reanudar posteriormente la operación o iniciar otra operación:

• Cuando el HBT está en línea, no se requieren actualizaciones de almacenamiento en la ubicación del segundo operando cuando se actualiza el historial. La dirección del segundo operando actualizada y el HL actualizado especifican la ubicación actualizada y la longitud actualizada del historial resultante.

• Cuando el HBT es circular, las actualizaciones de almacenamiento en la ubicación del tercer operando se realizan cuando se actualiza el historial. La dirección del tercer operando, el HO actualizado y la HL actualizada especifican la ubicación actualizada y la longitud actualizada del historial resultante.

Como ejemplos, las FIGS. 14A-14C ilustran la ubicación de una memoria intermedia de historial en línea con respecto al segundo operando antes y después de múltiples ejecuciones de una instrucción de Llamada de Conversión DEFLATE con la función DFLTCC-CMPR especificada, así como el historial en línea especificado (por ejemplo, el bit 310 = 0), cuando cada ejecución termina con una finalización parcial. Por ejemplo, la FIG. 14A representa el historial en línea antes de la ejecución número 1 de DFLTCC-CMPR; la FIG. 14B representa el historial en línea antes de la ejecución número 2 de DFLTCC-CMPR y después de la ejecución número 1; y la FIG. 14C representa el historial en línea después de la ejecución número 2 de DFLTCC-CMPR. La explicación proporcionada en la FIG. 14C también se aplica a las FIGS. 14A y 14B.

Cuando el HBT (tipo de memoria intermedia de historial) especificado por el bit 56 del registro general 0 es circular (por ejemplo, el bit 310 = 1), el historial se mantiene, por ejemplo, en una memoria intermedia de 32 K bytes situada en la ubicación del tercer operando. La ubicación del primer byte de historial dentro de la memoria intermedia (HB) se designa, por ejemplo, mediante la suma de los contenidos del registro general R3 y el desplazamiento de historial (HO) 386 (FIG. 3L). El primer byte del historial es el byte procesado menos recientemente de datos sin comprimir en la memoria intermedia. La ubicación del último byte del historial dentro de la memoria intermedia (HE) se designa mediante la siguiente ecuación, a modo de ejemplo:

HE = R3 módulo32K(HO HL -1)

El primer byte del historial es el byte procesado más recientemente de datos sin comprimir en la memoria intermedia. Cuando la suma del desplazamiento de historial (HO) 386 (FIG. 3L) y la longitud del historial (HL) 385 supera el tamaño del tercer operando (por ejemplo, 32 K-bytes), el historial se cierra desde el final del tercer operando hasta el principio del tercer operando.

Como ejemplos, las FIGS. 15A-15E ilustran la ubicación del historial dentro de una memoria intermedia de historial circular antes y después de múltiples ejecuciones de una instrucción de Llamada de Conversión DEFLATE con la función DFLTCC-CMPR especificada, así como una memoria intermedia de historial circular especificado (bit 310 = 1), cuando cada ejecución termina con una finalización parcial. Por ejemplo, la FIG. 15A representa una memoria intermedia de historial circular antes de la ejecución de DFLTCC número 1; la FIG. 15B representa una memoria intermedia circular antes de la ejecución de DFLTCC número 2 y después de la ejecución número 1; la FIG. 15C representa una memoria intermedia circular antes de la ejecución de DFLTCC número 3 y después de la ejecución número 2; la FIG. 15D representa la memoria intermedia circular antes de la ejecución de DFLTCC número 4 y después de la ejecución número 3; y la FIG. 15E representa la memoria intermedia circular después de la ejecución de DFLTCC número 4. La explicación proporcionada en la FIG. 15E también se aplica a las FIGS. 15A-15D.

En un ejemplo, cuando el HBT es circular y el número de bytes procesados desde la ubicación del segundo operando es inferior a, por ejemplo, 32.768, se aplica lo siguiente:

• Los almacenamientos se realizan en un rango de bytes en la ubicación del tercer operando. El rango de bytes incluye y comienza con la ubicación designada por, por ejemplo:

R3 módulo32K(HOO HLO),

donde

HOO: El desplazamiento de historial antes de que se ejecute la instrucción.

HLO: La longitud de historial antes de que se ejecute la instrucción.

El rango de bytes incluye y termina en la ubicación designada por, por ejemplo:

R3 módulo32K(HOO HLO BP -1),

donde

BP: El número de bytes procesados desde la ubicación del segundo operando durante la ejecución de la instrucción.

Los almacenamientos realizados en el rango de bytes que acabamos de describir están sujetos a excepciones de acceso de tipo almacenamiento, eventos de alteración de almacenamiento PER y bits de cambio de configuración, por ejemplo.

• Los almacenamientos que no modifican el contenido de las ubicaciones de almacenamiento y no son necesarios pueden convertirse en bytes en la ubicación del tercer operando que no están incluidos en el rango que se acaba de describir. Los almacenamientos en dichas ubicaciones también están sujetos a excepciones de acceso por tipo de almacenamiento, eventos de alteración de almacenamiento PER y bits de cambio de configuración.

Cuando el HBT es circular y el número de bytes procesados desde la ubicación del segundo operando es mayor o igual que, por ejemplo, 32.768, los almacenamientos se realizan en todos los bytes de la ubicación del tercer operando y están sujetos a excepciones de acceso de tipo de almacenamiento, eventos de alteración de almacenamiento PER y bits de cambio de configuración.

Cuando el indicador 377 de continuación de bloque (BCF) es cero, se almacena un encabezado de bloque de 3 bits, que incluye BFINAL seguido de BTYPE, en la ubicación del primer operando. El bit BFINAL del encabezado de bloque se establece igual al bit final 379 de encabezado de bloque (BHF) del bloque de parámetros. Cuando el tipo 376 de tabla de Huffman (HTT) es cero, el campo BTYPE del encabezado de bloque se establece en, por ejemplo, 01 binario y cuando el HTT es uno, el campo BTYPE del encabezado de bloque se establece en, por ejemplo, 10 binario. Cuando se almacena un encabezado de bloque, el bit BFINAL se almacena en el bit especificado por el SBB en el primer byte del primer operando. Posteriormente, el BTYPE se almacena en la ubicación del primer operando. Cuando el BCF es uno, no se almacena un encabezado de bloque.

Cuando el tipo de tabla de Huffman (HTT) es uno, se examina el formato comprimido de la tabla 367 de Huffman dinámica (DHT) especificado en el bloque de parámetros para determinar las condiciones generales de excepción de datos de operando. Cuando existe una condición general de excepción de datos de operando para el formato comprimido especificado de la DHT, la DHT comprimida se designa como no válida y no debe usarse para comprimir datos. Más abajo se describen con más detalle definiciones de ejemplos de condiciones generales de excepción de datos de operando. Cuando el formato comprimido de la DHT especifica una longitud de bits para una longitud de código, o una longitud de código para un byte literal, el símbolo EOB, una longitud de cadena duplicada o una distancia de puntero de cadena duplicada, que es mayor que la longitud requerida por el algoritmo de Huffman para especificar un árbol de Huffman adecuado y funcional, la DHT comprimida todavía se usa para derivar una DHT funcional y comprimir datos. Cuando el indicador de continuación de bloque (BCF) es cero y el HTT es uno, el formato comprimido de la DHT, tal como se especifica en el campo CDHT 367 del bloque de parámetros, se almacena en la ubicación del primer operando.

Durante la operación de compresión, los datos de origen de la ubicación del segundo operando se codifican en símbolos de datos comprimidos. Como parte de la codificación, los datos de origen se comparan con el historial. Cuando no se encuentra ninguna coincidencia, la representación intermedia de los datos de origen son bytes literales, que son los mismos que los datos de origen. Cuando se encuentra una coincidencia, la representación intermedia de los datos de origen es un puntero a una ubicación dentro del historial que contiene una copia duplicada de los datos de origen. Un puntero consiste en una longitud y una distancia. La longitud es el número de bytes de datos de origen que coinciden con una cadena en el historial. La distancia es el número de bytes desde el final del historial hasta el principio de la cadena que coincide con los datos de origen. En un ejemplo se usan dos árboles de códigos de Huffman de la tabla de Huffman para codificar la representación intermedia de los datos de origen en símbolos de datos comprimidos. Cuando el tipo de tabla de Huffman (HTT) es cero, una tabla de Huffman fija (FHT), tal como se describe en el estándar DEFLATE, especifica los dos árboles de códigos de Huffman que se utilizan para codificar los resultados intermedios. Cuando HTT 376 es uno, la tabla de Huffman dinámica (DHT), que se deriva de la representación comprimida de la DHT, especificada en el campo CDHT 367 del bloque de parámetros, especifica los dos árboles de códigos de Huffman utilizados para codificar resultados intermedios. La codificación se realiza como se describe en el estándar DEFLATE. Cuando se usa una DHT no universal que no especifica un código de Huffman que ha de ser utilizado para codificar la representación intermedia de los datos de origen, se reconoce una excepción general de datos de operando. Los bits del símbolo de datos comprimidos resultante se organizan en el orden especificado por el estándar DEFLATE antes de almacenar el resultado en la ubicación del primer operando.

En un ejemplo, las longitudes de las cadenas duplicadas oscilan entre 3 y 258 bytes.

Antes de procesar más datos de origen se actualiza el historial, tal como se describe en la presente memoria.

El proceso se repite, en un ejemplo, hasta que se hayan procesado todos los bytes de origen.

Después de que se hayan procesado los bytes de origen (por ejemplo, todos los bytes de origen) y el control de cierre de bloque (BCC) 378 sea uno, se almacena un símbolo de fin de bloque (EOB) en la ubicación del primer operando. Cuando se usa una tabla de Huffman fija, se usa el código de Huffman 0000000 binario para el símbolo EOB. Cuando se usa una tabla de Huffman dinámica (DHT), la DHT especifica el código de Huffman utilizado para el símbolo EOB. Los bits del símbolo EOB se organizan en el orden especificado por el estándar DEFLATE antes de almacenar el símbolo EOB en la ubicación del primer operando.

En un ejemplo, cuando el último símbolo de datos comprimidos de la operación (incluido el símbolo EOB) solo ocupa una parte del último byte que ha de ser almacenado, los bits que no contienen una parte del último símbolo se almacenan como ceros.

En una realización, tras procesar el último símbolo de datos comprimido, ocurre lo siguiente:

• El campo 381 de límite de subbytes (SBB) del bloque de parámetros se actualiza. Los campos 389 de longitud de final de bloque (EOBL) y 388 de símbolo de final de bloque (EOBS) del bloque de parámetros se actualizan.

Coincidiendo con la compresión de los datos de origen, los datos de origen son una entrada para generar un valor de comprobación de 32 bits, descrito más arriba. El valor de comprobación resultante se almacena en el campo 387 de valor de comprobación del bloque de parámetros.

Descompresión de datos

En una realización, la función de expansión de la instrucción de Llamada de Conversión DEFLATE se usa para descodificar un conjunto de datos comprimidos en datos sin comprimir. El conjunto de datos comprimidos en la ubicación del segundo operando incluye uno o más bloques de datos comprimidos consecutivos. Los bloques del conjunto de datos se procesan de izquierda a derecha, en un ejemplo, y los bytes de un bloque se procesan, por ejemplo, de izquierda a derecha. Los bloques pueden o no comenzar o terminar en los límites de los bytes. Cada bloque se descodifica independientemente de otros bloques del conjunto de datos. El registro general R2 especifica la dirección lógica del byte situado más a la izquierda del primer bloque del conjunto de datos. El último bloque del conjunto de datos es el bloque encontrado durante el procesamiento con el bit BFINAL igual a uno. En un ejemplo hay tres tipos de bloques que han de ser procesados. La técnica de descodificación del contenido de un bloque es una función del tipo de bloque (BTYPE).

Cuando comienza la operación (por ejemplo, cuando el campo 373 de indicador de continuación del bloque de parámetros es cero), el bit designado por el registro general R2, el campo 374 de nueva tarea (NT) y el campo 381 de límite de subbytes (SBB) se interpreta como el primer bit de un bloque de datos comprimidos (el bit BFINAL de un encabezado de bloque).

La función de expansión incluye hacer referencia a un historial actualizado de datos descomprimidos recientemente descodificados. En una realización, antes de que comience o se reanude la operación de descompresión, se aplica lo siguiente:

• Cuando NT es cero y el bit 56 del registro general 0 (HBT) es cero (en línea), el historial inicial disponible como referencia está situado a la izquierda y adyacente al byte más a la izquierda del primer operando, y la longitud del historial inicial se especifica mediante el campo 385 de longitud de historial (HL) del bloque de parámetros.

Durante la operación se pueden hacer referencias de tipo búsqueda a todo el historial, independientemente de qué bytes de historial se utilicen para realizar la operación. Además, cuando el tipo de memoria intermedia de historial es circular, se pueden hacer referencias de tipo búsqueda a toda la memoria intermedia de historial (por ejemplo, 32 K bytes), independientemente de qué bytes de historial se usen para realizar la operación.

El historial se actualiza durante la operación de descompresión. Después de descodificar los datos de origen sin encontrar una condición general de excepción de datos de operando, los bytes resultantes de los datos sin comprimir se concatenan al final del historial. Los bytes descodificados más recientemente de datos sin comprimir, hasta un máximo de 32 K bytes, constituyen el historial actualizado disponible como referencia al procesar datos de origen posteriores.

En un ejemplo, cuando finaliza la operación de descompresión se aplica lo siguiente al historial resultante disponible para reanudar posteriormente la operación o iniciar otra operación:

• Cuando el HBT es en línea, las actualizaciones de almacenamiento en la ubicación del primer operando también constituyen actualizaciones del historial resultante. La dirección del primer operando actualizada y la HL actualizada especifican la ubicación actualizada y la longitud actualizada del historial resultante.

Como ejemplos, las FIGS. 16A-16C ilustran ejemplos de la ubicación de una memoria intermedia de historial en línea con respecto al primer operando antes y después de múltiples ejecuciones de una instrucción de Llamada de Conversión DEFLATE con la función DFLTCC-XPND especificada, así como el historial en línea especificado, cuando cada ejecución termina con una finalización parcial. La longitud 385 de historial (HL) se modifica durante la operación. Por ejemplo, la FIG. 16A representa un ejemplo del historial en línea antes de la ejecución número 1 de DFLTCCXPND; la FIG. 16B representa un ejemplo del historial en línea antes de la ejecución número 2 de DFLTCC-XPND y después de la ejecución número 1; y la FIG. 16C representa un ejemplo del historial en línea después de la ejecución número 2 de DFLTCC-XPND. La explicación proporcionada en la FIG. 16C también se aplica a las FIGS. 16A-16B.

Cuando el HBT especificado por el bit 56 del registro general 0 es circular, el historial se mantiene, por ejemplo, en una memoria intermedia de 32 K bytes situada en la ubicación del tercer operando. La ubicación del primer byte de historial dentro de la memoria intermedia (HB) se designa mediante la suma de los contenidos del registro general R3 y el desplazamiento 386 de historial (HO). El primer byte del historial es el byte procesado menos recientemente de datos sin comprimir en la memoria intermedia. La ubicación del último byte del historial dentro de la memoria intermedia (HE) se designa, por ejemplo, mediante la siguiente ecuación:

HE = R3 módulo32K (HO HL -1)

El último byte del historial es el byte procesado más recientemente de datos sin comprimir en la memoria intermedia. Cuando la suma del desplazamiento de historial (HO) y la longitud de historial (HL) supera el tamaño del tercer operando (por ejemplo, 32 K-bytes), el historial se cierra desde el final del tercer operando hasta el principio del tercer operando. Las FIGS. 15A-15E, descritas en la presente memoria, ilustran ejemplos de la ubicación del historial dentro de una memoria intermedia de historial circular antes y después de múltiples ejecuciones de una instrucción de Llamada de Conversión DEFLATE con la función DFLTCC-XPND y una memoria intermedia de historial circular especificadas, cuando cada ejecución termina con una finalización parcial.

En un ejemplo, cuando el HBT es circular y el número de bytes almacenados en la ubicación del primer operando es inferior a, por ejemplo, 32.768, se aplica lo siguiente:

• Los almacenamientos se realizan en un rango de bytes en la ubicación del tercer operando. El rango de bytes incluye y comienza con la ubicación designada por:

R3 módulo32K (HOO HLO),

donde

HOO: El desplazamiento de historial antes de que se ejecute la instrucción.

HLO: La longitud de historial antes de que se ejecute la instrucción.

R3 módulo32K (HOO HLO BP -1),

donde

BP: El número de bytes almacenados en la ubicación del primer operando durante la ejecución de la instrucción.

Los almacenamientos realizados en el rango de bytes que se acaba de describir están sujetos a excepciones de acceso de tipo almacenamiento, eventos de alteración de almacenamiento PER y bits de cambio de configuración.

Cuando el HBT es circular y el número de bytes almacenados en la ubicación del primer operando es mayor o igual que, por ejemplo, 32.768, los almacenamientos se realizan, por ejemplo, en todos los bytes de la ubicación del tercer operando y están sujetos a excepciones de acceso de tipo de almacenamiento, eventos de alteración de almacenamiento PER y bits de cambio de configuración.

Cuando el BTYPE es 00 binario, el bloque no contiene datos comprimidos. La FIG. 6, descrita en la presente memoria, ilustra un ejemplo de un bloque con un BTYPE igual a 00 binario. El campo LEN especifica el número de bytes literales en el bloque. El orden de bytes del campo LEN es de extremo menor. El campo LEN puede especificar cero bytes literales. Los bytes literales del bloque están situados en la ubicación del primer operando. El historial también se actualiza, como se ha descrito anteriormente, con cada byte literal del bloque.

Cuando el BTYPE es 01 binario, el bloque contiene símbolos de datos comprimidos que se generaron utilizando una tabla de Huffman fija (FHT). El FHT está definido por el estándar DEFLATE y no forma parte del bloque. La FIG. 7, descrita en la presente memoria, ilustra un ejemplo de un bloque con un BTYPE igual a 01 binario. Después de interpretar el encabezado de bloque, los símbolos de datos comprimidos se descodifican en el orden en que aparecen en el bloque. Los bytes del bloque se procesan, por ejemplo, de izquierda a derecha y los bits dentro de cada byte del bloque se procesan, por ejemplo, de derecha a izquierda. En un ejemplo, cada símbolo se procesa completamente antes de procesar el siguiente símbolo del bloque. Cada símbolo que no es el símbolo de fin de bloque (EOB) representa un valor literal o un puntero a una subcadena previamente descodificada en la memoria intermedia de historial. Una subcadena previamente descodificada también se designa como cadena duplicada. En un ejemplo, las longitudes de cadenas duplicadas oscilan entre 3 y 258 bytes. Un puntero consiste en códigos que representan la longitud de subcadena y la distancia desde el final del historial hasta el principio de la subcadena. Cuando un símbolo representa una subcadena del historial, se hace referencia a la subcadena desde la memoria intermedia de historial. Los datos sin comprimir que resultan de la descodificación de un símbolo están situados en la ubicación del primer operando.

Antes de procesar más datos de origen, el historial se actualiza tal como se ha descrito anteriormente.

El historial actualizado se aplica a la descodificación del siguiente símbolo del bloque. Cuando se encuentra el símbolo EOB, el procesamiento del bloque está completo.

Cuando el BTYPE es 10 binario, el bloque contiene símbolos de datos comprimidos que se generaron utilizando una tabla de Huffman dinámica (DHT). Un formato comprimido de la DHT utilizada es un elemento del bloque de datos comprimido. La FIG. 8, descrita en la presente memoria, ilustra un ejemplo de un bloque con un BTYPE igual a 10 binario. Después de interpretar el encabezado de bloque se examina el formato comprimido de la DHT proporcionado dentro del bloque de datos comprimido para determinar las condiciones generales de excepción de datos de operando. Cuando existe una condición general de excepción de datos de operando para el formato comprimido proporcionado de la DHT, el formato comprimido de la DHT se designa como no válido y no debe usarse para descomprimir datos. Cuando el formato comprimido de la DHT especifica una longitud de bits para una longitud de código, o una longitud de código para un byte literal, el símbolo EOB, una longitud de cadenas duplicadas o una distancia de puntero de cadenas duplicadas, que es mayor que la longitud requerida por el algoritmo de Huffman para especificar un árbol de Huffman adecuado y funcional, la<d>H<t>comprimida todavía se usa para derivar una DHT funcional y comprimir datos. Tras examinar el formato comprimido de la DHT, los símbolos de datos comprimidos se descodifican en el orden en que aparecen en el bloque. Los bytes del bloque se procesan, por ejemplo, de izquierda a derecha y los bits dentro de cada byte del bloque se procesan, por ejemplo, de derecha a izquierda. En un ejemplo, cada símbolo se procesa por completo antes de procesar el siguiente símbolo del bloque. El procesamiento de símbolos en un bloque con BTYPE 10 binario es el mismo que el anteriormente descrito para procesar símbolos en un bloque con BTYPE 01, excepto que el primero usa la DHT proporcionada para descodificar símbolos, y el segundo usa la FHT para descodificar símbolos. Cuando se proporciona una DHT no universal que no especifica un código de Huffman que ha de ser utilizado para descodificar un símbolo de datos comprimidos, se reconoce una excepción general de datos de operando.

Coincidiendo con la descompresión del segundo operando, los datos descomprimidos son una entrada para generar un valor de comprobación (por ejemplo, un valor de comprobación de 32 bits). El valor de comprobación resultante se almacena en el campo 387 de valores de comprobación del bloque de parámetros.

En una realización, tras procesar el último bloque del conjunto de datos, ocurre lo siguiente:

Cuando la longitud del primer operando es cero al comienzo de la ejecución de la instrucción, no se accede al primer operando, y la dirección del primer operando y la longitud del primer operando en los registros generales R1 y R1 1, respectivamente, no se cambian. Esto es aplicable cuando el valor del campo CF 373 es cero o uno al comienzo de la ejecución de la instrucción.

Cuando la longitud del segundo operando es cero al comienzo de la ejecución de la instrucción, no se accede al segundo operando, y la dirección del segundo operando y la longitud del segundo operando en los registros generales R2 y R2 1, respectivamente, no se cambian. En una realización, la longitud del segundo operando es cero al comienzo de la ejecución de la instrucción para el siguiente caso:

• La instrucción se vuelve a ejecutar (por ejemplo, el campo CF 373 del bloque de parámetros es uno al principio de la ejecución de la instrucción) y todo el segundo operando se procesó cuando se ejecutó previamente la instrucción.

La operación de descompresión puede terminar sin almacenar ningún resultado en la ubicación del primer operando, incluso si los datos se procesaron desde la ubicación del segundo operando. En un ejemplo, esto ocurre cuando los datos procesados desde la ubicación del segundo operando solo contienen cualquiera de los siguientes elementos de bloque de datos comprimidos:

• Un encabezado de bloque.

• El campo LEN de un bloque con un de tipo de bloque 00 binario.

• El campo NLEN de un bloque con un de tipo de bloque 00 binario.

• Un formato comprimido de una tabla de Huffman dinámica.

• Un símbolo de fin de bloque (EOB).

En una o más realizaciones, las siguientes condiciones se aplican a la ejecución de la instrucción de Llamada de Conversión DEFLATE:

En un ejemplo se reconoce una excepción general de datos de operando cuando se especifica la función DFLTCC-GDHT y se produce la siguiente condición:

• El modelo no admite el formato del bloque de parámetros, tal como se especifica en el número 362 de versión de bloque de parámetros.

En un ejemplo se reconoce una excepción general de datos de operando cuando se especifica la función DFLTCC-CMPR y se produce cualquiera de las siguientes condiciones:

• El modelo no admite el formato del bloque de parámetros, tal como se especifica en el número 362 de versión del bloque de parámetros.

• NT 374 es cero y HL 385 es mayor que, por ejemplo, 32.768.

• HTT 376 es uno y CDHTL 366 es menor que, por ejemplo, 42 o mayor que, por ejemplo, 2283.

• HTT 376 es uno y CDHTL 366 no es igual a la longitud del formato comprimido de la DHT especificada en el campo CDHT 367.

• HTT 376 es uno y el subelemento HLIT del formato comprimido de la DHT es mayor que, por ejemplo, 29 (DHT no válida).

• HTT 376 es uno y el subelemento HDIST del formato comprimido de la DHT es mayor que, por ejemplo, 29 (DHT no válida).

• HTT 376 es uno y el formato comprimido de la DHT (contenido del campo CDHT 367) especifica un código que está en la secuencia de códigos que especifican las longitudes de bits para, por ejemplo, las 19 posibles longitudes de código definidas para una DHT comprimida, y es menor que la longitud requerida por el algoritmo de Huffman para especificar un árbol de Huffman funcional (DHT no válida).

• HTT 376 es uno y el formato comprimido de la DHT (contenido del campo CDHT 367) especifica la longitud del código, por ejemplo, 16 (copia la longitud del código anterior) como la primera longitud de código para el conjunto de elementos que consiste en bytes literales, un símbolo EOB y longitudes de cadenas duplicadas (DHT no válida).

• HTT 376 es uno y el formato comprimido de la DHT (contenido del campo CDHT 367) especifica un código que está en la secuencia de códigos que especifican longitudes de código para bytes literales, y el código no coincide con ninguno de los códigos determinados para representar el conjunto de longitudes de código de referencia, tal como se ha especificado anteriormente en la DHT comprimida (DHT no válida).

• HTT 376 es uno y el formato comprimido de la DHT (contenido del campo CDHT 367) especifica un código que asigna la longitud de código 0 (CL0) al símbolo EOB. En este caso, la DHT correspondiente no especifica un código de Huffman para representar un símbolo EOB (DHT no válida).

• HTT 376 es uno y el formato comprimido de la DHT (contenido del campo CDHT 367) especifica un código que está en la secuencia de códigos que especifican longitudes de código para longitudes de cadenas duplicadas y distancias de puntero, y el código no coincide con ninguno de los códigos determinados para representar el conjunto de longitudes de código de referencia, tal como se ha especificado anteriormente en la DHT comprimida (DHT no válida).

• HTT 376 es uno y el formato comprimido de la DHT (contenido del campo CDHT 367) especifica un número de longitudes de código que es mayor que el número de códigos de Huffman en la DHT, tal como se especifica mediante la suma de los valores en el campo HLIT, el campo HDIST y, por ejemplo, 258. Esto es posible con un uso inadecuado de las longitudes de código 16, 17 y 18, como ejemplos (DHT no válido).

• HTT 376 es uno y el formato comprimido de la DHT (contenido del campo CDHT 367) especifica una longitud de código para el conjunto de bytes literales, el símbolo EOB y las longitudes de cadenas duplicadas, que es menor que la longitud requerida por el algoritmo de Huffman para especificar un árbol de Huffman funcional (DHT no válida).

• HTT 376 es uno y el formato comprimido de la DHT (contenido del campo CDHT 367) especifica una longitud de código para el conjunto de distancias de puntero de cadenas duplicadas, que es menor que la longitud requerida por el algoritmo de Huffman para especificar un árbol de Huffman funcional (DHT no válida).

• La CPU intenta generar un símbolo de datos comprimidos para representar un byte literal en el segundo operando, y la DHT derivada del contenido del campo CDHT no es universal y no especifica un código de Huffman correspondiente a ese byte literal.

• La CPU intenta generar un símbolo de datos comprimidos para representar una cadena duplicada en el segundo operando, y la DHT derivada del contenido del campo CDHT no es universal y no especifica un código de Huffman correspondiente a esa longitud de cadena duplicada o distancia de puntero.

Una excepción general de datos de operando se reconoce, por ejemplo, cuando se especifica la función DFLTCC-XPND y se produce cualquiera de las siguientes condiciones, como ejemplos:

• NT 374 es cero y HL 385 es mayor que, por ejemplo, 32.768.

• Se encuentra un bloque de datos comprimido con BTYPE igual a 11 binario.

• Se encuentra un bloque de datos comprimido con BTYPE igual a 00 binario y NLEN no igual al complemento uno de LEN.

• Se encuentra un formato comprimido de una DHT (contenido de un bloque de datos comprimidos con BTYPE igual a 10 binario) y el subelemento HLIT de la DHT comprimida es mayor que, por ejemplo, 29 (DHT no válida).

• Se encuentra un formato comprimido de una DHT (contenido de un bloque de datos comprimidos con BTYPE igual a 10 binario) y el subelemento HDIST de la DHT comprimida es mayor que, por ejemplo, 29 (DHT no válida).

• Se encuentra un formato comprimido de una DHT (contenido de un bloque de datos comprimido con BTYPE igual a 10 binario) que especifica un código que está en la secuencia de códigos que especifican las longitudes de bits para, por ejemplo, las 19 posibles longitudes de código definidas para una DHT comprimida, y es menor que la longitud requerida por el algoritmo de Huffman para especificar un árbol de Huffman funcional (DHT no válida).

• Se encuentra un formato comprimido de una DHT (contenido de un bloque de datos comprimido con BTYPE igual a 10 binario) que especifica la longitud del código, por ejemplo, 16 (copia la longitud del código anterior) como la primera longitud de código para el conjunto de elementos que consiste en bytes literales, un símbolo EOB y longitudes de cadenas duplicadas (DHT no válida).

• Se encuentra un formato comprimido de una DHT (contenido de un bloque de datos comprimidos con BTYPE igual a 10 binario) que especifica un código que está en la secuencia de códigos que especifican longitudes de código para bytes literales, y el código no coincide con ninguno de los códigos determinados para representar el conjunto de longitudes de código de referencia, como se especificó anteriormente en la DHT comprimida (DHT no válida).

• Se encuentra un formato comprimido de una DHT (contenido de un bloque de datos comprimido con BTYPE igual a 10 binario) que especifica un código que asigna una longitud de código 0 (CL0) al símbolo EOB. En este caso, la DHT correspondiente no especifica un código de Huffman para representar un símbolo EOB (DHT no válida).

• Se encuentra un formato comprimido de una DHT (contenido de un bloque de datos comprimidos con BTYPE igual a 10 binario) que especifica un código que está en la secuencia de códigos que especifican longitudes de código para longitudes de cadenas duplicadas y distancias de puntero, y el código no coincide con ninguno de los códigos determinados para representar el conjunto de longitudes de código de referencia, tal como se ha especificado anteriormente en la DHT comprimida (DHT no válida).

• Se encuentra un formato comprimido de una DHT (contenido de un bloque de datos comprimidos con BTYPE igual a 10 binario) que especifica un número de longitudes de código que es mayor que el número de códigos de Huffman en la DHT, tal como se especifica mediante la suma de los valores en el campo HLIT, el campo HDIST y, por ejemplo, 258. Esto es posible con un uso inadecuado de las longitudes de código 16, 17 y 18, como ejemplos (DHT no válido).

• Se encuentra un formato comprimido de una DHT (contenido de un bloque de datos comprimidos con BTYPE igual a 10 binario) que especifica una longitud de código para el conjunto de bytes literales, el símbolo EOB y longitudes de cadenas duplicadas, que es inferior a la longitud requerida por el algoritmo de Huffman para especificar un árbol de Huffman funcional (DHT no válido).

• Se encuentra un formato comprimido de una DHT (contenido de un bloque de datos comprimidos con BTYPE igual a 10 binario) que especifica una longitud de código para el conjunto de distancias de puntero de cadenas duplicadas, que es inferior a la longitud requerida por el algoritmo de Huffman para especificar un árbol de Huffman funcional (DHT no válido).

• Un símbolo de datos comprimidos, que se encuentra en un bloque de datos comprimidos con BTYPE igual a 10 binario, especifica un código de Huffman que no está definido por la DHT no universal derivada del formato comprimido de la DHT en el mismo bloque. En este caso, el número de bits del segundo operando que deben estar disponibles para procesar, con el fin de reconocer la excepción general de datos de operando, depende del modelo. Más específicamente, un modelo que intenta descodificar un código indefinido puede procesar, por ejemplo, 15 bits antes de reconocer la excepción, aunque la excepción pueda determinarse después de procesar menos bits.

• Se encuentra un símbolo de datos comprimidos que es un puntero de cadenas duplicadas y especifica una distancia mayor que la longitud del historial disponible en el punto de procesamiento del símbolo.

• Un símbolo de datos comprimidos, que se encuentra en un bloque de datos comprimidos con BTYPE igual a 01 binario, especifica un código no válido (por ejemplo, un código de 11000110 o 11000111 binario para una longitud de cadena duplicada, o un código de 11110 o 11111 binario para una distancia de puntero de cadenas duplicadas). En este caso, el número de bits del segundo operando que deben estar disponibles para procesar, con el fin de reconocer la excepción general de datos de operando, depende del modelo. Más específicamente, un modelo que intenta descodificar un código no válido puede procesar, por ejemplo, 8 bits, en el caso de una longitud de cadena duplicada, o 5 bits, en el caso de una distancia de puntero de cadenas duplicadas, antes de reconocer la excepción, aunque la excepción pueda determinarse después de procesar menos bits.

Cuando se reconoce una excepción general de datos de operando, la operación se considera suprimida, aunque los campos 365 de código suplementario de finalización de operación (OESC) y 363 de número de versión de modelo (MVN) del bloque de parámetros se actualicen para proporcionar información adicional asociada a la excepción.

Cuando se ejecuta una función DFLTCC-CMPR o DFLTCC-XPND y se debe reconocer una excepción general de datos de operando para el segundo operando, el resultado es que se reconoce la excepción o que la operación termina con una finalización parcial y se establece el código de condición, por ejemplo, 3. Si se establece el código de condición 3, la excepción se reconocerá cuando la instrucción se ejecute nuevamente para continuar procesando los mismos operandos y la condición de excepción aún exista.

Otras condiciones incluyen, por ejemplo:

La ejecución de la instrucción es interrumpible. Cuando se produce una interrupción, las direcciones en los registros generales R1 y R2, las longitudes en los registros generales R1 1 y R2 1 y campos específicos del bloque de parámetros se actualizan, de modo que la instrucción, cuando se vuelve a ejecutar, se reanuda en el punto de interrupción.

Cuando se ejecuta una función DFLTCC-CMPR o DFLTCC-XPND y se debe reconocer una excepción de acceso para el primer o el segundo operandos, el resultado es que se reconoce la excepción o que la operación termina con una finalización parcial y se establece el código de condición, por ejemplo, 3. Si se establece el código de condición 3, la excepción se reconocerá cuando la instrucción se ejecute nuevamente para continuar procesando los mismos operandos y la condición de excepción aún exista.

Como se observa mediante esta CPU, otras CPU y programas de canal, las referencias al bloque de parámetros, al primer, segundo y tercer operandos pueden ser referencias de acceso múltiple, los accesos a estas ubicaciones de almacenamiento no son necesariamente simultáneos en bloques y la secuencia de estos accesos o referencias no está definida.

En una realización, los resultados son impredecibles si se especifica la función DFLTCC-CMPR o DFLTCC-XPND y se aplica cualquiera de las siguientes condiciones:

• El bloque de parámetros se superpone al primer o segundo operando.

• El primer operando se superpone al segundo operando.

• El tipo de memoria intermedia de historial (HBT) especificado es circular y el tercer operando se superpone al primer operando, al segundo operando o al bloque de parámetros.

• El tipo de memoria intermedia de historial (HBT) especificado está en línea, se especifica la función DFLTCC-CMPR y el historial se superpone al primer operando o al bloque de parámetros.

• El tipo de memoria intermedia de historial (HBT) especificado está en línea, se especifica la función DFLTCC-XPND y el historial se superpone al segundo operando o al bloque de parámetros.

En ciertas situaciones, a pesar de finalizar la ejecución de la instrucción de Llamada de Conversión DEFLATE con un número de bytes procesado determinado por la CPU que es cero, los datos pueden haberse almacenado en la ubicación del primer operando, los datos pueden haberse almacenado en la ubicación del tercer operando, en caso aplicable, y se han establecido bits de cambio correspondientes, en caso aplicable. En estos casos, el contenido del bloque de parámetros y los registros generales no se ha modificado con respecto a los valores originales. Estas situaciones pueden producirse cuando la CPU realiza una operación de inactividad o un reintento de CPU mientras ejecuta la instrucción de Llamada de Conversión DEFLATE.

Lo siguiente son ejemplos de Códigos de Condición Resultantes de la ejecución de la instrucción de Llamada de Conversión DEFLATE:

0 Finalización normal

1 La longitud del primer operando no es suficiente para completar la operación

2 La longitud del segundo operando no es suficiente para completar la operación (DFLTCC-XPND)

3 Cantidad de datos procesados determinada por la CPU

Excepciones de programa:

• Acceso (buscar, operando 2, historial en línea; buscar y almacenar, bloque de parámetros, operando 1, operando 3)

• Datos con DXC 0, operando general

• Funcionamiento (si la función de conversión DEFLATE no está instalada)

• Especificación

• Restricción de transacción

Más abajo se muestran ejemplos de prioridades de ejecución para la instrucción de LLAMADA DE CONVERSIÓN DEFLATE:

1.-6. Excepciones con la misma prioridad que la prioridad de las condiciones de interrupción de programa en el caso general.

7.A Excepciones de acceso para la segunda instrucción de media palabra.

7.B Excepción de operación.

7. C Restricción de transacción.

8. A Excepción de especificación debida a un código de función no válido o un número de registro no válido. 8.B Excepción de especificación debida a un bloque de parámetros no designado en un límite de 4 K bytes. 8. C Excepción de especificación debida a que la memoria intermedia de historial circular no está designada en un límite de 4 K bytes.

9. Excepciones de acceso para un acceso al bloque de parámetros.

10. Excepción general de datos de operando cuando el modo no admite el formato especificado del bloque de parámetros.

11. Excepción de especificación debida a que la longitud del segundo operando es igual a cero y CF igual a cero al principio de la ejecución de la instrucción.

12. Código de condición 1 debido a que la longitud del primer operando es igual a cero al principio de la ejecución de la instrucción y se especifica DFLTCC-CMPR.

13. A Excepción general de datos de operando debido a que el campo de longitud de historial es superior a 32.768 y el nuevo campo de tarea es cero cuando se especifica DFLt CC-CMPr o DFLTCC-XPND.

13.B Excepciones de acceso para un acceso al primer operando y la longitud del primer operando no es cero.

13.C Excepciones de acceso para un acceso al segundo operando y la longitud del segundo operando no es cero.

13.D Excepciones de acceso para un acceso al historial en línea especificado al principio de la ejecución de la instrucción.

13. E Excepciones de acceso para un acceso al tercer operando.

14. A Excepción general de datos de operando debida a condiciones distintas de las incluidas más arriba en los puntos 10 y 13.A.

14. B Códigos de condición 1, 2 o 3 debido a condiciones distintas de las incluidas más arriba en el punto 12.

15. Código de condición 0.

Antes de su uso se examina el formato comprimido de una DHT para detectar la existencia de condiciones generales de excepción de datos de operando. Cuando la longitud del formato comprimido de una DHT no se define con precisión debido a una condición general de excepción de datos de operando, la longitud interpretada puede depender de la condición, depender del modelo y no superar, por ejemplo, 286 bytes. Como resultado de ello, cuando se especifica la función DFLTCC-XPND y se encuentra un formato comprimido de una DHT con una condición general de excepción de datos de operando en, por ejemplo, los 286 bytes más a la derecha del segundo operando, depende del modelo si se reconoce la condición de excepción (prioridad 14. A) o el código de condición 2 (prioridad 14.B).

A continuación se proporciona un ejemplo de notas de programación:

1. Al comprimir o descomprimir datos, puede ser más eficiente en general cuando la operación se realiza con un número mínimo de veces que se ejecuta la instrucción de Llamada de Conversión DEFLATE. En otras palabras, ejecutar DFLTCC con un operando grande puede ser más eficiente que ejecutar DFLTCC con operandos pequeños varias veces.

2. Para las operaciones de compresión y descompresión, cuando se establece el código de condición 3, los registros generales utilizados por la instrucción y el bloque de parámetros se han actualizado de modo que el programa pueda volver a la instrucción para continuar la operación.

3. En una realización, la instrucción de Llamada de Conversión DEFLATE puede completarse después de realizar una subparte determinada por la CPU del procesamiento especificado por los parámetros de la instrucción. Cuando la instrucción se completa después de realizar solo una cantidad de procesamiento determinada por la CPU en lugar de todo el procesamiento especificado, la instrucción establece el código de condición 3. Después de dicha finalización, la dirección de instrucción en la PSW (palabra de estado del programa) designa la siguiente instrucción secuencial, y los parámetros de operando de la instrucción se han ajustado para que el procesamiento de la instrucción pueda reanudarse volviendo a la instrucción para ejecutarla nuevamente. Cuando la instrucción ha realizado todo el procesamiento especificado, establece un código de condición distinto de 3.

4. Cuando se especifica la función DFLTCC-CMPR y la operación termina con un valor distinto de cero en el campo de límite de subbytes (SBB) del bloque de parámetros, la operación incluía el almacenamiento en el byte designado por la dirección del primer operando resultante. Cuando se especifica la función DFLTCC-XPND y la operación termina con un valor distinto de cero en el SBB, la operación incluía la búsqueda del byte designado por la dirección del segundo operando resultante.

5. Cuando la operación termina con un conjunto de códigos de condición distinto de cero, el campo CSB 392 del bloque de parámetros puede contener datos procesados parcialmente, y se espera que el programa vuelva a ejecutar la instrucción para reanudar la operación.

6. Después de que la instrucción termine con un conjunto de códigos de condición distinto de cero, y antes de volver a ejecutar la instrucción con el fin de reanudar la operación, el programa no debe modificar ningún campo del bloque de parámetros; de lo contrario, los resultados son impredecibles.

7. Cuando se especifica la función DFLTCC-GDHT, la representación comprimida de una DHT generada describe tres árboles de código de Huffman completos y adecuados, según el algoritmo de Huffman. Es decir, no se describen árboles de códigos de Huffman incompletos. Un árbol de códigos de Huffman incompleto se deriva de una representación comprimida de una DHT que especifica una longitud de código para un elemento que es mayor que la longitud requerida por el algoritmo de Huffman para especificar un árbol de Huffman adecuado y funcional.

Cuando se especifica la función DFLTCC-CMPR, HTT es uno, y la representación comprimida de la DHT incluye una descripción de un árbol de códigos de Huffman incompleto, los resultados de los datos comprimidos se pueden transformar en los datos originales sin comprimir utilizando la función DFLTCC-XPND, pero no todos los descodificadores que cumplen con el estándar DEFLATE pueden transformar los resultados en los datos originales sin comprimir. Esto puede ocurrir, por ejemplo, cuando la representación comprimida de una DHT especificada por el programa para la función DFLTCC-CMPR no ha sido generada como resultado de la ejecución de la función DFLTCC-GDHT.

8. Cuando la función DFLTCC-CMPR termina con el código de condición 1 establecido, el resultado almacenado en el campo 381 de límite de subbytes (SBB) del bloque de parámetros es 000 binario. Reconocer este escenario puede ser relevante para un programa que asigne memorias intermedias de salida para su uso con la instrucción de Llamada de Conversión DEFLATE.

Como se describe en la presente memoria, en un aspecto se proporciona una única instrucción (por ejemplo, una única instrucción de máquina diseñada en la interfaz dehardware/software,por ejemplo, la instrucción de Llamada de Conversión DEFLATE) para realizar operaciones de compresión y/o descompresión utilizando un procesador de uso general. Esta instrucción es, por ejemplo, una instrucción dehardwaredefinida en una Arquitectura de Conjunto de Instrucciones (ISA). Como resultado de ello se reduce la complejidad del programa relacionado con las operaciones de compresión y/o descompresión. Además se mejora el rendimiento de las operaciones y, por lo tanto, del procesador.

Ventajosamente, la instrucción de Llamada de Conversión DEFLATE la envía, por ejemplo, un programador, en un procesador de uso general (por ejemplo, una unidad de procesamiento central, designada en la presente memoria como procesador), en lugar de un procesador de propósito especial, como un dispositivo de I/O, un dispositivo específico de una sola aplicación conectado a través de una interfaz de I/O u otros tipos de procesadores de propósito especial. En comparación con una implementación desoftware,la ejecución de la instrucción divulgada requiere significativamente menos ciclos de ejecución para realizar la misma operación. Además, en comparación con enviar una operación a un dispositivo de I/O, la ejecución de la instrucción descrita no requiere operaciones de I/O por parte de un sistema operativo y no hace que el sistema operativo realice un cambio de tarea mientras espera a que se complete la operación.

Aunque se describen varios campos y registros, uno o más aspectos de la presente invención pueden usar otros campos o registros, campos o registros adicionales o menos campos o registros, u otros tamaños de campos y registros, etc. Son posibles muchas variaciones. Por ejemplo, pueden usarse registros implícitos en lugar de registros o campos de la instrucción especificados explícitamente y/o pueden usarse registros o campos especificados explícitamente en lugar de registros o campos implícitos. También son posibles otras variaciones.

Una realización del uso de la instrucción de Llamada de Conversión DEFLATE se describe con referencia a la FIG.

17. En un ejemplo, un programa que se ejecuta en un procesador, tal como un procesador de uso general, especifica detalles de una operación que ha de ser realizada en un bloque de parámetros almacenado y especifica la ubicación del bloque de parámetros, ETAPA 1700. Por ejemplo, se proporcionan o configuran uno o más de los campos de un bloque de parámetros (por ejemplo, el bloque de parámetros 340, 360 o 370), dependiendo de la función que haya de ser realizada. Además, el programa especifica la operación que ha de ser realizada (por ejemplo, consultar, generar, comprimir, expandir, etc.), ETAPA 1702. Además, el programa especifica o actualiza la ubicación y la cantidad de los datos de entrada en el almacenamiento, ETAPA 1704, así como la ubicación y el tamaño de la memoria intermedia de resultados en el almacenamiento, ETAPA 1706.

A continuación, el programa ejecuta la instrucción de Llamada de Conversión DEFLATE (DFLTCC), ETAPA 1708. En un ejemplo, la instrucción se envía a un procesador de uso general. Como ejemplos, se procesa en el procesador de uso general o, al menos en parte, se procesa mediantehardwareacoplado al procesador de uso general y accesible sin utilizar una interfaz de I/O.

Sobre la base de la terminación de la instrucción, se determina si el código de condición resultante de la ejecución es igual a un primer valor definido, por ejemplo, 0, CONSULTA 1710. Si el código de condición es igual al primer valor definido, entonces se completa el procesamiento de la instrucción, ETAPA 1712. Sin embargo, si el código de condición no es igual al primer valor definido, entonces se toma una determinación adicional sobre si el código de condición es igual a un segundo valor definido, por ejemplo, 3, CONSULTA 1714. Si el código de condición es igual al segundo valor definido que indica que hay datos adicionales que han de ser procesados, entonces la instrucción se vuelve a ejecutar, ETAPA 1708. Sin embargo, si el código de condición no es igual al segundo valor definido, entonces se toma una determinación adicional sobre si el código de condición está establecido en un tercer valor definido, por ejemplo, 1, CONSULTA 1716. Si el código de condición se establece en el tercer valor definido que indica que la longitud del primer operando es insuficiente, entonces el procesamiento continúa con la ETAPA 1706; de lo contrario, la longitud del segundo operando es insuficiente para la función y el procesamiento continúa con la ETAPA 1704.

Como se ha indicado, la instrucción de Llamada de Conversión DEFLATE puede ejecutarse varias veces para comprimir o descomprimir un único flujo de datos. Por lo tanto, en un aspecto, la instrucción de Llamada de Conversión DEFLATE incluye un atributo que proporciona un mecanismo para que un programa declare una memoria intermedia (por ejemplo, una memoria intermedia de 32 K bytes), que se usa para acumular el historial de datos sin comprimir procesados durante una operación que abarca múltiples ejecuciones de la instrucción de Llamada de Conversión DEFLATE. La memoria intermedia es, por ejemplo, una memoria intermedia de historial circular.

En un aspecto, la instrucción de Llamada de Conversión DEFLATE usa un indicador (por ejemplo, un bit) en un registro implícito (por ejemplo, GR0.56) para indicar el uso de una memoria intermedia de historial circular. Cuando se indica la memoria intermedia de historial circular y la función especificada que debe realizar la instrucción de Llamada de Conversión DEFLATE consiste en comprimir o descomprimir datos, un campo de la instrucción (por ejemplo, R3) especifica la ubicación en la memoria de, por ejemplo, una memoria intermedia de 32 K bytes, que el procesador usa para buscar el historial desde el principio de una operación y almacenar el historial hasta el final de una operación. La longitud del historial dentro de la memoria intermedia de historial circular se especifica mediante un campo de bloque de parámetros asociado a la instrucción de Llamada de Conversión DEFLATE (por ejemplo, el campo HL 385), y el comienzo del historial dentro de la memoria intermedia se especifica mediante un desplazamiento incluido en otro campo del bloque de parámetros (por ejemplo, el campo HO 386).

Se describen detalles adicionales sobre el uso de una memoria intermedia de historial circular con referencia a la FIG.

18. En un ejemplo, un programa que se ejecuta en un procesador, tal como un procesador de uso general, especifica detalles de una operación que ha de ser realizada en un bloque de parámetros almacenado y especifica la ubicación del bloque de parámetros, ETAPA 1800. Por ejemplo, se proporcionan o configuran uno o más de los campos de bloque de parámetros (por ejemplo, el bloque 360 o 370 de parámetros), dependiendo de la función que haya de ser realizada. Además, el programa especifica la operación que ha de ser realizada (por ejemplo, comprimir, expandir, etc.).

Además, en un ejemplo, el programa asigna y especifica una ubicación en memoria de un tamaño predefinido (por ejemplo, 32 K bytes), ETAPA 1802. Además, el programa sitúa una parte de un flujo de datos sin comprimir en una memoria intermedia y especifica la ubicación y el tamaño de la memoria intermedia como una entrada a la instrucción de Llamada de Conversión DEFLATE, ETAPA 1804, y especifica o actualiza la ubicación y el tamaño de una memoria de resultados en almacenamiento, ETAPA 1806.

A continuación se ejecuta la instrucción de Llamada de Conversión DEFLATE, ETAPA 1808. Basándose en la ejecución de la instrucción, el procesador busca el historial de, por ejemplo, una memoria intermedia de historial circular, como una entrada a la operación, ETAPA 1820, y realiza la operación especificada, ETAPA 1822, tal como se describe en la presente memoria. Además, el procesador modifica el historial en la memoria intermedia de historial circular como una salida de la operación, ETAPA 1824. Se determina si se ha procesado todo el flujo de datos, CONSULTA 1826. Si no, entonces el procesamiento continúa con la ETAPA 1804. De lo contrario, el procesamiento se ha completado.

El uso de una memoria intermedia de historial circular proporciona lo siguiente, como ejemplos:

Cuando el tamaño de la memoria intermedia de entrada o salida, especificada para su uso con una ejecución individual de la instrucción de Llamada de Conversión DEFLATE, es relativamente pequeño (por ejemplo, 512 bytes), se puede usar un historial que abarque múltiples segmentos de datos almacenados en memoria intermedia, hasta, por ejemplo, 32 K bytes, como una entrada a la instrucción de Llamada de Conversión DEFLATE, que procesa una pequeña cantidad de bytes.

Cuando el tamaño de la memoria intermedia de entrada o salida, especificada para su uso con una ejecución individual de la instrucción de Llamada de Conversión DEFLATE, es relativamente grande (por ejemplo, 128 K bytes), se puede usar un historial del segmento anterior de datos almacenados en memoria intermedia, de hasta, por ejemplo, 32 K bytes, como una entrada a la instrucción de Llamada de Conversión DEFLATE que procesa los primeros 32 K bytes de datos.

En ambos casos, hay más historial disponible para procesar datos del que estaría disponible de otro modo. Como resultado de ello se mejora la eficacia de la detección de cadenas duplicadas, lo que resulta en una mejora de las relaciones de compresión generales. Esto facilita el procesamiento en el entorno informático y mejora el rendimiento.

Uno o más aspectos de la presente invención están inextricablemente ligados a la tecnología informática y facilitan el procesamiento dentro de un ordenador, mejorando el rendimiento del mismo. El uso de una única instrucción de máquina con arquitectura para realizar la compresión y/o descompresión mejora el rendimiento en el entorno informático. Los datos comprimidos/descomprimidos pueden usarse en muchos campos técnicos que gestionan y/o utilizan datos, tal como en procesamiento informático, procesamiento médico, seguridad, control de inventario, etc. Al proporcionar optimizaciones en la compresión/descompresión, estos campos técnicos mejoran mediante la reducción del tiempo de ejecución.

Algunos detalles adicionales de una o más realizaciones, en lo que respecta a uno o más aspectos de la presente invención, se describen con referencia a las FIGS. 19-22.

Pasando ahora a una visión general de las tecnologías que son más específicamente relevantes para aspectos de la invención, DEFLATE es un algoritmo para la compresión de datos que pueden tener un tamaño de varios gigabytes (GB) en el que una aplicación solo puede tener pequeñas memorias intermedias a la vez y la compresión debe completarse en bloques relativamente pequeños que pueden ser de 1 megabyte (MB) o menos. Por lo general, DEFLATE puede referirse a un conjunto complejo de instrucciones que se ejecutan en un acelerador o una NXU y que se pueden conectar a un subsistema de coherencia integrado en el chip (por ejemplo, una memoria caché L3) con una interfaz de entrada/salida (I/O) similar a la interfaz I/O utilizada para el acceso directo a la memoria (DMA). Desde una perspectiva arquitectónica, DEFLATE debe seguir ciertas reglas principales

Además, una instrucción interrumpible compleja es una instrucción (por ejemplo, DEFLATE; instrucción de Llamada de Conversión DEFLATE; una instrucción de un conjunto complejo de instrucciones que se ejecutan en un acelerador) que tiene un estado que es necesario guardar para que la instrucción pueda reiniciarse después de que se repare la interrupción. Téngase en cuenta que el estado puede ser el que sea necesario para permitir un reinicio, siempre que cumpla con requisitos de formato específicos (por ejemplo, un formato de bloque de parámetros). Los requisitos de formato particulares se pueden microdiseñar específicamente para un modelo de máquina original. A su vez, cuando se introduce un nuevo modelo de máquina con la misma instrucción interrumpible compleja, el estado de la misma instrucción interrumpible compleja se microdiseña específicamente para el nuevo modelo de máquina. El microdiseño significa, desde una perspectiva desoftware,que un área del estado es opaca, ya que solo es entendible por el modelo de máquina para el que se ha creado. Por lo tanto, después de la introducción del nuevo modelo de máquina, el entorno informático incluye dos máquinas (por ejemplo, el modelo de máquina original y la nueva máquina) que ejecutan la misma instrucción interrumpible compleja con dos formatos de bloques de parámetros diferentes.

Para instrucciones con funciones y bloques de parámetros complejos, se adopta una nueva estrategia de nivel de arquitectura virtual (VAL) de acuerdo con una o más realizaciones de la presente memoria. Es decir, en varios entornos informáticos complejos, el VAL se utiliza para gestionar la migración de sistemas, de modo que todas las instrucciones admitan todas las entradas de cualquier nivel de máquina inferior mediante la utilización de indicadores (dentro del VAL) establecidos en el nivel de máquina común más bajo para todas las máquinas virtuales. Por lo tanto, una o más realizaciones de la invención abordan las deficiencias arriba descritas manteniendo la compatibilidad para funciones complejas en múltiples generaciones de máquina (por ejemplo, entre el modelo de máquina original y la nueva máquina del entorno informático). Además, una o más realizaciones de la presente memoria definen un nivel de compatibilidad entre generaciones que requiere que cada máquina entienda solo dos formatos de bloques de parámetros diferentes. En este sentido, cada máquina implementa su propio nivel de bloque de instrucciones y parámetros, así como un mínimo común denominador.

La FIG. 19 representa un sistema 1900 de acuerdo con realizaciones de la presente invención. El sistema 1900 incluye una versión (n) 1910 de máquina (n) que admite una máquina virtual 1920 con un nivel 1929 de compatibilidad que contiene una versión n 1930 parmblock en la misma. La versión n 1930 parmblock incluye un indicador de un mínimo común denominador para todas las versiones de máquina (por ejemplo, el indicador 1931 de mínimo común denominador).

El sistema 1900 también incluye una versión (n 1) 1940 de máquina que admite una máquina virtual 1950 con un nivel 1959 de compatibilidad que contiene una versión n 1930 parmblock y una versión n 11960 parmblock en la misma. El sistema 1900 también incluye una versión (n 2) 1970 de máquina que admite una máquina virtual 1980 con un nivel 1989 de compatibilidad que contiene una versión n 1930 parmblock y una versión n 21990 parmblock en la misma. El indicador 1931 de mínimo común denominador dentro de los niveles 1929, 1959 y 1989 de compatibilidad se controla mediante una serie de bits de instalación que identifican qué funciones están disponibles en una máquina 1920, 1950 y 1980 virtual particular.

Téngase en cuenta que “n” es una designación para la generación; a su vez, si n -0, entonces la versión 1910 de máquina es una máquina de primera generación, la versión 1940 de máquina es una máquina de segunda generación y la versión 1970 de máquina es una máquina de tercera generación. Las versiones 1910, 1940 y 1970 de máquina pueden ser cualquier dispositivo que comprenda una combinación dehardware/softwareque soporte una o más máquinas virtuales (por ejemplo, la máquina virtual 1920, 1950 y 1980). Por ejemplo, cada versión 1910, 1940 y 1970 de máquina puede ser equivalente a un caso del sistema 2200 de la FIG. 22.

En general, dado que un sistema operativo puede migrar entre las máquinas virtuales 1920, 1950 y 1980, todas las máquinas virtuales 1920, 1950 y 1980 deben tener el mismo VAL. El mismo VAL significa que, si el complejo (por ejemplo, el sistema 1900; el CEC 200 de la FIG. 2) tiene la versión 1910 de máquina (por ejemplo, la máquina de primera generación) y la versión 1940 de máquina (por ejemplo, la máquina de segunda generación) y la máquina virtual 1950 se mueve de la máquina de primera generación a la máquina de segunda generación, la máquina virtual 1950, una vez movida, puede ejecutar instrucciones de máquina de primera generación. Téngase en cuenta que las instrucciones de la máquina de segunda generación no funcionarán en la máquina de primera generación. Obsérvese también que las instrucciones de máquina de primera y segunda generación pueden ser instrucciones interrumpibles complejas (por ejemplo, una instrucción de Llamada de Conversión DEFLATE o instrucciones de un conjunto complejo de instrucciones que se ejecutan en un acelerador) que cumplen con los requisitos de formato particulares de las máquinas de primera y segunda generación, respectivamente.

El sistema 1900 mantiene, dentro del VAL de cada máquina virtual 1920, 1950 y 1980, los niveles 1929, 1959 y 1989 de compatibilidad para una instrucción interrumpible compleja. Cada nivel de compatibilidad 1929, 1959 y 1989 está diseñado para una versión de máquina con el mínimo común denominador en las versiones 1910, 1940 y 1970 de máquina y para un formato de bloque de parámetros local para la instrucción interrumpible compleja. Téngase en cuenta que el formato de bloque de parámetros local está diseñado para una versión de máquina local para cada una de las versiones 1910, 1940 y 1970 de máquina. En este sentido, la máquina virtual 1920 admite un formato de bloque de parámetros que se puede ejecutar en la versión 1910 de máquina (ya que esta es la versión más antigua); la máquina virtual 1940 admite formatos de bloques de parámetros que pueden ejecutarse en la versión 1910 de máquina (el mínimo común denominador) y versión 1950 de máquina; y la máquina virtual 1970 admite formatos de bloques de parámetros que se pueden ejecutar en la versión 1910 de máquina (el mínimo común denominador) y la versión 1980 de máquina (local). Más particularmente, dado que la versión n es el mínimo común denominador, la versión n 1930 parmblock se replica en cada nivel 1929, 1959 y 1989 de compatibilidad en cada máquina virtual 1920, 1950 y 1980.

De acuerdo con una o más realizaciones, la máquina de las versiones 1910, 1940 y 1970 de máquina puede generar los niveles 1929, 1959 y 1989 de compatibilidad para ejecutar la instrucción interrumpible compleja correspondiente. Además, el indicador 1931 de mínimo común denominador puede ser generado por una máquina de las versiones 1910, 1940 y 1970 de máquina para ejecutar primero la instrucción interrumpible compleja correspondiente. El VAL utiliza el nivel 1929 de compatibilidad para incluir este indicador 1931 de mínimo común denominador, de modo que la versión n 1930 parmblock se replica cuando se generan los niveles 1959 y 1989 de compatibilidad posteriores. El indicador 1931 de mínimo común denominador puede asociarse a la versión n 1930 parmblock, como se muestra, o ser una parte independiente del propio nivel 1929 de compatibilidad. De acuerdo con una o más realizaciones, el indicador de denominador común más bajo y/o el nivel de compatibilidad pueden propagarse desde la máquina de las versiones 1910, 1940 y 1970 de máquina para ejecutar primero la instrucción interrumpible compleja a un número restante de las versiones 1910, 1940 y 1970 de máquina.

La FIG. 20 representa un flujo 2000 de proceso de acuerdo con una o más realizaciones de la presente invención. La FIG. 21 representa un sistema 2100 de acuerdo con realizaciones de la presente invención. El sistema 2100 representa inicialmente máquinas con versiones n, n - 1 y n - 2 de máquina (2110, 2140 y 2170, respectivamente), cada una de las cuales implementa diferentes formatos de bloque de parámetros (una versión n 2130 parmblock, una versión n - 1 2160 parmblock y una versión n - 22190 parmblock, respectivamente). De acuerdo con una o más realizaciones, cada bloque 2130, 2160 y 2190 de parámetros puede almacenarse individualmente dentro de las versiones n, n - 1 y n - 2 de máquina (2110, 2140 y 2170, respectivamente).

El flujo 2000 de proceso puede ser ejecutado por el sistema 2100. El flujo 2000 de proceso comienza en el bloque 2010, donde la máquina del nivel n - 2 (2170) es la primera máquina que implementa una instrucción interrumpible compleja (por ejemplo, DEFLATE; instrucción de Llamada de Conversión DEFLATE; una instrucción de un conjunto complejo de instrucciones que se ejecuta en un acelerador de la máquina 2170).

En el bloque 2020, el nivel de arquitectura virtual del sistema 2100 indica mediante el indicador 2191 de mínimo común denominador que un bloque de parámetros de la primera máquina (por ejemplo, la versión n - 22190 parmblock) se ejecuta/admite para la instrucción interrumpible compleja. El formato de la versión n - 2 2190 parmblock puede designarse como nivel de compatibilidad o formato génesis.

En el bloque 2030, el formato de la versión n - 22190 parmblock con el indicador 2191 de denominador común más bajo se propaga a cada máquina virtual que se ejecuta actualmente en el sistema 2100. Como se muestra en la FIG.

21 mediante las Flechas B, el formato de la versión n - 22190 parmblock se comparte con las máquinas virtuales 2120 y 2150. Ahora, las dos máquinas virtuales 2120 y 2150, que se ejecutan en los niveles n y n - 1 de máquina, pueden implementar la instrucción interrumpible compleja con el formato de la versión n - 2 2190 parmblock. Además, la máquina virtual 2120 , que se ejecuta en el nivel n de máquina, puede implementar la instrucción interrumpible compleja correspondiente al formato de la versión n 2130 parmblock, y la máquina virtual 2150, que se ejecuta en el nivel n - 1 de máquina, puede implementar la instrucción interrumpible compleja correspondiente al formato de la versión n - 1 2160 parmblock.

En el bloque 2040, el sistema 2100 detecta que la primera máquina está fuera de línea. Como se muestra en la FIG.

21 con la X, la máquina en el nivel n - 2 (2170) se desconecta. En el bloque 2050, el sistema 2100 detecta que una nueva máquina está en línea. Por ejemplo, la máquina del nivel n 1 (2191) entra en línea. En el bloque 2060, el sistema 2100 identifica el bloque de parámetros de la primera máquina como el denominador común más bajo en todas las versiones de máquina.

En el bloque 2070, el sistema 2100 propaga el bloque de parámetros de la primera máquina a la nueva máquina. Como se muestra en la FIG. 21, el sistema 2100 incluye ahora una máquina con una versión n 1 (2191) de máquina, que implementa un formato de bloque de parámetros (una versión n 12193 parmblock). Como se muestra en la FIG.

21 mediante la Flecha d, el formato de la versión n - 22190 parmblock se comparte con la máquina virtual 2192. Por lo tanto, cuando se migra cualquier máquina virtual, utiliza el nivel n - 2 de la función.

Los efectos y beneficios técnicos de realizaciones de la presente memoria pueden incluir cuando, para una instrucción/función compleja, cada generación de máquinas solo admite como máximo dos bloques de parámetros diferentes (su propio bloque de parámetros y un nivel de compatibilidad), una verificación y la validación se reducen a probar solo con la versión actual y de compatibilidad de los bloques de parámetros. Los efectos y beneficios técnicos de realizaciones de la presente memoria incluyen además, para la primera generación, que su formato de bloque de parámetros represente el formato de “génesis” y solo es necesario admitir/probar un formato. Por lo tanto, el contenido del bloque de parámetros específico de cualquier máquina de generación posterior se puede optimizar para esta máquina sin crear un impacto posterior para generaciones de máquina futuras.

Volviendo ahora a la FIG. 22, se muestra un sistema 2200 para implementar las enseñanzas de la presente memoria de acuerdo con una o más realizaciones de la invención. En esta realización, el sistema 2200 tiene un procesador 2201, que puede incluir una o más unidades centrales de procesamiento (CPU) 2201a, 2201b, 2201c, etc.

El procesador 2201, también designado como circuito de procesamiento, microprocesador, unidad informática, se acopla mediante un bus 2202 de sistema a una memoria 2203 de sistema y a varios otros componentes. La memoria 2203 de sistema incluye la memoria de solo lectura (ROM) 2204 y la memoria de acceso aleatorio (RAM) 2205. La ROM 2204 se acopla al bus 2202 de sistema y puede incluir un sistema básico de entrada/salida (BIOS), que controla determinadas funciones básicas del sistema 2200. La RAM es una memoria de lectura-escritura acoplada al bus 2202 de sistema para su uso por el procesador 2201.

El sistema 2200 de la FIG. 22 incluye un disco duro 2207, que es un ejemplo de un medio de almacenamiento tangible legible ejecutable por el procesador 2201. El disco duro 2207 almacenasoftware2208 y datos 2209. Elsoftware2208 se almacena como instrucciones para ejecución en el sistema 2200 por parte del procesador 2201 (para realizar procesos, tal como los flujos 2100, 2200 de proceso de las FIGS. 21-22). Los datos de 2209 incluyen un conjunto de valores de variables cualitativas o cuantitativas organizados en varias estructuras de datos para admitir y ser utilizados por operaciones delsoftware2208.

El sistema 2200 de la FIG. 22 incluye uno o más adaptadores (por ejemplo, controladores de disco duro, adaptadores de red, adaptadores de gráficos, etc.) que interconectan y admiten comunicaciones entre el procesador 2201, la memoria 2203 de sistema, el disco duro 2207 y otros componentes del sistema 2200 (por ejemplo, dispositivos periféricos y externos). En una o más realizaciones de la presente invención, el o los adaptadores pueden conectarse a uno o más buses de I/O que se conectan al bus 2202 de sistema a través de un puente de bus intermedio, y el o los buses de I/O pueden utilizar protocolos comunes, tales como la Interconexión de Componentes Periféricos (PCI).

Como se muestra, el sistema 2200 incluye un adaptador 2220 de interfaz que interconecta un teclado 2221, un ratón 2222, un altavoz 2223 y un micrófono 2224 al bus 2202 de sistema. El sistema 2200 incluye un adaptador 2230 de pantalla que interconecta el bus 2202 de sistema a una pantalla 2231. El adaptador 2230 de pantalla (y/o el procesador 2201) pueden incluir un controlador de gráficos para proporcionar rendimiento de gráficos, tal como una pantalla y gestión de una GUI 2232. Un adaptador 2241 de comunicaciones interconecta el bus 2202 de sistema con una red 2250 que permite al sistema 2200 comunicarse con otros sistemas, dispositivos, datos ysoftware,tales como un servidor 2251 y una base de datos 2252. En una o más realizaciones de la presente invención, las operaciones delsoftware2208 y los datos 2209 pueden implementarse en la red 2250 mediante el servidor 2251 y la base 2252 de datos. Por ejemplo, la red 2250, el servidor 2251 y la base 2252 de datos pueden combinarse para proporcionar iteraciones internas delsoftware2208 y los datos 2209 como una plataforma como un servicio, unsoftwarecomo un servicio y/o infraestructura como un servicio (por ejemplo, como una aplicación web en un sistema distribuido).

Por lo tanto, tal como se configura en la FIG. 22, las operaciones delsoftware2208 y los datos 2209 (por ejemplo, el sistema 2200) se basan necesariamente en la capacidad computacional del procesador 2201 y/o el servidor 2251 para superar y abordar las deficiencias descritas en la presente memoria de las migraciones contemporáneas de cargas de trabajo entre máquinas de tipos de máquina diferentes. A este respecto, elsoftware2208 y los datos 2209 mejoran las operaciones computacionales del procesador 2201 y/o el servidor 2251 del sistema 2200 al mantener la compatibilidad para funciones complejas en múltiples generaciones de máquina (reduciendo así la verificación y la validación y optimizando el contenido de bloques de parámetros específicos de la máquina de cualquier generación posterior sin crear un impacto posterior).

En la presente memoria se describen varias realizaciones de la invención con referencia a los dibujos relacionados. En la siguiente descripción y en los dibujos se exponen varias conexiones y relaciones posicionales (por ejemplo, por encima, por debajo, adyacentes, etc.) entre los elementos. Estas conexiones y/o relaciones posicionales, a menos que se especifique lo contrario, pueden ser directas o indirectas, y la presente invención no pretende ser limitante a este respecto. Por consiguiente, un acoplamiento de entidades puede referirse a un acoplamiento directo o indirecto, y una relación posicional entre entidades puede ser una relación posicional directa o indirecta. Además, las diversas tareas y etapas del proceso descritas en la presente memoria pueden incorporarse en un procedimiento o proceso más completo que tenga etapas o funcionalidad adicionales no descritas en detalle en la presente memoria.

Las siguientes definiciones y abreviaturas deben utilizarse para la interpretación de las reivindicaciones y la memoria descriptiva. Tal como se usan en la presente memoria, las expresiones “comprende”, “que comprende”, “incluye”, “que incluye”, “tiene”, “que tiene”, “contiene”, o “que contiene” o cualquier otra variación de las mismas, pretenden cubrir una inclusión no exclusiva. Por ejemplo, una composición, una mezcla, un proceso, un método, un artículo o un aparato que comprende una lista de elementos no se limita necesariamente solo a esos elementos, sino que puede incluir otros elementos no enumerados expresamente o inherentes a dicha composición, mezcla, proceso, método, artículo o aparato.

Además, el término “ejemplar” se usa en la presente memoria para significar “que sirve como un ejemplo, caso o ilustración”. Cualquier realización o diseño descrito en la presente memoria como “ejemplar” no debe interpretarse necesariamente como preferido o ventajoso sobre otras realizaciones o diseños. Puede entenderse que las expresiones “al menos uno” y “uno o más” incluyen cualquier número entero mayor o igual que uno, es decir, uno, dos, tres, cuatro, etc. Se puede entender que la expresión “una pluralidad” incluye cualquier número entero mayor o igual que dos, es decir, dos, tres, cuatro, cinco, etc. El término “conexión” puede incluir tanto una “conexión” indirecta como una “conexión” directa.

Las expresiones “alrededor de”, “sustancialmente”, “aproximadamente”, y sus variaciones pretenden incluir el grado de error asociado con la medición de la cantidad particular en función del equipo disponible en el momento de presentar la solicitud. Por ejemplo, “alrededor de” puede incluir un intervalo de ± 8 % o 5 %, o 2 % de un valor dado.

En aras de la brevedad, las técnicas convencionales relacionadas con la elaboración y el uso de aspectos de la invención pueden o no describirse en detalle en la presente memoria. En particular se conocen bien diversos aspectos de los sistemas informáticos y los programas informáticos específicos para implementar las diversas características técnicas descritas en la presente memoria. Por consiguiente, en aras de la brevedad, muchos detalles de implementación convencionales solo se mencionan brevemente en la presente memoria o se omiten por completo sin proporcionar los detalles bien conocidos del sistema y/o el proceso.

La presente invención puede consistir en un sistema, un método y/o un producto de programa informático en cualquier nivel posible de detalle técnico de integración. El producto de programa informático puede incluir un medio (o medios) de almacenamiento legible por ordenador que tenga instrucciones de programa legibles por ordenador en el mismo para hacer que un procesador lleve a cabo aspectos de la presente invención.

El medio de almacenamiento legible por ordenador puede ser un dispositivo tangible que puede retener y almacenar instrucciones para su uso por un dispositivo de ejecución de instrucciones. El medio de almacenamiento legible por ordenador puede ser, por ejemplo, pero no se limita a, un dispositivo de almacenamiento electrónico, un dispositivo de almacenamiento magnético, un dispositivo de almacenamiento óptico, un dispositivo de almacenamiento electromagnético, un dispositivo de almacenamiento de semiconductores o cualquier combinación adecuada de los anteriores. Una lista no exhaustiva de ejemplos más específicos del medio de almacenamiento legible por ordenador incluye lo siguiente: un disquete de ordenador portátil, un disco duro, una memoria de acceso aleatorio (RAM), una memoria de solo lectura (ROM), una memoria de solo lectura programable y borrable (EPROM o memoria Flash), una memoria estática de acceso aleatorio (SRAM), una memoria portátil de solo lectura de disco compacto (CD-ROM), un disco versátil digital (DVD), una memoria USB, un disco flexible, un dispositivo codificado mecánicamente, tal como tarjetas perforadas o estructuras elevadas en una ranura que tiene instrucciones grabadas en las mismas, y cualquier combinación adecuada de los anteriores. Un medio de almacenamiento legible por ordenador, tal como se usa en la presente memoria, no debe interpretarse como señales transitorias en sí, tales como ondas de radio u otras ondas electromagnéticas que se propagan libremente, ondas electromagnéticas que se propagan a través de una guía de ondas u otro medio de transmisión (por ejemplo, pulsos de luz que pasan a través de un cable de fibra óptica) o señales eléctricas transmitidas a través de un cable.

Las instrucciones de programa legibles por ordenador descritas en la presente memoria pueden descargarse a dispositivos informáticos/de procesamiento respectivos desde un medio de almacenamiento legible por ordenador o a un ordenador externo o dispositivo de almacenamiento externo a través de una red, por ejemplo Internet, una red de área local, una red de área amplia y/o una red inalámbrica. La red puede comprender cables de transmisión de cobre, fibras ópticas de transmisión, transmisión inalámbrica, enrutadores, firewalls, conmutadores, ordenadores de pasarela y/o servidores periféricos. Una tarjeta de adaptador de red o interfaz de red en cada dispositivo informático/de procesamiento recibe instrucciones de programa legibles por ordenador desde la red y reenvía las instrucciones de programa legibles por ordenador para su almacenamiento en un medio de almacenamiento legible por ordenador dentro del dispositivo informático/de procesamiento respectivo.

Las instrucciones de programa legibles por ordenador para llevar a cabo las operaciones de la presente invención pueden ser instrucciones de ensamblador, instrucciones de arquitectura de conjunto de instrucciones (ISA), instrucciones de máquina, instrucciones dependientes de la máquina, microcódigo, instrucciones defirmware,datos de establecimiento de estado, datos de configuración para circuitos integrados, o bien código fuente o código objeto escrito en cualquier combinación de uno o más lenguajes de programación, incluyendo un lenguaje de programación orientado a objetos tal como Smalltalk, C++ o similares, y lenguajes de programación de procedimiento, como el lenguaje de programación “C” o lenguajes de programación similares. Las instrucciones de programa legibles por ordenador pueden ejecutarse completamente en el ordenador del usuario, parcialmente en el ordenador del usuario, como un paquete desoftwareindependiente, parcialmente en el ordenador del usuario y parcialmente en un ordenador remoto o completamente en el ordenador o servidor remoto. En este último escenario, el ordenador remoto puede conectarse al ordenador del usuario a través de cualquier tipo de red, incluyendo una red de área local (LAN) o una red de área amplia (WAN), o la conexión puede realizarse a un ordenador externo (por ejemplo, a través de Internet utilizando un Proveedor de Servicios de Internet). En algunas realizaciones, los circuitos electrónicos que incluyen, por ejemplo, circuitos lógicos programables, las agrupaciones de puertas programables de campo (FPGA) o las matrices lógicas programables (PLA) pueden ejecutar las instrucciones de programa legibles por ordenador mediante el uso de información de estado de las instrucciones de programa legibles por ordenador para personalizar los circuitos electrónicos, con el fin de realizar aspectos de la presente invención.

En la presente memoria se describen aspectos de la presente invención con referencia a ilustraciones de diagramas de flujo y/o diagramas de bloques de métodos, aparatos (sistemas) y productos de programas informáticos de acuerdo con realizaciones de la invención. Se entenderá que cada bloque de las ilustraciones de diagrama de flujo y/o diagramas de bloques, y las combinaciones de bloques en las ilustraciones de diagrama de flujo y/o diagramas de bloques, pueden implementarse mediante instrucciones de programa legibles por ordenador.

Estas instrucciones de programa legibles por ordenador pueden proporcionarse a un procesador de un ordenador de propósito general, ordenador de propósito especial u otro aparato de procesamiento de datos programable para producir una máquina, de modo que las instrucciones, que se ejecutan a través del procesador del ordenador u otro aparato de procesamiento de datos programable, creen medios para implementar las funciones/acciones especificadas en el diagrama de flujo y/o bloque o bloques de diagrama de bloques. Estas instrucciones de programa legibles por ordenador también pueden almacenarse en un medio de almacenamiento legible por ordenador que puede dirigir un ordenador, un aparato de procesamiento de datos programable y/u otros dispositivos para que funcionen de una manera particular, de modo que el medio de almacenamiento legible por ordenador que tiene instrucciones almacenadas en el mismo comprenda un artículo de fabricación que incluye instrucciones que implementan aspectos de la función/acción especificados en el diagrama de flujo y/o bloque o bloques de diagrama de bloques.

Las instrucciones de programa legibles por ordenador también pueden cargarse en un ordenador, otro aparato de procesamiento de datos programable u otro dispositivo para provocar que se realice una serie de etapas de operación en el ordenador, otro aparato programable u otro dispositivo para producir un proceso implementado por ordenador, de modo que las instrucciones que se ejecutan en el ordenador, otro aparato programable u otro dispositivo implementen las funciones/acciones especificadas en el diagrama de flujo y/o bloque o bloques de diagrama de bloques.

El diagrama de flujo y los diagramas de bloques de las Figuras ilustran la arquitectura, funcionalidad y operación de posibles implementaciones de sistemas, métodos y productos de programas informáticos de acuerdo con varias realizaciones de la presente invención. A este respecto, cada bloque del diagrama de flujo o diagramas de bloques puede representar un módulo, segmento o parte de instrucciones, que comprende una o más instrucciones ejecutables para implementar la o las funciones lógicas especificadas. En algunas implementaciones alternativas, las funciones señaladas en los bloques pueden producirse fuera del orden indicado en las Figuras. Por ejemplo, dos bloques mostrados en sucesión pueden, de hecho, ejecutarse de manera sustancialmente simultánea, o los bloques pueden ejecutarse a veces en orden inverso, dependiendo de la funcionalidad implicada. También se observará que cada bloque de los diagramas de bloques y/o la ilustración de diagrama de flujo, y las combinaciones de bloques en los diagramas de bloques y/o la ilustración de diagrama de flujo, pueden implementarse mediante sistemas basados enhardwarede propósito especial que realizan las funciones o acciones especificadas o llevan a cabo combinaciones dehardwarede propósito especial e instrucciones de ordenador.

Las descripciones de las diversas realizaciones de la presente invención se han presentado con fines ilustrativos, pero no pretenden ser exhaustivas ni limitarse a las realizaciones descritas. La terminología utilizada en la presente memoria se ha elegido para explicar mejor los principios de las realizaciones, la aplicación práctica o la mejora técnica sobre tecnologías que se encuentran en el mercado, o para permitir que otros expertos en la técnica entiendan las realizaciones descritas en la presente memoria.

Claims

REIVINDICACIONES

1. Un sistema que comprende:

una pluralidad de máquinas que comprenden una máquina de primera generación, una máquina de segunda generación y una máquina de tercera generación, comprendiendo cada una de la pluralidad de máquinas una versión de máquina; las máquinas de primera, segunda y tercera generación que comprenden diferentes versiones de máquina, la máquina de primera generación que ejecuta una primera máquina virtual (1920) y un nivel de arquitectura virtual, la máquina de segunda generación que ejecuta una segunda máquina virtual (1950) y el nivel de arquitectura virtual, y la máquina de tercera generación que ejecuta una tercera máquina virtual (1980) y el nivel de arquitectura virtual, en donde el sistema se caracteriza por que:

el nivel de arquitectura virtual está configurado para proporcionar un nivel de compatibilidad para una instrucción interrumpible compleja para la primera, la segunda y la tercera máquinas virtuales,

el nivel de compatibilidad está diseñado para una versión de máquina con el mínimo común denominador en la pluralidad de máquinas,

el nivel de compatibilidad que comprende un indicador (1931) de mínimo común denominador que identifica la versión de máquina con el mínimo común denominador,

la instrucción interrumpible compleja que tiene un estado que se ha de guardar y que cumple con un formato de bloques de parámetros,

el nivel de compatibilidad comprende un formato (1930) de bloques de parámetros asociado con el indicador (1931) de mínimo común denominador,

el nivel de compatibilidad comprende un formato de bloques de parámetros local para la instrucción interrumpible compleja para cada una de la pluralidad de máquinas, estando diseñado el formato de bloques de parámetros local para la versión de máquina local para cada una de la pluralidad de máquinas,

el indicador (1931) de mínimo común denominador es generado por una máquina de la pluralidad de máquinas para ejecutar primero la instrucción interrumpible compleja, y

el indicador (1931) de mínimo común denominador se propaga desde la máquina de la pluralidad de máquinas para ejecutar primero la instrucción interrumpible compleja para un número restante de la pluralidad de máquinas.

2. El sistema de la reivindicación 1, en donde el indicador (1931) de mínimo común denominador dentro del nivel de compatibilidad se controla mediante una serie de bits de instalación que identifican qué funciones están disponibles en una máquina virtual particular.

3. El sistema de cualquier reivindicación anterior, en donde la instrucción interrumpible compleja comprende una instrucción de Llamada de Conversión DEFLATE.

4. El sistema de la reivindicación 1, en donde la instrucción interrumpible compleja comprende una instrucción de un conjunto complejo de instrucciones que se ejecutan en un acelerador.

5. Un método que comprende:

ejecutar una primera máquina virtual (1920) y un nivel de arquitectura virtual mediante una máquina de primera generación de una pluralidad de máquinas, comprendiendo cada una de la pluralidad de máquinas una versión de máquina;

ejecutar una segunda máquina virtual (1950) y el nivel de arquitectura virtual mediante una máquina de segunda generación de la pluralidad de máquinas;

ejecutar una tercera máquina virtual (1980) y el nivel de arquitectura virtual mediante una máquina de tercera generación de la pluralidad de máquinas; caracterizado por que:

proporcionar, mediante el nivel de arquitectura virtual, un nivel de compatibilidad para una instrucción interrumpible compleja para la primera, la segunda y la tercera máquinas virtuales,

el nivel de compatibilidad comprende un indicador (1931) de mínimo común denominador que identifica la versión de máquina con el mínimo común denominador,

en donde la instrucción interrumpible compleja comprende un estado que se ha de guardar y que cumple con un formato de bloques de parámetros,

en donde el nivel de compatibilidad comprende un formato (1930) de bloques de parámetros asociado con el indicador (1931) de mínimo común denominador,

en donde el nivel de compatibilidad comprende un formato de bloques de parámetros local para la instrucción interrumpible compleja para cada una de la pluralidad de máquinas, está diseñado el formato de bloques de parámetros local para la versión de máquina local para cada una de la pluralidad de máquinas,

en donde el indicador (1931) de mínimo común denominador se genera por una máquina de la pluralidad de máquinas para ejecutar primero la instrucción interrumpible compleja, y

en donde el indicador (1931) de mínimo común denominador se propaga desde la máquina de la pluralidad de máquinas para ejecutar primero la instrucción interrumpible compleja para un número restante de la pluralidad de máquinas.

6. El método de la reivindicación 5, en donde el indicador (1931) de mínimo común denominador dentro del nivel de compatibilidad se controla mediante una serie de bits de instalación que identifican qué funciones están disponibles en una máquina virtual particular.

7. El método de la reivindicación 5, en donde la instrucción interrumpible compleja comprende una instrucción de Llamada de Conversión DEFLATE.

8. El método de la reivindicación 5, en donde la instrucción interrumpible compleja comprende una instrucción de un conjunto complejo de instrucciones que se ejecutan en un acelerador.

9. Un producto de programa informático que comprende un medio de almacenamiento legible por ordenador que tiene instrucciones de programa incorporadas en el mismo, instrucciones de programa que son ejecutables para provocar operaciones que comprenden todas las etapas de cualquiera de las reivindicaciones de método 5 a 8.