In article <3n40ge$ngl@wcap.centerline.com>,
David Chase <chase@centerline.com> wrote:
>As far as ugly and confusing code goes, who's going to notice the
>difference?  I program in this godforsaken language because they pay
>me to, not because it's "pretty".

Lemme guess, comp.std.c++? ;-)

A language which does not produce elegant and pleasing code will be less
efficient than a language which produces elegant and artful code.

Read Ritchie's original criticism of noalias; it's quite good.

-s
--
Peter Seebach - seebs@solutions.solon.com  -- seebs@intran.xerox.com
C/Unix proto-wizard -- C/Unix questions? Send mail for help.
Moderator - alt.religion.kibology, comp.lang.c.moderated
Copyright 1995 Peter Seebach.  Not for distribution through Microsoft Network.

seebs@solutions.solon.com (Peter Seebach) writes:

|> David Chase <chase@centerline.com> wrote:
|> >As far as ugly and confusing code goes, who's going to notice the
|> >difference?  I program in this godforsaken language because they pay
|> >me to, not because it's "pretty".

|> Lemme guess, comp.std.c++? ;-)

Indeed.  I'll still write programs in Ansi-C for fun.

|> A language which does not produce elegant and pleasing code will be less
|> efficient than a language which produces elegant and artful code.

Therefore, since the most efficient language is Fortran, I conclude that the
programs written in it are elegant and pleasing/artful?  I think I've derived
a contradiction here.  Some of the most elegant, pleasing, and artful code
that I've ever seen has been written in languages like Scheme and ML, and
nobody accuses those languages of being efficient.

[might want to skip the next three paragraphs, but I really disagree with
 that sentence up above.]

Furthermore, I've written some hyper-efficient C, and the words "pleasing",
"elegant", and "artful" do not apply.  (30 Mflops bigger-than-cache matrix
multiply on a 50Mhz SuperSparc -- the code was cache-blocked,
register-blocked, and software pipelined.  Mark Bromley still beat me with a
piece of Fortran, at 34 Mflops.)

I've written the world's fastest version of a particular benchmark's inner
loop on a particular processor, and THAT was the biggest, most butt-ugly,
unmaintainable piece of shit I've ever seen.  In this case, I unrolled the
loop, jammed it, replaced control flow with data flow, vectorized the loads
and comparisons, then pipelined it.  The original code produced about 20
instructions -- the transformed code filled 9 pages.  It was at least twice as
fast.

Hopefully, compilers will perform this sort of extreme uglification for us in
the future, but for the outer limits of trashy efficient code, it still needs
that human touch.  Restricted pointers would give the compilers a little
more to work with.

|> Read Ritchie's original criticism of noalias; it's quite good.

I'm pretty sure I read it.  Restricted pointers are not noalias.  There's
been another proposal in the last 2 or 3 years.  I don't recall the details,
except that people whose opinions I respect (people in Sun's Floating Point
group) said that it was better.

And, of course, who's going to notice another wart on a toad?

David Chase, speaking for myself.

In article <6656@bigfoot.first.gmd.de>,
Vladimir Chukharev <chu@prosun.first.gmd.de> wrote:
>more clear force usage of const_cast<noalias T*> to invoke
>void copy(noalias char*, const char*, int);   //overloading on noalias
>copy(const_cast<noalias char*>(dst), src, n); // fast version, danger!
>(I'd prefer noalias, but const_cast<T *restrict> will do also.)
>Allow noalias only for parameters - inline functions can do the job

Lots of references to noalias.

>For more safety compiler can oblige programer to provide normal
>function to overload every one with noalias parameters.

ARGH.

Did no one *understand*?  Noalias is wrong.  It's bad.  Nothing *like*
it will ever work.  Make it go away.  (Ahh, well, let's keep it.  We all
have 300+ MIP workstations to run our AI compilers anyway, and who cares
if the code is bloated, ugly, and confusing?)

-s
--
Peter Seebach - seebs@solutions.solon.com  -- seebs@intran.xerox.com
C/Unix proto-wizard -- C/Unix questions? Send mail for help.
Moderator - alt.religion.kibology, comp.lang.c.moderated
Copyright 1995 Peter Seebach.  Not for distribution through Microsoft Network.

seebs@solutions.solon.com (Peter Seebach) writes:

|> Did no one *understand*?  Noalias is wrong.  It's bad.  Nothing *like*
|> it will ever work.  Make it go away.  (Ahh, well, let's keep it.  We all
|> have 300+ MIP workstations to run our AI compilers anyway, and who cares
|> if the code is bloated, ugly, and confusing?)

Actually, noalias would make the compiler smaller, for a given (high)
level of optimization.  In many cases, you're paying the (compiler code
size) overhead anyway, if you've got a common back end for C and for
Fortran.  That is, go look at a competent Fortran compiler's optimizer
and backend -- that's all that noalias will cost you.

