🚀 go-pugleaf

> That C promotes all values of type char to int before using them in an
> expression ... [is a performance disaster on an 8-bit machine] ...
> I think this is a significant deficiency in C.  Is ANSI doing anything to
> eliminate this or decrease its effect? ...  Is a potential doubling or
> tripling of text processing speed not significant enough to be worth
> redefining a  programming language for?

Only when it's really necessary to redefine the language to solve the
problem.  The X3J11 drafts state clearly that the semantics as given in
the draft define the required effects, and the compiler is free to get
those effects by whatever means it chooses.  In particular, if it can
determine that the result will only be 8 bits and that no overflow hassles
intervene, it is entirely free to use 8 bits, essentially optimizing out
the promotion.  This is in fact an example the drafts use.

> Perhaps the problem is that UNIX and C have traditionally been implemented
> only on machines ...in which using an 8-bit register always automatically
> tied up a 16-bit or larger register...

This is quite true, but as it happens it's not that hard for a compiler for
a small machine to optimize the code to use 8 bits most of the time.  The
only unoptimizable case is in function calls, and that is less of a
hassle.  It is, of course, quite possible to write a stupid compiler that
doesn't try to do this optimization.  In fact, there are quite a few of
them.  Particularly in the 8088 world, which is such a huge and uncritical
market that any get-rich-quick artist who puts an attractive package around
shoddy software can count on making a profit.  (There *is* some pretty good
8088 software, but Sturgeon's Law -- "95% of everything is crap" -- very
definitely applies.)

In short, you are being victimized by a stupid compiler, not a stupid
language.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry