🚀 go-pugleaf

That C promotes all values of type char to int before using them in an
expression may on the face of it seem to simplify expression evaluation and the
semantics of the language, but it also makes the implementation grossly
inefficient in some cases.  Experimenting with Lempel-Ziv compression that also
involved calculating a CRC, I found that code compiled by Microsoft C was as
much as 10 times slower than hand-crafted assembly code (this on an 8088 CPU)
even when macros were liberally used instead of functions. 

Inspecting critical loops in the generated code, I was shocked to find that the
compiler was doing what it could to make things fast, but it was hindered by
the requirement that char types be promoted to int before being used in an
expression.  The 8088 CPU has 16-bit registers that are made up of pairs of
8-bit registers and each 8-bit register can be separately used for 8-bit
operations, making character-oriented code extremely efficient.  But the
compiler was forced to treat such code as int-oriented code (ints being 16 bits
in this implementation).  Hand-crafted assembly code, where the programmer
knows whether or not 16 bits will be ultimately needed, isn't similarly
restricted. 

I think this is a significant deficiency in C.  Is ANSI doing anything to
eliminate this or decrease its effect?  Considering that the vast majority of
UNIX tools do text processing in 7-bit units, one would think that somebody
would have done something by now.  Is a potential doubling or tripling of 
text processing speed not significant enough to be worth redefining a 
programming language for?

Perhaps the problem is that UNIX and C have traditionally been implemented only
on machines (e.g. PDP-11, VAX-11/7xx) in which using an 8-bit register always
automatically tied up a 16-bit or larger register, and nobody ever imagined
that we would be running C programs on cheap microprocessors with 8-bit
registers. 

Rahul Dhesi
dhesi%bsu@csnet-relay.ARPA
...!seismo!csnet-relay.ARPA!bsu!dhesi