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

Groups > comp.arch > #118187

Re: Really compressed instruction streams

Show all headers | View raw

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