E
Eigenvector
Richard Heathfield said:
Thank you.
Thank you.
E
Eigenvector
Why do you say that the Intel C compiler isn't standard conforming?Tom St Denis said:
J
jacob navia
Tom St Denis a écrit :
You are just speaking nonsense. As specified here:
http://www.intel.com/cd/ids/developer/asmo-na/eng/dc/tools/compilers/236372.htm?page=4
the intel compiler complies with C99. It is the best compiler for the
intel architecture producing always the best possible code. It is
compatible with gnu's gcc under linux, and with microsoft msvc
under windows.
That compiler is a GREAT piece of software.
You are just speaking nonsense. As specified here:
http://www.intel.com/cd/ids/developer/asmo-na/eng/dc/tools/compilers/236372.htm?page=4
the intel compiler complies with C99. It is the best compiler for the
intel architecture producing always the best possible code. It is
compatible with gnu's gcc under linux, and with microsoft msvc
under windows.
That compiler is a GREAT piece of software.
K
Keith Thompson
jacob navia said:
"producing always the best possible code"?
Fortunately, the Intel web page you cite doesn't make that absurd
claim. I understand that it does generate good code, but I seriously
doubt that it's "always the best possible".
I'll note in passing that that web page contains the following
statement:
C89 is currently the de facto standard for C applications; however
use of C99 is increasing.
W
websnarf
Eigenvector said:
Not really. By its very nature C encourages non-portable programming.
In general, I try to write code portably, but the only thing keeping me
honest is actually compiling my stuff with multiple compilers to see
what happens.
To be completely portable, you also have to support multiple bit sizes
for int, be wary of arbitrary call order of parameters or expression
operands, 6 character unique variable names, use char as either signed
or unsigned, and allow for non-2s complement integers. The problem is
that its hard to find a compiler or platforms that supports variation
in those things.
The easy way to make C code "portable" is to lower your standards for
portability. I.e., just port your code to major compilers (MSVC, gcc
and some Unix cc -- personally, I add Borland C, Turbo C and Watcom C
when I want to really push it), and hope that's good enough.
In general writing any non-trivial amount of code in C for which you
have good certainty about portability is really quite time consuming.
The "open source community" tends to favor "make it work" over "make it
portable".
J
jacob navia
Keith said:
I have *yet* to see any compiler that beats intel's. Sorry.
T
Tom St Denis
jacob said:
GCC 3.4.6 beat Intel v8 in LibTomMath benchmarks. Therefore, GCC is
better than Intel C.
See that's the problem with singular benchmarks they don't mean much.
Intel C is a decent compiler but it allows you to use C++'isms in C
code where you shouldn't be able to. It also lets you use ridicuously
old syntax. And finally, it's inline asm is not 100% compatible with
GCC's asm.
Intel C is OT for this group though, so if you really want to have a
discussion about it email me in private.
Tom
A
Al Balmer
It doesn't say that at all. Did you actually read the article?
K
Keith Thompson
jacob navia said:
That may well be true, but it's not my point.
You claimed that Intel's compiler produces "always the best possible
code". This is a claim of absolute perfection, and it is well beyond
the current state of the art.
There is a tool that generates absolutely optimial code for a
specified operation on a particular CPU by doing an exhaustive search
of all possible instruction sequences (google "superoptimizer"). It
works only on very short sequences, and it takes a very long time, far
longer than would be practical in a compiler. (It's been used to find
canned sequences that can be emitted by rote by an optimizing
compiler.) Your claim, if taken literally, implies that the Intel
compiler does this kind of optimization for all inputs. Even if it's
the best compiler in the world, I don't believe it's the best compiler
possible.
If you want to be taken seriously, either don't make such far-reaching
claims, or back them up.
I'm not surprised that you've chosen to ignore the following from my
previous article.
| I'll note in passing that that web page contains the following
| statement:
|
| C89 is currently the de facto standard for C applications; however
| use of C99 is increasing.
K
Keith Thompson
Al Balmer said:
The table of compilation modes says:
-[no-]c99 C99 conformance and feature support
-std=c89 C89 conformance and feature support
I presume it conforms well to C89. The wording implies that it
conforms equally well to C99. My only reasons to doubt that are that
full C99 conformance is relatively rare, and I'd expect Intel to make
a bigger deal about it.
J
jacob navia
Al said:
You can't read?
In that page the option
-std=c99
is mentioned with explanation:
" C99 conformance and feature support"
in the first table of that page.
And you say:
There is no blinder person as the one that doesn't want to see!
jacob
A
Al Balmer
And that's what you're basing your conclusion on? An entry in a
options table? The name of one of the C++ options is "_strict_ansi",
but in the text above, they tell you that the C++ compiler has only "a
high degree of conformance." IOW, it's not "strict ansi."
As one who claims to be a compiler vendor, you should know that
standards compliance should be supplied as a separate statement, along
with the required statement of implementation dependent behavior.
It's entirely possible that Intel is fully C99 compliant (though you'd
think they would say so in their ads), but you can't tell from the
page you gave us.
A
Al Balmer
An unjustified presumption, imo. The text does claim good conformance
to the C++ standard, but really says nothing about either C89 or C99
conformance.
Or equally badly, if you mean the wording in the table of compilation
modes, which probably isn't legally binding
Fourth return from Google:
http://www.intel.com/support/performancetools/c/sb/cs-015003.htm
<quote>
C Standard Conformance
The Intel® C++ Compilers provide some conformance to the ANSI/ISO
standard for C language compilation (ISO/IEC 9899:1999).
For more information on C conformance, refer to the User's Guide.
</quote>
I expect the user's guide will have a detailed listing of
non-conforming items, as well as the list of implementation-dependent
items.
K
Keith Thompson
Al Balmer said:
Perhaps. My presumption is based largely on the fact that C89
conformance is much easier to achieve than C99 or C++ conformance.
There are plenty of compilers that conform well to the C89/C90
standard; Intel's compiler would have trouble competing if it had
significant gaps.
This is, of course, guesswork based on circumstantial evidence, not
guaranteed to be worth more than you paid for it.
M
Malcolm
Yes. There is a tension between efficiency and portability. In Java they
resolved it by compromising efficiency, in C we have to be careful to make
our portable code genuinely portable, which is why the topic is so often
discussed.
There is also the problem of "good enough" portability, for instance
assuming ASCII and two's complement integers.
F
Frederick Gotham
Websnarf posted:
Heavily subjective statement, and I disagree vehemently.
Without trying to sound condescending: You should have a better knowledge
of the restrictions (and freedoms) which the C Standard imposes upon
implementations. Things like:
(1) Null pointers need not be all bits zero.
(2) All bits zero must be a valid zero value for an integer type.
(3) All union members have the same address.
(4) There may be padding between struct elements.
I NEVER have to rely on different compiler tests to tell me if my code is
portable -- I just look for the relevant excerpt from the Standard.
Easily sorted with:
(1) sizeof
(2) IMAX_BITS written by Hallvard B Furuseth
Don't rely on order of evaluation. The language has sequence points for a
reason.
Only use "plain char" to store a character -- don't use it for numbers or
arithmetic.
When would one need to reply on having 2's complement? It would only be
relevant if you're doing bit-fiddling. In any case, you an easily make
allowances for it:
#if (-1 & 3 == ...
#define TWOS_COMPLEMENT...
#else
#define ONES_COMPLEMENT...
And... if all else fails, and your program simply MUST run on a two's
complement system, then:
#ifndef TWOS_COMPLEMENT
#error ...
But it's easy to find the relevant paragraphs in the Standard.
Better yet... just write 100% portable Standard-compliant code.
Not if you're familiar with writing portable code.
If the Open Source Community jumped off a cliff, would you ju...
Heavily subjective statement, and I disagree vehemently.
Without trying to sound condescending: You should have a better knowledge
of the restrictions (and freedoms) which the C Standard imposes upon
implementations. Things like:
(1) Null pointers need not be all bits zero.
(2) All bits zero must be a valid zero value for an integer type.
(3) All union members have the same address.
(4) There may be padding between struct elements.
I NEVER have to rely on different compiler tests to tell me if my code is
portable -- I just look for the relevant excerpt from the Standard.
Easily sorted with:
(1) sizeof
(2) IMAX_BITS written by Hallvard B Furuseth
Don't rely on order of evaluation. The language has sequence points for a
reason.
Only use "plain char" to store a character -- don't use it for numbers or
arithmetic.
When would one need to reply on having 2's complement? It would only be
relevant if you're doing bit-fiddling. In any case, you an easily make
allowances for it:
#if (-1 & 3 == ...
#define TWOS_COMPLEMENT...
#else
#define ONES_COMPLEMENT...
And... if all else fails, and your program simply MUST run on a two's
complement system, then:
#ifndef TWOS_COMPLEMENT
#error ...
But it's easy to find the relevant paragraphs in the Standard.
Better yet... just write 100% portable Standard-compliant code.
Not if you're familiar with writing portable code.
If the Open Source Community jumped off a cliff, would you ju...
K
Keith Thompson
Malcolm said:
I rarely find it useful to assume ASCII. It's usually just as easy to
write code that depends only on the guarantees in the standard, and
will just work regardless of the character set. It would be
marginally more convenient to be able to assume that the character
codes for the letters are contiguous, but that's easy enough to work
around.
As for two's complement, I typically don't care about that either.
Numbers are numbers. If I need to do bit-twiddling, I use unsigned.
R
Richard Heathfield
Keith Thompson said:
I suppose that this attitude is more natural for those of us who have
written code that has to work on real live non-ASCII systems, simply
because we're so used to not being /able/ to assume ASCII that it never
occurs to us to rely on ASCII even when we might get away with it.
Indeed. And, on a related note, I find it very difficult to understand this
fascination with integers that have a particular number of bits. If I need
8 bits, I'll use char (or a flavour thereof). If I need 9 to 16 bits, I'll
use int (or unsigned). If I need 17 to 32 bits, I'll use long (or unsigned
long). And if I need more than 32 bits, I'll use a bit array. I see
absolutely no need for int_leastthis, int_fastthat, and int_exacttheother.
The introduction of long long int was, in my continued opinion, a mistake.
All the ISO guys had to do was - nothing at all! Any implementation that
wanted to support 64-bit integers could simply have made long int rather
longer than before - such a system would have continued to be fully
conforming to C90. And if it broke code, well, so what? Any code that
wrongly assumes long int is precisely 32 bits is already broken, and needs
fixing.
I suppose that this attitude is more natural for those of us who have
written code that has to work on real live non-ASCII systems, simply
because we're so used to not being /able/ to assume ASCII that it never
occurs to us to rely on ASCII even when we might get away with it.
Indeed. And, on a related note, I find it very difficult to understand this
fascination with integers that have a particular number of bits. If I need
8 bits, I'll use char (or a flavour thereof). If I need 9 to 16 bits, I'll
use int (or unsigned). If I need 17 to 32 bits, I'll use long (or unsigned
long). And if I need more than 32 bits, I'll use a bit array. I see
absolutely no need for int_leastthis, int_fastthat, and int_exacttheother.
The introduction of long long int was, in my continued opinion, a mistake.
All the ISO guys had to do was - nothing at all! Any implementation that
wanted to support 64-bit integers could simply have made long int rather
longer than before - such a system would have continued to be fully
conforming to C90. And if it broke code, well, so what? Any code that
wrongly assumes long int is precisely 32 bits is already broken, and needs
fixing.
K
Keith Thompson
Richard Heathfield said:
Perhaps, but I've never really programmed for a non-ASCII system.
It just wouldn't occur to me to write code that depends on the
assumption that 'A' == 65. If I want 'A', I write 'A'.
But there are times when you need some exact number of bits,
particularly when you're using an externally imposed data format.
(But then whoever is imposing the data format on you should have
provided a header that declares the appropriate types.)
Something that might be more useful would be a way to ask for an
integer type with (at least) a specified *range*. If I'm using a type
to hold numbers rather than bags of bits, I care what numbers I can
store in it, not how many bits it uses to store them.
That's true, but 64 bits is the effective limit for this. The
following:
char 8 bits
short 16 bits
int 32 bits
long 64 bits
is a reasonable set of types, but if you go beyond that to 128 bits,
you're going to have to leave gaps (for example, there might not be
any 16-bit integer type).
My objection to C's integer type system is that the names are
arbitrary: "char", "short", "int", "long", "long long", "ginormous
long". I'd like to see a system where the type names follow a regular
pattern, and if you want to have a dozen distinct types the names are
clear and obvious. I have a few ideas, but since this will never
happen in any language called "C" I won't go into any more detail.
R
Richard Heathfield
Keith Thompson said:
Indeed. So is this:
char 8 bits
short 64 bits
int 64 bits
long 64 bits
and at least one implementation does it like that.
Er, and?
I think the C99 guys missed a trick by not reserving "very" for this
purpose. If they must spec extra types, at least make them scalable:
very long - at least 64 bits
very very long - at least 128 bits
very very very long - at least 256 bits
etc
Indeed. So is this:
char 8 bits
short 64 bits
int 64 bits
long 64 bits
and at least one implementation does it like that.
Er, and?
I think the C99 guys missed a trick by not reserving "very" for this
purpose. If they must spec extra types, at least make them scalable:
very long - at least 64 bits
very very long - at least 128 bits
very very very long - at least 256 bits
etc