Re: Processor specific optimisations

"Clark L. Coleman" <clc5q@cs.virginia.edu>
6 Feb 2002 23:22:56 -0500

          From comp.compilers

Related articles
[9 earlier articles]
Re: Processor specific optimisations mpointie@eden-studios.fr (Mickaël Pointier) (2002-01-28)
Re: Processor specific optimisations rickh@capaccess.org (2002-01-28)
Re: Processor specific optimisations mpointie@eden-studios.fr (Mickaël Pointier) (2002-01-30)
Re: Processor specific optimisations Ulrich.Teichert@gmx.de (2002-01-30)
Re: Processor specific optimisations perle@cs.tu-berlin.de (2002-01-30)
Re: Processor specific optimisations mpointie@eden-studios.fr (Mickaël Pointier) (2002-02-06)
Re: Processor specific optimisations clc5q@cs.virginia.edu (Clark L. Coleman) (2002-02-06)
Re: Processor specific optimisations rickh@capaccess.org (2002-02-06)
| List of all articles for this month |
From: "Clark L. Coleman" <clc5q@cs.virginia.edu>
Newsgroups: comp.compilers
Date: 6 Feb 2002 23:22:56 -0500
Organization: University of Virginia
References: 02-01-126 02-01-151
Keywords: optimize, architecture, comment
Posted-Date: 06 Feb 2002 23:22:56 EST

>[There are lots of CISC instruction sets with instructions that compilers
>never use because it's faster to use several simpler ones. The x86
>ENTER instruction is a good example. -John]


Yes, but instructions such as ENTER and LEAVE save space. If compilers
had a command line switch to optimize for code size before code speed,
then they would emit these instructions. This could be useful for
embedded code. It also might have an effect on the instruction caches
to optimize for space, reducing the bad effect on code speed. Almost
all of the classic examples from the VAX, X86, etc., of CISCy
instructions that no one should ever use actually could be used to
save space. They might save power, too, especially if there are cache
effects.


I wonder if the cost in terms of code speed is getting worse over the
years for these instructions, due to their being "deprecated" to some
degree, i.e. Intel and AMD are not putting hardware/microcode
resources into fast execution of instructions that "everyone knows are
never emitted by a good compiler". Perhaps someone from a CPU vendor
could share something with us about that.


Clark Coleman
University of Virginia
[To the second question, yes, it's pretty clear that chip vendors are
designing chips so the code that compilers emit runs fast. They do
lots and lots of profiling and simulation to make that happen. -John]


Post a followup to this message

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