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

David Wagner

You're (intentionally?) missing the point. Most DSP software performs general-purpose functions in addition to array processing. Much C software is aimed at general-purpose functions that might or might not be useful in some DSP applications. Why should it be unnecessarily coded so that it fails to work right when borrowed for such an application?

In fact, my coworkers recently ported a substantial amount of code from its original desktop environment to a DSP. That is part of the "real world", and a part that has growing significance.

Our DSPs are certainly used in network communications and security is definitely an issue.

I guess it depends on whether the 64 bits refers to the address space or to the word size. Certainly, 64-bit word platforms I've used have chosen 64 bits as the width of their C int.

Since there is no pressing reason for a 64-bit word architecture to use 32-bit ints, whereas subfield masking could be really expensive if the ISA doesn't have specific support for it, there is a natural tendency for C implementors on all platforms to make int as wide as the word, just as on 32-bit platforms where 32 bits was the usual width for int (not 16 bits, which somebody like DJB would have argued similarly for, at the time that C started to become available on 32-bit machines).

"Those that do not learn from history are doomed to repeat it."

Another factor in making a different choice might be that DJB and his ilk have produced so much code that unnecessarily has a built-in buttumption of 32-bit int that the vendors decide to cater to it rather than lose customers (even stupid ones) who would blame the compiler rather than themselves when their nonportable code fails.