Formato de archivo de objeto OS/360

El formato de archivo de objeto OS/360 es el formato de archivo de módulo de objeto estándar para los sistemas operativos de mainframe IBM DOS/360 , OS/360 y VM/370 , ^[1] Univac VS/9 , ^[2] y Fujitsu BS2000 ^[3] . En la década de 1990, el formato recibió una extensión con el registro de tipo XSD para el sistema operativo MVS para admitir nombres de módulo más largos en el lenguaje de programación C. ^[4] Este formato todavía se usa en el sistema operativo z/VSE (la continuación del sistema operativo DOS/360 ) . En contraste, ha sido reemplazado por el formato de archivo GOFF en el sistema operativo MVS (la continuación del sistema operativo OS/360 ) y en el sistema operativo z/VM (la continuación del sistema operativo VM/370 ). Dado que los cargadores MVS y z/VM todavía manejan este formato más antiguo, algunos compiladores han optado por seguir produciendo este formato en lugar del formato GOFF más nuevo . ^[5]

Este formato permite la descripción del código objeto de una aplicación compilada, que puede enviarse a un editor de enlaces para convertirlo en un programa ejecutable o ejecutarse directamente a través de un cargador de módulos de objetos. Lo crea el ensamblador o un compilador de lenguaje de programación. En el resto de este artículo, a menos que se requiera una razón para ser explícito en la diferencia entre un compilador de lenguaje y un ensamblador, el término "compilar" incluye "ensamblar" y "compilador" incluye "ensamblador".

Este formato se consideró adecuado para la época en que se desarrolló originalmente, alrededor de 1964. Con el tiempo, tuvo una serie de debilidades, entre las que se encuentra que

• Solo admite nombres de 8 bytes de longitud (y normalmente existe una convención de que los nombres están SOLO EN MAYÚSCULAS y están restringidos a ciertos símbolos en el nombre, consulte la discusión a continuación).
• No se puede especificar la alineación.
• No se puede especificar un módulo que sea puro dato y no sea ejecutable.
• No se puede especificar un módulo reentrante (a diferencia de uno simplemente de sólo lectura).
• no se puede distinguir entre una subrutina (una rutina que maneja datos sólo a través de argumentos) y una función (una rutina que devuelve datos a través de un valor de retorno).
• No se puede especificar un módulo diseñado para que sea móvil (en lugar de simplemente reentrante).
• Las constantes de dirección no se pueden identificar como punteros (por ejemplo, para el acceso a una estructura de datos), a diferencia de, por ejemplo, el acceso a una tabla (que no se modifica) o a un método virtual en un registro dinámico.
• Los atributos no se pueden asignar a referencias externas (una referencia es a un código frente a una referencia a datos).
• No hay ningún medio para permitir que los procedimientos o funciones verifiquen o validen tipos de argumentos o validen estructuras externas.
• no hay forma de declarar un objeto, donde parte de la estructura son datos y parte es código (métodos que operan sobre los datos del objeto).
• La tabla simbólica SYM está limitada en la información que puede proporcionar.

Estas y otras debilidades hicieron que este formato fuera reemplazado por el formato de archivo de módulo GOFF . Pero fue una buena elección ya que era satisfactoria para las necesidades de los lenguajes de programación que se usaban en ese momento, funcionaba y era fácil de implementar (especialmente donde las máquinas en ese momento podían tener tan solo 8K de memoria, muchas operaban múltiples trabajos concurrentes o consecutivos con tan solo 64K y realmente realizaban un trabajo útil), fácil de usar y para programas simples (la orientación a objetos y conceptos como los métodos virtuales estarían décadas en el futuro desde cuando se desarrolló originalmente), todavía puede ser adecuado. Además, el formato sigue siendo satisfactorio para continuar usándose para programas más antiguos que nunca se cambiaron o donde el código fuente no está disponible y los archivos de objeto son la única parte del programa que queda.