As far as ugly and confusing code goes, who's going to notice the
difference?  I program in this godforsaken language because they pay
me to, not because it's "pretty".

David Chase, speaking for myself

In article <3maoka$5ha@hustle.rahul.net>, rfg@rahul.net (Ronald F. Guilmette) writes:
|> In article <3m18b6$e8h@hawk.hcsc.com>,
|> Bill Leonard <Bill.Leonard@mail.csd.harris.com> wrote:
|> >In article <3lgi96$62p@nz12.rz.uni-karlsruhe.de>, ig25@fg70.rz.uni-karlsruhe.de (Thomas Koenig) writes:
|> >> Bill Leonard (bill@amber.ssd.csd.harris.com) wrote in comp.std.c,
|> >>  article <3lcmlr$2b9@hawk.hcsc.com>:
|> >> >The problem with this proposal, as with noalias, is that it is an
|> >> >uncheckable assertion by the programmer whose truth *may* affect the
|> >> >correctness of the code generated by the compiler, or it may not.
|> >>
|> >> If a compiler writer is willing to put enough work into it, restricted
|> >> pointers are checkable at runtime; checker-gcc (only out for Linux)
|> >> could do this quite nicely, given a bit of extensions.  Also compare
|> >> the -Dv flag for Fujitsu's frt - compiler.
|> >
|> >But you wouldn't run your program in production mode with those checks
|> >turned on...
|>
|> Quite so.
|>
|> I don't think that a convincing case can be made in favor of the restricted
|> pointers proposal which has been considered by the ANSI/ISO C committee on
|> the basis of any alleged possibility of checking (at run-time) that the
|> aliasing which `restrict' says won't happen actually _has_ happened.
|>
|> But I am still a fan of `restrict'.  It does certainly add to the language
|> yet another mechanism by which the unwary programmer may shoot himself (or
|> herself) in the foot, but I think that both C and C++ already provide
|> plenty of ways to do that, so I frankly don't see much harm in adding yet
|> another.
|>
|> I do however see a positive gain in providing a new way for the _careful_
|> programmer to give additional information to an optimizer which it can
|> then use to generate better code.

Quite agree. And to make possibility of shooting oneself in the foot
more clear force usage of const_cast<noalias T*> to invoke
dangerous function, e.g. this way:

void copy(char *, const char *, int);
void copy(noalias char*, const char*, int);   //overloading on noalias

copy(dst, src, n);                            // normal version
copy(const_cast<noalias char*>(dst), src, n); // fast version, danger!

