[Libre-soc-dev] v3.1B prefix

[Luke Kenneth Casson Leighton]

thanks for this alexandre.  i'm running with a disasm of /bin/bash,
there's some anomalies:

Summary
32-bit uncompressed instructions: 222369
16-bit compressed instructions: 18300
16-imm compressed-mode instructions: 0
10-bit compressed instructions: 21141
10-bit mode-switching nops: 7776
10-bit mode-switching nops for imm-16: 0
16-bit mode-switching nops after imm-16: 0
Compressed size estimate: 983910
Original size: 1047240
Compressed/original ratio: 0.945640

also by changing the numbering to this:
# It must contain 0 for proper working of at least storex.
cregs3 = { 0, 31, 30, 1, 2, 3, 9, 10 }
# Ditto in a 2-bit mapping.  It needs not contain 0, but it must be a
# subset of cregs3 for proper working of at least storex.
cregs2 = { 1, 2, 3, 9 }

i get this:
Compressed/original ratio: 0.939527

i found the top-used regs with this:
cat bash_disasm.txt | python3 ./insn-histogram.py > table.txt

although... that's the top *total* regs which is not the same as the
"top regs used by the top instructions".

i did find it odd that there's no 16-bit imm instructions,
particularly that the distribution of addi for example is as follows:
      1373 2-bit
      1836 14-bit
      2335 7-bit
      2783 6-bit
      6468 15-bit
      6991 1-bit
     22325 0-bit

surely there should be *one* addi after one other instruction that has
gone into 16-bit mode?

ah: found a sequence:

   2f770:   ori     r0,r0,0 ; 10-bit
   2f774:   b       2f670 <main@@Base+0x9d0>    ; 16-bit
   2f778:   addi    r10,r10,8
   2f77c:   ori     r0,r0,0 ; 16-bit auto-back, vs 10-bit
   2f780:   extsw   r4,r10

that addi r10,r10,8 should definitely fit, and the extsw too... errr
oh wait, no: no room for r4.

still: this is very much along the lines of, "wtf".

l.