Tenga en cuenta que el formato de archivo GOFF simplemente reemplazó a este formato (y proporcionó más información para un compilador de lenguaje o ensamblador), el formato aún es válido, puede seguir utilizándose y no quedó obsoleto. Este formato tiene la ventaja de que es fácil y simple de crear, y un compilador para un lenguaje que puede vivir con sus restricciones, que son nombres de módulo de máximo 8 caracteres en mayúsculas solamente, aplicaciones no mayores a 2^24 en tamaño (16 megabytes) para código y datos, significa que cualquier lenguaje de programación que pueda escribir archivos binarios de formato fijo de 80 bytes (básicamente cualquier cosa, incluidos COBOL y FORTRAN, no solo ensamblador), se puede utilizar para crear un compilador para este formato de objeto. De hecho, el compilador Pascal 8000 de la Comisión Australiana de Energía Atómica para IBM 360/370, escrito en Pascal como un compilador autohospedado en 1978-1980, creó directamente sus propios archivos de objetos sin usar el ensamblador como paso intermedio.

Hay 6 tipos de registros diferentes:

• Los registros ESD definen programas principales, subrutinas, funciones, secciones ficticias, Fortran Common y cualquier módulo o rutina que pueda ser invocada por otro módulo. Se utilizan para definir los programas o segmentos de programa que se compilaron en esta ejecución del compilador y las rutinas externas utilizadas por el programa (como exit() en C , CALL EXIT en Fortran ; new() y dispose() en Pascal ). Los registros ESD deben aparecer antes de cualquier referencia a un símbolo ESD.
• Los registros TXT contienen las instrucciones o los datos de la máquina que guarda el módulo.
• Los registros RLD se utilizan para reubicar direcciones. Por ejemplo, un programa que hace referencia a una dirección ubicada a 500 bytes dentro del módulo, almacenará internamente la dirección como 500, pero cuando el módulo se carga en la memoria, seguramente estará ubicado en otro lugar, por lo que un registro RLD informa al editor de enlaces o al cargador qué direcciones cambiar. Además, cuando un módulo hace referencia a un símbolo externo, generalmente establecerá el valor del símbolo en cero y luego incluirá una entrada RLD para ese símbolo para permitir que el cargador o el editor de enlaces alteren la dirección al valor correcto.
• Se agregaron registros SYM para permitir proporcionar información adicional sobre un símbolo, como el tipo de datos (carácter o numérico) y el tamaño del elemento.
• Se agregaron registros XSD para proporcionar información adicional más allá de la proporcionada en el registro ESD sobre símbolos públicos como procedimientos y funciones, y para ampliar el tamaño del nombre de un procedimiento o función a más de 8 caracteres.
• Los registros END indican el final de un módulo y, opcionalmente, dónde debe comenzar la ejecución del programa.

Todos los registros tienen exactamente 80 bytes de longitud; los campos no utilizados deben completarse con espacios en blanco. El primer byte de cada registro es siempre el valor binario 02. Los siguientes 3 bytes son siempre el tipo de registro. Los valores de caracteres están en EBCDIC . El resto de los campos de cada registro dependen del tipo de registro. Por convención, si el módulo fue nombrado en la declaración TITLE de un programa en lenguaje ensamblador (o el compilador del lenguaje decide darle un nombre al módulo), su nombre aparece justificado a la izquierda en las posiciones 73-80 de cada registro; si el nombre es más corto que 8 caracteres o no se le dio ningún nombre, aparece un número de secuencia (en caracteres, justificado a la derecha con relleno de ceros) para el resto de cada registro. En la práctica real, el campo de número de secuencia puede estar en blanco o contener cualquier cosa que el traductor del lenguaje quiera poner allí, y es esencialmente un campo de comentario.

El ensamblador (o compilador, en el caso de un lenguaje de alto nivel como C , COBOL , Fortran , Pascal , PL/I o RPG III ) crearía un registro ESD para cada subrutina, función o programa, y ​​para bloques comunes en el caso de programas Fortran. Se crearían entradas ESD adicionales en los registros ESD para las instrucciones ENTRY (un alias para un módulo o un punto de entrada alternativo para un módulo), para subrutinas, funciones o bloques COMUNES Fortran con nombre o en blanco adicionales incluidos como parte de módulos compilados o ensamblados, y para los nombres de subrutinas y funciones externas llamadas por un módulo.

Tenga en cuenta que existen dos tipos de símbolos públicos: entradas ESDID y entradas LDID. Las entradas ESDID son CSECTS y DSECTS (programas, procedimientos y funciones, y posiblemente declaraciones de registro o estructura) y las entradas LDID son instrucciones ENTRY (puntos de entrada alternativos o alias para un CSECT o DSECT). El espacio de numeración ESDID es independiente del espacio de numeración LDID y, por lo tanto, dos símbolos con nombre diferentes, uno ESDID y otro LDID, pueden tener el valor binario 0001.

