Ian Ollmann (iano@apple.com) on 7/6/10 wrote:
---------------------------
>1) Weak support for threading. The timing of operations is at times over-described or under-described.

This gives ISA designers the freedom to try out various relaxed memory models.

>2) No SIMD vector support / failure to standardize types early on -- how big is
>an int anyway? A double? What is the bit pattern for these things? (I group these
>together because many algorithms for vectors require fixed data representations.)

# include

# if INT_MAX >= 1 << (CHAR_BIT << 1)
# error An int is more than 2 bytes
/* and so on */
# endif

The point of C is portability, e.g. to both 2s complement and sign-magnitude machines -- never mind they no longer exist. That's why these things were not specified.

>3) Most of all -- The language is conversion-happy. Following basic hardware models
>of 50 years ago, it tries to convert everything to a core hardware type, do the
>work, and convert back.

Well, all my RISC machines work exactly this way, and I'm sure the x86 people would rather not have to deal with AH, AL, AX, EAX and RAX etc.

All the conversions are a problem, because they make it
>difficult to precisely describe an algorithm -- what you see is not what you get.
>E.g. short << 16, forces a conversion to int (of what size?) before the shift
>occurs, so if you right shift again later, those bits might be there or might not.

Can be solved with . Although P.J. Plaugher is to blame for C89's stupid move away from K+R C's rule of preserving unsignedness.