Deutsch English Français Italiano |
<v1gban$2u4c$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!news.mixmin.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 19:04:23 +0200 Organization: A noiseless patient Spider Lines: 86 Message-ID: <v1gban$2u4c$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> <v1fqvb$3ushi$1@dont-email.me> <20240508153648.00005583@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 19:04:23 +0200 (CEST) Injection-Info: dont-email.me; posting-host="db8ec420ad94a4aef27b43c8dfdd9aba"; logging-data="96396"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19HAQcczmVOidOGM4Cw7YSL7OMJ7tScppSwX24h0EtfOA==" 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:9NUkusWsErLxKkHYLYKsQAjUXU0= In-Reply-To: <20240508153648.00005583@yahoo.com> Bytes: 4719 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. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"