CA1248238A - Compiler including retargetable data generation - Google Patents

Abstract

ABSTRACT OF THE DISCLOSURE
A retargetable data generation method for a compiler program which may be executed on a general purpose information handling system such as an IBM*System 370 includes the following steps, ordering the data according to a storage class, mapping the ordered data into sections in accordance with established criteria, ordering the sections into a number of parcels in accordance with one or more data attributes, determining format for an item in a parcel, and formatting each such item in each such parcel according to the determined format.
* Registered trade mark

Description

3~

COMPILER INCLUDING RETAGETABLE DATA GENERATION

BACKGROUND OF THE INVE~rION
1. Field of the Invention The presen~ inventlon relates to methods for controlling Information Handling Systems and more ! particularly to methods for adapting compiler programs to different Information Handling Systems.

2. Description of the Prior Art Retargetable Compilers O Most compilers are designed to take as input programs written in one specific language (e.g., FORTRAN, PASCAL, COBOL) and generate code for one specific target machine (e.g., IBM System 370). To generate code for a different target machine a significant portion of the compiler needed to be rewritten in order to build a compiler for the new tar8et machine. The goal of a retargetable compiler is to make the building of a compiler for a new target machine a much simpler task.
The primary outputs of a compiler program are program code and data. The functions within the compiler to provide these outputs are generally referred to as code generation and data generation.

Tha present lnvention relatés ~o a re~argetable data generation function in a retargetable compiler program.
The following are systems representative of the prior art.
The following publications relate generally to retargetable compilers but focus on ~he code generation function of compilers rather than data generation.
"A Machine Independent Algorithm for Code Generation and Its Use in Retargetable Compilers", by 0 R. S. Glanville, Ph.D. Dissertation, Depar-t~ents of Electrical Energy and Computer Science, University of California at Berkley, December, 1977, includes a detailed description of a design Qf a retargetable compiler which incorporates a retargetable code genera~or.
Although the dissertation discusses many aspects of retargetable compilation, it does not deal with the function of retargetable data generation according to the present invention.
O "~ New Method for Compiler Code Generation", by R.
S. Glanville and S. L. Graham, Fifth ACM Symposium on Principles of Programming Languages, January, 1978 at pages 231-240, also deals with the retargetable code generation func~ion in a retargetable compiler. The paper relates generally to R table driven code generator in which the compiler may be retar8etted to any number of processing systems by replacin~ the table.
As above, although the paper relates generally to retargetable compilers, the paper does not address the problem of retargetable data generation in accordance with the present invention.
"Retargetable Compiler Code Generation", by Ganapathi, Fischer and Hennessy, ACM Computing Surveys, V~lume 14, Number 4, December, 1982, as above relates 0 generally to the problem of retargetable code generation techniques for retargetable compilers.
However, the paper does not address the problem of retargetable data generation which is the subject matter of the present invention.
S The following U.S. patents are cited for completeness. ~lthough the patents relate generally to compiler progrnms, none of the patents cited below teaches nor sug~ests a retargetable data generation method in accordance with the present invention. il. 5 0 U.S. Patent 3,593,313 for Calculator Apparatus by Tomaszewski, et. al.; U.S. Patent 3,8Z8,322 for Electronic Computers to DeSandre, et. al.; U.S. Patent

3,530,232 for Format Insensitive Digital Compute~ to Wnllach, et. al.; U.S. Patent 4,126,897 for Request Forwarding 5ystems to Capowski, et. al.; U.S. Patent

4,342,081 for Tap~ Device Adapter to Dubuc; U.S. Patent 4,417,322 for Peport Generation Control Syste~ for Text Processing Machines to Berry, et. al.; U.S. Patent 4,433,377 for Data Processing with Format Varying to Eustis, et. al.; U.S. Patent 4,435,758 for Method for Conditional Branch Execution in SIMD Vector Processors, to Lorie, et. al.; and U.S. Patent 4,437,184 for Method of Testing a Data Communications System to Cork, et.
al.

SUMMARY OF THE INVENTION
Therefore~ it is a primary object of th~ present invention to generate r~targetable data in a compiler program for an information handli~g system including the steps of ordering the data according to a storage class, mapping the ordered data into sections in accordance with established criteria, ordering the S sections into a number of parcels in accordance with on0 or more data attributes, determining format for an item in ~ parcel, snd formatting each such item in each such parcel according to the determined format.
It is a further object of the present invention to O map retargetted data in accordance with a parcel value assigned to the data.
It is yet another object of the present invention to g~nerate retargetable data for a compilier program further including ~ generation of a number of tables which are used in various phases of compiler operation to construct desired retargetted output data.

