Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!husc6!necntc!ima!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: The D Programming Language
Message-ID: <2809@haddock.ISC.COM>
Date: 2 Mar 88 00:50:52 GMT
References: <11702@brl-adm.ARPA> <243@eagle_snax.UUCP> <2245@geac.UUCP> <2718@mmintl.UUCP> <1988Feb25.202237.8688@utzoo.uucp> <7359@brl-smoke.ARPA>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 61
Summary: sizeof should measure bits; statements should be expressions

>In article <1988Feb25.202237.8688@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>>Most machines cannot handle bits with anywhere near the efficiency
>>with which they handle bytes; the appropriate base unit for efficient code
>>*is* the byte.

"Word-addressible cannot handle bytes with anywhere near the efficiency
with which they handle words; the appropriate base unit for efficient code
is the word."  Right?

On a word-addressible machine, there is a perceived need to address objects
smaller than one word; hence most C compilers give you access to individual
bytes via "char".  (There may be some that define char as a machine word, but
I'm not familiar with any.)  Similarly, on byte-addressible machines there is
a (less) perceived need to address objects smaller than one byte.

If sizeof were measured in bits (the original statement in this thread, I
believe), then (a) no functionality would be lost, because you get the number
of char-sized bytes by using sizeof(thing)/sizeof(char); and (b) it becomes
possible to add a datatype "bit" with sizeof(bit)==1.  Code that doesn't use
it would still be just as efficient as it used to be.  Code that does use it
on a bit-addressible machine would have access to the entire address space.
And code that uses it on a byte- or word-addressible machine may have to use
goofy pointers, just like (char *) on a word-addressible machine.  (Presumably
the author of such code is aware of the space-time tradeoffs.)

In article <7359@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>My "short char" proposal did not REQUIRE bit addressability, but it did
>allow it to be exploited if the implementor decided it was wanted.
>(1 = sizeof(short char) <= sizeof(char).)

This is a less radical proposal, which would be consistent with C.

>The other main implementation would be to let a "short char" be an 8-bit byte
>and a normal "char" be big enough to hold an entire textual unit (typically
>16 bits in Japan).

I see this as a different problem, which is better solved by "long char".  For
example, a Japanese system on a bit-addressible machine should be able to use
both features: 1-bit short char, 8-bit char, 16-bit long char.

>>Please explain how avoiding superfluous words and keeping necessary ones
>>short is consistent with changing {/} to begin/end for no particular reason.
>
>A better reason for a change here is the problems cause by "dangling else"
>and accidental ";" after the closing ")" of a while().

A better change would be to leave the punctuation alone, and but make the
braces required even for a null- or single-statement body.  In other words,
change the syntax to read "compound-statement" instead of "statement".

>If would also be nice if such statements could return values (so ?: could
>be dispensed with).

Yes, let's make *all* statements return values (more precisely, remove the
distinction between expressions and statements).  Then there's no need for the
distinction between ?: vs. if-else, nor () vs. {}, nor the comma operator vs.
semicolon.  (The semicolons in the "for" statement are a minor nuisance, but
no worse than non-operator commas.  "for ((i=0; j=N); i<N; (++i; --j))" is
parsable.)  Statements that have no obvious value (while; elseless if) could
be void expressions.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint