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

Groups > comp.arch > #118191

Re: Really compressed instruction streams

Show all headers | View raw

On 9/24/2026 5:17 PM, MitchAlsup wrote:
> 
> Thomas Koenig <tkoenig@netcologne.de> posted:
> 
>> 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.
> 
> Pitfalls...
>   

Yes.

Fixed length: Cheapest;
16/32: Affordable;
Variable Bytes: Expensive;
Variable Bits: Impractical.

Often, one can get part of the way to the results of a more expensive 
solution by being more clever with the cheaper solution.


The stronger tools may seem like magic, but they don't come free.



>> 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.
> 
> Realistically, adding 3-or-4-bits to IP (or equally restricting
> IP to 60-DoubleWord address-bits would allow bit indexing at
> FETCH.
>   

If the bit lengths are variable, branch displacements and relocs are 
going to be straight up evil.


>> For example, one could make the Icache into a micro-op-store
>> and decode on fetching from L2.
> 
> What happens when somebody (ld.so) writes into code space ??
> What happens when SSD writes into code space ??
>   
>> Branch targets could then be in the form block,instruction in
>> block.
> 
> Or bit addresses (see above) and leave out blocks altogether.
> 
>>          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.
> 
> Packet and trace caches have this problem. After building a
> packet-cache (1991) and seeing the instruction density (60%
> filled and less than 1/2 as dense as normal instruction
> cache--I decided to go a different direction for my current
> 6-wide machine.
>   
>> One would also have to look at PC-relative branches; these
>> would probably become block-relative + instruction in block.
> 
> Bit addressing solves this, too !!
>   
>> Writing binutils for this kind of architecture would be fun,
> 
> For a perverse definition of "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.
> 
> Imaging the poor guy trying to debug::
> 
>       ADD  IP,R7,#1234567
>   

Looks at hex dump of memory: White noise.

Branch goes wrong: White noise.
Or, if you compression is good enough, the instruction stream looks like 
something plausible, but completely wrong. Like if an LLM hallucinated 
ones' disassembler output.


>> The ISA to be compressed would not be limited by having to
>> fit into a container determined by byte or word sizes.
> 
> Not at all--see Mill.
> 
>> 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?

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