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

[Jacob Lifshay]

On Sun, Dec 13, 2020, 13:53 Alexandre Oliva <oliva at gnu.org> wrote:

> On Dec  8, 2020, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
>
> > On 12/8/20, Alexandre Oliva <oliva at gnu.org> wrote:
> >> On Dec  7, 2020, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
> >>
> >>> i did find it odd that there's no 16-bit imm instructions,
> >>
> >> Sorry, I failed to mention that they're not implemented yet.
>
> > lol that would do it.  addi is the higher end of the opcodes used.
> > although not being able to use it unless already in 16bit mode, this
> > is very inconvenient.
>
> I'm trying to implement the remaining opcodes now, but getting all
> confused by the mismatches between the bit widths and range of values
> supposed to be encoded:
>
> | 0 | 1  | 2 | 3 4 | | 567.8 | 9ab  | cde | f |
> | 1 | 1  | 1 | i2  | | 001.0 | RA!=0| imm | 1 | addis
> | 1 | i2           | | 010.0 | RA!=0| imm | 1 | addi
>
> * addi is EXTS(i2||imm) to give a 4-bit range -8 to +7
> * addis is EXTS(i2||imm||000) to give a 11-bit range -1024 to +1023 in
> increments of 8
>
> I suppose the bullets are lagging behind encoding updates, because:
>
> - I count 5 bits for addis; if signed, that's enough for -16..15
>
> - I count 7 bits for addi.  With a left-shift by 3, that makes for a
> 10-bit range.
>
> If these were to be used the way I would conceive of them, the ranges
> would be complementary, so that a pair of these insns could encode 12
> bits.
>

I wouldn't necessarily have them match up since there is always the 32-bit
instruction that can specify 16-bits of immediate, the 32-bit instruction
is preferred over 2 16-bit instructions in 99% of cases.

Jacob