Re: optimizing compiler against iaverage assembly programmer.

bromage@cs.mu.oz.au (Andrew Bromage)
30 Jun 1997 00:07:38 -0400

          From comp.compilers
Related articles
[2 earlier articles]
Re: optimizing compiler against iaverage assembly programmer. cliffc@risc.sps.mot.com (Cliff Click) (1997-06-19)
Re: optimizing compiler against iaverage assembly programmer. gmiller@iswt.com (Greg Miller) (1997-06-20)
Re: optimizing compiler against iaverage assembly programmer. lehotsky@tiac.net (1997-06-20)
Re: optimizing compiler against iaverage assembly programmer. rnordier@iafrica.com (Robert Nordier) (1997-06-24)
Re: optimizing compiler against iaverage assembly programmer. jim-neil@digital.net (1997-06-24)
Re: optimizing compiler against iaverage assembly programmer. jbuck@synopsys.com (1997-06-24)
Re: optimizing compiler against iaverage assembly programmer. bromage@cs.mu.oz.au (1997-06-30)
Re: optimizing compiler against iaverage assembly programmer. charles.marslett@tempe.vlsi.com (1997-06-30)
Re: optimizing compiler against iaverage assembly programmer. graham.hughes@resnet.ucsb.edu (Graham C. Hughes) (1997-06-30)
Re: optimizing compiler against iaverage assembly programmer. WStreett@shell.monmouth.com (1997-06-30)
Re: optimizing compiler against iaverage assembly programmer. creedy@mitretek.org (1997-06-30)
Re: optimizing compiler against iaverage assembly programmer. als@tusc.com.au (1997-07-04)
Re: optimizing compiler against iaverage assembly programmer. conway@mundook.cs.mu.OZ.AU (1997-07-04)
[4 later articles]
| List of all articles for this month |
From: bromage@cs.mu.oz.au (Andrew Bromage)
Newsgroups: comp.compilers,comp.lang.asm.x86
Date: 30 Jun 1997 00:07:38 -0400
Organization: Comp Sci, University of Melbourne
References: 97-06-071 97-06-078
Keywords: optimize, assembler

G'day all.


Greg Miller <gmiller@iswt.com> writes:


>Well, I've never seen a compiler that was better than a typical
>assembly coder, but the truth is that the costs of coding in assembly
>don't pay for the benefits.


Most programs that I write are not CPU-bound anyway. Either they are
structure-crunching programs for which main memory is the bottleneck,
disk-crunching programs for which I/O is the bottleneck, or interactive
programs where most time is spent waiting for the human even with
optimisation turned off.


I'm still waiting for the time when J. Random User actually wants to
run specint as part of their normal day's computing...


Cheers,
Andrew Bromage
--

Post a followup to this message

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