Re: libitery directory in gcc-3.1.1 source code package

From: Keith Thompson (kst-u_at_mib.org)
Date: 08/23/04 

Date: Mon, 23 Aug 2004 09:09:11 GMT

Tim Rentsch <txr@alumnus.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
> > Tim Rentsch <txr@alumnus.caltech.edu> writes:
[...]
> > I suspect that would encourage programmers to write code that only
> > works if SINGLE_LINEAR_ADDRESS_SPACE is true. (Too many programmers
> > do that already, of course.)
>
> Notice the argumentative sleight-of-hand. An opinion is presented
> without any reasoning or supporting evidence, then subsequent
> discussion implicitly gives the opinion the status of fact.

I presented a suspicion, clearly labeled as such. I don't believe
everything I wrote after that depended on the truth of the suspicion.

> On the contrary - if something like SINGLE_LINEAR_ADDRESS_SPACE were
> written into the standard, then the sort of people who know about such
> things would likely provide a specialized implementation for those
> systems that had it defined as 1, and a more mundane implementation
> (or just an outright error) for those systems that had it defined
> as 0. And of course people who didn't know about it wouldn't change
> their behavior. In either case the situation is no worse off then
> before, unless of course someone thinks that people knowing about
> the flag will be encouraged to write code that depends on it being
> true and NOT checking for it. That seems a little silly.

Why not just write the "mundane implementation" and be done with it?
(Presumably the answer is improved performance for the SLAS==1 case;
see below for my response to that.)

My concern is with the "outright error" case. With the current
situation, knowledgeable programmers write code that doesn't assume a
single linear address space. It turns out that most of them do a
pretty good job within that restriction. One result of this is that I
can use Perl scripts on a Cray SV1 (Perl's implementation includes
several hundred thousand lines of C); I can also use my favorite text
editor and other tools (more hundreds of thousands of lines of C).

If the programmers who wrote all that code had taken advantage of a
SINGLE_LINEAR_ADDRESS_SPACE macro, one of two things would happen.
Either they'd write two distinct versions of some of their code (and
the SLAS==0 version might never be tested if the authors didn't have
an exotic system at their disposal), or they'd only bother to write
the SLAS==1 version (and the code wouldn't compile on a Cray vector
system in the first place).

> Moreover, the presence of such a standard-defined flag would mean
> that a system could give a diagnostic for code that seems to make
> such assumptions on a system where SINGLE_LINEAR_ADDRESS_SPACE is
> defined to be 0. For that matter, compilers could give a diagnostic
> for code on *any* system that has code using SLAS-specific behavior
> and not wrapped in a '#if' or 'if' testing SINGLE_LINEAER_ADDRESS_SPACE.
> I'm not suggesting that such tests be made mandatory, only that they
> could be put in place if some compiler writers chose to - and surely
> that would *raise* consciousness about what assumptions are reasonable
> to make when trying to write portable C code.

Compilers are already free to give a diagnostic for code that assumes
a single linear address space. In effect, the current situation is as
if SINGLE_LINEAR_ADDRESS_SPACE were 0 for all systems.

> > Of course you can implement such a preprocessor symbol yourself, and
> > configure it for each system. It's a little extra work, but frankly
> > it probably should be.
>
> Another unsupported opinion, and a statement that's just plain false.
> It's not a little extra work, it's quite a bit of work, and
> furthermore one that most people simply don't have the resources to
> support. I for one do not have access to many of the different,
> unusual machine architectures to know how they should be labelled;
> I doubt most people reading this newsgroup do either. (For the
> record that last statement was my opinion - I welcome people who
> do have such access to chime in with some evidence.)

Ok, that's not a bad point. It's a small amount of work for each
system you want to support. If the SINGLE_LINEAR_ADDRESS_SPACE macro
were required by the language, that small amount of work would be done
approximately once for each platform, by the implementers of the
compiler for that platform, rather than once on each platform by each
programmer who cares about the issue.

[...]
> > Of course something like memcpy() can be made much more efficient if
> > it can detect pointer alignment and copy word-by-word whenever
> > possible. That's why memcpy() is in the standard library, where it
> > can be implemented with non-portable code.
>
> There are basically two paths we can think about going down here.
> One, we can relegate all system-specific behavior to library
> functions, and make the library ever larger as more and more functions
> are argued about and agreed to in the standards committee. Or, two,
> we can try to provide some definitions in the language environment
> that allow some system-specific -- but still universally conformant --
> code to be written without having to wait for the right library
> function to appear. Whether it is a SINGLE_LINEAR_ADDRESS_SPACE
> symbol or some other similar mechanism, the second path seems better
> than the first path.

The point of SINGLE_LINEAR_ADDRESS_SPACE is to enable certain
techniques to be used on systems that support them. I'm just not
convinced that it's worth it. In my (admittedly limited) experience,
I haven't found the need to make more assumptions about pointers than
what the standard guarantees. The example given in this thread of a
case where it would help was a re-implementation of memcpy() -- but
memcpy() is in the standard library, so its implementation is free to
any system-specific tricks that will improve its performance. (That
could include things like knowledge of alignment requirements and
block-copy CPU instructions, neither of which would be supported by
SINGLE_LINEAR_ADDRESS_SPACE.)

Even if adding SINGLE_LINEAR_ADDRESS_SPACE wouldn't hurt code
portability, it would require some effort to create a rigorous
definition of what it means, and it would add slightly to the
complexity of the language. To overcome that, you'll have to convince
a number of people (not me) that there's a significant benefit. That
probably means showing that there are significant real-world
algorithms outside the standard library that can be implemented
significantly more efficiently with the assumption of a single linear
address space, and that adding the macro makes more sense than making
an addition to the standard library.

You should also be aware that changes to the language take years to
show up in the standard, and it takes many years after that before
programmers can safely assume a new feature is available widely enough
to be used in portable code.

I'm not trying to discourage you. If you think you can demonstrate
that it would be a good addition to the language, I wish you luck. 

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

Relevant Pages

  • No Starch Press Releases "Write Great Code, Volume 2"
    ... Thinking Low-Level, Writing High-Level ... Explains how compilers work and how to get the best quality output from ... code for those high-level language statements and data structures, ... In the early days of computing, programmers used high-level language code ...
    (comp.os.linux.announce)
  • Re: Garbage collection
    ... Unfortunately making an accurate GC for C would require compiler ... "The programmers knows what he does" it would be ... support GC or beeing against it. ... So I'd argue there's hardly a language whith more tools ...
    (comp.lang.c)
  • Re: Should anyone be using modern Fortran any more?
    ... (Getting compilers to run or run with the right set of options has nothing to do with language standard.) ... any sort of computer language is a "convenience" - you could always go an work at the machine instruction level! ... on teaching and upgrading programmers by employers or the self-employed ...
    (comp.lang.fortran)
  • Re: Problem with a linked list
    ... And vendors who make C compilers generally make C and C++ combined products. ... On the rare occasions they do change the intermediate language, they will change all the front ends to use it so they only have one optimiser and code generator to maintain. ... This is why basically no vendor is rushing to support the "C99" standard. ...
    (comp.lang.c)
  • Re: macro with variable length of argument
    ... C programmers can't and won't do it. ... Can't because, before C99, there was no standard mechanism for inlining functions, won't because it's a staple of C culture. ... None of the compilers I did and do C with claimed C99 conformance btw, ... in C++ 'inline' is part of the language and constants can be used to declare arrays, so two possible reasons that you need them are gone. ...
    (comp.lang.c)