Re: Why C is much slower than Fortran

lindahl@pbm.com (Greg Lindahl)
6 Jun 1999 22:58:21 -0400

          From comp.compilers

Related articles
[9 earlier articles]
Re: Why C is much slower than Fortran hwstock@wizard.com (H.W. Stockman) (1999-06-02)
Re: Why C is much slower than Fortran erik@arbat.com (Erik Corry) (1999-06-02)
Re: Why C is much slower than Fortran lindahl@pbm.com (1999-06-02)
Re: Why C is much slower than Fortran sokal@holyrood.ed.ac.uk (Daniel Barker) (1999-06-02)
Re: Why C is much slower than Fortran djb@koobera.math.uic.edu (1999-06-02)
Re: Why C is much slower than Fortran Peter.Mayne@compaq.com (Peter Mayne) (1999-06-03)
Re: Why C is much slower than Fortran lindahl@pbm.com (1999-06-06)
Re: Why C is much slower than Fortran john@iastate.edu (1999-06-12)
Re: Why C is much slower than Fortran erik@arbat.com (Erik Corry) (1999-06-14)
Re: Why C is much slower than Fortran jeff@jeff-jackson.com (Jeffrey Glen Jackson) (1999-06-19)
| List of all articles for this month |

From: lindahl@pbm.com (Greg Lindahl)
Newsgroups: comp.lang.c++,comp.compilers,comp.arch
Date: 6 Jun 1999 22:58:21 -0400
Organization: a guest of Shadow Island Games
References: 99-06-023
Keywords: architecture

"Peter Mayne" <Peter.Mayne@compaq.com> writes:
> Greg Lindahl <lindahl@pbm.com> wrote
> > how many hardware architectures have hardware bounds checking?
>
> VAX for one.


And the MC68010 and x86. But, to belabor the obvious, didn't the 801
people write a paper about how you can do software bounds checking for
a rather small cost if you do some optimization of the bounds checks?


As a result, what *modern* hardware architecture has hardware bounds
checking? Zip zilch none.


Software alias analysis of subroutine arguments is even cheaper than
bounds checking. C compilers already have to figure out which
statements contain potential alias problems. In some cases, it's
obvious that it's an argument alias problem.


-- g


Post a followup to this message

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