Accordingly, a retargetable data generation method for a compiler program which may be executed on a general purpose information handling system such as an IBM System 370 lncludes the following steps: ordering ; the data according to a storage class, mapping the ordered data into sections in accordance with established criteria, ordering the sections into a number of parcels in accordance with one or more data attributes, determining format for an item in a parcel, O and formatting each such ltem in each such parcPl according to the determined format.
The foregoing and other objects, features and advantages of the invention will be apparent from the more particular description of the preferred embodiments of the invention, as illustrated in the accompanying drawing.

BRIEF DESCRIPTION OF THE DRAWING
Fig. 1 is a diagræ~ showing phases of compiler program operation.
~O Fig. 2 is a block diagram of a retargetable compiler program showing the base compiler load modules and a number of target dependent load modules.
Fig. 3 is a flow chart diagram of the construction of a ~argct dcpendent load modulc for a retargetable :5 compiler program.

-~ ~z~

Fig. 4 is a diagram of the organization of data into sections and parcels in accordance with a preferred embodiment of the present invention.
Fig. 5 is a block flow diagram of the operation of 8 retargetable data genera~ion method in accordance with z preferred embodiment of the present invention.
In the drawing, like elements are designated with similar reference numbers, and identical elements,in different specific embodiments are designated by O identical reference numbers.

DESCRIPTION OF A PREFERRE~ E~IBODIMENT OF 1~ VENTION
Introduction Compiler programs and the construction thereof are well known to those skilled in the art. Normally, a compiler is designed to improve the efficiency of execution of an application program written in a specific high-level programming language. To enha~ce the vfllue of applications programs and make them migratable from one system to another, a compiler is required which can compile the application program into assembler code which can execute on different computing systems.

A compiler according to the present inve~tion can be "retargeted" to produce machine-specific code for any machine whose characteristics have been described to the compiler.

The primary outputs of a compiler are code and data.
The jobs to do this are generally refered to as code generation and data generation. Within data generation, O some of the functions which must be performed are the ordering of data according to "storage class" (e.g., static data, automatic data~ based data, etc), the selection of which items known to the compiler are actually to bq generated, the form in which they are to be generated, and any desired orderlng of items within ~2~3~
the storage class. Frequently, too, it is necessary to precede and follow data within a storage class r"ith special controls or lnformation (e.g, assem~ler controls, linkage editor controls~ boundary alignment information, etc.).

These problems have been solved in the past mostly by "hsrd coding" the data genera~ion and sequencing the code to produce the correct ordering. Many thousands of lines of code were required.

O COMPILER PHASES

Most compilers are constructed in terms of a number of "passes" over the source information, or "phases". Some simple compilers make only one pass over the source information while othar, more complex ones, may make S m~ny passes. Fig. 1 shows types of compiler phases.
The concept of compiler phases is generally described in Aho and Ullman "Principles of Compiler Design", Addison Wesley, 1979, at page 5, section 1~3.

To make the building of a compiler for a new target 0 machine n simpler task requires rewriting the target-speciil portions of the compiler so that they are ~able driven (by target-speciic tables) or by replacing specific modules of code with target-specific modules. As a result, portions of the retargetable compiler are the same for all targets ~Base Compiler Load Module) and portions are unique to each supported target machine (Target Dependent Load Module).

When the compiler is invoked, the ~CLM determines the target machins which the user is interested in and loads the appropriate TDLM. This is shown in FIG. 2 The TDLM for a specific target is constructed from O target machine specifications by use of a standard compiler and a generator facility as shown in FIG. 3.

The target machine is defined using macro statements which were designed for ease of communicating information about the target mach me characteristics.
These macros are compiled in the usual manner to produce code and tables.

Some of the information is fed into a parser generator as described by Glanville and the resulting tables and code are used to build a TDLM load module.

) The specification and processlng of the Datagen portion will be shown in more detail below.

~24~3~
RETARGETABLE DATAGEN CONCEPTS

During the operation of the compiler, facilities are provided for the managernen~ of data. This includes data which was defined by the user via explicit and implicit source program declarations and data which is defined by the compiler during its operation, both by the BCLM
and TDLM. Some of the data which is defined may need to be generated as output to the assembler following the operation of the compiler.

