[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 #13 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #12)
> (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.

i read it again last night and it seems it does sit "on top" of what was v2.06
BE 32 bit ISA at the time.

ie it is the PowerISA direct equivalent of RVC.  the only weirdness is that
some entirely new 32 bit encodings (extensions of 16 bit to give slightly
longer immediates) were added.


> 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 

yes.  the only extra one would be bank-switching.


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

really? ha! then out they go.  it may be possible to drop in bc after all. 
have to check.


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

this is best discussed on the predication sv issue, and we can come back here
after.  context/reminder: PowerISA is fundamentally designed to make
data-dependent decisions based around CRs.


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

again, let's transfer this to the sv predication issue.

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

yes.  this is in the 10bit mode.  i couldn't think what to do with the 16 bits
so went "err let's add RT".

now i am just realising the 3 bits could be used for size or rounding modes,
particularly for FP and *maybe* LD. and cmp it looks useful.

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

i added some for 16bit mode.

> 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]\)

niice.

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