Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > libitery directory in gcc-3.1.1 source code package

Reply
Thread Tools

libitery directory in gcc-3.1.1 source code package

 
 
CBFalconer
Guest
Posts: n/a
 
      08-20-2004
"L. Chen" wrote:
>
> > Nope. Casting a pointer to any form of integer is not guaranteed
> > to be reversible, and the results are implementation defined.

>
> Sometimes, I feel it is so difficult to make the C programmes
> portable. There is the modified one,
>
> void* memcpy3 (register void* dest, register void* src, register size_t len)
> {
> void* pdest = dest;
>
> if( (dest-src)%4==0 )


Not if you stick to operations defined by the standard. The above
is not. That is one of the fundamental reasons that memcpy()
exists as a standard function. You can't duplicate it without
using forbidden (for portability purposes) system knowledge.

--
Chuck F ((E-Mail Removed)) ((E-Mail Removed))
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!


 
Reply With Quote
 
 
 
 
Tim Rentsch
Guest
Posts: n/a
 
      08-23-2004
Keith Thompson <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> writes:
> [...]
> > First let's see if we can fix the definite bugs (not counting any
> > possible problems with casting a pointer to an unsigned int, I count
> > at least three), and clean the code up a bit:
> >

> [snip]
> > {

> [snip]
> > if( (unsigned int)s % K == 0 ){
> >
> > Now let's return to the question at the start of the posting.
> >
> > Even though the method of testing pointer alignment in the code above
> > isn't guaranteed to work, the fact is that it will work on many
> > architectures (probably most architectures, but I expect that depends
> > on how the counting is done). Since this is so, why not provide a
> > standard means of checking for it? There could be a C preprocessor
> > symbol, eg, SINGLE_LINEAR_ADDRESS_SPACE, that could be used to mean
> > that pointers look like integers. Something along these lines could
> > be written into the standard to provide a conformant means of writing
> > code to do this kind of pointer manipulation. Make sense?

>
> 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.

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.

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.


> 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.)


> Currently, if I write portable code that will work even for a
> non-linear address space, I can recompile and run it on a
> "non-lineary" system and it should work.


The presence of a standard-imposed definition of SLAS wouldn't change
that. It would give you the option of writing specialized code that
ran only on such systems, presumably with some performance gain, and
using the non-SLAS code as fallback on other systems. And your code
would still be portable to all the machines it was before.


> An example of a system where SINGLE_LINEAR_ADDRESS_SPACE would be
> undefined is a Cray vector system, where a machine address points to a
> 64-bit word. The C compiler has CHAR_BIT==8 to allow for code
> portability, but a char* pointer has a 3-bit offset in the top of the
> word. Well written portable code works just fine. Code that makes
> assumptions about how pointers are represented doesn't. (The systems
> run a Unix-based OS, and most Unix-based software compiles and runs
> correctly, so the lack of ability to do that kind of low-level pointer
> manipulation hasn't been much of a problem.)


What bugs me here is the phrase "code that makes assumptions....".
The whole point of an SLAS-like proposal is to provide a means whereby
code doesn't "make assumptions" but relies on some standard-defined
behavior to enable certain kinds of code in some situations.

Incidentally, the description of the Cray character addresses is
perhaps interesting, but not especially relevant after the first
sentence. If SLAS were "off" on the Cray, then code that depended
on SLAS being "on" wouldn't be present.


> 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.


Perhaps this should have been posted on comp.std.c rather than
comp.lang.c (or perhaps both). It seemed better to continue
the thread in the group it started, and comp.lang.c seems
at least reasonably appropriate. If anyone has some comments
on that, please feel free to send them to me directly in email.
thanks.
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      08-23-2004
Tim Rentsch <(E-Mail Removed)> writes:
> Keith Thompson <(E-Mail Removed)> writes:
> > Tim Rentsch <(E-Mail Removed)> 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) http://www.velocityreviews.com/forums/(E-Mail Removed) <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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to find directory of package residence from within package? Krishna Chaitanya Perl Misc 5 04-03-2009 05:19 PM
J2EE Java Blueprints package/directory structure: best practice for common code? jsoftwaredev@gmail.com Java 1 10-21-2007 02:16 AM
System.IO.Directory.GetDirectories() and System.IO.Directory.GetFiles() are not returning the specified directory Nathan Sokalski ASP .Net 2 09-06-2007 03:58 PM
Source code for the MP package that I'm trying to debug mike3 C++ 9 08-24-2007 09:55 PM
Anyone who can help me to compile a source code package under the Solaris platform? jing C++ 1 12-08-2005 03:19 PM



Advertisments