Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #107 > unrolled thread

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

Back to article view | Back to comp.compilers

Contents

  Re: IBM mainframe compilers produce object code or invoke assembler? compilers@is-not-my.name - 2011-04-27 21:19 +0000
    Re: IBM mainframe compilers produce object code or invoke assembler? Thomas David Rivers <rivers@dignus.com> - 2011-04-27 19:05 -0400
      Re: IBM mainframe compilers produce object code or invoke assembler? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-04-27 23:46 +0000
    Re: IBM mainframe compilers produce object code or invoke assembler? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-04-27 23:22 +0000
    Re: IBM mainframe compilers produce object code or invoke assembler? arnold@skeeve.com (Aharon Robbins) - 2011-04-29 07:31 +0000

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

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? If they produce object code
directly, what is the reason that approach was chosen instead of invoking
the assembler? 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.
[They produce code directly.  Unix compilers are pretty much the only ones
that run through the assembler, and that's because the PDP-11 Unix system
had an assembler so fast that it wasn't much slower than generating the
object files directly. -John]

[toc] | [next] | [standalone]

#108

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? ...

In general; they produce object code.  The compilers have to take
advantage of object-specific features that are not available via the
assembler syntax.

The Dignus compilers produce assembler, and we have to provide our own
assembler that not only is IBM compatible, but also has support for
these features.

And, due to the various complexities of IBM assembler syntax, it's
frequently the case that the compile step is much faster than the
assemble step.

   - Dave Rivers -
--
rivers@dignus.com                        Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
[What OS object features can't the usual IBM assemblers produce? -John]

[toc] | [prev] | [next] | [standalone]

#111

Thomas David Rivers <rivers@dignus.com> wrote:
John wrote:

> [What OS object features can't the usual IBM assemblers produce? -John]

For the OS/360 object files, I don't believe there is anything
that the assembler can't produce, but with LE and GOFF, there are
some things.  I don't remember them, and a web search doesn't
show them.

Well, the assemblers have PUNCH which lets you write any bits
you want into the object file.  That is sometimes used to generate
linker control cards into the object deck, and also to generate
the SYSGEN files, which all come from the assembler.

-- glen

[toc] | [prev] | [next] | [standalone]

#109

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]

[toc] | [prev] | [next] | [standalone]

#113

the moderator wrote:
>[They produce code directly.  Unix compilers are pretty much the only ones
>that run through the assembler, and that's because the PDP-11 Unix system
>had an assembler so fast that it wasn't much slower than generating the
>object files directly. -John]

Sadly, modern Unix assemblers are slower.  When Ken Thompson wrote the
C compiler(s) for Plan 9, he went to generating object code directly.
And that was circa 1989!
--
Aharon (Arnold) Robbins 			arnold AT skeeve DOT com
P.O. Box 354		Home Phone: +972  8 979-0381
Nof Ayalon		Cell Phone: +972 50  729-7545
D.N. Shimshon 99785	ISRAEL

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compilers

csiph-web