0 The Dictionary is the primary repository of information about data during the operation of the compiler. It holds information about constant values, variables, procedures, entry points, program labels, and items ~hich may be output to the assembler (e.g., size of automatic data). Data generation is driven by dictionary entries and therefore all information not generated as "code" must be generated by placing appropriate entries in the dictionary. The ?DIDCL
(declare) and ?DIREDCL (modify) macros are provided to 0 simplify dictionary entry tefinition and modification by BCLM and TDLM authors.

To aid m the generation of data for the assembler, data is grouped logically into "Sections" and "Parcels"
as shown in FIG. 4. Sections are generally used to group data together which share certai~ storage and addressability characteristics and which are generally generated together for the assembler The grouping of dats into the appropriate storage class (and therefore section) is controlled by the explicit or default storage class assigned when the item was declared.
Certain section characteristics may be defined by the TDLM author by using the ?SECTION and ?SECTEND macros (below).

Parcels are a grouping and ordering of data within a section. When Data Generation puts out data for a section it puts out dictionary entries in order according to their parcel number (1 thru Z5;). The allocation of dictionary items to parcel numbers is - defined by the TDLM author using the ?PARCEL macros (below).

O The Parcel definition mncro provides a way for the TDLM author to define the ordering of data for the assembler. The parcel value may also be used to help select the output format for the assembler. Thus the use of the parcel value is als~ a tool for generating unique "card image" sequences for the assembler which 3~

might be required by a paIticular L~l (e.g. CSECT, DS~CT, boundary alignment, special narnes, etc). The parce] and section numbers can be used to precisely control the location and format of specific "card"
types.

Parcels The concept of parcels is used to help control the selection~ ordering and formatti_~ of data.

Data can be selected for Data Generation by placing it O on the appropriate storage class chain and by_~ivin~
a non-zero Parcel value. Dsta with a parcel value of zero will not be mapped by the Data Map phase and will not be Data Gen'd when processing a chain. This is a way to "hide" data from Data Generation. The BC~ does this for certain types of items which by default do not require any data generation (e.g , local labels and entry points). The TDLM may use parcel 0 for items which are used only during the compilation, for items which define constant strings for output formats, or O for items which the TDL~ author will handle in aspecial manner (e.g., imbedded parameter lists generated by codegen).

- \
3~

Non-zero parcel values are useful for ordering the da~a in a data section (e.g., static storage). Through the ?PARCEL macros the TD~l author can specify the criteria by which dictionary entries are given parcel ; values (thus controlling their order of generation).
Thus data items can be ordered for output (e.g., all 4 byte arithmetics, all 2 byte arithmetics, and so on).

Parcel values can be assigned such that certain ones are reserved for special purposes (e.g. parcel 1 item causes generstion of a an @DATA DSECT "card"). It is the responsibility of the TDL~ author to 1) define all the required "card images" for the assembler, 2) assign them to appropriate parcel values so they are generated in the correct position, 3) during exits enter S appropriate entries in the dictionary to cause them to be generated, and 4) define the assembler format of the - image (see below).

The responsibility of the TDLM author for defining the sequence and location of special card images is similar ~0 to the job of generating the linkage convention instruction sequences.

Data Mapping Data mapping is the funtion performed by the BCLM of ordering data according to parcel value and then computing the byte offset of each item as it is rnapped S onto storage. Items are mapped onto s~orage in such a way that the requested boundary requirements are met (i.e., "holes" are left if necessary to meet boundary requirements). Data are mapped by the Data Map phase just prior to Codegen. This is done so that instruction 0 references to this data can be resolved to an absolute offset value.

The TDLM can specify that spaces be left in storage when data is mapped. This is done in the section definitions using the black hole (?BLAKHOLE) macro.
i Items are mapped as usual, with spaces skipped as required by the TDLM.

Data specified as parcel 0 are treated uniquely. They are ordered first relative to other parcel values by Data Map, but they are not mapped (offsets calculated) and they are not Datagen'ed when encountered while processing a chain.

~2~Z3~
Data Formating Various assemblers have different conventions for the formatting of data items. The locations, ordering and "spelling" of certain things can differ. Also the manner in which boundary alignment and "spacing" is accomplished can differ. The TDLM author must define the formats which can be generated and the selection criteria by which a format i5 chosen for a dictionary entry. This is done using the ?DAT~FORM (formats) and .0 ?ASMDATA (selection criteria) macros (below).

In summary, this general and easily retargetable approach then allows:

