Re: Why do we still assemble?

johnm@cory.EECS.Berkeley.EDU (John D. Mitchell)
Mon, 11 Apr 1994 21:56:35 GMT

          From comp.compilers

Related articles
[13 earlier articles]
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)
Re: Why do we still assemble? johnm@cory.EECS.Berkeley.EDU (1994-04-11)
Re: Why do we still assemble? conway@munta.cs.mu.OZ.AU (1994-04-11)
Re: Why do we still assemble? rcskb@minyos.xx.rmit.EDU.AU (1994-04-12)
Re: Why do we still assemble? bill@amber.ssd.csd.harris.com (1994-04-12)
Re: Why do we still assemble? bill@amber.ssd.csd.harris.com (1994-04-12)
Re: Why do we still assemble? pardo@cs.washington.edu (1994-04-13)
Re: Why do we still assemble? hbaker@netcom.com (1994-04-13)
[14 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: johnm@cory.EECS.Berkeley.EDU (John D. Mitchell)
Keywords: assembler, C++, performance
Organization: University of California, Berkeley
References: 94-04-032 94-04-055
Date: Mon, 11 Apr 1994 21:56:35 GMT

Henry G. Baker <hbaker@netcom.com> wrote:
>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?)


Well, we did in the undergrad class that I took at UCB but that probably
is as much dependent on the professor as anything else.


An assembler for the 8086 written in GNU's Bison had it's assembly time
cut by 20-40+ percent when handling/stripping comments was special cased
in the lexer rather than being passed on in the usual ways to the parser.




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


Yeah, that's outrageous. I know that in the cases that I know about from
the insiders viewpoint, the reason for the big jumps has always been
either marketing pressure (time to market, other more important use of
engineering time on other things, etc.) or poor management. An inhouse
debugger that was fairly stable and had been used for years had certain
sections of it speeded up by 10-100 *times* after the product had been
release to outside people who complained bitterly about it's sluggish
performance (and those gains were produced in about 3 weeks worth of
effort and some profiling tools :-).


John


P.S. I find it encouraging though that a C parser written using
PCCTS was *faster* than a well done, hand written parser. So
don't count the theory people out yet just make sure they
care out resource efficiency too. :-)
--


Post a followup to this message

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