Re: High Level Language vs Assembly

"jacob navia" <jacob@jacob.remcomp.fr>
25 Feb 2001 11:00:07 -0500

          From comp.compilers

Related articles
[4 earlier articles]
Re: High Level Language vs Assembly iank@idiom.com (2001-02-23)
Re: High Level Language vs Assembly thp@hill.cs.ucr.edu (Tom Payne) (2001-02-25)
Re: High Level Language vs Assembly walter@bytecraft.com (Walter Banks) (2001-02-25)
Re: High Level Language vs Assembly walter@bytecraft.com (Walter Banks) (2001-02-25)
Re: High Level Language vs Assembly rhyde@transdimension.com (Randall Hyde) (2001-02-25)
Re: High Level Language vs Assembly max@max.mcs.gac.edu (Max Hailperin) (2001-02-25)
Re: High Level Language vs Assembly jacob@jacob.remcomp.fr (jacob navia) (2001-02-25)
Re: High Level Language vs Assembly tej@melbpc.org.au (Tim Josling) (2001-02-25)
Re: High Level Language vs Assembly henry@spsystems.net (2001-02-25)
Re: High Level Language vs Assembly fjh@cs.mu.OZ.AU (2001-02-25)
Re: High Level Language vs Assembly ts3@ukc.ac.uk (T.Shackell) (2001-03-01)
Re: High Level Language vs Assembly samiam@cisco.com (Scott Moore) (2001-03-01)
Re: High Level Language vs Assembly samiam@cisco.com (Scott Moore) (2001-03-04)
[14 later articles]
| List of all articles for this month |

From: "jacob navia" <jacob@jacob.remcomp.fr>
Newsgroups: comp.compilers
Date: 25 Feb 2001 11:00:07 -0500
Organization: Wanadoo, l'internet avec France Telecom
References: 01-02-094 01-02-101
Keywords: assembler, performance
Posted-Date: 25 Feb 2001 11:00:07 EST

A compiler must be correct for all cases. This means that will never
be as clever as the programmer doing a concrete program.


Take for instance a routine that uses often a global variable. A human
assembly programmer, knowing the use of the variable in the program,
can cache that in a register. The compiler can't since it could be in
principle modified by another thread. It must generate code to read it
each time from RAM.


Of course the linker could be changed to determine that that variable
is never used, after all, and optimize it at link time, but this is
rarely done.


Another stuff is, to add another example, rounding. An assembly
programmer will round to nearest, the compiler must follow the C
specs, truncate it in C (i.e. set the FP unit in the right rounding
mode), then make the operation, and of course restore the old setting
of the FPU. This is surely less efficient. (For x86 architectures
obviously)


Big projects can't be done in assembly. But small parts can be recoded
in assembly. The gain can be considerable, or not, as stated in
another contributions, it can be even faster to change the algorithm
in a HLL.


I like assembly. For instance, I discovered that generating in-line a
loop to replace strlen is actually smaller in code size, than the call
itself! It contains more instructions but they are shorter. Adding up
the size of the pushes, and the stack adjustement after the big call
instruction you come out with smaller programs by inlining!


This reduced program size quite considerably in the case of
strlen. But it would be difficult to do this in assembly without a
macro facility. And then, when you start considering macros in asm,
they are more and more near a C like syntax anyway.


Post a followup to this message

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