Storage classes to be generated in any desired order by mapping to specific section numbers.

Control information related to a storage class can be specified on the section definition and, optionally, precede or follow the data for the storage class.

Data items known to the compiler which should not O be generated can be assigned to parcel O which is never generated.

RT qR ~ -nn~ - 15 3~

o Items can be efficiently packed within a storage cl~ss by selscting items with similar size chsracteristics and assigning them to th2 same parcel values and placing those with different characteristics in different parcel values.

If the machine has instructions which can more efficiently access items in a particular part of storage, this can be controlled by appropriate assignment to parcel values.

. Any special control "cards" for an assembler or linkage editor ("funny cards") can be generated if desired in the correct location by appropriate assignment to speclal parcel numbers.

Uniqus formatting requirements can be controlled 1~ by the assigment to particular section or parcel values.

The approach described has been found to be very adaptable to a number of unique machine and assembler requirements. The retargetable compiler code to support this powerful approach is only a fraction of the size of the "hard coded" approach and the spscificat.iQn for a particular target machine is typically only about 100 lines of easily maintainable macro specification.

3~
Significan~ Features:

o Simple yet very general specification of the data capabilities of a target machine.

~ Provides ease of retargetability of the compiler data generation to different target machines.

SPEC:IFYING A RETARGETABLE DATAGEN

To specify the datagen component for the retargetable compiler ths "TDLM author" must specify the following information so that the generator can generate the O necessary pieces of the TDLM. You may wish to refer ~o the example and operation sections below to better understand the following description. Each of the macros described belo~ is used to build a table of information, but the description of the operation may, for simplicity, describe the compiler operation with reference to the macros.

The TDLM author must specify how the data within each section of storage is assigned to parcels. This is essentially an order1ng of the data based upon the O characteristics of the data. The ~SECTION mflCrO defines the start of a section specification and the ?SECTEND

.

macro designates the end. Within a sec~ion, the ?PARCEL macro is used to define the data characteristics which cause program data (dictionary entries) ~o be assigned a partlcular parcel ~urnber.
During Dictionary Completion phase the compiler uses the table built from the ?P~RCEL macros to assign a parcel number to each dictionary entry. The parcel specifications are searched in the order they were specified so that the specifications can be used to ~ "sieve out" various types of data. Any data added to the dictionary in later phases is also assigned a parcel number in the same manner by the dictionary service routines.

Judicious choices i~ the ordering of information and assignment of parcel numbers can be used to minimize the number of ?AS~ATA and ?DATAFORM macros described below. This is illustrated in the example.

During the Data Map phase the dictionary is actually sorted in section and parcel number order so that data 0 generation can put the items out in the order desired by the TDLM author. l'he data map phase also assigns offset values to each dictionary item. The ?BLAKHOLE
macro is used by the TDLM author to specify any storage locations which are unavailable for assignment.

3~3~

The ?ASMDATA macros are used at data generatior~ time to determine how each item (except parcel O items) from the dic-tionary is to be formatted. ~le "sieve" of ?ASMDATA macro statements selects a 7DATAFOR~ rnacro to be used to format the dictionary iteM. ~le ?DATAFOKM
macro specifies the actual format of the item.

DATA GENERATION OPERATION

The following provides a description of how the infor~ation providsd by the TDLM author is used to O construct the TDLM datagen information for the target machine and how this information is used during the operation of the retargetable compiler to generate data for the target machine.

The source information from the TDLM author is compiled into tables, as shown in FIG. 5, in a straightforward manner. These tables are then used by a number of phases of the compiler to construct the desired output information.

The TDLM is generated once to build the TDLM (Target O Dependent Load Module). Thereafter, whenever the compiler is invoked, the TDLM is loaded and linked into the base compiler load module. This provides the base 3~
c~mpiler with the access to the ~arget dependent tables needed to generate the da~ according to the rOIM
author's specifications.

The manner in which the data from the TDLM author's specifications is used is outlined in the section describing the TDLM macros.

DATA GENERATION SPECIFICATION EXAMPLE

?TDLMOOO;

