Re: why bits, Byte Addressability And Beyond

On 5/6/24 3:13 PM, MitchAlsup1 wrote:

John Levine wrote:
 

According to Lawrence D'Oliveiro  <ldo@nz.invalid>:

On Sat, 04 May 2024 15:21:04 GMT, Scott Lurndal wrote:
>

d) all modern major architectures have instructions for bitfield
manipulation (insert, extract) obviating any need for general bit-level
addressing.

>
Even if those bottom three bits of the address must be zero in every other instruction but these, I thought it would be convenient to have them, just for these bitfield instructions. It would save passing around a separate bit-offset field in arbitrary-bit-aligned pointers.

 

The only significant application for bit addressing that anyone has
mentioned is data compression. It's not something that computers spend
a great deal of time doing, and I see no reason to believe that bit
addressing would make it much faster than the way it's done now with
shifting and masking.

 

If you do want to make compression faster, it'd make more sense to add
instructions to do the compressing you compare about, like DFLTCC in
S/360 and zSeries that speed up gzip, rather than adding three bits to
the other 99% of instructions that don't use bit fields.

 

If you think otherwise, what are the applications that will make all
those address bits useful, and why do you think bit addressing will be
faster than shifting and masking? There's still going to be memory
underneath that's byte or word addressed so the shifting and masking
is going to happen anyway.

 Placing bit-field access INSIDE LDs and STs requires adding 2 stages
of multiplexing in the LD/ST aligners (memory shifters). This has the
potential to slow the overall pipeline frequency--at which point you
have lost more than you can gain.

The extra shifting could be applied only for bit-granular
accesses, so byte-granular accesses could have normal latency.
(Bit-field loads would have higher latency.)
I think some Sun SPARC implementation did something similar with
sign extension, presumably to minimize latency for full-size and
unsigned loads (load latency being more important for in-order
designs). The slow double-load method of handling unaligned word-
crossing loads seems similar (if word-crossing loads are rare,
this might be acceptable) — in this context "word" might be cache
bank width not register width or legacy size (such as 16-bit for
x86 or 32-bit for many 64-bit RISCs).
In theory, one could have all shifted accesses have higher
latency. (One might be able to have word-aligned sub-word loads be
similarly fast. Unsigned loads would be easier, but using carry
propagation delay to hide sign extension delay might be
practical.) I suspect such is highly theoretical. (ECC word size,
for ECC-protected data, would also affect the need for read-
modify-write for smaller accesses; i.e., store latency and even
cache bandwidth can depend on size. Mini-caching ECC words might
be useful.)
Variable load latency would presumably increase forwarding
complexity, which might hurt frequency.
Since cache accesses are more expensive than extractions, one
might feel that multiple values should be extracted from a single
load. Such an optimization might be applied at cache block size
(e.g., 64B) and/or at cache bank size (e.g., 16B). This might have
an impact on the interface for accessing memory for smaller
values. (For register-size loads, software could sometimes merge
smaller loads into a single register when operations in the lower
part do not overflow into upper parts, but this might cost extra
shift operations to align both operands.)