🚀 go-pugleaf

I think that it'd be interesting to have bit addressing on a 64-bit machine.

From what i can see, the main problem seems to be C.  I like C a lot, but it
has just enough subtle assumptions that it becomes extremely difficult when
dealing with objects whose size is not a multiple of the size of a character.

I think that some minor changes twenty years ago could have greatly improved
the situation.  There were, for example, popular machines with 36-bit words
and 7-bit characters, and as it stands, C just does not work with that.

On a machine that only loads/stores words, there's basically no difference
between accessing bytes or other small units.  Accessing a field that fits in
a word can be done with one load, updating it takes a load and a store, and a
field that might cross a word boundary takes twice as many loads and stores.
Also in many cases, the compiler can combine operations on the same word.

Even on a machine that supports byte load and stores fine, many memory or
string operations are better done at the word level.  We find that efficient
byte operations become almost identical to the more general bit operations.
Also note that it becomes irrelevant whether data crosses byte boundaries.

Another problem is that there's too much code that plays games with pointers
and will break with bit addressing.  Of course most of this code is crap and
isn't even close to portable.  But on the other hand, there are some things
that seem useful enough that the standard provides absolutely no help for.

Since i don't want to promote non-portable features, and i'm too cynical to
think that C and C programs will be fixed, it's interesting to consider how
bit addressing might benefit programs that don't care about it at all.

Consider that it becomes an artificial distinction to specify some field and
then test or update a bit in it, when you can directly address a specific bit.
Something with many operations in a `high-level' language may become simpler
in machine code, if you can't easily specify what you want in the HLL.

Operations like "p->field |= MASK" or "(p->field & MASK) != 0" are extremely
common in C programs, so any machine designer should consider what they can do
to make these run fast.  Combining the byte offset and bit offset may help.

Of course there is a more clear benefit in anything that deals with bitmaps,
integers with weird sizes packed in memory, or variable-length bit strings.
A good example of something that looks complicated but may end up being quite
simple is the idiom "(((char *)bitmap)[index / 8] & 1 << (index % 8)) != 0".

Note that i'm not saying that machines should have single instructions for
these operations, like the VAX, but it should be possible to do these things
with a minimum of extra steps, while keeping with the load/store paradigm.
Bit addressing may help with this, or you may do just as well without it.

Basically i'd like to decrease the importance of the common unit, eight bits.
It may be convenient for storing European text, or integers with a range of
about a hundred, but it's not so special.  Units of four bits or sixteen bits
are also interesting, and my machine would not support them better or worse.

In article <46e6ge$nf7@engr.orst.edu>
Lawrence Crowl <crowl@jade.CS.ORST.EDU> writes:
>I agree, however, that a large-scale shift to bit addressing is
>unlikely.  I disagree with the characterization that it is useless.

Overall i think that it'd be interesting, it wouldn't be that difficult, and
it wouldn't give enough benefit to convince people to fix their crappy code.

--
Joe Keane, amateur architect