Path: ...!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: "Mini" tags to reduce the number of op codes
Date: Thu, 11 Apr 2024 12:22:47 +0200
Organization: A noiseless patient Spider
Lines: 50
Message-ID: <uv8dlo$1krvp$1@dont-email.me>
References: <uuk100$inj$1@dont-email.me>
 <lf441jt9i2lv7olvnm9t7bml2ib19eh552@4ax.com> <uuv1ir$30htt$1@dont-email.me>
 <d71c59a1e0342d0d01f8ce7c0f449f9b@www.novabbs.org>
 <uv02dn$3b6ik$1@dont-email.me> <uv415n$ck2j$1@dont-email.me>
 <uv46rg$e4nb$1@dont-email.me>
 <a81256dbd4f121a9345b151b1280162f@www.novabbs.org>
 <uv4ghh$gfsv$1@dont-email.me>
 <8e61b7c856aff15374ab3cc55956be9d@www.novabbs.org>
 <uv5err$ql29$1@dont-email.me>
 <e43623eb10619eb28a68b2bd7af93390@www.novabbs.org>
 <S%zRN.162255$_a1e.120745@fx16.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 11 Apr 2024 12:22:48 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0e068abbfdc66e7dff6ecc0805f42343";
	logging-data="1732601"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX199ym5o3OwEM43kvadG0Jyoz/YpkIpK6+6ex35wgbDyFg=="
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:OJqPNAsfGAYGSA/3XripfH4E2mk=
In-Reply-To: <S%zRN.162255$_a1e.120745@fx16.iad>
Bytes: 3512

Scott Lurndal wrote:
> mitchalsup@aol.com (MitchAlsup1) writes:
>> BGB wrote:
>>
>>> On 4/9/2024 7:28 PM, MitchAlsup1 wrote:
>>>> BGB-Alt wrote:
>>>>
>>
>>> Also the blob of constants needed to be within 512 bytes of the load
>>> instruction, which was also kind of an evil mess for branch handling
>>> (and extra bad if one needed to spill the constants in the middle of a
>>> basic block and then branch over it).
>>
>> In My 66000 case, the constant is the word following the instruction.
>> Easy to find, easy to access, no register pollution, no DCache pollution.
> 
> It does occupy some icache space, however; have you boosted the icache
> size to compensate?

Except it pretty rarely do so (increase icache pressure):

   mov temp_reg, offset const_table
   mov reg,qword ptr [temp_reg+const_offset]

looks to me like at least 5 bytes for the first instruction and probably 
6 for the second, for a total of 11 (could be as low as 8 for a very 
small offset), all on top of the 8 bytes of dcache needed to hold the 
64-bit value loaded.

In My 66000 this should be a single 32-bit instruction followed by the 
8-byte const, so 12 bytes total and no lookaside dcache inference.

It is only when you do a lot of 64-bit data loads, all gathered in a 
single 256-byte buffer holding up to 32 such values, and you can afford 
to allocate a fixed register pointing to the middle of that range, that 
you actually gain some total space: Each load can now just do a

   mov reg,qword ptr [fixed_base_reg+byte_offset]

which, due to the need for a 64-bit prefix, will probably need 4 
instruction bytes on top of the 8 bytes from dcache. At this point we 
are touching exactly the same number of bytes (12) as My 66000, but from 
two different caches, so much more likley to suffer dcache misses.

Terje


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