Re: why bits, Byte Addressability And Beyond

On Tue, 7 May 2024 06:35:53 -0000 (UTC)
"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> wrote:

MitchAlsup1 wrote:
 

John Levine wrote:
 

According to John Savard  <quadibloc@servername.invalid>: 

On Mon, 6 May 2024 02:54:11 -0000 (UTC), John Levine
<johnl@taugh.com> wrote:
 

Why do you think bit addressing will be
faster than shifting and masking? ... 

 

So just because a processor has a 64-bit bus to memory doesn't
mean it has to implement fetching a single byte from memory by
doing a shift and mask operation in a 64-bit register. Instead,
each byte of the bus could have a direct wired path to the low
8-bits of the internal data bus feeding the registers. 

 

I was more thinking about storing bit fields, where you probably
have to fetch the whole word or cache line or whatever, shift the
new field into it, and then store it back. You already have to do
something like that for byte stores but bit addressing makes it 8
times as hairy. 

 
Which is no different than ECC, BTW...
 
Could someone invent a bit field ISA that was as efficient as a byte
accessible architecture:: probably.
 
Could this bit accessible architecture outperform a byte ISA on
typical codes:: doubtful. Two reasons:: 1) more delay in the LD/ST
pipeline, 2) most programs use as little bit-fielding as possible
(not as much as practical) !!! 

 
 
Some time ago, I proposed an additional instruction, a load varient
that allowed you to address bit fields.  Would it be slower than a
"normal" byte oriented load?  Almost certainly.  But would it be
faster than doing all the shifts, masks, word crossing calculations,
etc. via extra instructions?  Again, almost certainly.  So you keep
the benefits of byte oriented loads most of the time, but have
"reasonable" access to bit fields when you need them, faster than
without the extrainstructions.  Hopefully the best of both worlds.
 
 
 
 

When you load bit field from memory, there is very high chance that you
would want adjacent bit field soon thereafter.
Think about it.