Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #118225

Re: Really compressed instruction streams

Show all headers | View raw

On 9/25/2026 5:59 PM, MitchAlsup wrote:
> 
> BGB <cr88192@gmail.com> posted:
> 
>> On 9/25/2026 10:46 AM, Stefan Monnier wrote:
>>>> So, the idea of using actual compression seems interesting.
>>>> This has been tried in the past, but it didn't catch on.
>>>
>>> There are different levels at (and ways in) which compression can be
>>> applied, with very different tradeoffs.
>>>
>>> E.g. I remember an article years ago (maybe from ETHZ?) doing
>>> compression on bytecode where common sequences of bytecode were turned
>>> into something akin to "functions", IOW a kind of "common sub-expression
>>> elimination" that's also reminiscent of LempelZiv.  The result was
>>> compressed bytecode executable "without decompression".
>>>
>>
>> BGBCC often does something similar with prologs and epilogs:
>> If more than a certain number of registers are saved/restored, the
>> sequences are folded off and then a call/branch is used to do the actual
>> bulk save/restore.
>>
>> Luckily, works regardless of ISA.
>> Don't want to go too small though for the limit, or else it may reduce
>> performance and/or make code density worse (if very small).
>>
>> So, a usual cutoff is around 6 or 8 loads/stores (or 12 or 16 registers
>> if one has Load/Store Pair).
> 
> How does the hardware recognize that this sequence of STs (prologue)
> or LDs (epilogue) are using a dense set of addresses so that one only
> needs to access the tag once (or twice) instead of (12-16) times?
> 

Load/Store Pair gets it down to 6/8 ...

I guess in theory a CPU could recognize that pairs of LDP/SDP 
instructions are, say, actually LDQ/SDQ operations. Though, this would 
mean a 256 bit memory port, and needing to move 4 registers at a time. 
This wouldn't really work with a 4R2W or 6R3W register file with 64-bit 
ports though.

Well, or add special instructions, assuming the CPU has the register 
ports to make it happen.


Could in theory work if one did a register file as 4R2W 128-bit (then 
with some trickery to support 64-bit operations). I once looked into 
this, but noted that a 4R2W regfile operating 2-wide with 128-bit ports 
(but faking 64-bit operations at the register-port level) would give 
worse performance on-average than a 6R3W regfile with 64-bit ports for 
64-bit operations (would mostly make sense if the goal was more 
specifically to try to build a SIMD monster with a 256 bits/cycle 
throughput or similar).

Ironically, wouldn't really need to change the ISA for this, though it 
would have effects on the compiler's instruction shuffling/scheduling 
heuristics.


> How does the hardware recognize that this sequence stays all within
> one page and thus one TLB hit suffices for 12-16 memory references ??
> 

Dunno. Likely the absence of TLB misses would imply a hits by extension.


> And if performed with Call/Return semantics, how do non-memory instructions
> get through the Decoder and into Reservation Stations--while those strings
> of memory references get performed ??
> 

FWIW, with an in-order pipeline, I explicitly don't allow anything to 
co-execute with branch style instructions. With OoO, dunno. Probably 
need some way to create a barrier to separate between the pre-branch and 
post-branch parts of the pipeline so that if a branch mispredict happens 
one isn't "up a creek".


> Instead, if one uses ENTER/EXIT, one address calculation satisfies many
> accesses, one TLB lookup satisfies all those accesses, and the cache tag
> is only accesses once (or twice).
> 

You do however, need a mechanism to orchestrate these sub-tasks, vs just 
using a naive instruction sequence.

Can also note that ARM32 had LDM/STM, but ARM64 explicitly dropped to 
Load/Store Pair.

Went and checked before, seemingly Load/Store Pair is safe, as the way 
it works in XG2 and XG3 is effectively covered by prior art established 
by SPARC.


Then again, can also note that seemingly most of the ARM64 cores are 2 
or 3 wide, so would likely face the same issue as above.

Seemingly, going 4-wide (or wider) mostly being a thing in PC/server 
class processors.


> You also get the ability to scoreboard all the registers being written,
> scoreboard all the registers being read, read the return address before
> reading the preserved registers, and begin fetch before all the loads
> have been performed.
> 
> And, ENTER is only 1 32-bit instruction without any flow control while
> EXIT is 1 32-bit instruction with flow control faster than data access.
>   

Using a call or branch for a reused Load/Store blob, while not free, 
does at leas not ask anything special from the CPU...

Like, the compiler then is the only one that needs to care (and the CPU 
can remain dumb).

...


Then again, thinking about it more, would maybe be interesting if there 
were some way to (somehow) cram an instruction-level LZ decompressor 
into the I$.

Hard thing would be trying to figure out some way to make it play well 
with interrupts (and would need to somehow deal with potentially 
multiple independent locations per-cycle).

...

Back to comp.arch | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Really compressed instruction streams Thomas Koenig <tkoenig@netcologne.de> - 2026-09-24 20:04 +0000
  Re: Really compressed instruction streams MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-24 22:17 +0000
    Re: Really compressed instruction streams BGB <cr88192@gmail.com> - 2026-09-24 18:00 -0500
    Re: Really compressed instruction streams scott@slp53.sl.home (Scott Lurndal) - 2026-09-25 14:39 +0000
      Re: Really compressed instruction streams cross@spitfire.i.gajendra.net (Dan Cross) - 2026-09-25 20:53 +0000
      Re: Really compressed instruction streams antispam@fricas.org (Waldek Hebisch) - 2026-10-05 23:10 +0000
        Re: Really compressed instruction streams John Levine <johnl@taugh.com> - 2026-10-06 02:46 +0000
  Re: Really compressed instruction streams quadibloc@invalid.com (John Savard) - 2026-09-24 22:37 +0000
    Re: Really compressed instruction streams MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-25 00:37 +0000
      Re: Really compressed instruction streams scott@slp53.sl.home (Scott Lurndal) - 2026-09-25 14:42 +0000
  Re: Really compressed instruction streams Robert Finch <robfi680@gmail.com> - 2026-09-24 20:56 -0400
    Re: Really compressed instruction streams Thomas Koenig <tkoenig@netcologne.de> - 2026-09-25 18:56 +0000
  Re: Really compressed instruction streams Michael S <already5chosen@yahoo.com> - 2026-09-25 11:54 +0300
    Re: Really compressed instruction streams Thomas Koenig <tkoenig@netcologne.de> - 2026-09-25 15:05 +0000
  Re: Really compressed instruction streams Michael S <already5chosen@yahoo.com> - 2026-09-25 17:39 +0300
  Re: Really compressed instruction streams Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-25 11:46 -0400
    Re: Really compressed instruction streams BGB <cr88192@gmail.com> - 2026-09-25 16:09 -0500
      Re: Really compressed instruction streams MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-25 22:59 +0000
        Re: Really compressed instruction streams BGB <cr88192@gmail.com> - 2026-09-25 18:51 -0500
          Re: Really compressed instruction streams scott@slp53.sl.home (Scott Lurndal) - 2026-09-28 15:26 +0000
            Re: Really compressed instruction streams BGB <cr88192@gmail.com> - 2026-09-28 17:42 -0500
      Re: Really compressed instruction streams BGB <cr88192@gmail.com> - 2026-09-26 03:21 -0500
    Re: Really compressed instruction streams Paul Clayton <paaronclayton@gmail.com> - 2026-09-27 21:12 -0400
      Re: Really compressed instruction streams BGB <cr88192@gmail.com> - 2026-10-01 15:42 -0500

csiph-web