(I'd prefer noalias, but const_cast<T *restrict> will do also.)
Now one can't say he does not notice difference.
Allow noalias only for parameters - inline functions can do the job
wherever needed.

For more safety compiler can oblige programer to provide normal
function to overload every one with noalias parameters.
---
Vladimir Chukharev
chu@first.gmd.de

In article <3m18b6$e8h@hawk.hcsc.com>,
Bill Leonard <Bill.Leonard@mail.csd.harris.com> wrote:
>In article <3lgi96$62p@nz12.rz.uni-karlsruhe.de>, ig25@fg70.rz.uni-karlsruhe.de (Thomas Koenig) writes:
>> Bill Leonard (bill@amber.ssd.csd.harris.com) wrote in comp.std.c,
>>  article <3lcmlr$2b9@hawk.hcsc.com>:
>> >The problem with this proposal, as with noalias, is that it is an
>> >uncheckable assertion by the programmer whose truth *may* affect the
>> >correctness of the code generated by the compiler, or it may not.
>>
>> If a compiler writer is willing to put enough work into it, restricted
>> pointers are checkable at runtime; checker-gcc (only out for Linux)
>> could do this quite nicely, given a bit of extensions.  Also compare
>> the -Dv flag for Fujitsu's frt - compiler.
>
>But you wouldn't run your program in production mode with those checks
>turned on...

Quite so.

I don't think that a convincing case can be made in favor of the restricted
pointers proposal which has been considered by the ANSI/ISO C committee on
the basis of any alleged possibility of checking (at run-time) that the
aliasing which `restrict' says won't happen actually _has_ happened.

But I am still a fan of `restrict'.  It does certainly add to the language
yet another mechanism by which the unwary programmer may shoot himself (or
herself) in the foot, but I think that both C and C++ already provide
plenty of ways to do that, so I frankly don't see much harm in adding yet
another.

I do however see a positive gain in providing a new way for the _careful_
programmer to give additional information to an optimizer which it can
then use to generate better code.
--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- E-mail: rfg@segfault.us.com ----------- Purveyors of Compiler Test ----
-------------------------------------------- Suites and Bullet-Proof Shoes -

In article <3lgi96$62p@nz12.rz.uni-karlsruhe.de>, ig25@fg70.rz.uni-karlsruhe.de (Thomas Koenig) writes:
> Bill Leonard (bill@amber.ssd.csd.harris.com) wrote in comp.std.c,
>  article <3lcmlr$2b9@hawk.hcsc.com>:
> >The problem with this proposal, as with noalias, is that it is an
> >uncheckable assertion by the programmer whose truth *may* affect the
> >correctness of the code generated by the compiler, or it may not.
>
> If a compiler writer is willing to put enough work into it, restricted
> pointers are checkable at runtime; checker-gcc (only out for Linux)
> could do this quite nicely, given a bit of extensions.  Also compare
> the -Dv flag for Fujitsu's frt - compiler.

But you wouldn't run your program in production mode with those checks
turned on.  So the fact remains that the only bugs you find are the ones
exposed by your test cases.  It is extremely likely that you'll never try
the test cases that will expose the more obscure aliasing bugs.

Even if you *did* run with these checks turned on, how does that help the
user of your program?  Runtime checks are no substitute for removing
bugs -- they may help you find the bugs, and they may prevent those bugs
from doing more damage than necessary, but the bugs remain.

Conclusion: Runtime checks don't make the assertion provably correct, however
much it might improve our confidence in it.

> OTOH, passing a multidimensional array the Fortran way might be
> a better way, for example:
>
> void foo(double a[n][m], const int n, const int m);
>
> Only let people put 'restricted' attributes on arrays, and you're probably
> set.

No matter what you do, the fact remains that it is an assertion by the
programmer that cannot be *proven* true or false by the compiler.  Sooner
or later, the programmer will be wrong and the program will break.  The bug
will be extremely difficult to find unless you have such runtime checks as
mentioned above.

--
Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
Bill.Leonard@mail.hcsc.com

These opinions and statements are my own and do not necessarily reflect the
opinions or positions of Harris Computer Systems Corporation.

------------------------------------------------------------------------------
More people run Windows on their home computers than on any other home
appliance.
------------------------------------------------------------------------------

Bill Leonard (bill@amber.ssd.csd.harris.com) wrote in comp.std.c,
 article <3lcmlr$2b9@hawk.hcsc.com>:

>IMHO, the restricted pointer proposal should die a quiet death.  It is a
>positive invitation for programmers to put bugs in their code that will
>only be detected much later.

>The problem with this proposal, as with noalias, is that it is an
>uncheckable assertion by the programmer whose truth *may* affect the
>correctness of the code generated by the compiler, or it may not.

If a compiler writer is willing to put enough work into it, restricted
pointers are checkable at runtime; checker-gcc (only out for Linux)
could do this quite nicely, given a bit of extensions.  Also compare
the -Dv flag for Fujitsu's frt - compiler.

Yes, this will slow down the code to a crawl; and also, yes, this will
find a number of bugs you're unwilling to believe until you've tried it.

OTOH, passing a multidimensional array the Fortran way might be
a better way, for example:

void foo(double a[n][m], const int n, const int m);

Only let people put 'restricted' attributes on arrays, and you're probably
set.
--
Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet.
The joy of engineering is to find a straight line on a double
logarithmic diagram.

In article <3ku98j$sr1@news.cs.tu-berlin.de>, jutta@cs.tu-berlin.de (Jutta Degener) writes:
> A version of the restricted pointer proposal can be found on the
> World-Wide Web in http://www.lysator.liu.se/c/restrict.html .
> Ascii, PostScript, and LaTeX copies of its base document are available
> via ftp from ftp.dmk.com, Directory /DMK/x3j11/aliasing/ .
>
> Dennis Ritchie's coments on type qualifiers in response to an earlier
> draft of the ANSI C standard (which are the closest thing to an answer
> to "What was noalias?" that I could find) have been marked-up in
> http://www.lysator.liu.se/c/dmr-on-noalias.html .  (Lest readers jump to
> conclusions, I hear that Dennis Ritchie _supports_ restricted pointers
> in C, in stark contrast to his position on noalias, which summarizes as
> "over my dead body.")

IMHO, the restricted pointer proposal should die a quiet death.  It is a
positive invitation for programmers to put bugs in their code that will
only be detected much later.

The problem with this proposal, as with noalias, is that it is an
uncheckable assertion by the programmer whose truth *may* affect the
correctness of the code generated by the compiler, or it may not.

