hmmm, no C99

[Serve La]

Serve La wrote:



Strictly conforming code written to C99 rules is portable to all conforming
C99 compilers, of which the number appears (slowly) to be increasing. The
same cannot be said for void main.

Talking about numbers, there's far more compilers in use that support void
main than there are C99 compilers.
Since VC is the most used compiler in the world, not being able to program
C99 in VC means that void main is more portable than C99.

 

[jacob navia]

Here is what lcc-win32 generates:
; long double ld = ull; // This is the C code. ull is unsigned long long
; First, load the 64 bit integer into the eax:edx register pair
movl -4(%ebp),%edx
movl -8(%ebp),%eax
; Load 32 into the FPU. This will be used when scaling the long double later
pushl $32
fildl (%esp)
; Clear this memory location, since we are going to use it later
movl $0,(%esp)
; push the bits 32-63 of the unsigned long long
pushl %edx
;; load the bits 32-63 into the FPU
fildq (%esp)
; scale it by 2^32. This is why we loaded the 32 above
fscale
; put the bits 0-31 in memory
movl %eax,(%esp)
; load it into the FPU
fildq (%esp)
; add low and high parts
faddp
; adjust the stack
addl $8,%esp

This leaves the 64 bit number in the FPU.

Microsoft doesn't do this, because an optimizing compiler doesn't emit operations
that are too long

jacob

 

[Andreas Kahari]

Talking about numbers, there's far more compilers in use that support void
main than there are C99 compilers.

A compiler is perfectly welcome to compile non-conforming
code into something that is executable and that does what the
programmer expects it to do. It is, however, not required to do
so.

Since VC is the most used compiler in the world, not being able to program
C99 in VC means that void main is more portable than C99.

So VC (whatever that is) doesn't support "int main(void) { ... }"?

 

[Severian]

Talking about numbers, there's far more compilers in use that support void
main than there are C99 compilers.
Since VC is the most used compiler in the world, not being able to program
C99 in VC means that void main is more portable than C99.

No matter what compilers let you do it, void main() is still STUPID
and looks especially ignorant on a newsgroup for discussing standard
C.

Even Microsoft says it should return int, to wit:

A special function called main is the starting point of
execution for all C and C++ programs. If you are writing
code that adheres to the Unicode programming model, you
can use the wide-character version of main, wmain.

The main function is not predefined by the compiler;
rather, it must be supplied in the program text.

The declaration syntax for main is:

int main( );

or, optionally:

int main( int argc[ , char *argv[ ] [, char *envp[ ] ] ] );

- Sev

 

[jacob navia]

What "steady progress" are you talking about? I haven't noticed any
changes in http://gcc.gnu.org/c99status.html for the last couple of
years...

Well, they have done complex arithmetic. I am debugging my implementation of
complex arithmetic using gcc.

That's a really difficult stuff to do. I can tell you Dan, with 3 different complex
numbers (in float/double/long double varieties), 3 types of floating point
numbers, and 3 kinds of integers to interchange, well done numeric C99 is quite
difficult.

jacob

 

[Keith Thompson]

[top-posting fixed]

Yes, this bug is since quite a long time.

The problem is that to do this conversion you cannot use the x86, since the
only 64 bit integer conversion in the x86 is signed. Unsigned long long means
that a quite long sequence of machine instructions must be emitted.

I just tried a compiling a small test program on an x86 system with
gcc. Converting from signed long long to double seems to require 2
instructions; converting from unsigned long long to double takes 10,
including a comparison and conditional branch.

The point, though, is that gcc generates the code to do this. It's a
compiler; that's its job. If MSVC (which I've never used) doesn't do
this, that's a bug. (The suggestion to "use `long long' instead" is
particularly silly; perhaps it should say "use `gcc' instead".)

 

[Default User]

Talking about numbers, there's far more compilers in use that support void
main than there are C99 compilers.

So what?

Since VC is the most used compiler in the world, not being able to program
C99 in VC means that void main is more portable than C99.

How does that make int main() less portable?

You seem to have real problems (to paraphrase Dan Pop) engaging your
brain.



Brian Rodenborn

 

[Severian]

Here is what lcc-win32 generates:
; long double ld = ull; // This is the C code. ull is unsigned long long
; First, load the 64 bit integer into the eax:edx register pair
movl -4(%ebp),%edx
movl -8(%ebp),%eax
; Load 32 into the FPU. This will be used when scaling the long double later
pushl $32
fildl (%esp)
; Clear this memory location, since we are going to use it later
movl $0,(%esp)
; push the bits 32-63 of the unsigned long long
pushl %edx
;; load the bits 32-63 into the FPU
fildq (%esp)
; scale it by 2^32. This is why we loaded the 32 above
fscale
; put the bits 0-31 in memory
movl %eax,(%esp)
; load it into the FPU
fildq (%esp)
; add low and high parts
faddp
; adjust the stack
addl $8,%esp

This leaves the 64 bit number in the FPU.

Microsoft doesn't do this, because an optimizing compiler doesn't emit operations
that are too long

Wouldn't it be more efficient to check the high bit and use the
quicker signed conversion if the 64-bit ULL can be represented as a
LL?

- Sev

 

[Simon Josefsson]

Serve La wrote:



Strictly conforming code written to C99 rules is portable to all conforming
C99 compilers, of which the number appears (slowly) to be increasing. The
same cannot be said for void main.

