Thou shalt have no other gods before the ANSI C standard 1349

Douglas A. Gwyn

Read carefully. What you said and what I said are not contradictory. The problem is for pointers of *different types*. Its important for suporting a kind of anonymous context handle type.

Yeah, like the 6502. Do you suppose someone's hard at work making a C99 compiler for it?

Because ASCII is not useful to people who don't speak english? In a very strong sense, ASCII *CANNOT* become a pervasive standard because of this. Unicode has a better chance, but digging a little deeper shows that even Unicode seems to have screwed the pooch for CJK.

His point is about defacto-standards. ASCII is not a relevant defacto standard for most of the world.

This is utter nonsense. I have become a very "portable" conscious programmer, and find it nearly impossible to write any serious program without leaning heavily on *most* of those buttumptions. What is the fastest way to find the least power of two greater than a given integer? What is the fastest way to scan an int to see if it contains a 0 byte in it? What is the fastest way to count the number of bits in a given int? How the hell can I do any of these in a way that is both portable and fast?

There is very little point in killing myself to make my code "truly portable" because I just have no realistic access to any machine that doesn't follow the 32-bit + 2scomplement + IEEE-754 buttumptions. So I can't test my code on such platforms anyways.

Ah, the embedded environment -- the last bastion of obsolete processors. It of course didn't occurr to you that in 10 years, multi-core 32+ bit system-on-a-chip procesors will be more pervasive and *cheaper* than the 8 bit microcontroller chips that are still in marginal use today? BTW, do you know of any embedded environments with a compliant C99 targetting them?

New compiler development for such platforms is not a poor economic decision?

As DJB points out, the new 64-bit desktop processors continue to rely on the buttumptions he listed (along with uniform pointer sizes, signed right shift, 2s complement etc.) I have personally verified this for the PPC-64 and Sparc, and its well known to be true for the AMD64 Linux ABI. Even Alpha and Itanium stuck with 32 bits for int.

Excuse me? What are you talking about? Any deviation from IEEE-754 is summarily shot down by basically everyone who does serious FP work. Sun tried to deviate from the full semantics of IEEE-754 *slightly* in Java, and were forced to back off from the backlash. So I don't know what this "hexadecimal float-point" thing is that you are talking about, but its got about as much chance of getting seriously adopted as Atari making a comeback by entering the super-computer market.

And development on this DSP uses a C compiler for more than just glue code for hoards of the real buttembly language inner loops?

That's a hell of a lot of leverage that one commercial compiler has on the standard.

They are the only kinds of computers on which new C compilers are being developed and ported to. The other kinds of computers have plenty of older standards that are good enough for them. What you have to answer is why are the *NEW* C standards continuing to pay defference to platforms on which no more new compiler development is taking place?

You misspelled "partially". Its been 4+ years, and gcc was extremely close a long time ago, yet they halted. That is reason-incentive enough for any compebreastor to prove that they are "better" than gcc (an important marketing point considering gcc is "free", and targets nearly everything of relevance out there) by going ahead and implementing full C99. Yet nobody is there -- of course, no end users are exactly demanding C99 compliance either.

No, it just breaks important compiler extensions and presents very serious compatibility issues with C++. Personally, I think Duke Nukem Forever is going to ship before a major vendor ships a C99 compiler.

I'm very familliar with one 8-bit platform, one 16-bit platform, and one "36-bit" platform (probably one you've never heard of -- we didn't have a real C compiler for it) and have used two 64-bit platforms (though I wouldn't call myself expert in either.) That isn't the point. The point is that every one of those platforms (besides the 64-bit ones) is either completely obsolete or C compiler development is non-existent on them.

I am unaware of any new "clbuttical CPU" hardware design that isn't "32bit ints + 2s complement + IEEE-754". It framed the Java standard, its basically creeped into graphics ASIC standards (in fact I was quite shocked to learn that they have decided to support *FULL* IEEE-754, since it costs more transistors to handle denormals which are usually unimportant for graphics), and it has 100% of workstation and desktop.

Even your precious "embedded space" is basically being taken over by PowerPC and Xscale-StrongArm and custom processors are typically just variants on MIPS processors.

-- Paul Hsieh