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

Groups > comp.arch > #118222

Re: Really compressed instruction streams

Show all headers | View raw

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?

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

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 ??

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 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.
 

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