OS/360 Objektfilformat
OS /360 Object File Format är standardobjektmodulfilformatet för IBM DOS/360 , OS/360 och VM/370 , Univac VS/9 och Fujitsu BS2000 stordatoroperativsystem. På 1990-talet fick formatet en förlängning med XSD-typposten för MVS - operativsystemet för att stödja längre modulnamn i programmeringsspråket C. Detta format används fortfarande av operativsystemet z/VSE (uppföljaren till operativsystemet DOS/360 ). Däremot har det ersatts av GOFF- filformatet på MVS- operativsystemet (uppföljaren till OS/360- operativsystemet) och på z/VM -operativsystemet (uppföljaren till VM/370- operativsystemet ). Eftersom MVS- och z/VM -lastarna fortfarande kommer att hantera detta äldre format, har vissa kompilatorer valt att fortsätta att producera detta format istället för det nyare GOFF -formatet.
Använda sig av
Detta format tillhandahåller beskrivningen av en kompilerad applikations objektkod, som kan matas till en länkredigerare för att göras till ett körbart program, eller köras direkt genom en objektmodulladdare. Det skapas av Assembler eller av en kompilator för programmeringsspråk. För resten av den här artikeln, såvida det inte krävs ett skäl för att vara explicit i skillnaden mellan en språkkompilator och en assembler, inkluderar termen "kompilera" "assembler" och "kompilator" inkluderar "assembler".
Svagheter
Detta format ansågs lämpligt för den tid det ursprungligen utvecklades, runt 1964. Med tiden hade det ett antal svagheter, bland annat att
- den stöder endast 8-byte långa namn (och vanligtvis finns det en konvention om att namnen endast är VERSALER och är begränsade till vissa symboler i namnet, se diskussionen nedan).
- justering kan inte specificeras.
- en modul som är ren data och inte är körbar kan inte specificeras.
- en återkommande modul (i motsats till en endast skrivskyddad) kan inte specificeras.
- kan inte skilja mellan en subrutin (en rutin som hanterar data endast genom argument) och en funktion (en rutin som returnerar data genom ett returvärde).
- en modul utformad så att den är rörlig (i motsats till att bara återinträda) kan inte specificeras.
- adresskonstanter kan inte identifieras som pekare (som för åtkomst till en datastruktur) i motsats till till exempel åtkomst till en tabell (som inte ändras) eller till en virtuell metod i en dynamisk post.
- attribut kan inte tilldelas externa referenser (en referens är till kod kontra en referens till data).
- inget sätt att tillåta procedurer eller funktioner för att kontrollera eller validera argumenttyper eller validera externa strukturer.
- inget sätt att deklarera ett objekt, där en del av strukturen är data och en del är kod (metoder som verkar på objektets data).
- den symboliska tabellen SYM är begränsad i den information den kan tillhandahålla.
Dessa och andra svagheter gjorde att detta format ersattes av GOFF -modulens filformat. Men det var ett bra val eftersom det var tillfredsställande för behoven hos de programmeringsspråk som användes vid den tiden, det fungerade och var enkelt att implementera (särskilt där maskiner vid den tiden kan ha haft så lite som 8K minne, många fungerade flera samtidiga eller på varandra följande jobb med så lite som 64K och faktiskt utför användbart arbete), enkla att använda och för enkla program (objektorientering och koncept som virtuella metoder skulle vara årtionden i framtiden från när det ursprungligen utvecklades), kan fortfarande vara lämplig. Dessutom är formatet fortfarande tillfredsställande för att fortsätta att användas för äldre program som antingen aldrig ändrades, eller där källkoden inte är tillgänglig och objektfilerna är den enda delen av programmet som finns kvar.
Observera att GOFF-filformatet bara ersatte det här formatet (och gav mer information för en språkkompilator eller assembler), formatet är fortfarande giltigt, kan fortfarande användas och har inte föråldrats. Det här formatet har fördelen att det är lätt och enkelt att skapa, och en kompilator för ett språk som kan leva med sina begränsningar, som är maximalt 8 tecken med versaler endast modulnamn, applikationer som inte är större än 2^24 i storlek ( 16 megabyte) för kod och data, betyder att vilket programmeringsspråk som helst som kan skriva 80-byte fastformat binära filer (i princip allt inklusive COBOL och FORTRAN, inte bara Assembler), kan användas för att skapa en kompilator för detta objektformat. I själva verket skapade den australiska atomenergikommissionens Pascal 8000-kompilator för IBM 360/370, själv skriven i Pascal som en självvärd kompilator redan 1978–1980, sina egna objektfiler direkt utan att använda Assembler som ett mellansteg .
Rekordtyper
Det finns 6 olika posttyper:
- ESD-poster definierar huvudprogram, subrutiner, funktioner, dummysektioner, Fortran Common och alla moduler eller rutiner som kan anropas av en annan modul. De används för att definiera programmen eller programsegmenten som kompilerades i denna körning av kompilatorn, och externa rutiner som används av programmet (som exit() i C , CALL EXIT i Fortran ; new( ) och dispose ( ) i Pascal ). ESD-poster bör förekomma före varje hänvisning till en ESD-symbol.
- TXT-poster innehåller maskininstruktioner eller data som lagras av modulen.
- RLD-poster används för att flytta adresser. Till exempel, ett program som hänvisar till en adress som ligger 500 byte inuti modulen, kommer internt att lagra adressen som 500, men när modulen laddas in i minnet måste den vara placerad någon annanstans, så en RLD-post informerar länkredigeraren eller laddaren om vad adresser att ändra. Dessutom, när en modul refererar till en extern symbol, kommer den vanligtvis att ställa in symbolens värde till noll, och sedan inkludera en RLD-post för den symbolen för att tillåta laddaren eller länkredigeraren att ändra adressen till rätt värde.
- SYM-poster lades till för att ge ytterligare information om en symbol, såsom typen av data (tecken eller siffror) och objektets storlek.
- XSD-poster lades till för att ge ytterligare information utöver den som tillhandahålls i ESD-posten om offentliga symboler såsom procedurer och funktioner, och för att utöka storleken på en procedur eller funktionsnamn till mer än 8 tecken.
- END-poster indikerar slutet på en modul, och valfritt var programmet ska börja köras.
Formatera
Alla poster är exakt 80 byte långa; oanvända fält ska vara tomma. Den första byten i varje post är alltid det binära värdet 02. De nästa 3 byten är alltid posttypen. Teckenvärdena är i EBCDIC . Resten av varje posts fält beror på posttypen. Enligt konvention, om modulen namngavs i TITLE-satsen för ett assemblerspråksprogram (eller språkkompilatorn bestämmer sig för att ge modulen ett namn), visas dess namn vänsterjusterat i positionerna 73–80 i varje post; om namnet är kortare än 8 tecken eller inget namn har angetts, visas ett sekvensnummer (i tecken, högerjusterat med nollfyllning) för resten av varje post. I praktiken kan sekvensnummerfältet vara tomt eller innehålla vad som helst som språköversättaren vill placera där, och är i huvudsak ett kommentarsfält.
Assembleren (eller kompilatorn, i fallet med ett högnivåspråk som C , COBOL , Fortran , Pascal , PL/I eller RPG III ), skulle skapa en ESD-post för varje subrutin, funktion eller program, och för Vanliga block i fallet med Fortran-program. Ytterligare ESD-poster i ESD-poster skulle skapas för ENTRY-satser (ett alias för en modul eller en alternativ ingångspunkt för en modul), för ytterligare subrutiner, funktioner eller Fortran-namngivna eller tomma COMMON-block som ingår som en del av en kompilerad eller sammansatt modul, och för namn på externa subrutiner och funktioner som anropas av en modul.
Observera att det finns två typer av offentliga symboltyper, ESDID-poster och LDID-poster. ESDID-poster är CSECTS och DSECTS (Program, Procedures and Functions, och eventuellt Record- eller Structure-deklarationer) och LDID-poster är ENTRY-satser (alternativa eller alias ingångspunkter till en CSECT eller DSECT). ESDID-numreringsutrymmet är separat från LDID-numreringsutrymmet, och därför kan två olika namngivna symboler, en ett ESDID och en ett LDID båda ha det binära värdet 0001.
Programmets körbara objektkod och data skulle lagras i TXT-poster. Anrop till andra subrutiner, funktioner eller GEMENSAMMA block löses genom RLD-poster, som modifierar adressen som lagras i en TXT-post för att fastställa subrutinens eller funktionens fullständiga adress. Alternativt kan ett språk tillhandahålla symbolisk referensinformation som objektnamn och datatypinformation eller felsökningssymboler genom SYM-poster, och sedan anger END-satsen slutet på en objektmodulfil och den valfria startadressen för subrutinen, funktionen eller programmet som denna fil bör startas på, om startadressen för rutinen inte är den första byten i den första rutinen (vissa rutiner kan ha icke-körbar data som föregår deras faktiska kod eller den första rutinen som sammanställs eller kompileras inte är "huvudprogrammet" eller "primär" modul.) Som har rapporterats upptäckte vissa människor på grund av hur äldre montörer arbetade (cirka 1968–1975), att ett program kompilerades snabbare om du satte data "ovanför" ett program före koden för programmet, en gång assemblern började lägga märke till instruktioner, det var mycket långsammare, så programmerare skrev rutiner där de satte data och konstanter först och sedan inkluderade kod för programmet. När sammansättningen av ett program kunde ta 30 minuter till en timme istället för några sekunder som nu, var detta en stor skillnad.
Observera att även om det inte krävs, är det en konvention att modulnamn och symboliska namn är i versaler , att det första tecknet i ett namnfält är en bokstav eller symbolerna @,# eller $, och att efterföljande tecken i ett namn består av dessa tecken plus teckensiffrorna 0 till 9, även om äldre programvara kanske eller inte kan bearbeta objektmodulfiler som använde gemener identifierare korrekt. De flesta andra programmeringsspråk än Assembly kan inte anropa moduler som har namn som innehåller @ eller # (särskilt Fortran , vilket är anledningen till att dess runtime-bibliotek har ett namn med ett # i så att det inte skulle komma i konflikt med något namn som valts av en programmerare). så de flesta program, subrutiner eller funktioner skrevs för att endast använda en bokstav för det första tecknet, och om namnet var längre än 1 tecken, för att endast använda bokstäver och siffror för det 2:a till (upp till) 8:e tecknet. Medan de flesta icke-assembler-språk inte kan hantera $ i namnet, är ett undantag Fortran som kan känna igen subrutinnamn med $ i dem. (Observera att det här valet att inte använda # @ eller $ inte gäller för ett "huvudprogram" skrivet i Assembler eller något annat språk som kan använda dessa identifierare, programladdaren bryr sig inte om vad modulens namn är.) , moduler skrivna för att användas som subrutiner begränsade sig vanligtvis till 6 tecken eller mindre eftersom versioner av Fortran före omkring 1978 inte heller kan använda subrutiner eller moduler med mer än 6 tecken långa. COBOL-kompilatorn kasserar vanligtvis bindestrecket om det förekommer i ett programs PROGRAM-ID eller en CALL-sats till en extern modul.
På 1990-talet, en ny posttyp, XSD-posten, lades till för att utöka användningen av detta objektmodulformat till att omfatta längre modulnamn än 8 tecken och för att tillåta blandade skiftlägesnamn, som krävs av programmeringsspråket C.
Allmän layout
Prefix (byte 1) | Typ (byte 2–4) | Syfte | Adress (Byte 6–8) i binär om den används | Storlek på information i byte 17+ (byte 11–12) | Flaggabitar (XSD-post) eller tomma (Byte 13–14) | Binärt ESDID (byte 15–16) | Data | Ident (Byte 73–80) | |
---|---|---|---|---|---|---|---|---|---|
(Byte 17–64) | (Byte 65–72) | ||||||||
02 | ESD | Modultyp | Blanks | Storlek som används i byte 17-64 | Blanks | Binär ESDID för första icke-LD-modulsymbol i byte 17–64 eller blank om alla symboler på denna post är LD | 1 till 3 16-byte modulsymboler (se nedan) | Blanks |
Däck-ID, sekvensnummer eller båda |
Text | Program eller data | Relativ adress för data i byte 17–72 i denna post | Storlek används i byte 17–72 | Blanks | ESDID | 1-56 byte data ("data" kan vara programinstruktioner, programdata eller båda) | |||
RLD | Flyttbar information | Blanks | Storlek används i byte 17–72 | Blanks | Blanks | 1 till 13 flyttposter med variabel längd (se tabellen nedan) | |||
SYM | Symbol Tabellinformation | Blanks | Storlek används i byte 17–72 | Blanks | Blanks | Symboldata med variabel längd (se tabellen nedan) | |||
XSD | Utökad symbolinformation | Blanks | Storlek används i byte 17–72 | Flaggbitar (se tabell nedan) | LDID Identifier om XSD är för en LD; annars ESDID | XSD-data (se tabellen nedan) | |||
SLUTET | Slut på modulen | Inmatningsadress om angiven eller tom | Blanks | ämnen | ESDID för inmatningsadress eller tomma | Slutdata (se tabellen nedan) |
ESD-rekord
Fält | Storlek | Anteckningar | ||
---|---|---|---|---|
namn | 8 | Identifierar programmet, funktionen, subrutinen eller FORTRAN COMMON-blocket (Detta kommer att vara tomt för PC eller tomt COMMON eller namnlöst BLOCKDATA) | ||
Typ | 1 |
Värde (hexadecimalt) |
Modultyp _ |
Vad modulen är |
00 | SD | START, CSECT, DSECT (Dummy-sektion; kommer inte att ha några TXT-poster) eller Fortran-namnad BLOCK DATA-modul | ||
01 | LD | ENTRY (etikettdefinition inom en tidigare identifierad CSECT) | ||
02 | ER | EXTRN (extern referens) | ||
04 | PC | Privat kod (START eller CSECT som inte har något namn eller Fortran namnlös BLOCK DATA-modul; denna modul kan inte anropas som en funktion eller subrutin från ett annat program) | ||
05 | CENTIMETER | Fortran namngiven eller tom COMMON (Ger endast storlek; CM-poster har aldrig TXT-poster) | ||
06 | XD (PR) | Extern dummysektion eller pseudoregister | ||
0A | WX | WXTRN (Weak Extern - En extern rutin som inte behöver finnas för att modulen ska fungera) | ||
0D | SD | Quad-Aligned START eller CSECT | ||
0E | PC | Fyrjusterad privat kod | ||
0F | CENTIMETER | Quad-Aligned Common (Ger endast storlek; COMMON har aldrig TXT-poster) | ||
Adress | 3 | Binär startadress för denna modul; adress för symbol inom modulen för LD | ||
Flagga | 1 | |||
Justering i binär för XD; Blank för ER, LD eller WX; för SD, CM eller PC använd följande: |
||||
Bits | Värde | Syfte | ||
0-1 | Inte använd | |||
2 | 0 | Använd bit 5 för värdet på RMODE | ||
1 | RMODE 64 bitar | |||
3 | 0 | Använd bitarna 6–7 för AMODE | ||
1 | AMODE 64 bitar | |||
4 | 0 | Modulen är Läs/skriv | ||
1 | RSECT (Modul är skrivskyddad och är inte självmodifierande) | |||
5 | 0 | RMODE 24 bitar | ||
1 | RMODE 31 bitar eller RMODE NÅGON | |||
6–7 | 00 | AMODE 24 bitar | ||
01 | AMODE 24 bitar | |||
10 | AMODE 31 bitar | |||
11 | AMODE NÅGON | |||
Storlek | 3 | Längd i binär för PC, CM eller SD; en blank följt av 2-byte binärt LDID för LD (och ESDID-nummer är separata från LDID-nummer; ett ESDID kan numreras 0001 och det kommer att vara en annan identifierare än LDID med nummer 0001); blanks för ER, XD, PR eller WX. Observera att en programkompilator som skapar en SD-post som inte vet hur lång modulen kommer att vara kan lämna detta fält tomt och sedan ange längden på denna modul i END-posten. |
RLD omlokalisering poster
Observera att den första omlokaliseringsposten för en RLD-post måste vara 8 byte. Om någon posts flaggfält har bit 7 satt, använder posten efter den samma värden för omplacerings- och positionsvärdena som denna post, och den efterföljande posten har 4 byte, den har bara flagg- och adressfälten. Om den postens flaggfält har bit 7 satt, fortsätter detta för posten som följer den; om flaggbiten för den posten inte är satt, använder nästa post efter den (om det finns några ytterligare poster i denna post) hela 8 byte. För att göra detta enkelt, anta till exempel att ett C-program som heter basura anropar exit ()-funktionen. |
||||
Fält | Storlek | Anteckningar | ||
---|---|---|---|---|
Omlokalisering | 2 | Binär ESDID för symbolen som ska flyttas; detta är den främmande symbolen ( utgång ) | ||
Placera | 2 | Binärt ESDID där omlokaliseringen ska göras; detta är modulen som refererar till flyttsymbolen ovan ( basura ) | ||
Flagga | 1 | |||
Bits | Menande | |||
0 | Reserverad | |||
1 | Om 1, lägg till 4 för att adressera konstant längdvärde i bitar 4–5 | |||
2-3 | Värde | Adress Konstanttyp | ||
0 | A - Extern adress, kan vara en datatabell eller kan vara en extern modul | |||
1 | V | |||
2 | F | |||
3 | CXD | |||
4-5 | Adress konstant längd - 1 | |||
6 | Förflyttningsriktning (0 för att addera; 1 för att subtrahera) Subtraktion används vanligtvis endast för A-adresskonstanter | |||
7 | om 1 är positions- och omlokaliseringsvärdefälten för posten efter denna i denna RLD-post samma som denna, och den posten är bara 4 byte lång. Den sista inmatningen i en RLD-post måste rensa denna bit. Denna funktion passar för ett specifikt fall, och förmodligen det vanligaste: när ett program gör omlokaliseringar till sig självt. ESID:erna för adressen som ska lokaliseras och platsen där adressen lagras är desamma, så det används för att markera adressreferenser till andra delar av den modulen. | |||
Adress | 3 | Absolut adress i modul för Positionsinmatning som ska flyttas. |
SYM rekord
Observera att för symbolinformationen packas poster efter varandra; endast de två första fälten är alltid närvarande. Namnfältet utelämnas om bit 4 i Organisation är 1; eventuella senare fält utelämnas också för icke-dataobjekt (bit 0 i organisation är 0). I fallet med ett dataobjekt (bit 0 i organisationen är 1) kommer endast fälten för datatyp och längd alltid att finnas, och längdfältet kan vara 1 eller 2 byte beroende på datatyp. | |||||
Fält | Byte nr. | Storlek | Anteckningar | ||
---|---|---|---|---|---|
Organisation | 1 | 1 | |||
Bits | Värde | Menande | |||
0 | 0 | Icke-datatyp | |||
1 | Data typ | ||||
(För icke-datatyp) | |||||
1-3 | 000 | Plats | |||
001 | Kontrollsektion | ||||
010 | Dummy kontrollsektion | ||||
011 | Allmänning | ||||
100 | Maskininstruktion | ||||
101 | CCW | ||||
(För datatyp) | |||||
1 | 0 | Ingen mångfald | |||
1 | Multipel (indikerar närvaro av M-fält) | ||||
2 | 0 | Oberoende (inte en packad eller zonindelad decimalkonstant) | |||
1 | Kluster (packad eller zonindelad decimalkonstant) | ||||
3 | 0 | Ingen skalning | |||
1 | Skalning (indikerar närvaro av S-fält) | ||||
Både datatyp och icke-datatyp | |||||
4 | 0 | Har namn | |||
1 | Inget namn anges | ||||
5-7 | Namnets längd - 1 | ||||
Adress | 2 | 3 | Offset från början av Csect | ||
namn | 0-8 | Om bit 4 i byte 1 är 1, finns inte detta fält, annars 1-8 byte | |||
Följande fält finns endast för dataobjekt (Bit 0 i byte 1 är 1) | |||||
Data typ | 1 | Värde i hexadecimalt | |||
00 | Tecken (C - Typ; längd på 2 byte) | ||||
04 | Hexadecimal (X - typ; 2 byte längd) | ||||
08 | Binär (B - typ; 2 byte längd) | ||||
10 | F-typ, 32-bitars heltal (1 byte längd, vanligtvis 4) | ||||
14 | H-typ, 16-bitars heltal (1 byte längd, vanligtvis 2) | ||||
18 | E-typ, 32-bitars (enkel precision) flyttal (1 byte längd, vanligtvis 4) | ||||
1C | D-typ, 64-bitars (dubbel precision) flyttal (1 byte längd, vanligtvis 8) | ||||
20 | A-typ eller Q-typ 32-bitars adress eller värde (1 byte längd, vanligtvis 4) | ||||
24 | Y-typ, 16-bitars adress eller värde (1 byte längd, vanligtvis 2) | ||||
28 | S-typ (1 byte längd) | ||||
2C | V-typ, 32-bitars extern symbol (1 byte längd, vanligtvis 4) | ||||
30 | P-typ, packad decimal med variabel längd (1 byte längd) | ||||
34 | Z-typ, zonerad decimal med variabel längd (1 byte längd) | ||||
38 | L-typ (1 byte längd) | ||||
Längd | 1 eller 2 | Längd - 1; 2 byte för tecken, hexadecimal eller binär typ (dvs. storlek från 1 till 32 768 byte); 1 byte för alla andra typer (storlek från 1 till 256 byte) | |||
Mångfald | 0 eller 3 | M-fält; 3 byte upprepningsantal eller förmodat värde på 1 (upprepas inte) om detta fält inte finns (bit 1 i organisation är 0) | |||
Skala | 0 eller 2 | S-fält; 2-byte skalvärde (finns endast för data av typen F, H, E, D, L, P och Z) eller skalan antas vara 0 om detta fält inte finns (bit 3 i organisation är 0) |
XSD-rekord
XSD-posttypen lades till på 1990-talet för att tillåta MVS att stödja längre modulnamn för C-kompilatorn. | |||||
Fält | Byte nr. | Storlek | Anteckningar | ||
---|---|---|---|---|---|
Flagga byte 1 | 13 | 1 | Bitarna 1-6 används för XPLINK; Bit 7 används för AMODE 64; ingen av dessa används av bindemedlet; Bit 8 är alltid 0. | ||
Flagga byte 2 | 14 | 1 | Bit | Menande | |
1 | Namnet kan ha flera definitioner | ||||
2 | Namnet är förvanskat | ||||
3 | Intern koppling | ||||
4 | Mall | ||||
5 | Concat | ||||
6 | Namn som är kvalificerad för import eller export | ||||
7 | 1 om namn är en funktion | ||||
8 | 1 om namnet kartlades (t.ex. #pragma-karta) | ||||
Längd | 17-20 | 4 | Namnets längd | ||
Offset | 21-24 | 4 | Offset av första byte av namn eller delsträng av namn (ursprunget till 1) | ||
Typ | 25 | 1 |
Värde (hexadecimalt) |
Modultyp _ |
Vad modulen är |
00 | SD | START, CSECT, DSECT (Dummy-sektion; kommer inte att ha några TXT-poster) eller Fortran-namnad BLOCK DATA-modul | |||
01 | LD | ENTRY (etikettdefinition inom en tidigare identifierad CSECT) | |||
02 | ER | EXTRN (extern referens) | |||
04 | PC | Privat kod (START eller CSECT som inte har något namn eller Fortran namnlös BLOCK DATA-modul; denna modul kan inte anropas som en funktion eller subrutin från ett annat program) | |||
05 | CENTIMETER | Fortran namngiven eller tom COMMON (Ger endast storlek; CM-poster har aldrig TXT-poster) | |||
06 | XD (PR) | Extern dummysektion eller pseudoregister | |||
0A | WX | WXTRN (Weak Extern - En extern rutin som inte behöver finnas för att modulen ska fungera) | |||
0B | UR | ||||
Adress | 26-28 | 3 | 24-bitars adress för symbol | ||
Specifikation | 29 | 1 | Beror på modultyp (värdet på byte 25) | ||
Modultyp | Värde | Menande | |||
LD ER CM Null eller WX | Tom | Inte använd | |||
PR | Inriktningsfaktor | ||||
00 | Bytejustering | ||||
01 | Halvordsjustering | ||||
03 | Ordjustering | ||||
07 | Dubbelordsjustering | ||||
SD eller PC | Bits 1-2 | Inte använd | |||
Bit 3 | Om 1, RMODE 64; annars använd värdet på bit 6 | ||||
Bit 4 | Om 1, AMODE 64; annars använd värdet på bitarna 7 och 8 | ||||
Bit 5 | 1 om RSECT | ||||
Bit 6 | 0=RMODE 24; 1=RMODE 31; (Ignoreras om bit 3 är 1) | ||||
Bits 7-8 | 00 eller 01=AMODE 24; 10=AMODE 31; 11=AMODE någon (Ignoreras om bit 4 är 1) | ||||
Längd eller identifierare | 30-32 | 3 | Värde | Menande | |
Noll | Om längden anges på END-posten för typerna SD, PC, CM | ||||
Längd | Styrsektionens längd För typer SD, PC, CM; Pseudo-Registerlängd för typ PR | ||||
Identifierare | Identifierare för SD-post som innehåller namn för typ LD | ||||
Tom | Om typen är ER eller WX | ||||
namn | 33-72 | Varierar | Namn eller understräng av namn |
END post
En modul avslutas med data för END-posten. Detta måste vara den sista posten i modulen. Mer än en modul kan förekomma tillsammans i ett objektdäck (en grupp av moduler placerade tillsammans i en fil), men var och en måste börja med en ESD-post och avsluta med en END-post. | |||
Fält | Byte nr. | Storlek | Anteckningar |
---|---|---|---|
Starta ESDID | 15-16 | 2 | För typ 1 END-post (se byte 33) Binär ESDID för startpunkten för denna modul om given; tomrum om typ 2 END-post eller inte ges. Observera att start-ESDID för denna modul kan vara en extern symbol. Detta gör att en modul automatiskt kan starta ett körtidsbibliotek eller en startkod istället för sig själv. (Språkkompilatorn skulle antingen alltid tilldela huvudprogrammet för ett program som det kompilerade samma namn eller skapa ett alias "postnamn", antingen en SD- eller LD-post med ett standardnamn som alltid var detsamma och till vilket det kunde överföras kontroll till när den var redo att starta användarens program.) |
Startnamn | 17-24 | 8 | För typ 2 END-post (se byte 33) namn på startpunkten för denna modul om det ges; tomrum om typ 1 END-post eller inte ges |
Modulstorlek | 29-32 | 4 | Binär längd på modulen i byte om den inte anges på SD-posten i ESD-posten; byte 29 är noll om den specificerades där; ämnen om de inte tillhandahålls. Detta gör att en kompilator i huvudsak kan vara "one pass" och skriva objektkoden till en objektfil som den kompilerade den, och sedan ange storleken på modulen efter att den hade kompilerat den, när den faktiskt "vet" hur stort programmet är. |
END Format eller IDR-antal | 33 | 1 | EBCDIC-siffrigt tecken '1', '2' eller tom; indikerar formattyp för END-post. Observera att vissa versioner av assemblern använder denna byte för att indikera antalet Identifier-poster (IDR) (värden i byte 34–52, eller i 53–71 om sådana finns), som finns i denna post. Tom kan betyda att 1 post finns, eller att ingen finns, eller kan användas för att indikera att det är en typ 1 assembler-post. Identifieringsfälten är i huvudsak ett kommentarsfält så att de kan användas till vad som helst (särskilt ordernummerfältet), eller kan vara tomt. |
Observera att byte 34–52 kollektivt hänvisas till som en IDR-post. Byte 53–71 är kända som en sekundär IDR-post. De kan antingen eller båda vara tomma. Dessutom, till skillnad från alla andra informationsfält som innehåller siffror, är värdena i en IDR all text och ingen är uttryckt i binärt. | |||
Beställningsnr. | 34-43 | 9 | Beställningsnummer för assemblern eller kompilatorns identifierare, kan ha bokstäver eller siffror |
Version | 44-45 | 2 | 2-siffrigt versionsnummer för assembler eller kompilator |
Revision | 46-47 | 2 | 2-siffrigt revisionsnummer för assembler eller kompilator |
Körår | 48-49 | 2 | De två sista siffrorna i år som denna sammanställning kördes eller programmet kompilerades t.ex. 80 för 1980 eller 2080. Givet när formatet utvecklades är 00 och siffror större än 63 troligen på 1900-talet (1964-2000) och alla siffror över 0 och under 64 är troligen i den 21:a (2001-2063). |
Löpdag | 50-52 | 3 | 3-siffrig dag på året som denna sammanställning kördes eller programmet kompilerades, t.ex. 001 för 1 januari; 032 för 1 februari, etc. Siffror senare än 059 (vilket alltid skulle betyda 28 februari) kan vara en dag eller dagen efter det datumet beroende på om det ursprungliga programmet kompilerades eller sattes ihop under ett skottår; 060 skulle vara antingen 29 februari ett skottår eller 1 mars vilket som helst annat år. 365 skulle vara 30 eller 31 december beroende på om året det sammanställdes var ett skottår eller inte. 366 skulle alltid betyda en modul monterad eller sammanställd den 31 december under ett skottår. |
Ytterligare identifierare | 53-71 | 18 | Är i huvudsak samma format som 33–52 om det ingår, eller är tomt. |
- ^ OS/VS - VM/370 Assembler Programmer's Guide , GC33-4021-4, Fifth Edition, IBM, San Jose, CA (september 1982) http://www.textfiles.com/bitsavers/pdf/ibm/370/asm /GC33-4021-4_OS_VS_VM_370_Assembler_Programmers_Guide_Sep82.pdf
- ^ VS/9 Assembler Referenshandbok: Programmeringsguide för Univac 90/60, 90/70 och 90/80 serier stordatorer, Sperry Univac, Cinnamonson, NJ, 1978
- ^ ASSEMBH Reference Manual , U5223-J-Z125-3-7600, Fujitsu Technology Solutions GmbH, juni 2010, http://manuals.ts.fujitsu.com/file/957/assh_bs.pdf (Hämtad 7 augusti 2013)
- ^ High Level Assembler för z/OS & z/VM & z/VSE Programmerarguide , Appendix C. Release 6, SC26-4941-05, IBM, San Jose, CA, juli 2008 http://publibfp.boulder.ibm. com/cgi-bin/bookmgr/download/asmp1020.pdf (hämtad 27 mars 2010)
- ^ IBM z/VSE System Control Statements: Version 5 Release 1 , SC34-2637-00, IBM, 1984, 2011.
- OS/MVS Program Management: Advanced Facilities , SA22-7644-07, Eightth Edition, IBM, Poughkeepsie, NY, Eightth Edition, September 2007 http://publibz.boulder.ibm.com/epubs/pdf/iea2b270.pdf (Hämtad 9 augusti 2013
- John R. Ehrman, How the Linkage Editor Works: A Tutorial on Object/Load Modules, Link Editors, Loaders, and What They Do for (and to) You , IBM Silicon Valley (Santa Teresa) Laboratory, San Jose, 1994, 2001 ftp://ftp.boulder.ibm.com/software/websphere/awdtools/hlasm/s8169a.pdf (hämtad 29 juli 2013)