Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Terje Mathisen <terje.mathisen@tmsw.no>
Newsgroups: comp.arch
Subject: Re: why bits, Byte Addressability And Beyond
Date: Wed, 8 May 2024 14:25:15 +0200
Organization: A noiseless patient Spider
Lines: 64
Message-ID: <v1fqvb$3ushi$1@dont-email.me>
References: <v0s17o$2okf4$2@dont-email.me> <v19f9u$2asct$1@dont-email.me>
 <v19goj$h9f$1@gal.iecc.com> <5r3i3j58je3e7q9j2lir1gd4ascsmumca2@4ax.com>
 <v1bgru$jo2$1@gal.iecc.com>
 <6d6fa399e0f5dd481125348fa56d8ef8@www.novabbs.org>
 <v1ci49$33ua6$1@dont-email.me> <20240507114742.00003e59@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 08 May 2024 14:25:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a37bdc857cdc0af3199b89eb5b9300a8";
	logging-data="4158002"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+XMJ3fNPM890mQm0Qjl4KkIPt1y+dPAnY6RMYUoZlAUQ=="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.18.2
Cancel-Lock: sha1:+K+mFOrDCyhcRuyEmxJfy2R9Rvk=
In-Reply-To: <20240507114742.00003e59@yahoo.com>
Bytes: 3853

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


-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"