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

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Sun Nov 15 12:05:20 GMT 2020


--- Comment #7 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(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! :)  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.

> and maybe m[ft]cr).

m[ft]cr if used for predication will become much more common.

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


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

> 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

very challenging / limited.

* maybe bit 1 can be used too, maybe bit 0
* it will only be active in 16-bit mode not 10-bit mode
* with no room for RT it can't act as a mv because it is either
  "set RA=offs" or it is "add offs to RA".

potentially, 1 bit of "8 9 a" could be used to indicate which of those
is to be done (at the expense of sacrificing the range of RA)

one other option (which i am not hugely keen on) is to - haha - copy
the v3.1B "prefix" mode concept and apply 16-bit immediate prefixes
to the following instruction.  given that this makes it a 32-bit
instruction it's like, um, "then use the 32-bit standard PowerISA variant,
duh" :)

i think this (subconsciously) has been why i haven't added any immediate
ops in at all, with the exception of branch.  i'd really like to try
to jam even a limited variant of branch-conditional in there, however
the encoding will be... complicated.

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

More information about the libre-soc-bugs mailing list