回信： [openrisc] Huffman encoding operands

[jimmy87@sunplus.com.tw]

DOOLITTLE said:
I disagree.  Instruction set compression (not necessarily Huffman)
is a good thing, we all know, as it reduces memory bandwidth, and
increases (fixed size) cache effectiveness, at the expense of slightly
more complex instruction decoding.  And yes, you can compress operands.

The mechanism used by all compression techniques is to hold some state
across symbol boundaries.  In particular, to avoid Damjan's objection
to hard-coding r9 in the ISA, define a new register "C", which is not
encoded in each individual instruction, but is part of the processor
state.  Add one more instruction so the program can change the 4-bit
value of C.  Now you can build infrequently used instructions (that
therefore have a lot of op-code bits) that refer to rC (thereby saving
insn bits), and you don't lock it into a particular register.
    h.configrC <4-bits>
^^^^^^^^^it's 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.
-------------



There is great value in sliding the boundary between hardware and
software support around to its most economical location.  For instance,
you shouldn't demand that stock gcc generate a beautiful and efficient
strcpy, and sweat blood on the compiler and ISA front to make it happen.
Instead, just make sure the hardware can do it, and write a few lines
of in-line assembler to do it.  For a canonical list of operations that
need support in that manner, look at Linux's
   /usr/include/asm/{atomic,bitops,checksum,string}.h
It's helpful to put in weird instructions, that these macros can use,
even if gcc itself never generates them.

   - Larry Doolittle  <LRDoolittle@lbl.gov>
^^^^^^^^^
YES!!! that's what I mean before. Weird insns really could help
a lot in some critical programs.


-----------
P.S. To get really exotic, you could set rC automatically.  On every
instruction (compressed or not), set the 4-bit value that identifies
rC to be the destination register (if such a concept makes sense).
Now these compressed instructions would, by default, use the value
that was just computed.  OTOH, slip h.configrC into the instruction
stream, and you can perform the general case.  Hey, h.configrC is
itself no longer a special instruction, it's just h.or rA,0 !
^^^^^^^^^ we need have extra 4-bit vacancy. Besides, rC's loading would be
very large if we want it to do ALU operations/MAC operations and etc.
But I think it's a good idea :)
Best regards, Jimmy