Are there any C99 to C89 translators around? Is it possible to write
one? Compare with the C89 to K&R translators that was popular once.

 

[Richard Heathfield]

Talking about numbers, there's far more compilers in use that support void
main than there are C99 compilers.

I know of only one C compiler that documents support for void main. Most of
my compilers do not support it, and at least two of them actively diagnose
it as being incorrect, when invoked in conforming mode.

Since VC is the most used compiler in the world, not being able to program
C99 in VC means that void main is more portable than C99.

By the same argument, the Windows API is more portable than C99. And yet,
50% of the computers here in my study don't have Windows API support. All
of these (four) machines, however, can run gcc, which is on its way to C99
support, and one of them actually has a full C99 (Comeau/Dinkumware)
implementation. So, from my point of view, C99 is much more portable than
void main. As for the world, well, last I heard, it was going to hell in a
handbasket.

 

[jacob navia]

Wouldn't it be more efficient to check the high bit and use the
quicker signed conversion if the 64-bit ULL can be represented as a
LL?

Interesting. I do not know if it would be faster but if I add a
test $0x80000000,address+4
jne label
fildq address
jmp label+1
label:
; do the hard conversion here
label+1:

The forward jump would be consistently predicted as not taken, so it would not
take a lot of time, and then the jumps are always correctly predicted... so this
would not disturb the pipeline.

It does add 4 instructions and a 32 bit constant to the code. But this
conversions are not that common, so your idea is a good one.

jacob

 

[Ben Pfaff]

Interesting. I do not know if it would be faster but if I add a
test $0x80000000,address+4

It does add 4 instructions and a 32 bit constant to the code.

Use an 8-bit constant instead:
test $0x80,address+7

 

[Keith Thompson]

Talking about numbers, there's far more compilers in use that support void
main than there are C99 compilers.
Since VC is the most used compiler in the world, not being able to program
C99 in VC means that void main is more portable than C99.

That's probably true, but it's not particularly interesting. There's
no excuse for using void main(). Change the "void" to "int" and add a
"return 0;" at the end; your program is more portable, and the
denizens of comp.lang.c will stop yelling at you.

 

[lawrence.jones]

Wouldn't it be more efficient to check the high bit and use the
quicker signed conversion if the 64-bit ULL can be represented as a
LL?

It would be simpler to just do the signed conversion in any case and
then fixup the result, if necessary, by adding ULLONG_MAX+1.0.

-Larry Jones

This game lends itself to certain abuses. -- Calvin

 

[Micah Cowan]

Are there any C99 to C89 translators around? Is it possible to write
one? Compare with the C89 to K&R translators that was popular once.

It's my understanding that this is what the Comeau C99 compiler does.

www.comeaucomputing.com

-Micah

 

[Serve Laurijssen]

That's probably true, but it's not particularly interesting. There's
no excuse for using void main(). Change the "void" to "int" and add a
"return 0;" at the end; your program is more portable, and the
denizens of comp.lang.c will stop yelling at you.

Another case of usenet incomprehension.
I don't want to discuss void main, I agree with that of course. (and it's
been beaten to death already)
But when Richard Heathfield told me to "vote with my feet" I started
thinking that the same could be said for features that are implemented on
your implementation but not on others. Just don't use these other
implementations.
But then why is the emphasize in clc on portability?

 

[Severian]

It would be simpler to just do the signed conversion in any case and
then fixup the result, if necessary, by adding ULLONG_MAX+1.0.

Quite so, and shorter and quicker, too!

- Sev

 

[Randy Howard]

Since VC is the most used compiler in the world,

Is it really the most used? I would probably suspect either
gcc (across a host of different platforms) or perhaps some
other 8051 specific compiler to the winner there. Last I
checked, there are far, far more 8051 embedded devices in
active use on the planet than there are Wintel boxes.

 

[Randy Howard]

But when Richard Heathfield told me to "vote with my feet" I started
thinking that the same could be said for features that are implemented on
your implementation but not on others.

If you are writing code that *must* do something that is outside of the
standard for C, then you must abandon the project, or develop platform
dependent code. Of course, if you are careful you can isolate those
bits so that 95%+ of the remaining program is still within the
"sandbox" so to speak.

That doesn't mean that if a compiler supports doing something wrong,
AND supports doing it correctly, that you should do it the wrong
way just because you can get away with it. Similarly, if more
than one compiler is available, one of which lets you write code
portably to achieve you objectives while another does not, why on
earth (apart from management BS) would you have to use the latter?

But then why is the emphasize in clc on portability?

Because there are numerous platform-specific newsgroups that help people
with the non-portable bits. In each of those, the audience is
specifically attuned to a particular platform and you are much more likely
to get an accurate answer. A group where people from a LOT of different
platforms hang out answer such a question, you're likely to get more
than a few wrong answers, or miss getting a correct answer at all.

So, if you know that asking a platform-dependent question about pthreads
programming is 5% likely to get a good answer in c.l.c, and 95% likely to
get you a flame and a pointer to the FAQ, whereas posting the same
question to comp.programming.threads is going to have inverse statistics
to those, why would you bother to worry about it in this newsgroup?

 

[Dan Pop]

Nope: certain C99 features cannot be implemented in portable C89 code.

Compare with the C89 to K&R translators that was popular once.

It's my understanding that this is what the Comeau C99 compiler does.

Nope: it converts C99 code to C89 code + platform specific extensions.
Therefore, it works only for the supported C89 compilers.

Dan