Re: Folk Theorem: Assemblers are superior to Compilers

qualtrak@netcom.com (Qual Trak)
Sat, 30 Oct 1993 07:32:35 GMT

          From comp.compilers

Related articles
[16 earlier articles]
Re: Folk Theorem: Assemblers are superior to Compilers adk@sun13.SCRI.FSU.EDU (1993-10-29)
Re: Folk Theorem: Assemblers are superior to Compilers elliottm@csulb.edu (1993-10-29)
Re: Folk Theorem: Assemblers are superior to Compilers jvn@fermi.clas.virginia.edu (Julian V. Noble) (1993-10-29)
Re: Folk Theorem: Assemblers are superior to Compilers Freek.Wiedijk@phil.ruu.nl (1993-10-29)
Re: Folk Theorem: Assemblers are superior to Compilers synaptx!thymus!daveg@uunet.UU.NET (Dave Gillespie) (1993-10-29)
Re: Folk Theorem: Assemblers are superior to Compilers rfg@netcom.com (1993-10-30)
Re: Folk Theorem: Assemblers are superior to Compilers qualtrak@netcom.com (1993-10-30)
Re: Folk Theorem: Assemblers are superior to Compilers johnson@cs.uiuc.edu (1993-10-31)
Re: Folk Theorem: Assemblers are superior to Compilers henry@zoo.toronto.edu (1993-10-31)
Re: Folk Theorem: Assemblers are superior to Compilers drraymon@watdragon.uwaterloo.ca (1993-11-01)
Re: Folk Theorem: Assemblers are superior to Compilers dmr@alice.att.com (1993-11-02)
Re: Folk Theorem: Assemblers are superior to Compilers steven.parker@acadiau.ca (1993-11-02)
Re: Folk Theorem: Assemblers are superior to Compilers pardo@cs.washington.edu (1993-11-03)
[5 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: qualtrak@netcom.com (Qual Trak)
Keywords: assembler
Organization: QualTrak Corporation
References: 93-10-104 93-10-130
Date: Sat, 30 Oct 1993 07:32:35 GMT

elliottm@csulb.edu (Mike Elliott) writes:
> Folk Theorem 1:
>[assembler code is faster than compiled code]


prener@watson.ibm.com (Dan Prener) writes:
>I think there are two relevant points.
>
>First, a highly-skilled assembly language programmer can, indeed, produce
>better code than a compiler. However, there are many fewer highly-skilled
>assembly language programmers than most people realize.
>
>Second, even if there were many highly-skilled assembly language
>programmers, who always produced better code than any compiler, and even
>if portability were of no significance, the lower productivity of assembly
>language programmers would lead to the widespread use of higher level
>languages.


A couple of ideas -


Supposing I have a project that takes a year to write in c and my friend
the super assemply language programmer can write to the same spec in say
18 months. His code is twice as fast as mine. BUT six months after he
finishes his version of the product vendor xyz comes out with a new
machine twice as fast as the one we originally coded on. My code ports in
a day or so - he begins another 18 month project (make it a year this
time) and again two years later company def comes out with a processor
twice as fast ...


I seem to remember that once upon a time that Microsoft originally wrote
their macro assembler in assembly language. They introduced a new version
of it that had been rewritten in c and it was touted as being about twice
as fast. I know that it was noticeably faster than the previous
incarnation. I certainly won't claim that the c compiler generated
"tighter" code than the assembly language programmer but it seems that
larger projects seem to benefit from higher level languages.


The above would seem to point out something about assembly language and
large projects - or that Microsoft had some terrible assembly language
programmers - or none of the above - that it was time to clean out the
warts with a rewrite and if they'd done it in assembler it would have been
even faster - but my gut feeling is that managing a medium sized software
project would be considerably more difficult in assembly language than in
a high level language (is c a high level language?). Not to say more
expensive.
--
John Birchfield - QualTrak Corp (408) 748-9500 x 141
3160 De La Cruz Blvd., Suite 206, Santa Clara, CA 95054
jb@QualTrak.COM
--


Post a followup to this message

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