Article View: comp.lang.misc
Article #2202Re: Changes to C...
From: Greg Lindahl
Date: Wed, 21 Nov 1990 02:09
Date: Wed, 21 Nov 1990 02:09
51 lines
2752 bytes
2752 bytes
In article <1990Nov20.220526.24202@ingres.Ingres.COM> thomasm@llama.Ingres.COM (Tom Markson) writes:
>C is great. We all love C. But a time comes when you say "Modifying C
>is not the answer".
Well, if you avoid being overly general, what does C need to deal with
this example of code that messes with arrays?
foo( float *a, float *b, float *c, float *d, int n )
{
int i;
for( i = 0 ; i < n ; i++ ) {
c[i] = a[i] + b[i];
d[i] = a[i] - b[i];
}
Now, normal C has two big problems with this code:
1. Most programmers would do strength-reduction by hand and obscure
what is going on. This makes the compiler's job much more difficult.
2. It's difficult to analyze and prove that the store to c[i] won't
stomp on a[i] or b[i], so they have to be re-loaded for the second
loops statement. This case is rather simple; most of the time the
index values are more complex.
What does C need? Well, if I could declare that a, b, c, and d were
arrays of size n, the compiler would have all the info it needs to do
a *simple* run-time check for aliasing, no matter how nasty the index
expressions are. And it would optionally be able to insert
bounds-checking, should I want it.
Such a change wouldn't break existing code. However, to get the
performance benefit, programmers would have to avoid obscuring arrays.
In the good old days, you had to be obscure to be fast. In the brave
new world, things are different.
Of course, I'd also want true N-dimensional arrays and a stronger
library. This is only a first step. The major question is: would you
end up with a simple language at the end? I hope that the end product
would be easier to optimize, but it would certainly be bigger than
before.
> The real solution
>is to start over and design something you feel solves the problems you
>encounter or corrects percieved deficits with C.
I'm stuck using lots of machines, and it would be expensive for me to
write compilers for all of them. Your real solution is great for
research, but not so great if you're an end-user.
Technical Details
Message-ID:
<1990Nov21.020928.13858@murdoch.acc.Virginia.EDU>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!emory!gatech!mcnc!uvaarpa!murdoch!astsun7.astro.Virginia.EDU!gl8fReferences:
<1990Nov18.033622.1517@murdoch.acc.Virginia.EDU> <QG279:@xds13.ferranti.com> <1990Nov20.220526.24202@ingres.Ingres.COM>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!emory!gatech!mcnc!uvaarpa!murdoch!astsun7.astro.Virginia.EDU!gl8f From: gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl) Newsgroups: comp.lang.misc,alt.lang.cfutures Subject: Re: Changes to C... Message-ID: <1990Nov21.020928.13858@murdoch.acc.Virginia.EDU> Date: 21 Nov 90 02:09:28 GMT References: <1990Nov18.033622.1517@murdoch.acc.Virginia.EDU> <QG279:@xds13.ferranti.com> <1990Nov20.220526.24202@ingres.Ingres.COM> Sender: news@murdoch.acc.Virginia.EDU Organization: Department of Astronomy, University of Virginia Lines: 51