For instance, suppose you declare a pointer argument to a function as
restricted.  The compiler may or may not be able to take any advantage of
that information, but let's suppose that it can and does.  Sometime much
later you or someone else adds a new call to that function and passes a
pointer that does not always meet the restriction.  The compiler probably
will be unable to tell that the restriction is violated (after all, if it
could *always* tell, we wouldn't need the programmer's help in telling us
about it), so things compile just fine.  They may even work fine for a long
time -- it depends on whether that new call gets executed or not and, if it
does, whether the pointer passed does indeed violate the restriction AND
whether that violation happens to matter to the generated code.  (This
latter depends on exactly how the compiler took advantage of the
restriction declaration.)

Sooner or later though, the program fails.  The bug is extremely difficult
to find and, most probably, will be blamed on the compiler.  Not 1 programmer
in 1000 will even think to check whether a 'restrict' declaration has been
violated.  Many will simply compile the program without optimization, which
will probably work, and say "Must be the optimizer that's broken."

I know this happens because I used to work on our compiler optimizer, and
once in awhile we'd get bug reports that ultimately were found to be caused
by bugs in the program.  (The most common is using an uninitialized
variable which, under the optimizer, got allocated to a register instead of
pre-initialized memory.)  Adding the restricted pointer feature will simply
multiply enormously the number (and difficulty) of such complaints.

Another thing that happens is that somebody's program works for years until
we make the optimizer just a little smarter or more aggressive, and
suddenly it matters that his 'restrict' declarations were wrong.

I know it is tempting to want to do something about C/C++ pointer
aliasing.  It does inhibit optimizations that could make significant gains
in performance for some programs.  But IMHO, this is not the way to do it.

Think about what is required for the compiler to be able to detect the
absence of aliasing.  In many cases, it requires complete knowledge of the
program plus information about the actual flow of data.  The programmer
must have exactly the same information to be *certain* that a given
'restrict' declaration is correct.  Now how often do programmers have that
kind of *certain* knowledge?

I think the only sure way to address the pointer aliasing problem *and*
prevent subtle bugs is to introduce some mechanism that the compiler can
check, so that we are not relying on the programmer's knowledge alone.  The
'const' qualifier, for instance, can be checked because there are
restrictions on assignment among const and non-const pointers.  The
restrictions on assignment between restrict and non-restrict pointers are
much looser and allow assignments whose ultimate validity can only be
checked at runtime.  Moreover, assignment *between* restricted pointers
(unlike assignment between const pointers) may or may not cause undefined
behavior.

--
Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
Bill.Leonard@mail.hcsc.com

These opinions and statements are my own and do not necessarily reflect the
opinions or positions of Harris Computer Systems Corporation.

------------------------------------------------------------------------------
More people run Windows on their home computers than on any other home
appliance.
------------------------------------------------------------------------------

In article <3kebd2$f0l@hustle.rahul.net> "Ronald F. Guilmette" <rfg@rahul.net> writes:

> I still hold out some vague hope that the C++ standardization committee
> will adopt the `restricted pointers' proposal which has been approved by
> the international C standardization committee (WG14) for inclusion into
> a forthcoming Technical Report (and probably into the next revision of
> the C standard).

Please tell me what the `restricted pointer' is.
Thanks in advance.

hoshi

[Followups directed to comp.std.c.]

>[Ron F. Guilmette still has hopes that C++]
>> will adopt the `restricted pointers' proposal which has been approved by
>> the international C standardization committee (WG14) for inclusion into
>> a forthcoming Technical Report (and probably into the next revision of
>> the C standard).

Ron, you're jumping to conclusions.

hoshi@sra.co.jp (Hoshi Takanori) writes:
> Please tell me what the `restricted pointer' is.

Step-son of noalias.  A type qualifier (like "const" or "volatile"),
applicable to pointer types only, that promises that this pointer
is the only pointer in scope pointing to its target object.  The
details where much more complex than that last time I understood them.

A version of the restricted pointer proposal can be found on the
World-Wide Web in http://www.lysator.liu.se/c/restrict.html .
Ascii, PostScript, and LaTeX copies of its base document are available
via ftp from ftp.dmk.com, Directory /DMK/x3j11/aliasing/ .

Dennis Ritchie's coments on type qualifiers in response to an earlier
draft of the ANSI C standard (which are the closest thing to an answer
to "What was noalias?" that I could find) have been marked-up in
http://www.lysator.liu.se/c/dmr-on-noalias.html .  (Lest readers jump to
conclusions, I hear that Dennis Ritchie _supports_ restricted pointers
in C, in stark contrast to his position on noalias, which summarizes as
"over my dead body.")

Jutta Degener (jutta@cs.tu-berlin.de)