Instrucciones de llamada del supervisor

Este artículo cubre las instrucciones específicas sobre los mainframes IBM System/360 y sus sucesores , y las máquinas compatibles. Para conocer el concepto general de una instrucción para realizar llamadas a un sistema operativo, consulte Llamada del sistema .

Una instrucción de llamada de supervisor ( SVC ) es una instrucción de hardware utilizada por la familia System/360 de computadoras mainframe de IBM hasta las contemporáneas zSeries , Amdahl 470V/5, 470V/6, 470V/7, 470V/8, 580, 5880, 5990M y 5990A, y otras; Univac 90/60 , 90/70 y 90/80, y posiblemente otras; Fujitsu M180 (UP) ^[1] y M200 (MP), y otras; y también se utiliza en el software de emulación de mainframe de código abierto Hercules . Provoca una interrupción para solicitar un servicio del sistema operativo . La rutina del sistema que proporciona el servicio se denomina rutina SVC . SVC es una llamada del sistema .

Los mainframes IBM de las familias System/360 y sucesoras funcionan en uno de dos estados: estado de problema o estado de supervisor y en una de las dieciséis claves de acceso de almacenamiento (0 a 15). En el estado de problema , un gran conjunto de instrucciones de propósito general sin privilegios están disponibles para un programa de usuario. En el estado de supervisor , los programas del sistema pueden utilizar además un pequeño conjunto de instrucciones privilegiadas que generalmente están destinadas a funciones de supervisión. Estas funciones pueden afectar a otros usuarios, otros procesadores o a todo el sistema informático. En la clave de almacenamiento 0, un programa puede acceder a todo el almacenamiento direccionable ^[a] ; de lo contrario, está limitado a las áreas de almacenamiento con una clave coincidente. Un programa solo puede acceder a funciones de supervisión específicas después de una verificación de autorización exhaustiva por parte del sistema operativo: DEBCHK (SVC 117), TESTAUTH (SVC 119) y, posiblemente, pruebas adicionales. Los programas que no superan cualquiera de estas pruebas se terminan de forma anormal y dejan de procesarse inmediatamente. Algunas de estas pruebas no estaban disponibles en OS/360, pero se agregaron en OS/VS1 , SVS o MVS/370 , pero todas estaban disponibles en MVS/370 o versiones posteriores, y todavía están disponibles hasta el día de hoy.

En OS/VS1 , OS/VS2 (SVS) , MVS/370 y versiones posteriores del SO, la función MODESET (SVC 107) eliminó la necesidad de muchos SVC escritos por el usuario, ya que este SVC del sistema admitía cambios en el modo (estado del problema a estado del supervisor) y la clave (8-15 [usuario] a 0-7 [sistema]) en una sola operación, y muchos SVC escritos por el usuario estaban pensados ​​originalmente para cambios simples de modo y clave, de todos modos, y posteriormente el único requisito especial era que el paso de trabajo estuviera autorizado por APF ^{[b] [c]} y que el programa que invocaba MODESET residiera en una concatenación de bibliotecas, todas las cuales se identificaran como autorizadas, y este enfoque seguro estaba completamente bajo el control de la instalación. Este enfoque generalmente simplificaba los controles del usuario sobre la autorización, aunque por ello se requerían algunos cambios simples en la aplicación. En general, las instalaciones de usuario favorecían este enfoque, y por ello la confiabilidad general del sistema mejoraba significativamente.

Aunque las aplicaciones mainframe son típicamente procesos sincrónicos , el sistema operativo en sí es naturalmente asincrónico , aunque el sistema también soporta muchos procesos que son naturalmente sincrónicos . Cuando una aplicación solicita un servicio del sistema que es naturalmente asincrónico , como el procesamiento de entrada/salida, se debe emplear un mecanismo para sincronizar la aplicación y el sistema operativo. Este mecanismo esencial es a través de funciones que están integradas en el sistema operativo, o que son específicamente soportadas por él, incluyendo: WAIT (detener temporalmente el procesamiento de la aplicación hasta que haya ocurrido un evento externo); POST (indicar la ocurrencia de un evento externo para que el procesamiento de la aplicación pueda continuar); y SYNCH (cambiar el modo de procesamiento del sistema—de supervisor a usuario y clave del sistema a clave del usuario—mientras se preserva la integridad del sistema, y ​​realizar sincrónicamente una función en nombre de la aplicación, después de lo cual el procesamiento del supervisor puede continuar).

La siguiente tabla de SVC de OS/360 indica las condiciones bajo las cuales se pueden emplear estas funciones de sincronización.

