Re: Processor specific optimisations

"MickaŽl Pointier" <mpointie@eden-studios.fr>
28 Jan 2002 01:06:17 -0500

          From comp.compilers

Related articles
[3 earlier articles]
Re: Processor specific optimisations rickh@capaccess.org (2002-01-18)
Re: Processor specific optimisations usenet@gehre.org (2002-01-18)
Re: Processor specific optimisations walter@bytecraft.com (Walter Banks) (2002-01-24)
Re: Processor specific optimisations jgd@cix.co.uk (2002-01-24)
Re: Processor specific optimisations thp@cs.ucr.edu (2002-01-24)
Re: Processor specific optimisations RLWatkins@CompuServe.Com (R. L. Watkins) (2002-01-24)
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)
[1 later articles]
| List of all articles for this month |

From: "MickaŽl Pointier" <mpointie@eden-studios.fr>
Newsgroups: comp.compilers
Date: 28 Jan 2002 01:06:17 -0500
Organization: ImagiNET / Colt Internet
References: 02-01-077 02-01-126
Keywords: optimize
Posted-Date: 28 Jan 2002 01:06:14 EST

> The short answer is "No".


> Too many of the hand-optimizations done by assembly language
> programmers (e.g. wraparound/overflow tricks) depend on information
> about the intent of the design of which the compiler itself is
> ignorant.


> An optimizing compiler will never accomplish such things until it
> can carry on a dialog with the programmer about these matters
> without inundating the programmer by rote with every possible
> question, at which point it will become not a compiler but an
> automated assembly language programmer.


At this point, it's a problem with the language itself.


C can be considered as a kind of high level assembly language, where
you have a virtually unlimited number of "registers" (variables), no
need to perform instruction scheduling by hand, and so on.


The problem is that you have to express what you want to do at such a
low level, that the source code does not represent at all what you
want to do initialy.


After all, when I want to erase a bloc of memory, or copy a bloc of
data from somewhere to somewhere else, it's really what I want to
do. My intent was not originaly to declare some pointers, some index
variables, and perfom a loop that put some particular value to the
adress pointed by the pointer :)


        Mickael Pointier


Post a followup to this message

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