From mboxrd@z Thu Jan 1 00:00:00 1970 From: craig@jcb-sc.com To: torvalds@transmeta.com Cc: craig@jcb-sc.com Subject: Re: Linux and aliasing? Date: Fri, 04 Jun 1999 08:49:00 -0000 Message-id: <19990604144904.21044.qmail@deer> References: X-SW-Source: 1999-06/msg00144.html >On 4 Jun 1999 craig@jcb-sc.com wrote: >> >> Any programmer worth his salt, wanting "a laser-guided nightsight", >> and not wanting to tweak (or even rewrite) his code for every new >> compiler release, will *not* use a C compiler. Period. > >Oh? > >That's a new argument. Instead of "don't use that feature", it's now >"don't do anything clever at all". No, you misunderstand. C is simply a poor language for the task at hand. It provides too little low-level control of how a C compiler should do its work, yet it's not high-level enough to make it practical for the compiler to do enough of the optimization work for the programmer to satisfy developers of embedded/OS code. Your recently-expressed concerns about `volatile' were a perfect example of that. You correctly (or pretty nearly so) noted the distinction you wanted to make between a volatile *reference* to an object and a reference to an object via a volatile *address* (pointer). That's a distinction C apparently doesn't provide, among many, in a language supposedly "suitable" for "low-level" coding (and, I admit, it's better than PL/I in that regard). Not that I have anything great to suggest in place of C, you understand, and I fully realize that you're not about to rewrite Linux into some other language anyway. But what you're essentially asking for is for us to make gcc compile some language that is less and less like C, one that is more and more like your particular *vision* of what C should be, which happens to be quite at odds with the direct C9X and others are taking, if my impressions of those efforts (based on posts to this list) are correct. (Clearly it'd be easier if those working on the upcoming C standard simply implemented your desires...at least, easier on the gcc developers.) Further, you're asking for us to do language design "on the fly", while implementing a compiler for that language. In my experience, that attempt to marry language design and compiler implementation, while plenty of fun and full of opportunity for cleverness to show itself, almost always leads to poor language design. You've already been bitten by hard-to-find bugs stemming from *extensions* to GNU C that you used, sometimes without regard to the fact that they were not particularly well documented. These experiences have led you to conclude, or at least complain, that gcc was going in a direction you did not like. (Worst of all, you often express this by insulting people like myself, who, especially in my case, aren't the ones *causing* the trouble, but are simply trying to *explain* it to you!) Now you are complaining about a *standard* language feature being implemented in a standard-conforming way by gcc, one which you can work around by changing your code to be standard-conforming (surely a SMOP, say a few lines of Perl ;-) *or* by using a command-line option...but you don't like the pain of the former, or the performance of the latter. Welcome to C hell. I don't know the details of the issues involved, but I trust those that have spoken against your proposal, that they *do* know them. What I have been trying to do is get you to see that, at some point, you have to conclude that you're never going to succeed at making the edge of *this* particular hammer, gcc, sharp enough to make nice clean cuts in silk, for any length of time, without a whole lot of pain, because every time someone uses it as a hammer, those nice cutting edges get worn off. tq vm, (burley) P.S. Due to my own outbursts on this thread, and the resulting email I got, I promise to make this the *last* time I will *ever* respond to queries, complaints, etc. about similar issues coming from the Linux camp. Clearly I do not have what it takes to respond to what I see as extreme (and repeated) childishness without letting myself be dragged (at least somewhat) down into the muck, a problem I've long known I've had, but have yet to fully address. So, those of you who *encouraged* me in private email, thanks, but, from now on, you're on your own in defending the honor of gcc developers against the unfounded, and unfair, accusations of people like Linus Torvalds. It's not just that I don't have the maturity to cope with it -- I don't have the patience, and I surely don't have the time, to keep going over the same ground again and again. From mboxrd@z Thu Jan 1 00:00:00 1970 From: craig@jcb-sc.com To: torvalds@transmeta.com Cc: craig@jcb-sc.com Subject: Re: Linux and aliasing? Date: Wed, 30 Jun 1999 15:43:00 -0000 Message-ID: <19990604144904.21044.qmail@deer> References: X-SW-Source: 1999-06n/msg00144.html Message-ID: <19990630154300.v9F307RS3xJV6KdkXVqVQb5PE5p72E87IQA5s0joMF0@z> >On 4 Jun 1999 craig@jcb-sc.com wrote: >> >> Any programmer worth his salt, wanting "a laser-guided nightsight", >> and not wanting to tweak (or even rewrite) his code for every new >> compiler release, will *not* use a C compiler. Period. > >Oh? > >That's a new argument. Instead of "don't use that feature", it's now >"don't do anything clever at all". No, you misunderstand. C is simply a poor language for the task at hand. It provides too little low-level control of how a C compiler should do its work, yet it's not high-level enough to make it practical for the compiler to do enough of the optimization work for the programmer to satisfy developers of embedded/OS code. Your recently-expressed concerns about `volatile' were a perfect example of that. You correctly (or pretty nearly so) noted the distinction you wanted to make between a volatile *reference* to an object and a reference to an object via a volatile *address* (pointer). That's a distinction C apparently doesn't provide, among many, in a language supposedly "suitable" for "low-level" coding (and, I admit, it's better than PL/I in that regard). Not that I have anything great to suggest in place of C, you understand, and I fully realize that you're not about to rewrite Linux into some other language anyway. But what you're essentially asking for is for us to make gcc compile some language that is less and less like C, one that is more and more like your particular *vision* of what C should be, which happens to be quite at odds with the direct C9X and others are taking, if my impressions of those efforts (based on posts to this list) are correct. (Clearly it'd be easier if those working on the upcoming C standard simply implemented your desires...at least, easier on the gcc developers.) Further, you're asking for us to do language design "on the fly", while implementing a compiler for that language. In my experience, that attempt to marry language design and compiler implementation, while plenty of fun and full of opportunity for cleverness to show itself, almost always leads to poor language design. You've already been bitten by hard-to-find bugs stemming from *extensions* to GNU C that you used, sometimes without regard to the fact that they were not particularly well documented. These experiences have led you to conclude, or at least complain, that gcc was going in a direction you did not like. (Worst of all, you often express this by insulting people like myself, who, especially in my case, aren't the ones *causing* the trouble, but are simply trying to *explain* it to you!) Now you are complaining about a *standard* language feature being implemented in a standard-conforming way by gcc, one which you can work around by changing your code to be standard-conforming (surely a SMOP, say a few lines of Perl ;-) *or* by using a command-line option...but you don't like the pain of the former, or the performance of the latter. Welcome to C hell. I don't know the details of the issues involved, but I trust those that have spoken against your proposal, that they *do* know them. What I have been trying to do is get you to see that, at some point, you have to conclude that you're never going to succeed at making the edge of *this* particular hammer, gcc, sharp enough to make nice clean cuts in silk, for any length of time, without a whole lot of pain, because every time someone uses it as a hammer, those nice cutting edges get worn off. tq vm, (burley) P.S. Due to my own outbursts on this thread, and the resulting email I got, I promise to make this the *last* time I will *ever* respond to queries, complaints, etc. about similar issues coming from the Linux camp. Clearly I do not have what it takes to respond to what I see as extreme (and repeated) childishness without letting myself be dragged (at least somewhat) down into the muck, a problem I've long known I've had, but have yet to fully address. So, those of you who *encouraged* me in private email, thanks, but, from now on, you're on your own in defending the honor of gcc developers against the unfounded, and unfair, accusations of people like Linus Torvalds. It's not just that I don't have the maturity to cope with it -- I don't have the patience, and I surely don't have the time, to keep going over the same ground again and again.