Re: optimizing compiler against iaverage assembly programmer.

als@tusc.com.au (Anthony Shipman)
4 Jul 1997 14:39:24 -0400

          From comp.compilers

Related articles
[9 earlier articles]
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)
Re: optimizing compiler against iaverage assembly programmer. als@tusc.com.au (1997-07-04)
Re: optimizing compiler against iaverage assembly programmer. dietz@interaccess.com (1997-07-04)
Re: optimizing compiler against iaverage assembly programmer. cef@geodesic.com (Charles Fiterman) (1997-07-04)
Re: optimizing compiler against iaverage assembly programmer. johncl@online.no (1997-07-04)
| List of all articles for this month |

From: als@tusc.com.au (Anthony Shipman)
Newsgroups: comp.compilers,comp.lang.asm.x86
Date: 4 Jul 1997 14:39:24 -0400
Organization: TUSC Computer Systems Pty Ltd., Melbourne, Australia
References: 97-06-071 97-06-081 97-06-101 97-06-134
Keywords: assembler, optimize

WStreett@shell.monmouth.com (Wilbur Streett) writes:
..................
>Good programmers in C understand what the CPU is up to underneath the
>covers, and probably can write Assembler if the need arises. So as
>has often been said, C is a portable assembler, and the real issue is
>if the programmer understands the base architecture of the system that
>the code is running on and the software architecture of the software
>created for the task at hand.


I think this is rapidly acquiring myth status. The C model of the
hardware is vintage 70s. For example the C idiom


int out;
err = f(in, &out);


presupposes a memory-to-memory architecture since pointers only point
to memory locations. There is also in C a presumption of simple
sequential execution. Modern architectures are register oriented and
have multiple units executing in parallel e.g. the Pentium Pro.


C compilers have to go to heroic lengths to match C code to what the
modern machine prefers e.g. in the above idiom a C compiler has to
decide whether it is safe to keep 'out' in a register and at what
points it must be flushed to memory in order to preserve the C model.


>BUT
>I doubt that you can optimize LISP as much as you can C or Assembler..


Functional languages make fewer assumptions about the hardware and (if
pure) are more easily parallelised so they can actually be optimised
better on modern architectures than C.


--
Anthony Shipman
TUSC Computer Systems Pty Ltd
E-mail: als@tusc.com.au
--


Post a followup to this message

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