Re: Why do we still assemble?

hbaker@netcom.com (Henry G. Baker)
Fri, 8 Apr 1994 17:17:36 GMT

          From comp.compilers

Related articles
[6 earlier articles]
Re: Why do we still assemble? Nand.Mulchandani@Eng.Sun.COM (1994-04-07)
Re: Why do we still assemble? pardo@cs.washington.edu (1994-04-08)
Re: Why do we still assemble? pardo@cs.washington.edu (1994-04-08)
Re: Why do we still assemble? law@snake.cs.utah.edu (1994-04-08)
Re: Why do we still assemble? steve@cegelecproj.co.uk (1994-04-08)
Re: Why do we still assemble? bill@amber.csd.harris.com (1994-04-08)
Re: Why do we still assemble? hbaker@netcom.com (1994-04-08)
Re: Why do we still assemble? rcskb@minyos.xx.rmit.EDU.AU (1994-04-10)
Re: Why do we still assemble? Keith.Bierman@Eng.Sun.COM (1994-04-10)
Re: Why do we still assemble? lgc@robotics.jpl.nasa.gov (1994-04-11)
Re: Why do we still assemble? hbaker@netcom.com (1994-04-11)
Re: Why do we still assemble? djohnson@arnold.ucsd.edu (1994-04-11)
Re: Why do we still assemble? mfx@cs.tu-berlin.de (1994-04-11)
[21 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: hbaker@netcom.com (Henry G. Baker)
Keywords: assembler, design, comment
Organization: nil
References: 94-04-032 94-04-035
Date: Fri, 8 Apr 1994 17:17:36 GMT

I wrote:
> Con: This argument is, of course, pure hogwash for today's virtual memory
> systems.


djohnson@arnold.ucsd.edu (Darin Johnson) writes:
>So I guess it's safe to assume that some compilers will want to be run in
>as small a space as possible. Until there's a large computer to do cross
>compiling for every small computer anyway...


You have an excellent point. However, the problem is not with virtual
memory itself, but with poor compiler technology.


At the ACM PLDI'89 conference in Portland, there was an excellent tutorial
on how to build fast compilers by someone from the British (?) _Cobol_
compiler company (MicroFocus??), and he spent quite a long time explaining
why many of the standard 'academic' approaches made for very inefficient
compilers. (He also explained why Cobol was quite difficult to compile
efficiently. Apparently there are an incredible number of cases to
consider when compiling a simple A=B statement. Any undergraduate
compiler courses teach the 'by name' option?)


I personally made the rounds at a recent Ada conference, and compiled and
ran the same 5,000 line benchmark Ada program on as many systems in the
booths that would allow me. The differences were absolutely astounding.
The compilers of companies T,V, and A, who shall remain anonymous ;-),
each took between 30 and 40 _mega_ bytes of swap space, and took about 15
_minutes_ to compile on what appeared to be sparcstations. The compiler
of Company M took only about 1+ megabytes of swap space, and compiled in
about 2 minutes on a 66MHz 486 with a several megabyte disk buffer. (The
486 only had 16 Mbytes of real memory, and the disk light was flashing, so
it wasn't running entirely in RAM.)


All of this compile time might be useful if the compiled code actually ran
faster. But it didn't. All of the compiled programs executed in nearly
the same time. (No, it wasn't I/O or FP bound; it is a CPU/memory
intensive integer benchmark.)


While one of the Unix compilers was running, I did a periodic 'ps' to find
out what was taking so much time. Apparently the very first phase which
did lexical analysis, parsing and building a syntax tree took most of the
time.


I was also told by a British company who built a large Ada system with HW
and SW from company D, that his 180,000 line system took an entire _week_
(i.e., around 168 hours) to compile. He was forced to begin using binary
patches....


These compilers come from established companies with some of the best
people in the business. What gives?


Is it any wonder that people run TCL?


--------------


On the original subject of assembling, Dave Mooney tells me that the IBM
RS/6000 compilers generate object code, and if someone gives the '-S'
option to get an assembler file, an _additional_ phase is invoked which
_disassembles_ the '.o' file to get the '.s' file.


What an inspired and elegant solution! Any decent system has to have a
good disassembler, anyway, so it's better to put good manpower into this
task than into writing an assembler.


----------------------


I think that the Burroughs people were pretty proud of the fact that their
operating system had essentially no assembler code in it. I don't know
for sure, but I think their (Algol) compiler generated object code
directly.
[Indeed it did. There was no assembler provided to customers, evidently
they didn't miss it. -John]
--


Post a followup to this message

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