sima/autoconf/
sima/hosts/i386/
sima/mudlib/
sima/mudlib/kernel/
sima/mudlib/obj/
sima/mudlib/sys/
sima/synhash/mips/
Disclaimer: I would code all my time critical code in assembler if there
was only a single assembler... preferably something like 68030 or sparclite.

You cannot declare critical paths, nor probability / possibility that a
variable has a particular value or a value in a particular range.

You cannot distinguish between tight, intermediate and loose coupling of
inlined functions. Sometimes you have two mutually recursive functions
with the larger one being used unly once (this being in the smaller one).
The default tight coupling for inline spoils register allocation in the
small function. Using two disct functions can mean excessive parameter
passing; just look at find_object() / load_object() do...

You cannot declare that for some path in the control flow, the value
of a used variable has no effect on the global result of the computation,
so that this variable need not be saved across function calls.

You could hint that there are no default values outside the presented range
for a switch by using enums; alas, gcc does not recognize this. It even
checks that an unsigned char it just fetched with movzbl is not greater
than 255.

a switch() statement has only a single dispatch point; you can do a bit
with goto, but there is no way to inline the dispatch code.

You cannot give different implementations of the same concept and tell the
compiler to pick the one best suited for the target machine.

There is no storage type declarator that says to keep a value in a register
when compiling with optimization.

You cannot split control blocks; there are some places where in a switch,
you would naturally do:
 { block a:

  variable declarations...

  initialize variables...
  goto label_c
{ block b:
}
/* fall through */
{ continue block a:
  initialize variables...
label_c:
}
As it is now, you have to forcefully include block b into block a, making the
variables therein visible.

You cannot declare a pointer to some type scewed by an offset. Working with
char/void pointers instead and using macros to get accesses therein is messy.

There is no operator to reverse the bit order in an integer value; e.g.
0x01 -> 0x80; 0x0001 -> 0x8000; 0x00000001 -> 80000000; 0x1ac4 -> 0x2358 .
Of course this would need extra asseembler intructions, bit this is trivial
to implement in the hardware ALU. But without high level language
acessability, this is not likely to happen.
In conjunction with ffs, this can be used for multidimensional
searching & sorting, storage allocation for number base conversions, and
dynamic sized hash tables.

(minor): you cannot pass scalar data in structures from/to functions without
using a temporary variable.