Re: [openrisc] Huffman encoding operands

[Larry Doolittle <ldoolitt@recycle.lbl.gov>]

John Leuner <jewel@pixie.co.za> wrote:
> ... suggest hardware facilities to compress data in normal memory.
> I've read an excellent paper on the topic by Scott Kaplan, if you're
> interested have a look at:
> "The Case for Compressed Caching in Virtual Memory Systems" at
> http://www.cs.utexas.edu/users/sfkaplan/papers/compressed-caching.ps.gz

Nice paper.  Thanks for the reference.  If the ISA is suitably designed,
compressing code pages will be ineffective :-) .
My particular interest in or1k is not served by page compression,
but exploration of that technology is certainly something that or1k
can facilitate, and that's great.

Jimmy <jimmy87@sunplus.com.tw> wrote:
>  [ h.configrC <4-bits> is ] similar to the insn lwpai*/swpai*/etc
> that uses PAIR (post address increment register).
> It's a good idea. This specific register still has one problem that
> we must first use mtsr and do some ALU operations and then mfsr again.
> So, if we hardcoded it into register file, maybe we don't need to
> use mtsr/mfsr. But auto address increment is good to our means.
> Besides, MAC insns have that property, too.

That is a different case.  The register file model of or1k (correct me
if I'm wrong) is two-read one-write per cycle.  A few instructions,
(autoincrement, mult, div, and mod, maybe more) don't fit with that
concept.  They need additional hardware registers to support them
efficiently (alternatively, they could be multi-cycled).

What I suggest is to label one of the 16 registers in the file for
instruction use, that is not selected in the ordinary way (taking
up 4-bits of code space).  Rather, it's label is part of the processor
state, that is set either implicitly or explicitly by the program.
To the extent that the program uses the same register repeatedly,
you have now compressed redundant bits out of the code stream.
I think in the particular case of remembering the previous destination
register, and using that as a default source register (at least for
some instructions) this could be effective.

Damjan <lampret@opencores.org> wrote:
> Sure you can compress almost everything. But I am just afraid we will add
> too much complexity to the architecture.

A legitimate concern, of course.  When we have filled up all of the XCV50
and the processor benchmarks as fast as possible, we are done. :-)

      - Larry Doolittle  <LRDoolittle@lbl.gov>