?BLAKHOLE SIZE(10) MODULAR(1024);
~O /* SKIP 10 BYTES EVERY */
/* 1024, START AT O */
?SECTION NAME(SI'ATIC);
?PARCEL VALUE(41) CAV(A#BIN32) BDY(EQ);
/* screen out Fixed 32 */
?PARCEL VALUE(41) CAV(A#BIT32) BDY(EQ);
/* screen out Bit 32 */
?PARCEL VALUE(42) CAV(A#BIN31) BDY(EQ);
/* screen out Fixed 31 */
?PARCEL VALUE(51) CAY(A#BIN16) BDY(EQ);
!0 /* screen out Fixed 16 */
?PARCEL VALUE(51) CAV(A#BIT16) BDY(EQ);
/* screen out ait 16 */

3~
?PARCEL VALUE(52) CAV(A."BIN15) BDY(EQ);
/* screen out Fi~ed 15 ~/
?PARCEL VALUE(70) DEFAULT;
/~ ANYTHING ELS~ LAST */
?SECTEND;

~z~
?SECTIO,~ NA~IE(AVTOMATIC) STARTLBL('@DATA') STARTVAL(100);
?PARCEL VALVE(41) CAV(A#BIN32) BDY(EQ);
/* screen out Fxed 32 */
; ?PARCEL VALUE(41) CAV(A#BIT32) BDY(EQ);
/~ scr~en out Bit 32 */
?PARCEL VALUE(42) CAV(A#BIN31~ BDY~EQ~;
/* screen out Fixed 31 ~/
?PARCEL YALU-.(51) CAV(A#BIN16~ BDY(EQ);
/* screen out Fixed 16 */
~O ?PARCEL VALUE(51~ CAV(A#BIT16~ BDY(EQ);
/* screen out Bit 16 */
?PARCEL VALUE(52) CAV(A#BIN15) BDY(EQ);
/* screnn out Fixed 15 */
?PARCEL VALUE(70) DEFAULT;
~5 /* ANYTHING ELSE LAST */
?SECTEND ENDLBL('@ENDDATA');

Z3~3 ?ASMDATA DATAFORM(STORAGE) PARCEL~41) ARGS~'F');
/J" Fixed 32 */
?AS~ATA DATAFO~I(STORAGE) PARCEL(42) ARGS('F');
/* Fixed 31 */
?AS~ATA DATAFORM(STORAGE) PARCEL(51) ARGS('H');
/* Fixed 16 */
?AS~fDATA DATAFORM(STORAGE) PARCEL(52) ARGS('H');
/* Fixed 15 */

/* "Funny cards" to delimit sections O to the assembl~r and pgm end */
?ASMDATA DATAF0~1(CSECT ) PARCEL(l);
/~ Parcel 1 is CSECT card*/
?ASMDATA DATAFORM(SECTIONj PARCEL(2);
/* Name Section begin pt */
?ASMDATA DATAFORM~SECTION) PARCEL(254);
/* Name Section end point*/
?AS~ATA DATAFORM~PGMEND ) PARCEL~255);
/* End of program "card" */

3~3 ?DATAFOR~ NA~E(SECTION) FIELDS(NAME,TAB(lO),'ORG J ~ ) ;
?DATAFORM NA~IE(CSECT
FIELDS(NAME,TAB(lO),'CSECT ,',BVY);
?DATAFORM NA~(STORAGE) FIELDS(NAME,TAB(lO),'DS',TAB(16),ARG);
?DATAFORM NA~(PGMEND ) FIELDS(TAB(lO),'END ',NA~, '(' , CONSNAME(@VERSION), ',' , CONSNAME(@DATE), ')' );

?TD~IOOg9;

DATAGEN MACROS

This section describes in precise detail the use of specific datagen macros and provides limited examples S of their use in context. If the detailed use is not of interest to you this section may be skipped and used simply for reference.

'SECTIC)N MACRO' The SECTIOM macro defines a section of data.

?-SEGTION-NAME(<name>)~
, ~ , ~ STARTL8L~<label>)~ ~STARTVAL(<fx value>)T-;
.

NAME(~name>) O - This is the name of the section (e.g., STATIC, AUTOMATIC).

STARTLBL(~label>) - This provides a place for the TDLM author to define a default section start "label". This can be retrieved by the TD~l exits and its use and interpretation are up to the TDLM exit author. The <label> may be either a quoted char string or variable holding a character string.

STARTVAL(<fx value>~
This v~lue will be used by the data mapping service as the starting value of the Data Genereation offset.

3~

If none is specified, zero is used. The <fx value> may be either a constant value or variable holding a fixed value.

'Examples' ?SECTION NA~E(STATIC);
-?SECTION NA~(AUTOMATIC) STARTLBL('@DAT~')STARTVAL(100);

'SECTEND MACRO' The SECTEND macro defines the end of a section ~O definitio~. All ?PARCEL macros between a ?SECTION and ?SECTEND apply ~o that section.

. . . _ .
?-SECTEND = T--;

~5 ENDLBL(<label>) - This provides a plac~ for the TDL~ author to define a default section end 'label". This can be retrieved by 3~

the TDL`I exits and its use and interpret~tion are up to the TDL~I exit author.

'Examples' ?SECTION NAME~STATIC);
...
?SECTEND;

?SECTION N~IF(AUTOMATIC) STARTLBL(@DATA);

?SCTEND ENDL~L(@ENDDATA);

'PARCEL MACRO' The PARCEL mscro specifies the criteria for placing a dictionary item into the specified parcel (given parcel value). The parcel definitions should be thought of as a series of "sieves" which select out items for a i particular parcel. Thus, the order of parcel definitions is very important. Every one of the specified conditions must be met ("AND" relationship).
"OR" relationships are specified by using muLtiple PARCEL macros. "NOT" conditions are handled by ) screening out the undesired relation with a prior PARCEL macro. If a definition appears to select items ~2~

which are not desired, a yrior definition may be required to "screen out" the unwanted i~ems. ~lore than one definition c~n specify the same parcel value.

?-PARCEL-VALUE(~fx value>)~

~CAV(<A# const>)J
- I
I ` r-- -- - -r v~
~AITRS(lD# const>l)J
I
I j ~PLACE(<fx value>) J
_ L-BDY(<relational>) !0 L~BDYOFF(CONFORM)J ¦

I I I ;
~DEFAULTJ

.

S VALUE(<fx value~) - This is the number of ehe parcel by which parcels will be ordered by premap.

CAV(<A# const>) - The A#const values are compiler-defined constants which are used to indicate ~ specific data~ype/precision. This keyword indica~es the datatype requirements for items to be in the parcel.
The A#-const can be a specific class/element (e.g., A#BIN31 - Binary Fixed 31) or an entire class ~e.g., A#CHR - any charac~er string item). If no CAV value is specified or A#NULL is specified then there are no datatype restrictions.

PLACE(<fx value>) - This indicates the minimum boundary to which each ~0 dictionary item in this parcel will be mapped by premsp. The range is >~1 and <= Z~31 and it must be a power of t~o( 1, 2, 4, 8 etc...). The default value is 1. Use of certain PLACE values may cause bytes to be skipped in storage.

BDY(<relational') - This is used to specify a relational (EQ, LT, GT, LE, GE, NE). This keyword indicates that the dictionary item must meet the specified boundary relationship with respect to the default boundary for O the datatype (e.g., if the bdy of the dictionary item is "word" t4) and the default is halfword (2) then the relationship GE (i.e., 4 GE 2) would be met but the relationship EQ t4 EQ 2) would not be. This keyword can be used to screen out items with high boundary requirements which might cause poor packing of data.

BDYOFF(CONFOR~l) - This keyword may be used only with BDY relationals ~0, GE or GT. It specifies that the bdy offset of the dictionary item must conform with the default bdy offset. For example, if the deEault bdy is (4,2) then the bdy/offsets which conform are (4,2), (8,2), (8,6), (16,2), (16,6), (16,10), etc. In other word the remainder of the item boundary divided by the default boundary must equal the default offset.
- D#const values are used to indicate any valid da~a at~ribute (e.g., STATIC, AUTOMATIC, NONLOCAL, ARRAY, STRUCTURE, etc).

ATTRS(<D# const list>) Thi~ keyword specifies a list of attributes which must be met for the item to be placed in the specified parcel.

DEFAULT
- This specifies that this VALUE is also the DEFAULT
value to be used if none of the parcel specifications ~re met. It can be specified on any of the specs, but ~0 can be specified only once pcr SECTIO~.

'Examples' ?SECTION NAME(AUTO~IATIC) STARTLBL(@DATA);
?PARCEL VALUE(70) ATTRS(D#STRC);
/~ SCREEN OUT S1'RUCTURES ~/

~5 KI985-006 - 30 -3~

?PARCEL VALUE(80) ATTRS(D#DIM );
/* SCREEN ou-r ARRAYS ~/
?PARCEL VALUE(90) BDY(GT);
/* SCREEN o~r I,ARGE BDYS '/
?PARCEL VALUE(30) CAV(A#FXBIN);
/* ARITH~IETICS FIRST ~/
?PARCEL VALUE(40) DEFAULT;
/* ANYl~IING ELSE SECOND */
?SECTEND ENDLBL(@ENDDATA);

'BLAKHOLE MACRO' The BLAKHOLE macro specifies the criteria for skipping spaces in storage. It defines the areas to be skipped and how often they occur. Data items will then be mapped around these holes.

lS . _ _ _ ?-BLAKHOLE - SIZE(value) -~

~0 LMODULAR(repeats,starts)- ;

3&~
SIZE(value) - This is the size of the space to be skipped in storage. , ~IOVULAR(repeats,starts) - "Repeats" indicates how often e~ch space occurs and "starts" indicates the start of the first space.
"Starts" has a default value of 0.

EXAMPLE
FO OFF
.0 ?SECTION NAME(AUTOMATIC) STARTLBL(@DATA);
?BLAKHOLE SIZE(16) MODULAR(2048,10);
?BLAKHOLE SIZE(10) MODULAR(lOZ4);
/* STARTS DEFAULTS TO O */
?BLAKHOLE SIZE(5) MODULAR(2048);
.5 /* STARTS DEFAULTS TO 0 ~/
?SECTEND ENDLBL(@ENDDATA);

'THE ASMDATA MACRO' The ASMDATA (assembler data) macro specifies the criteria for selecting a specific data forma~ and the :0 arguments (if any) passed to it.

- - - - - - - - -?-AS~IDATA-DATAFOR~I(cname>)~
-J v -,---~--~
~-ARGS(I <field-def>
S ~< .
~PARCEL(~fx value>) ~<
~-BDY(<fx value>) ~ < ~
~BDYOFF(<fx value>) -I
~ < - - - - - . . .
~-ATTRS(<~ value~) ~
~<
~-CAV(~A~value>) ---~<
~-DNAME(~dname~
.

~!0 DATAFORM(<name~
- This is the name of the format (unquoted). It can be aIIy unique name from 1 to 8 characters.It must match a format name in a DATAFOR~I macro.

ARGS
'S - This defines the arguments passed to the format.

PARCEL(<fx value>~
- The item ~ust have the specified parcel value in order to be selected by this macro.

BDY(<fx value>) ~ KI985-006 - 33 -- The item rnust have the specified boundary valu~ in order to be selected by this macro.

BDYOFF(cfx value>) - The item must have the speclfied boundary offset value in order to be selected by this macro.

ATTRS(<D#value~) - The item must have the specified attributes in order to be selected by this macro.

CAV(<A#value>) - The item must have the specified composite attribute value in order to be selected by this macro.

DNAME(<dname>) The item must have the sp~cified dictionary name in ` orde~ to be selected by this macro.

'Examples' ?ASMDATA DATAFORM(STORAGE) CAV(A#BIN31) ARGS('F');
?ASMDATA DATAFORM(STORAGE) CAV(A#BIN32) ARGS('F');
?ASMDATA DATAFORM(STORAGE) CAV(A#BIN15) ARGS('H');
?ASMDATA DATAFORM(STORAGE) CAV(A#PTR32) ARGS( A );
?AS~IDATA DATAFORM(CSECT ) PARCEL(l);
?ASMDATA DATAFORM(SECTION) PARCEL(Z);
7ASMDATA DATAFORM(SECTION) PARCEL(254);
?ASMDATA DATAFOR~I(PGMEND ) PARCEL(255);

'THE DATAFORM MACRO' The DATAFORM ~data format) macro specifies the format of data for the assemble.

. _ O ?-DAT~FORM-NAME(<name>)-~
l ~ l 'FIELDS( -I-'field-def>~

NAME(<name>) - This is the name of the format (unquoted). It can be any unique name from 1 to 8 characters.

FIELDS
- This defines the fields of the format.

ARG or ARG(<fx value>) - Keyword indicates that the content of this field is specified by an argument ~rom th~ ?AS;~arA rnacro which caused this format to be selected.

'Examples' ?DATAFORM N~(SECTION) FIELDS~NAME,TAB(lO),'ORG -');
?DATAFORM NAME(CSECT
FIELDS(NAME,TAB(lO),tCSECT ,',BDY);
LO ?DATAFORM N~(STORAGE) FIELDS(NAME,TAB(lO),'DS',TAB(16),ARG);
?DATAFORM NAME(PGMEND ) FIELDS(TAB(lO),'END ',Ne~IE, '(' , CONSNAME(@VERSION), ',' , CONSNAME(@DATE), ')' );

'THE TDLMOOOO STATEMENT' The TDLMOOOO statement appears exactly once and must be the first statement coded in the Datagen TDLM
definition. It replaces a normal PL/S PROC statement.
~0 It has the for~:

~- name:- TD~10000 - DATAGEN
LLEvEL~ evel-characters-)-;

-- -_ _ _ _ _ _ name - This is the name of the Datagen modula. It is pointed to by the NAME keyword on a LOADLIST macro which has "PHASE(DATAGEN)" coded.

Q DATAGEN
- This keyword is coded to irldicate that Datagen is being defined. Other TD~I modules will also use the TDLMOOOO statement but with different keywords provided~

LEVEL ( level characters ) - The level of this expression transformation module is defined by the author of the TDLM. It is a character string of one to eight characters.

Example:

? IRLUClJ: TDL'IOOOO DATAGEN LEVEL( 00001.00 ~;

3~
'THE TDLM0099 STATEMENT' This is coded once. It replaces the "ENDj" statement which normally terminates a PL/S program. The statement has the following form:

S
? - TDLM0099 _ _ Thus, while the invention has bsen described with reference to preferred embodiments thereof, it will be understood by those skilled in the art that various changes i~ form and details may be made without departing from the scope of the invention.

Claims (11)

The embodiments of the invention in which an exclusive property or privilege is claimed are defined as follows:

1. A method for compiling a program for use with one of a plurality of data processing systems comprising the steps of:
separating the program into procedural code and data objects;
determining a target system as one of said plurality of data processing systems for which compiling is to be performed;
generating procedural code for said target system;
ordering data objects into sections according to storage class;
ordering data objects within said sections into a plurality of parcels in accordance with one or more data attributes of said data objects;
determining an output format for said target system for each data object in each parcel; and generating each data object in each parcel according to the determined format for said target system.

2. A method for compiling a program according to claim 1 further comprising the steps of:
building a dictionary of formatted items to store information regarding data objects to be generated;
modifying dictionary entries to reflect data object section and parcel; and ordering said dictionary by section and parcel.

3. A method of constructing a compiler program for compiling a program as defined in claim 1 to generate code for a target data processing system, the method comprising the steps of:
dividing compiler functions into target data processing system specific functions and base compiler functions;
generating target system specific tables to support the target specific portions of the compiler through the steps of:
specifying target system specific section classification criteria;
specifying target system specific parcel classification criteria;
specifying target system specific output formats associated with each section;
specifying target system specific output formats associated with each parcel;
generating target system specific tables from said target specific classification criteria and output formats.

4. A method of constructing a compiler program according to claim 3 further comprising the steps of:
constructing one or more target system specific load modules containing target system specific portions of said compiler;
selecting one of said target specific load modules corresponding to said selected target system and joining said base compiler functions and said selected target specific load modules to form a complete compiler program.

5. A method according to claim 1 wherein the step of determining an output format comprises:
determining output format for objects within said parcel;
determining unique formatting requirements for said parcel on said target system;
determining the need for additional spacing within said data output formats for said parcel on said target system.

6. The method according to claim 1 wherein the step of generating each data object comprises the steps of:
determining whether the parcel requires data generation;
generating each data object in said parcel according to the determined format for said target system, if said parcel requires data generation; and repeating said determining and generating steps for each defined parcel.

7. The method according to claim 3, further comprising the steps of:
designating one or more parcel classifications to be ignored during data generation.

8. The method according to claim 3 further comprising the steps of:
designating one or more parcel classifications to be target system specific control parcels; and specifying target system specific output formats for said system specific control parcels to be target system specific control commands.

9. A method for compiling a program for use with one of a plurality of data processing systems, said method comprising:
separating the program into procedural code and data objects;
determining a target system as one of said plurality of data processing systems for which compiling is to be performed;
determining data classification criteria associated with said target system;
classifying data objects according to said data classification criteria;
ordering data objects by data classification;
determining data output format associated with each data classification;
generating procedural code;
generating data items for use with said target system from said ordered data objects in accordance with said data output format.

10. The method according to claim 9 wherein said step of classifying data objects comprises:
determining data object section based on data object storage and addressability characteristics; and determining data object parcel based on data object type and output formats required for said target system.

11. The method according to claim 9 wherein the step of ordering data objects of data classification comprises:
building a dictionary of data objects;
modifying said dictionary in accordance with data classification criteria; and ordering said dictionary by said data classification criteria.