SVC es una instrucción de dos bytes con el código de operación hexadecimal 0A ; el segundo byte de la instrucción, el número SVC , indica la solicitud específica. ^[2] El número SVC puede ser cualquier valor entre 0 y 255, y el número SVC particular depende del implementador del sistema operativo, por ejemplo, en MVS de IBM, SVC 3 se utiliza para finalizar un programa, mientras que en los sistemas operativos UNIVAC VS/9 y Fujitsu BS2000, SVC 9 se utilizó para el mismo propósito.

Cuando un programa emite un SVC, se produce una interrupción. El PSW, un registro privilegiado de 8 bytes (en el System 360 y S/370) o 16 bytes (en el z/System), que contiene, entre otras cosas, la dirección actual de la instrucción que se va a ejecutar, el bit de privilegio (1 si es privilegiado) y la clave de almacenamiento, se guarda en una dirección real ^[d] . Estas son las ubicaciones 32-39 en el 360 y 370; 320-335 en el z/System. Luego, el PSW se carga desde una dirección real ^[d] diferente ; es 96-103 en el 360 y 370, 448-463 en el z/System. La ejecución se reanuda en la dirección que se cargó en el PSW. Los bits 24-31 del PSW guardado (dirección real ^[d] 35 en el 360 y 370, 323 en el z/System) contienen el número de llamada del Supervisor.

SVC invoca una función de supervisión, generalmente implementada como una "subrutina cerrada" del controlador de interrupciones SVC del sistema . La información que se pasa hacia y desde las rutinas SVC se pasa a registros de propósito general o a la memoria.

En OS/360 y sucesores , el retorno de una rutina SVC se realiza, para las rutinas SVC de tipo 2, 3 y 4, a través de una invocación SVC 3 (EXIT), y para otros tipos de SVC, mediante la instrucción privilegiada Load PSW (LPSW), que es ejecutada en nombre de la rutina SVC por el despachador del programa de control o el manejador de interrupciones SVC.

En sistemas operativos no desarrollados por IBM, como MUSIC/SP, desarrollado por la Universidad McGill en Montreal, Canadá, para mainframes IBM, y para mainframes no IBM, VS/9 , desarrollado por Univac (a partir del sistema operativo TSOS para las computadoras de la serie RCA Spectra 70 ) para la línea de mainframes UNIVAC Serie 90 , y el sistema operativo B800 (también desarrollado a partir del sistema operativo TSOS) para mainframes Fujitsu, todos utilizan la instrucción LPSW para salir de una llamada de supervisor .

La elección de si se debe hacer que una llamada de supervisor regrese al programa que la llamó directamente a través de una instrucción LPSW o a través de algún otro medio, como una instrucción de retorno de subrutina o una llamada de supervisor en sí, es una cuestión de diseño. No hay una manera obvia "correcta" de hacerlo; puede haber razones para ambos métodos. El uso de una instrucción LPSW para salir de una rutina SVC permite una ejecución más rápida, pero significa que la prueba real de la rutina debe realizarse en una máquina dedicada que ejecute el código como parte de un supervisor de sistema operativo real. Si el código se escribió como una subrutina común, se puede probar de la misma manera que cualquier programa común y potencialmente implementarlo sin tener que modificarlo. También permitiría medir métricas, como cuánto tiempo tardó una rutina de llamada de supervisor en completar su tarea, lo que permitiría el análisis de rutinas que tienen un tiempo de ejecución excesivamente largo (o que son muy rápidas).

En OS/360 y versiones posteriores del sistema operativo, los puntos de entrada de bifurcación y enlace son alternativas a las invocaciones de SVC para algunas rutinas de modo supervisor. En MVS/SP V1R3 y versiones posteriores del sistema operativo, las entradas de Llamada de programa (PC) han aumentado los SVC para las invocaciones de muchas funciones de supervisión por parte de programas autorizados y no autorizados; y algunas funciones solo pueden ser invocadas por entradas de bifurcación o PC, por ejemplo, STARTIO . (Esto también tiene la ventaja de evitar que los sistemas operativos IBM se ejecuten en hardware que no sea de IBM).

Los distintos sistemas operativos de IBM tienen poca compatibilidad en los códigos específicos utilizados o en los servicios de supervisión que pueden invocarse. Los sistemas VM/370 y z/VM utilizan la instrucción DIAG de manera similar y dejan el SVC para que lo utilicen los sistemas operativos que se ejecutan en máquinas virtuales. La mayoría de los SVC de OS/360 se han mantenido para programas "heredados", pero algunos SVC se han "ampliado" con el paso del tiempo.

