From: Peter Flass on
Fritz Wuehler wrote:
>> Of course that's effectively two programs - a macro processor and an
>> assembler. The PL/I preprocessor isn't tied to the language and can be
>> used as a general-purpose macro processor.
>
> The IBM assembler macro processor *is* part of the assembler and *is*
> tightly bound to the language.
>

Sort of. OS/360 SYSGEN used the assembler as part of its process, but
it didn't really assemble anything. The sysprog coded assembler macros
to specify the options he wanted included in the system, the macros were
processed by the assembler, which punched a "stage 2" deck of JCL and
utility control cards.

The PL/I preprocessor is part of the compiler, but I have used it for
macro processing completely unrelated to PL/I.
From: glen herrmannsfeldt on
In comp.lang.fortran Peter Flass <Peter_Flass(a)yahoo.com> wrote:
> Fritz Wuehler wrote:
(snip)
>> The IBM assembler macro processor *is* part of the assembler and *is*
>> tightly bound to the language.

> Sort of. OS/360 SYSGEN used the assembler as part of its process, but
> it didn't really assemble anything. The sysprog coded assembler macros
> to specify the options he wanted included in the system, the macros were
> processed by the assembler, which punched a "stage 2" deck of JCL and
> utility control cards.

Yes. With the assembler PUNCH opcode you can send any string
that you can create using the assembler's string processing
out SYSPUNCH. (Where object code normally goes.)

Also, in the early microprocessor days it was often used to
assemble code for other processors. With a macro for each
opcode in the target assembly laanguage, it wasn't hard to do.
The assembler arithmetic operations were used to generate
the little-endian absolute addresses needed.

There was a program to convert the object deck output to the
formats needed, such as motorola hex format (often used to
write EPROMS), and another to make the listing file look like
one would expect.

> The PL/I preprocessor is part of the compiler, but I have used it for
> macro processing completely unrelated to PL/I.

It is more powerful, but less general than the C preprocessor.
The input has to make some sense in terms of the PL/I syntax,
where the C preprocessor will do substitutions even in what
doesn't look much like C.

-- glen
From: glen herrmannsfeldt on
In comp.lang.fortran Peter Flass <Peter_Flass(a)yahoo.com> wrote:
(snip)

> That's it. I believe it was an IBM 704, although probably other old
> computers used them also.

Well, Fortran I on the 704 has the READ DRUM and WRITE DRUM statements.
(That should get it back to Fortran, anyway.)

> Drums were popular as storage on systems,
> even with disks, because, being head per track, they were much faster.
> They were often used as a swap medium.

The IBM 2301 and 2303 were around for the S/370 days, but the
popular swap device for S/370 was the 2305 fixed head disk.
The 2xxx devices are from the S/360 generation, where 3xxx
numbering was used with S/370.

> This is a little far afield for these three NGs.

-- glen
From: James J. Weinkam on
J. Clarke wrote:
>
> The main distinction for me was that dumps don't come out in assembler.
> But I never thought of machine code and assembler being distinct as a
> result--just two ways to write the same thing.

Your point is well taken for machines of the 60's and 70's, at least for the IBM ones with which I
am most familiar. For example in 360 assembler, if you wanted to add two numbers you had your choice
of A, AR, AH, AP, AL, ALR, AE, AER, AD, ADR, AXR, AU, AUR, AW, AWR and maybe a few more that I have
forgotten. There was a one-to-one correspondence between each of these mnemonics and their
corresponding numerical op codes.The assembly language programmer had to choose the correct mnemonic
instruction to suit the circumstances. Moreover, while the assembler may have issued a warning in
some cases, there was nothing to stop the programmer from using, for example, a half word op code to
operate on a variable that had been defined as a full word point value or vice versa.

I think the reason that many people want to make a distinction nowadays is that with processors such
as the Intel 80xxx family, exactly what part of the instruction constitutes the op code is a little
harder to pin down, and with an instruction such as

add x,y

the mnemonic op code add can generate any one of several dozen bit patterns spread varying parts of
the first two bytes depending on how x and y are defined. There is definitely no one-to-one
correspondence between mnemonic op codes and the bit pattern in any specific part of the machine
instruction.

Nevertheless, it remains true that the assembly language programmer who knows what he is about has
complete control over the binary code generated, although I would venture to say that few, if any,
assembly language programmers think of what they are doing in those terms most of the time.
From: Georg Bauhaus on
On 6/8/10 8:27 AM, James J. Weinkam wrote:

> Nevertheless, it remains true that the assembly language programmer who
> knows what he is about has complete control over the binary code
> generated, although I would venture to say that few, if any, assembly
> language programmers think of what they are doing in those terms most of
> the time.

Would this control include control over pipelines, parallelism,
and possibly translation of assembly instructions to microcode?