Re: why bits, Byte Addressability And Beyond

Stephen Fuld wrote:

Terje Mathisen wrote:
 

Michael S wrote:

On Wed, 8 May 2024 14:25:15 +0200
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
>

Michael S wrote:

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.

>
Which means that you would like to have a dedicated streaming
buffer cache for the EXTR operation?
>
Terje
>
>

>
That not what I wanted to hint to Stephen.
I wanted to hint that in typical situation, i.e. when one 32-bit or
64-bit load serves several bit field extractions, his additional
instruction would be slower rather than faster than existing
practice.
>

>
Yeah, as I wrote earlier, i my own code I tend to use a register as
my buffer and keep it bottom-aligned at all times, i.e. end each
extraction by a SHR buffer, token_len
>
This means that most of the time, the buffer reg already contains all
the bits of the next token.

  The key word being"most".  If it isn't "always", you have to test for
the condition.  That test, and the conditional branch reduces, and
perhaps eliminates the advantage.

It was exactly these kinds of optimizations I made in order to double the speed of Intel's reference BluRay decoder. However, instead of asking me to write a complete version they decided to licence a piece of VLSI to do it in hardware, and that was almost certainly the correct decision since my code needed 4 cores working nearly 100% in order to handle the highest possible size/speed quality (1080p, 60 Hz, CABAC encoding and 40 Mbit/s bitrate).
With a hw decoder a laptop can show film for hours on battery power.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"