En OS/360 y sistemas posteriores, los números SVC del 0 al 127 aproximadamente están definidos por IBM, y los números del 255 en adelante están disponibles para que los use el personal de programación de sistemas de una instalación. z/OS cambió esto a los números SVC del 0 al 200 aproximadamente para IBM, y del 255 en adelante para la instalación, ya que IBM estaba implementando servicios de sistema adicionales, principalmente en apoyo del cifrado/descifrado, utilizando SVC. Las rutinas SVC deben tener nombres de módulo en un formato específico que comience con IGC.

Por diseño de sistema, el término "deshabilitado" significa deshabilitado para todas las interrupciones excepto las interrupciones de verificación de máquina en sistemas anteriores a MVS/370, y con el "bloqueo local" mantenido, pero no "deshabilitado" para ninguna interrupción en MVS/370 y todos los sistemas posteriores. El primero es una deshabilitación física, el segundo es una deshabilitación lógica, ya que el "bloqueo local" de un espacio de direcciones tiene el mismo impacto dentro de su espacio de direcciones que la deshabilitación física, pero no tiene impacto en otros espacios de direcciones.

OS/360 definió cuatro tipos de rutinas SVC, llamadas del "Tipo 1" al "Tipo 4"; MVS/370 agregó un "Tipo 6" adicional, que es similar al "Tipo 1" excepto que la rutina SVC está físicamente deshabilitada. El "Tipo 5" no fue definido ni implementado. La siguiente información, parte de una tabla para OS/360, aumentada para MVS/370 y sistemas sucesores, da una idea de las consideraciones involucradas en la escritura de una rutina SVC.

Las restricciones de tamaño en las rutinas SVC de tipos 3 y 4 son necesarias porque se cargan en "áreas transitorias" designadas (PLPA en post-MVT) cuando se invocan.

• Un ejemplo de Tipo 1 es SVC 10, utilizado tanto para GETMAIN como para FREEMAIN, que asigna un área de almacenamiento principal a una tarea y posteriormente la libera, respectivamente. SVC 10 se conoce informalmente como "REGMAIN", ya que intercambia parámetros a través de registros de propósito general únicamente, y puede obtener y liberar almacenamiento. SVC 4 y SVC 5 pueden realizar funciones GET y FREE similares, respectivamente, pero intercambian parámetros a través de listas de parámetros en el almacenamiento.
• Un ejemplo del tipo 2 es SVC 42, ATTACH, que crea una nueva tarea.
• Un ejemplo de tipo 3 es el SVC 33, IOHALT, que finaliza las operaciones de E/S en un dispositivo que no es DASD. Este SVC se cambió al tipo 2 en OS/VS, ya que IOHALT se utiliza mucho en muchos sistemas basados ​​en teleprocesamiento.
• Un ejemplo de un Tipo 4 es SVC 19, OPEN, que se utiliza para poner un conjunto de datos a disposición de un programa de usuario, que incluye módulos comunes a todos los métodos de acceso y llama a módulos adicionales específicos para cada método de acceso . OPEN también admite conjuntos de datos que se van a utilizar con un método de acceso "personalizado", como aquellos a los que se accede utilizando EXCP .
• Un ejemplo del Tipo 6 es SVC 107, MODESET, que no obtiene bloqueos, pero puede cambiar el modo del sistema y la clave del sistema, de acuerdo con los parámetros pasados.

En general, OS/360 no tenía ninguna forma de restringir el uso de SVC. En consecuencia, existían bastantes riesgos no intencionales de integridad de datos y del sistema que eran posibles al emplear ciertas secuencias de SVC y otras instrucciones. Se convirtió en una práctica común que los usuarios curiosos intentaran descubrir estos riesgos, pero algunos programadores de sistemas los utilizaban en lugar de desarrollar sus propios SVC escritos por el usuario.

A partir de MVS/370, IBM consideró que era un defecto del producto si un error de diseño del sistema permitía que un programa de aplicación entrara en estado de supervisor sin autorización. Ordenaron que todos los SVC de IBM estuvieran protegidos para cerrar todas las exposiciones de integridad del sistema y de los datos. "Garantizaron" cerrar dichas exposiciones a medida que se descubrieran. En la versión 3.7 de MVS/370 en 1977, prácticamente todas esas exposiciones habían sido identificadas y cerradas, a un costo de 100.000 Informes de análisis de programas autorizados (APAR) y correcciones temporales de programas (PTF) relacionadas. Este fue un logro notable, ya que el "tiempo de funcionamiento" del sistema se midió a partir de entonces en años , en lugar de en días o incluso en horas .

• Cragon, Harvey G. (23 de agosto de 2000). Arquitectura e implementación de computadoras. Cambridge University Press. ISBN 9780521651684– a través de Google Books.
• Harris, J. Archer (21 de diciembre de 2001). Esquema de sistemas operativos de Schaum. McGraw Hill Professional. ISBN 9780071394482– a través de Google Books.