El código del objeto ejecutable y los datos del programa se almacenarían en registros TXT. Las llamadas a otras subrutinas, funciones o bloques COMUNES se resuelven mediante registros RLD, que modifican la dirección almacenada en un registro TXT para determinar la dirección completa de la subrutina o función. Opcionalmente, un lenguaje puede proporcionar información de referencia simbólica, como nombres de objetos e información de tipo de datos o símbolos de depuración a través de registros SYM, y luego la declaración END indica el final de un archivo de módulo Object y la dirección de inicio opcional para la subrutina, función o programa en el que se debe iniciar este archivo, si la dirección de inicio de la rutina no es el primer byte de la primera rutina (algunas rutinas pueden tener datos no ejecutables que preceden a su código real o la primera rutina ensamblada o compilada no es el programa "principal" o el módulo "primario"). Como se ha informado, algunas personas descubrieron que debido a la forma en que funcionaban los ensambladores más antiguos (circa 1968-1975), un programa se compilaba más rápido si colocaba datos "encima" de un programa antes del código para el programa, una vez que el ensamblador comenzaba a notar las instrucciones, era mucho más lento, por lo que los programadores escribían rutinas donde colocaban los datos y las constantes primero, luego incluían el código para el programa. Cuando ensamblar un programa podía llevar de 30 minutos a una hora en lugar de unos pocos segundos como ahora, esta era una gran diferencia.

Tenga en cuenta que, si bien no es obligatorio, es una convención que los nombres de módulos y simbólicos estén todos en mayúsculas , que el primer carácter de un campo de nombre sea una letra o los símbolos @, # o $, y que los caracteres posteriores de un nombre consistan en esos caracteres más los dígitos de caracteres del 0 al 9, aunque el software más antiguo puede o no procesar correctamente los archivos de módulo de objeto que usaban identificadores en minúsculas. La mayoría de los lenguajes de programación que no sean Assembly no pueden llamar a módulos que tengan nombres que contengan @ o # (notablemente Fortran , por lo que su biblioteca de tiempo de ejecución tiene un nombre con un # para que no entre en conflicto con cualquier nombre elegido por un programador), por lo que la mayoría de los programas, subrutinas o funciones se escribieron para usar solo una letra para el primer carácter, y si el nombre tenía más de 1 carácter, para usar solo letras y dígitos para el 2.º hasta (hasta) el 8.º carácter. Si bien la mayoría de los lenguajes que no son ensambladores no pueden manejar $ en el nombre, una excepción es Fortran que puede reconocer nombres de subrutinas con $ en ellos. (Tenga en cuenta que esta opción de no utilizar # @ o $ no se aplica a un programa "principal" escrito en ensamblador o cualquier lenguaje que pueda utilizar estos identificadores, al cargador de programas no le importa cuál es el nombre del módulo). Además, los módulos escritos para usarse como subrutinas generalmente se limitaban a 6 caracteres o menos, ya que las versiones de Fortran anteriores a 1978 tampoco pueden usar subrutinas o módulos que utilicen más de 6 caracteres de longitud. El compilador COBOL generalmente descarta el carácter de guión si aparece en el PROGRAM-ID de un programa o en una declaración CALL a un módulo externo.

En la década de 1990, se agregó un nuevo tipo de registro, el registro XSD, para ampliar el uso de este formato de módulo de objeto para abarcar nombres de módulo más largos que 8 caracteres y permitir nombres con mayúsculas y minúsculas, como lo requiere el lenguaje de programación C.

• OS/MVS Program Management: Advanced Facilities , SA22-7644-07, octava edición, IBM, Poughkeepsie, NY, octava edición, septiembre de 2007 http://publibz.boulder.ibm.com/epubs/pdf/iea2b270.pdf Archivado el 19 de octubre de 2021 en Wayback Machine (consultado el 9 de agosto de 2013).
• John R. Ehrman (1 de marzo de 2001). "Cómo funciona el editor de enlaces: un tutorial sobre módulos de objetos/cargas, editores de enlaces, cargadores y lo que hacen por usted (y para usted)" (PDF) . San José: Laboratorio IBM Silicon Valley (Santa Teresa) . Consultado el 24 de diciembre de 2023 .