Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!clyde!cuae2!ltuxa!ttrdc!levy
From: levy@ttrdc.UUCP (Daniel R. Levy)
Newsgroups: comp.lang.c
Subject: Re: sizeof(char)
Message-ID: <1305@ttrdc.UUCP>
Date: Sun, 9-Nov-86 05:24:49 EST
Article-I.D.: ttrdc.1305
Posted: Sun Nov  9 05:24:49 1986
Date-Received: Mon, 10-Nov-86 23:58:26 EST
References: <4617@brl-smoke.ARPA> <657@dg_rtp.UUCP>
Organization: AT&T, Computer Systems Division, Skokie, IL
Lines: 47

In article <5310@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
>Guy is still missing my point about bitmap display programming;
>I have NOT been arguing for a GUARANTEED PORTABLE way to handle
>individual bits, but rather for the ability to do so directly
>in real C on specific machines/implementations WITH THE FACILITY:
>...
>Direct use of Pixel pointers/arrays tremendously simplifies coding for
>such applications as "dmdp", where one has to pick up typically six
>bits at a time from a rectangle for each printer byte being assembled
>(sometimes none of the six bits are in the same "word", no matter how
>bits may have been clumped into words by the architect).
>
>From the resistance he's been putting up, I doubt that I will convert
>Guy to my point of view, and I'm fairly sure that many people who have
>already settled on some strategy to address the multi-byte character
>issue are not eager to back out the work they've already put into it.
>However, since I've shown that a clean conceptual model for such text
>IS workable, there's no excuse for continued claims that explicit
>byte-packing and unpacking is the only way to go.

At the risk of sounding ultra-stupid, I am having trouble trying to relate
the issue of multi-byte character handling to that of "addressing individual
bits."  They sound like separate, distinct issues to me.

However, presuming Gwyn's interest is in doing the latter, it seems to me
that a smart enough C compiler on a machine which can "address individual
bits" within a data entity (byte, word, etc.) could use the bit-addressing
instructions to advantage when presented with the code contained within a
series of the "set bit" and "clear bit" and "copy bit" (etc.) macros which Guy
is pushing for "portable" programs.  That is, the compiler would implement
the intent of the code in the macros directly through bit operations rather
than shifting, masking, OR-ing, AND-ing, etc.  This would allow things like
what I think Gwyn wants, like copying, setting or clearing one or several
bits in random places in RAM without having to read the data containing those
bits into the CPU first the way a conventional machine would.  If that were
so, then one could have the best of the portable and the bit-addressable
worlds.

This seems too simple.  So, what have I missed?
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
	   go for it!  			allegra,ulysses,vax135}!ttrdc!levy