[Libre-soc-dev] v3.1B prefix
programmerjake at gmail.com
Sun Dec 13 22:03:02 GMT 2020
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
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.
More information about the Libre-soc-dev