Re: IBM mainframe compilers produce object code or invoke assembler?

glen herrmannsfeldt <gah@ugcs.caltech.edu>
Wed, 27 Apr 2011 23:22:16 +0000 (UTC)

          From comp.compilers

Related articles
Re: IBM mainframe compilers produce object code or invoke assembler? compilers@is-not-my.name (2011-04-27)
Re: IBM mainframe compilers produce object code or invoke assembler? rivers@dignus.com (Thomas David Rivers) (2011-04-27)
Re: IBM mainframe compilers produce object code or invoke assembler? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2011-04-27)
Re: IBM mainframe compilers produce object code or invoke assembler? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2011-04-27)
Re: IBM mainframe compilers produce object code or invoke assembler? arnold@skeeve.com (2011-04-29)
| List of all articles for this month |

From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups: comp.compilers
Date: Wed, 27 Apr 2011 23:22:16 +0000 (UTC)
Organization: A noiseless patient Spider
References: 11-04-040
Keywords: object, assembler
Posted-Date: 27 Apr 2011 19:31:36 EDT

compilers@is-not-my.name wrote:
> Does anyone happen to know if the traditional IBM language products like
> COBOL, PL/I, FORTRAN etc. invoke the assembler internally to produce object
> code, or if they produce object code directly?


All the ones I know of generate code directly. They also can produce
a listing of the generated code, usually in a form that would not be
acceptable as input to an actual assembler.


> If they produce object code directly, what is the reason that
> approach was chosen instead of invoking the assembler?


The OS/360 assembler F, among others, is pretty slow. I believe
it uses four passes. The XF assembler and Assembler G from
Waterloo are similar, but with some consolidation to reduce
the number of passes. (And intermediate files between the passes.)


> What are the benefits and disadvantages of the possible approaches?


> It seems to me a little risky to generate object code since
> presumably the assembler will always be updated as part of the base OS
> deliverable but then again maybe that's also a moving target to be avoided.


As far as I know, the main advantage of the indirect method is that
it allows the assembler to worry about addresses and offsets.


For a forward reference, you don't know the address until sometime
later. For direct generated code, you have to keep it in memory until
you have the offset. Well, there is another way with the OS/360
object module format, and that is that you can write out the offset
later. Each card has a starting address on it. As far as I know,
though, that wasn't usual for compilers. (It was commonly used for
debug patching to save the time of running the assembler. Some
routines have a patch area so you can add instructions.)


I do remember stories about older machines that generated assemblable
output. One is about an assembler that used the first four characters
of labels for its symbol table hash function, and the corresponding
compiler that generated labels of the form XXXXnnnn where the XXXX
were actual C'XXXX' characters, and the nnnn were digits.


-- glen
[IBM Assembler H and its descendant HLASM are a lot faster, but they're
not part of the base system. -John]



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.