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

Groups > comp.arch > #118207

Re: Really compressed instruction streams

Show all headers | View raw

On Thu, 24 Sep 2026 20:04:24 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

> It seems that the different CISC and compressed instruction sets
> are ad-hoc (and not very good) attempts at compression of the
> actual instructions that machines execute.  Pure RISCS have very
> little compression, RISC-V has some, CISC has some more.  AMD's
> micro-op cache goes some way towards this when it splits
> x86_64 instructions into micro-ops.
> 
> So, the idea of using actual compression seems interesting.
> This has been tried in the past, but it didn't catch on.
> 
> There are a few basic problems to be solved.  One that comes to
> mind immediately is branch addresses.  If the instruction stream
> is compressed, any bit of the compressed stream can start an
> instruction, and calculating the target of a branch instruction
> is not straightforward.  To avoid having to decode the whole
> program, it would be necessary to create blocks of some sort,
> which could be decoded on loading into a suitable cache level.
> 
> For example, one could make the Icache into a micro-op-store
> and decode on fetching from L2.
> 
> Branch targets could then be in the form block,instruction in
> block.  There would have to be an upper limit on the number
> of instructions per block, leading to some waste for easily
> compressible instructions.  Also, instructions which no
> longer fit in a block would reduce the efficieny.
> 
> One would also have to look at PC-relative branches; these
> would probably become block-relative + instruction in block.
> 
> Writing binutils for this kind of architecture would be fun,
> in the sense of absoutely no fun at all.  Object code would
> probably be uncompressed, with the poor guy implementing the
> linker having to do all the dirty work.
> 
> The ISA to be compressed would not be limited by having to
> fit into a container determined by byte or word sizes.
> If one so desired, one could chose an ISA based on any
> bit size, although having instructions based on an n-bit
> package size (with multiples) would still make sense for
> further decoding of the micro-ops.
> 
> Other thoughts?

Last time I gave it a serious thought was more than 5 but less
than 10 years ago. Then I came to conclusion that the only  practical
way for bit-compressed instruction set is "reversed VL-VLIW".
I.e. instruction stream consists of aligned fixed-width chunks, most
likely 256 bit, but 512 bit is also possible if it turns out that 256b
is not enough for good compression. Each chunk carries variable number
of individual instructions. Details of encoding may vary, but probably
based on format header that is placed in fixed position in the chunk
that governs the rest of parsing.

Jumps into the middle of chunk are allowed, jump target is expressed as
a tuple - address-of-chunk:index-of-instruction-in-chunk. For
conditional branches address part is relative and covers limited
distance, may be -256 to + 255 chuncks, similarly to conventional
designs.

I didn't rethink it since then, but I know that I didn't become any
smarter.

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