Xref: utzoo comp.lang.c:8356 comp.arch:3982
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c,comp.arch
Subject: Re: Bit Addressable Architectures
Message-ID: <7489@brl-smoke.ARPA>
Date: 20 Mar 88 03:27:04 GMT
References: <11702@brl-adm.ARPA> <243@eagle_snax.UUCP> <2245@geac.UUCP> <1988Mar6.002518.945@utzoo.uucp> <2760@mmintl.UUCP> <17458@watmath.waterloo.edu> <7452@brl-smoke.ARPA> <2767@mmintl.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 22

In article <2767@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes:
-In article <7452@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
->It's occasionally been tried, and there is nothing fundamentally wrong with
->the idea.  The biggest reason for lack of popularity is that it doesn't help
->much with the code generated for typical existing high-level langauges; they
->often don't provide convenient access to bit-level data, so applications are
->coded to access data in larger chunks and pick it apart themselves.
-Of course, high-level languages which provide convenient access to bit-level
-data have been tried occasionally, and haven't been very popular.  The
-biggest reason for this is that popular machine architectures don't provide
-efficient access to bit-level data, so applications are coded to access data
-in larger chunks and pick it apart themselves.

No, the IMPLEMENTATION would do the work in that case.  Although it
amounts to the same thing at the nitty-gritty level, assuming the
particular hardware doesn't support bit operations, it makes
application programming much nicer.  And, when compiled on a machine
that DOES have bit operations, the object code runs much faster.

This vicious circle of cause-and-effect needs to be broken somehow.
The fact that there are several application areas that could benefit
(as I listed earlier) should be sufficient reason to try.