🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #2202

Re: Changes to C...

#2202
From: Greg Lindahl
Date: Wed, 21 Nov 1990 02:09
51 lines
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!gl8f
References: <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