Re: Why do we assemble?

Paul Robinson <PAUL@TDR.COM>
Wed, 13 Apr 1994 03:37:56 GMT

          From comp.compilers

Related articles
Re: Why do we assemble? PAUL@TDR.COM (Paul Robinson) (1994-04-13)
| List of all articles for this month |

Newsgroups: comp.compilers
From: Paul Robinson <PAUL@TDR.COM>
Keywords: Pascal, assembler
Organization: Compiler Service Company, Silver Spring MD USA
Date: Wed, 13 Apr 1994 03:37:56 GMT

Some systems probably support assembly because someone feels that they
need it. Often that someone is whoever has the politcal muscle to order
an assembler as part of the system, or because the programmers cannot find
out how to generate object files for the system, or because they prefer to
have their compiler generate assembly code and let the assembler do the
work of generating object files.

It seems like the best implementations either don't support assembly or
only support it rudimentarily. Adding assemblers seems to make the
compilers less effective.

Versions of Turbo Pascal below 4.0 did not support assembly other than as
insertion of inline code specified as hexadecimal byte or word values,
with some minor capability to reference "*" - the program counter.

I note that starting with version 4.0 is when they started including an
assembler. Version 6.0 has an assembler built into the application which
allows the user to include ASM directives in the source code. Turbo 6.0
is also the first release that would not fit on a 360K diskette. With all
samples and Turbo Vision, version 6 took up something like 5 meg of disk

The only thing that was worse was Turbo Pascal for Windows. Which took up
something like 12 meg of disk space.

The National Bureau of Standards ("NBS") Pascal Compiler generated direct
object files for PDP-11 machines, specifically for RT-11. No assembler
and it ran in less than 64K. This compiler, however, due to the small
size of the machine, had to be broken into two passes. Each pass is about
4,000 lines of Pascal Code, and the run-time library consists of about
50-100 routines to handle most features used in a language. (NBS is now
called "NIST", for people who insist on accuracy.)

The Oregon Software Pascal compiler ("OMSI") has its own version of the
assembler for the PDP-11, and as a result, the OMSI compiler requires two
passes over the code, one for the compiler and one for its assembler. Or
its assembly code could be run through MACRO on the 11. For obvious
reasons, you could have Inline assembly code as part of a comment.

The Stanford University Pascal Compiler ("Stanford") generated a "P-Code"
essentially identical to the one Wirth described in a section of a book on
Pascal or compilers I once saw at the University of California at Irvine
Library. This P-Code was then passed to a post-processor that converted
it into an IBM 370 object file suitable for linking with the linkage

The Australian Atomic Energy Commission ("AAEC") released a Pascal
Compiler for the IBM 360/370 series mainframe. It was a one-pass compiler
that generated object code files directly, same as the Fortran or Cobol
compilers. And, just like those compilers, you had the option of having
the compiler list what code it generated as an assembly language listing.
I note that, just as someone else mentioned for a different program, the
AAEC Pascal compiler didn't have an assembler; it had a *disassembler*.
AAEC wasn't bad at all in terms of compiler speed or size; the compiler is
written in Pascal and is about 6500 lines, with another 5,000 in the run
time library. As far as speed is concerned I'd say it was comparable to
the "big two" compilers for Fortran or Cobol. In fact, I am trying to
convert the AAEC compiler to Turbo Pascal and eventually get it to be
self-compiling. The big problem I have is the way procedures were
compiled on the 370 and how Turbo Pascal creates procedures; the two
systems have significant philosophical differences. If that doesn't work,
I'll start over again with NBS.

I'm still looking for a copy of the Stanford Pascal Compiler Sources, does
anyone have a copy on a tape somewhere?

NBS, Stanford and AAEC were "academic" type compilers; you could get them
for free or nominal copying costs of less than $50. (Maybe NBS Pascal
doesn't deserve that term if you consider "academic" to be perjorative; it
was developed by a private company under contract to what was then called
NBS and is explicitly marked as public domain). OMSI was a commercial

So it goes both ways; there are academic compilers that generate object
code, and there are commercial compilers that generate assembly language,
and there are hybrids of the two. It depends on why you are developing
the compiler, whether you have to support a target audience, and what you
have to cover in developing the compiler.

Paul Robinson - Paul@TDR.COM

Post a followup to this message

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