[Libre-soc-bugs] [Bug 238] POWER Compressed Formal Standard writeup

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=238

--- Comment #12 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #7)
> (In reply to Jacob Lifshay from comment #4)
> 
> > > i am currently just arbitrarily experimenting, there's no backup studies
> > > to show statistical preference for one combination over another, here
> > 
> > Yeah, we need to at least check instruction statistics on some integer code.
> 
> i planned ahead, here, and asked on openpower-hdl-cores at the beginning
> of the year.  someone very kindly responded.
> > > * System sc/rfid
> > 
> > What are system instructions doing in 16-bit mode?!!
> 
> i don't know!  they're in VLE! :)

I haven't looked at the spec for VLE, but if it's like ARM's Thumb1 ISA where
32-bit instructions aren't supported, then you do need sc. We are planning on
an ISA more like RISC-V's C extension where all it does is add shorter forms of
already existing instructions and the longer instructions are still supported,
so we don't have to support the less commonly used instructions, unlike Thumb1. 

>  and as they are "obscure bitfields"
> that take up things i can't think of how to use with registers i went,
> "mmm let's see".  if however there's a way to encode a register in that
> space then yes.  if dropping both sc and rfid then a 1-reg operation
> could use that and the rest of bits "8 9 a" to indicate which reg.
> 
> > they should be 32-bit
> > only, they are very uncommon (with the possible exception of m[ft]ctr,
> > m[ft]lr
> 
> for branches etc.  hence why i added m[ft]tar as well.

Since tar is only usable from privileged mode, it will make m[ft]tar and btar
into very uncommon instructions, since compilers most likely won't ever use
them unless you explicitly ask for it using either intrinsics or assembly.

> 
> > and maybe m[ft]cr).
> 
> m[ft]cr if used for predication will become much more common.

Even if we use CR regs for predication, I think using instructions that have
only 1 bit per element in integer regs instead of the 4 bits that mfcr uses
will be much more commonly used. Similarly for mtcr.

> > > LD i wanted to reserve the 2 spare bits for width, update and other modes.
> > 
> > it will require some stats, but I think update can be left for 32-bit only.
> 
> ok.
> 
> > 
> > Some other instructions that should be 32-bit mode only are the less
> > commonly used CR instructions, only a few of them are commonly used. 
> 
> except if CRs are used for predication, in which case the ones that transfer
> them in and out of integers, as well as do some basic operations, become
> a much higher priority.

Hence why you support just and, or, andc, and maybe xor, since you rarely need
most of the others, even if using them for predication. if you need a less
common op, use a 32-bit instruction, they're not that expensive.
> 
> > You can
> > probably cram a addi instruction in there instead, those are very common,
> > and it can double as mv.
> 
>     | 0 1 | 2 3 4 | | 567 | 8 9 a | b c d | e | f |
>     |     |  RT   | | 010 | RB    | RA!=0 | 0 | 1 | add
>     |     | offs  | | 010 | RA    | 0 0 0 | 0 | 1 | addi

Works better if you have nearly all 16/10-bit instructions use one register for
both source and destination (like x86 and RVC) instead of using an extra 3 bits
to encode the third register.

addi is common enough that you'd want to dedicate some extra encoding space to
it.

Some stats:
generated using (on ppc64le):
objdump -d --no-show-raw-insn /bin/bash | sed 'y/\t/ /;
    s/^[ x0-9A-F]*: *\([a-z.]\+\) *\(.*\)/\1 \2 /p; d' |
    sed 's/\([, (]\)r[1-9][0-9]*/\1r1/g;
    s/\([ ,]\)-*[0-9]\+\([^0-9]\)/\11\2/g' | sort | uniq --count |
    sort -n | less

...
    25 ldu r1,1(r1)
...
    207 stdu r1,1(r1)
    225 std r0,1(r1)
    284 mflr r0
    285 add r1,r1,r1
    304 lbz r1,1(r1)
    326 mtlr r0
    327 ld r0,1(r1)
    343 blr
    406 lwa r1,1(r1)
    466 extsw r1,r1
    649 stw r1,1(r1)
    691 lwz r1,1(r1)
    705 cmpdi r1,1
    791 cmpwi r1,1
    794 addis r1,r1,1
   1474 std r1,1(r1)
   1846 li r1,1
   2031 mr r1,r1
   2473 addi r1,r1,1
   3012 nop
   3028 ld r1,1(r1)

-- 
You are receiving this mail because:
You are on the CC list for the bug.